Namespaces as Sugar (was: complexity tax)

[Mark S. Miller]

On Sun, May 25, 2008 at 1:16 PM, Mark S. Miller <erights at google.com> wrote:
> On Tue, May 20, 2008 at 7:02 AM, Mark S. Miller <erights at google.com> wrote:
>> 2008/5/19 Brendan Eich <brendan at mozilla.org>:
>>> On May 19, 2008, at 6:54 PM, Mark Miller wrote:
>>>
>>>> If I could
>>>> have a language with some of the syntactic conveniences of ES4 but
>>>> without ES4's semantics, I'd be quite happy.
>>>
>>> What semantics in particular, can you pick on something specific that's not
>>> in your classes as sugar proposal (rather than have me guess)?


> b) At the property-name level, in order to be able to add additional
> properties to existing objects without breaking existing code that is
> already using those names for other reasons.

> So, although I don't find any of these use-cases compelling, I'd agree
> that #b is at least a real problem, and is the most plausible of the
> arguments for some additional support in a future JavaScript. My next
> message, if I get to it, will be "Namespaces as Sugar". If you agree
> with me that #b is better avoided than solved, feel free to skip it.


                             Namespaces as Sugar


JavaScript already allows non-identifier strings to be used as
property names. However, such non-identifiers cannot be used with the
'.'  syntax, and must be quoted in the object literal syntax, so they
are generally avoided.

ES4 grammar contains the productions

NameExpression ::=
    Identifier
|   NamespaceExpression "::" PropertyIdentifier

NamespaceExpression ::=
    NameExpression
|   StringLiteral

// Used in object literals
FieldName ::=
    NameExpression
|   ...

// Used to access a property
PropertyOperator ::=
    "." NameExpression
|   ...


Good enough. Rather than invent new semantic concepts of Name and
Namespace objects, we could just have these expand into non-identifier
strings consisting of components (typically identifiers) separated by
some kind of path separator string. The most logical choices for path
separator would probably be either "::" or ".". For clarity in this
note, in order to keep the levels distinct, I will use the path
separator "/". Note that my actual preference would be "::".

So, for example, the program

    const meta = "meta";
    const obj = {meta::foo: 3};
    const n = obj.meta::foo;
    obj.meta::foo = 4;

is syntactic sugar for

    const meta = "meta";
    var tmp = {}; tmp[meta+"/foo"] = 3; const obj = tmp;
    const n = obj[meta + "/foo"];
    obj[meta + "/foo"] = 4;

This use of NamespaceExpressions will be familiar from XML. The value
of the NamespaceExpression can be a longer string, allowing us to
refer to long fully qualified names using short locally defined names.

    const nest = "com/fudco/reflect/bar/nest";
    const obj = {nest::foo: 3};

As with XML namespaces, this proposal does not allow namespaces to be
what ES4 calls "open". In other words, namespace-qualified names would
always be explicitly qualified.

The proposal above is *only* for a syntactic convenience. It would not
expand the semantics of the language at all.

-- 
    Cheers,
    --MarkM