Comments for It's Actors All The Way Down

Comment on Mutable Objects in Kernel by Implementing Actors in Kernel

Implementing Actors in Kernel — Fri, 17 Feb 2012 04:14:18 +0000

[...] predicates actor? and behavior? are exported. We also create an empty queue for events, using the object-oriented queue implementation shown [...]

Comment on Deconstructing the Actor Model by Implementing Actors in Kernel

Implementing Actors in Kernel — Fri, 17 Feb 2012 04:12:45 +0000

[...] provides a solid foundation on which we will build a simple implementation of the Actor primitives (CREATE, SEND and BECOME). Encapsulated types and first-class environments help express Actor [...]

Comment on Parsing Expression Grammars, part 4 by Ben White

Ben White — Tue, 07 Feb 2012 03:38:52 +0000

Nice article, in particular where you state, “Notice that both of these grammars describe the same language.” Certainly the wikipedia article isn’t very helpful.

I recently encountered this problem while trying to parse statements of the form “a[x].b[y] = c” where left to right associativity is required and the operators have equal precedence.

Comment on Mutable Objects in Kernel by John Shutt

John Shutt — Sun, 22 Jan 2012 20:22:03 +0000

I had to think about this, but (as often happens) eventually decided most solutions are making it harder than it has to be. A straightforward approach is to use strings. Strings have an external representation (a weakness of encapsulated types that I recognized from the outset but didn’t, and still don’t, see an obviously “Right” way to fix). Strings are also immutable (though I see I never even started adding content to that section of the Report).

Comment on Mutable Objects in Kernel by Dale Schumacher

Dale Schumacher — Sat, 21 Jan 2012 16:40:11 +0000

Of course! How could I have forgotten about procedural representation? I presume you mean the technique described in SICP section 2.1.3. Message-passing style, as described in 2.4.3 and elaborated in 3.1.1, uses quoted symbols to implement dynamic dispatch. Since Kernel discourages quoting, what would you recommend we use in place of these symbolic constants?

Comment on Mutable Objects in Kernel by John Shutt

John Shutt — Fri, 20 Jan 2012 21:51:02 +0000

The *other* other structured data type is, of course, the combiner. Using combiners as objects is a standard exercise in Scheme, and I gather past RxRS authors have had that style specifically in mind. Plus, of course, it’s the origin of the claimed analogy between procedures and actors. Oh yes, and in reflective Lisps, from what I understand of them, it’s a standard technique to use procedures as environments.

Comment on Mutable Objects in Kernel by Dale Schumacher

Dale Schumacher — Fri, 20 Jan 2012 15:03:54 +0000

Interestingly enough, that’s one of the points I wanted to make with this article. What other structured types does Kernel offer? Pairs, which have a rich history demonstrating their use in building nearly anything (but with what efficiency). And Environments, which are mutable Dictionaries (think Smalltalk) with a multiple-inheritence chaining mechanism.

I think one of the best things about Kernel’s environments is that mutation is limited to environments to which you have direct access (not just inherited). This supports a copy-on-write semantics which reminds me of JavaScript objects. YMMV.

Comment on Mutable Objects in Kernel by Manuel Simoni

Manuel Simoni — Fri, 20 Jan 2012 14:52:15 +0000

I object to the use of environments as “objects”, even if only internal to the implementation. Why? Environments are more powerful than a mere dictionary (e.g. they have a parent link and special rules governing name lookup). I fear that “let’s use 1st class environments for everything” may become the new “let’s use conses for everything” in Kernel.

Comment on Mutable Objects in Kernel by Dale Schumacher

Dale Schumacher — Fri, 20 Jan 2012 14:38:00 +0000

Thanks for your precision, John.

Operationally, my $set! is the same as your standard version. Only my explanation is less general, focusing only on the “special case” of a single named field.

I considered using make-environment to construct a truly-empy “dictionary” for the object. That’s still a valid implementation choice. In the back of my mind I was considering potential extensions for inheritance. Also, using the local environment was the simplest thing that seemed to work, and (as you said) is relatively harmless.

Typos fixed. Thanks!

Comment on Mutable Objects in Kernel by John Shutt

John Shutt — Fri, 20 Jan 2012 05:03:42 +0000

Neatly done. A few items (most interesting first):

Your $set! does not appear to be less general than Kernel’s built-in version; it should handle compound definiends just fine. Though it seems a worthwhile exercise to implement it here.

In new-queue, the local environment has no initial *local* bindings. It does have plenty of visible bindings, not that they do any harm since the environment is encapsulated so that those who can access it are already able to see its parent environment. Using the local environment brings home the lesson that it’s really an *environment*, in the usual sense.

“indicating that this is causes mutation” (spurious “is”).
“an new (empty) queue” (spurious “-n”).