Design new unified actor & class syntax & implement actor inheritance and support protocol extensions

[plajjan]

Supporting:

• base classes
• override
• implicit self
• implicit __init__
• class vs instance attributes
• protocols (to be tracked in separate issue when the time comes)

[sydow]

This syntax unification seems a great idea. So when this is in the air I would like to mention something that has always disturbed me.

• A class is a template from which we can generate individual instances (objects), which carry their own state and so on... The word "class" gives at least some intuition in this direction.

• An actor is also a template from which we can generate instances with state, but these individuals are more encapsulated, communicate via message passing etc. But the word "actor" for the template definition gives the wrong intuition, and leads thoughts to an individual. Already when I read the first sentence in this bullet point "An actor is ..." I feel that something is wrong. The actors are the instances; when we create three instances of "actor A...", then we have three actors entering the game, but the sentence speaks about the template.

I have been thinking about "async class" for actor templates. From plain classes we generate (passive) objects, from async classes we generate (active) actors. Another possibility would be "actor class".

Just wanted to raise the question...

[nordlander]

On 4 Nov 2022, at 12:44, sydow @.***> wrote:

This syntax unification seems a great idea. So when this is in the air I would like to mention something that has always disturbed me.

• A class is a template from which we can generate individual instances (objects), which carry their own state and so on... The word "class" gives at least some intuition in this direction.

• An actor is also a template from which we can generate instances with state, but these individuals are more encapsulated, communicate via message passing etc. But the word "actor" for the template definition gives the wrong intuition, and leads thoughts to an individual. Already when I read the first sentence in this bullet point "An actor is ..." I feel that something is wrong. The actors are the instances; when we create three instances of "actor A...", then we have three actors entering the game, but the sentence speaks about the template.

I have been thinking about "async class" for actor templates. From plain classes we generate (passive) objects, from async classes we generate (active) actors. Another possibility would be "actor class".

Just wanted to raise the question...

I'm very much in favor of emphasizing the distinction between actor classes and their instances. I think we shouldn't hesitate to use such terminology when we talk or write about actors in Acton.

But I also think there's no obviously best solution to what syntax we should use for that purpose. Saying "async class" conveys too little, in my opinion, as if actors were just a minor asynchronous variant of regular classes. The "actor class" syntax is more accurate, but a bit clumsy as there are no "actor " phrases in the language grammar.

We do have candidates for " class" declarations, though, like "object class" and "value" class" instead of the current "class X (object)" and "class X (value)" forms. Perhaps even "protocol class" or "extension class" could be considered.

But these variants all have the drawback of using more keywords than necessary for stating an unambiguous intent. So maybe the phrases "object X", "value X", "protocol X", "extension X", and "actor X" should also be considered, they are at least consistent -- although with the big caveat that "object" and "actor" means something that creates instances of objects and actors. But even that isn't very controversial, there are other languages whose "module" or "data" declarations take parameters and thereby introduce names that should more accurately be called templates for generating module or data instances.

Be that as it may, however. In our case I think we're trapped between programmer convenience, terminological accuracy and tradition (mostly our Python heritage). The "class" concept is quite deeply rooted and I don't think replacing it with "object" and "value" will be very illuminating. The "protocol" and "extension" declarations carry less tradition, but here programmer convenience might win -- shorter declarations beats accuracy.

Perhaps this is also the case for actors. At least I don't have any problem looking at existing Acton code in this respect. The problems occur when one starts describing what an "actor" declaration really is, and there I think there's no way around the fact that actor declarations must be explained as a "templates", "patterns", "classes" or "generators" of actors. And while it's straightforward to use the word "actor" for a particular actor at run-time, it doesn't hurt to also push the term "actor instance" in those cases.

In the end I don't know what syntax I prefer. While I fully subscribe to the idea of terminological accuracy, we also don't want the syntax to look overly pedantic. The " class" forms are at least systematic but maybe too verbose.

Let's discuss further at our next meeting!

-- Johan

[plajjan]

I agree with almost everything said so far... to emphasize, I think:

• good to use actor classes and actor instances in documentation etc
• actor is better than async class, we are an actor based language so it is natural to define actor classes rather than async classes IMHO
• actor is better than actor class because it is shorter
  • it is technically less correct but meh
• class is better than object class because it is shorter, on the other hand, I think the outcome from yesterdays meeting is that it will be class Foo() from object and then object Foo() is shorter