Object literals

[Stefan Marr]

Hi:

[Richard and James on CC] 

Richard and James started to look into getting object literals to work in SOMns and that lead to some discussions about how they can work.

The first issue Richard noticed is that the object literal grammar isn't straight forward to implement in my recursive descent parser.

Since you guys use quite a different style of parser, I suppose the object literal syntax isn't problematic?

The spec in 5.1.10 says the grammar should be:

`objectLiteral = (identifier, keywordMsg opt) opt, classBody.`

I assume that objectLiteral is legal in place of any primary expression:

`primary = unarySelector | literal | block | parenthesizedExpression.`

In the recursive descent parser, we got the challenge that the grammar requires unlimited look-a-head to work, if I am not mistaken.

Specifically, the issue is with the `keywordMsg` for the superclass constructor/factory method and the ambiguity between a `parenthesizedExpression` expression and `classHeader`, which is part of `classBody`.

Any ideas or suggestions of how that could be resolved would be welcome.

At the moment, it seems to me that support that syntax would require quite extensive changes to the SOMns parser. But, perhaps I am missing something.

The next issue that came up is instantiation semantics of the object literal class.

I would assume that each instantiation of an object literal also creates a separate class.

Is that how it is intended to be?

So, assuming we have something like `Array new: 1000 withAll: [ Object ()() ]`, this would create an array with 1000 fresh objects, and each having a separate class.

I believe this is necessary to preserve isolation between actors. We can't cache the class in the method/AST, because it would break things.

I am pretty sure this is the right way of doing it, but it might be considered surprising on first look.

The next issue that was thought of is lookup semantics inside an object literal.

I am not entirely sure yet whether that's an issue. But, I was wondering whether we might stumble over any surprising issues there that you guys might already have considered.

Thanks and best regards

Stefan

[Gilad Bracha]

Hi Stefan, James, Richard,

First, a big caveat, which is explicit in the Newspeak spec. Section  5.1.10, that defines object literals, begins by noting that they are not implemented.  So anything I have to say here is handwaving. We have not missed them, and because of various worries I've had, were never in a hurry to put them in. I've even considered removing them from the spec. Of course, given that you are looking toward Grace, you probably don't see it that way.  Now, to the substance.

a. We use parser combinators, and so unbounded lookahead was not a concern in principle (though it could slow down the parser which might be a real issue given that it's slow to begin with, and we do things like using it to parse on every keystroke for colorization). I'm open to discussing an alternate notation.

b. Yes, each literal has its class created upon evaluation (spec says that).  The spec doesn't directly speak about the mixin the class' are based on. The intent is that the mixin is shared per source location (but always remember the caveat).

c. I don't think there is anything special about lookup semantics in an object literal. Implementation is a different matter. Essentially, it's like closures on steroids.  One needs a scheme for accessing lexical variables that works everywhere in a class; our implementations only worried about these things inside a method body, but not for superclass clauses, factory methods etc. Also, some serialization schemes don't work well with anonymous constructs like object literals (or class literals, also unimplemented).

Please keep the Ministry of Truth in the loop as you progress.

[Gilad Bracha]

Here is a revised draft spec clarifying these points.

[Ryan Macnak]

On Wed, Feb 8, 2017 at 8:03 AM, Gilad Bracha <gbr...@gmail.com> wrote:

Hi Stefan, James, Richard,

First, a big caveat, which is explicit in the Newspeak spec. Section  5.1.10, that defines object literals, begins by noting that they are not implemented.  So anything I have to say here is handwaving. We have not missed them, and because of various worries I've had, were never in a hurry to put them in. I've even considered removing them from the spec. Of course, given that you are looking toward Grace, you probably don't see it that way.  Now, to the substance.

a. We use parser combinators, and so unbounded lookahead was not a concern in principle (though it could slow down the parser which might be a real issue given that it's slow to begin with, and we do things like using it to parse on every keystroke for colorization). I'm open to discussing an alternate notation.

The spec mentions plans to change the grammar to use braces instead of parentheses to delimit the class header, method bodies, etc. IIRC this resolves an ambiguity in factory messages and presumably would resolve this ambiguity with object literals too.

[Gilad Bracha]

Yes, that's true as well. But we might have an issue with tuples then. Which we can change, which will force a change to blocks, which might be a problem again. 

[Gilad Bracha]

One simple approach is to make the superclass clause mandatory for object literals. I think one can then factor the grammar such that things are manageable. It's a tad verbose, but given how much we've needed it, maybe not a concern?

[Stefan Marr]

Hi Gilad,

Hi Ryan:

Thanks for your comments.

I am also not entirely sure I actually want object literals.

We'll see how it goes.

We might support the necessary infrastructure under the hood for Grace and forgo exposing them in the SOMns syntax for now.

Thanks and best regards

Stefan