Quasis: assignable substitutions?

Mark S. Miller erights at google.com
Sat Jun 18 13:04:34 PDT 2011


On Sat, Jun 18, 2011 at 10:53 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

> 2011/6/17 Mark S. Miller <erights at google.com>:
>
[...]

> >     "${x}" continue to expand to "x", as in the current not-slotified
> > proposal.
> >     "${=x}" expand to
> >     ice9({
> >         get: function() { return x; },
> >         set: function(newVal) { x = newVal; }
> >     })
> > where ice9 freezes the record, the functions within the record, and the
> > prototypes of those functions, since syntactic expansions should not
> > introduce new implicit communications channels. But the point here isn't
> > ice9.
>
> So ice9 unpacks property descriptors to freeze the getter and setter?
> Is that what you mean by "the functions within the record?"
>

The functions above are not actually the getters and setters of any actual
property. They're just the values of the 'get' and 'set' properties of the
record. Forget ice9. If we had <
http://wiki.ecmascript.org/doku.php?id=strawman:const_functions> I would
have just written

    Object.freeze({
      get: const() { return x; },
      set: const(newVal) { x = newVal; }
    })

#-functions or lambdas would be even better, but we don't have any of these
yet. Speaking of lambdas, even after prohibiting "arguments" in the x
position, there's a remaining TCP problem with "this". I think the expansion
should really be:

    Object.freeze({
      get: Object.freeze(const() { return x; }.bind(this)),
      set: Object.freeze(const(newVal) { x = newVal; }.bind(this))
    })

Since we don't have const functions, consider this just a specification
ploy, in the same manner that we qualify the above by saying "As if using
the original values of Object.freeze and Function.prototype.bind.

Since the only TCP problems in JS *Expressions* are "this" and "arguments",
prohibiting "arguments" and binding "this" takes care of all TCP problems.
(If we extend JS to allow statements within expressions, then we'll need to
revisit this issue. Indeed, I would argue that we should only allow
statements in expressions if we chose lambda over arrow functions, in order
to avoid multiplying TCP problems. But that's an argument for another
thread.)

The point about getters/setters is only that the record itself has the form
of (a subset of) the property descriptor of an accessor property, leading to
some useful idioms:

Given a quasiliteral position where a slot is expected, perhaps

    re`(${=x.y}\w)`

to assign the matching capture text to x.y, one could instead do

    re`(${Object.getOwnPropertyDescriptor(x, 'y')}\w)`

which is not only more verbose, it only works if x.y is an accessor
property. Ok, maybe this idiom isn't all that useful ;).


> > This makes ${x} more different from ${=x} which I know you wanted to
> avoid.
> > But it gives ${x}, which is by far the typical case, a simpler semantics
> and
> > a cheaper implementation. With the typical case made this cheap, the
> > atypical ${=x} can afford the extra allocations of a more natural object
> > representation. (And one that's compatible with the property descriptor
> of
> > an accessor property.)
>
> What is the advantage of this representation of a writable slot?
>

It reifies the ability to read vs the ability to write into two separate
methods.

FWIW, it also plays well with the property descriptor representation of
accessor properties. But the above example suggests that this second point
may indeed not be worth much.



>
> What idiom should quasi handler authors use to distinguish a writable
> slot from a read-only slot?
>

The expansion only creates expressions that evaluate immediately to values,
or to read-write slots. If you want to pass a read only slot in a position
where a quasi expects a read-write slot, you could do it manually. Ignoring
freezing issues:

    re`(${ { get: function() { return x.y; }.bind(this) } }\w)`

If there's actually a real need for read-only slots in quasis, then the
absence of syntactic support for this third case is a significant criticism
of my suggested variation of your slotification strawman. Is there?

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110618/293196db/attachment.html>


More information about the es-discuss mailing list