Quasis: assignable substitutions?

Mike Samuel mikesamuel at gmail.com
Sat Jun 18 10:53:54 PDT 2011

2011/6/17 Mark S. Miller <erights at google.com>:
> On Fri, Jun 17, 2011 at 1:50 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
>> 2011/6/17 Mark S. Miller <erights at google.com>:
>> > A failed strict assignment throws, and therefore a failed ES-next
>> > assignment
>> > does. So are you sure it does not currently throw? From your expansion,
>> > I'd
>> > expect it does.
>> The SVE of ${x} in the slot expansion variant is
>>    function() { return x; }
>> which silently fails to assign to x when passed a value.
> I see. I think I misunderstood the question.
> In any case, I'd like to propose an alternate slotification you and I have
> talked about:
>     "${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?"

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

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

> --
>     Cheers,
>     --MarkM

More information about the es-discuss mailing list