Quasis: assignable substitutions?

Mike Samuel mikesamuel at gmail.com
Sat Jun 18 17:59:45 PDT 2011

2011/6/18 Mark S. Miller <erights at google.com>:
> 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; }
>     })

My mistake.  I assumed that they were property descriptors because I
saw the contextually-reserved keyword "get" and didn't notice there
was no actual property name after it.

>> 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.

Ok, and those methods can be dealt with as separate capabilities.

>> 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?

By read-only slot vs read-write slot I meant

  ${x} is read only
  ${=y} is read-write

I should have phrased that as read-only substitution vs read-write
substitution using the alternate slot spec for SVE.

More information about the es-discuss mailing list