Proxies: Additional item for January Agenda
On Jan 9, 2010, at 9:24 PM, Mark S. Miller wrote:
Tom Van Cutsem & I are quite satisfied with the alternate catchall
strawman we have posted as "proxies" at <strawman:proxies. The current state of this strawman reflects all the input we have
received from discussions on es-discuss. It seems to hold up very
well to all the use-case experiments we have subjected it to (as
gedanken experiments we cannot run yet).
I raised a point about [[Invoke]] not being equivalent to [[Get]] and
then [[Call]] due to order of evaluation:
esdiscuss/2009-December/010332
Did you or Tom have more thoughts on this issue? I couldn't find them
in the wiki page.
I do not mean to monopolize the January meeting. But if no one has
more pressing topics, I suggest all of these would also be good
discussion topics for es-discuss between now and the January
meeting. Especially if anyone has any remaining unaddressed
objections to the weak-pointer or proxies strawmen.
We should definitely spend time on proxies and weak references, but
we'll have modules to cover too, with dherman and samth attending.
On Sat, Jan 9, 2010 at 10:43 PM, Brendan Eich <brendan at mozilla.com> wrote:
On Jan 9, 2010, at 9:24 PM, Mark S. Miller wrote:
Tom Van Cutsem & I are quite satisfied with the alternate catchall strawman we have posted as "proxies" at < strawman:proxies>. The current state of this strawman reflects all the input we have received from discussions on es-discuss. It seems to hold up very well to all the use-case experiments we have subjected it to (as gedanken experiments we cannot run yet).
I raised a point about [[Invoke]] not being equivalent to [[Get]] and then [[Call]] due to order of evaluation:
esdiscuss/2009-December/010332
Did you or Tom have more thoughts on this issue? I couldn't find them in the wiki page.
I see the issue. No more thoughts at the present time. To recap, in your example
array[index++].method(--j, ++k)
were proxies reflecting this with a get() trap that was then invoked (as they used it in our original proposal), the get() trap would be called after the index++ side effect and before --j or ++k. The gotten function (or gotten function proxy) would still be called after --j and ++k, but that's besides the point.
In the present proposal, an invoke() trap is only called after all three side effects. The default invoke() trap,
invoke: function(receiver, name, args) { return this.get(receiver, name).apply(receiver, args); },
is defined in terms of the get() trap, emulating this aspect of the earlier proposal imperfectly, since it thus calls the get() trap after all three side effects. The only solution I can think of to this problem is to withdraw the invoke() handler from the proposal, reverting to this aspect of the previous design. If we can convince ourselves we can optimize away the implied extra allocation, this may indeed be best. It certainly makes the proposal simpler. What are your thoughts from the implementation side?
I do not mean to monopolize the January meeting. But if no one has more pressing topics, I suggest all of these would also be good discussion topics for es-discuss between now and the January meeting. Especially if anyone has any remaining unaddressed objections to the weak-pointer or proxies strawmen.
We should definitely spend time on proxies and weak references, but we'll have modules to cover too, with dherman and samth attending.
Modules would be great! But I believe Ihab, due to travel conflicts, has been preparing to present a module proposal for the March meeting, not the January one. Ihab?
There could be some useful overlap with the code.google.com/p/es-lab/wiki/SecureEcmaScript proposal and modules.
The restricted eval (esp #6) could be the core mechanism of a module system.
On Sat, Jan 9, 2010 at 11:13 PM, Mark S. Miller <erights at google.com> wrote:
Modules would be great! But I believe Ihab, due to travel conflicts, has been preparing to present a module proposal for the March meeting, not the January one. Ihab?
That is correct -- thanks Mark for noting this. Fwiw, Kris Kowal and I are working on it actively and plan to have written strawpersons long before March for discussion.
Ihab
On Jan 10, 2010, at 1:14 AM, Kevin Curtis wrote:
There could be some useful overlap with the code.google.com/p/es-lab/wiki/SecureEcmaScript proposal and modules.
The restricted eval (esp #6) could be the core mechanism of a module
system.
Only if you insist on using eval to turn source text into code for a
module to be processed.
That is one way to do it, and code generators such as Caja can make
use of such an eval. But it's not essential to the module system's
syntax or semantics, it's an implementation detail.
If we specify by implementing modules using only code generation and
the smallest set of extensions to ES5 possible, we risk specification
leaks (e.g., over-specification), as well as missing better road-not-
taken alternatives that are possible only with native module support
(browser-based, no new eval and no code generator required).
From SecureEcmaScript proposal: 6. The top level binding of this in an evaled Program is not the
global object, but rather a frozen root object containing just the
globals defined in the ES5 spec.
For many current applications, the frozen |this| object is not
necessary or desirable in global code. The essential characteristic of
modules, isolation for each module's "inside" from unimported effects
of other modules, does not necessarily mean no mutation of primordial
objects.
Beyond isolation, it seems desirable to have true lexical scope in
modules, so that free variable uses are an error. See
On Sat, Jan 9, 2010 at 10:43 PM, Brendan Eich <brendan at mozilla.com> wrote:
I raised a point about [[Invoke]] not being equivalent to [[Get]] and then [[Call]] due to order of evaluation:
esdiscuss/2009-December/010332
Did you or Tom have more thoughts on this issue? I couldn't find them in the wiki page.
I too don't have a good solution for this issue. I went ahead and added MarkM's recap of your example to the "Open issues" section of the proxies strawman page.
On Sat, Jan 9, 2010 at 11:13 PM, Mark S. Miller <erights at google.com> wrote:
Modules would be great! But I believe Ihab, due to travel conflicts, has been preparing to present a module proposal for the March meeting, not the January one. Ihab?
I am available if you want someone to work the arms and legs of the modules strawmen. It would be good to receive an express invitation, however, since I understand non-members are only permitted to attend once.
Kris Kowal
On Fri, Jan 15, 2010 at 6:54 PM, Kris Kowal <kris.kowal at cixar.com> wrote:
On Sat, Jan 9, 2010 at 11:13 PM, Mark S. Miller <erights at google.com> wrote:
Modules would be great! But I believe Ihab, due to travel conflicts, has been preparing to present a module proposal for the March meeting, not the January one. Ihab?
I am available if you want someone to work the arms and legs of the modules strawmen. It would be good to receive an express invitation, however, since I understand non-members are only permitted to attend once.
Fwiw, I have managed to massage things so that I will be there. Hopefully, Kris will be too.
Ihab
Tom Van Cutsem & I are quite satisfied with the alternate catchall strawman we have posted as "proxies" at < strawman:proxies>. The current state
of this strawman reflects all the input we have received from discussions on es-discuss. It seems to hold up very well to all the use-case experiments we have subjected it to (as gedanken experiments we cannot run yet).
Earlier I suggested that the weak-pointer / ephemeron-table strawman < strawman:weak_references> be on the
agenda for the January meeting, for us to consider promoting to "proposal" status. I believe this strawman also reflects well the input from prior discussions on es-discuss.
Proxies and weak-pointers are each individually fundamental enablers, in that they make possible use-cases which are not really possible without them, even by desugaring. An interesting curiosity is that we've found that there seems to be a natural synergy between these two strawmen. Together, they enable some important use cases that are not possible with either individually, such as discardable compartments (illustrated at the < code.google.com/p/es-lab> home page).
I suggest that the January (27,28?) meeting agenda also include a discussion of this proxies strawman, and that we should consider promoting it from "strawman" to "proposal" status at that time. (Istvan and John, that's why I'm cc'ing you explicitly.)
Finally, if there remains time, I would like to take time at the January meeting to discuss the progress we're making towards defining a draft SES (Secure EcmaScript) that can almost be implemented practically, indeed, almost trivially, on an ES5 system (draft code at < code.google.com/p/es-lab/source/browse/trunk/src/ses> not working
yet). I am surprised to find how close ES5 already comes to achieving Harmony goal #5. I don't have any action items to suggest re SES, but simply want to share thinking and progress.
I do not mean to monopolize the January meeting. But if no one has more pressing topics, I suggest all of these would also be good discussion topics for es-discuss between now and the January meeting. Especially if anyone has any remaining unaddressed objections to the weak-pointer or proxies strawmen.