Quasis: assignable substitutions?

Mike Samuel mikesamuel at gmail.com
Fri Jun 17 14:42:35 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.

Shouldn't ice9 enumerate all reachable properties from its starting
point and then delete them all?

> 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.)
>
> --
>     Cheers,
>     --MarkM
>


More information about the es-discuss mailing list