Re: May the defineProperty method of a proxy handler throw a TypeError?
Le 26/05/2011 22:19, David Flanagan a écrit :
On 5/26/11 10:46 AM, David Bruant wrote:
Le 26/05/2011 18:44, David Flanagan a écrit :
I'd put that distinction in an abstract Proxy.Handler class and then
rename the current Proxy.Handler to Proxy.ForwardingHandler.
What do you call a class is is a constructor with some arguments?
Could you provide a code snippet of how you'd see it work.
All I really mean is that Proxy.Handler should be an object suitable
for use as a handler prototype.
Are you suggesting a generic Proxy.Handler (or Proxy.DerivedTraps) or
something targeted for the forwarding handler use case.
For the forwarding handler use case, I think that [1] addresses what you
suggest.
For a generic handler object with generic methods, I think it's
pointless, because there is no such thing like a generic handler method.
However, if you have examples of what you think would be suitable for
generic handler methods, any handler object could inherit from, please
do share code snippets
Rather than calling it Proxy.Handler, maybe Proxy.DerivedTraps would
be better. Then, using Allen's proposed | operator you could do:
p = Proxy.create(Proxy.DerivedTraps | {
// fundamental traps, and optionally some derived traps defined here
});
Functionally, the current proposal is doing this (without the explicit
inheritance) with shorter syntax.
David
[1]
http://wiki.ecmascript.org/doku.php?id=strawman:derived_traps_forwarding_handler
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
Le 27/05/2011 01:22, Waldemar a écrit : Categorization: No review, no advance: Unicode Concurrency Enumeration Simple module functions No review, advance: Multiple Globals Maps and Sets Math enhancements Function.toString Name property of functions Review, advance: String Extras Array Comprehensions Completion Reform Classes Extended Object Literals (the goals were advanced, the syntax used by the strawman was not) Quasis Review, no advance: Soft Fields Object Change Notifications Deferred Functions Guard Syntax Paren-Free Arrow Function/Block I do not see anything about proxies. If I remember well, a lot of decisions had been delayed from the previous meeting to this one. Did something happened about proxies? Thanks for these notes and I'm glad to see ECMAScript moving. So exciting :-) David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On May 26, 2011, at 9:36 PM, Peter Michaux wrote:
I'm looking at the strawman for guards.
http://wiki.ecmascript.org/doku.php?id=strawman:guards
I don't quite see how they are created.
I understand this part about how they would be used
function f(p :: String, q :: MyType) :: Boolean { ... }
but there is no specific example of how MyType is defined. Is that
related to classes at all? I'm hoping it is not related to classes and
that it is more akin to some kind of interface definition.
From http://wiki.ecmascript.org/doku.php?id=strawman:guards#creating_guards,
Optionally we may have an Object.setBrand(guard, brand) method that creates a
[[Brand]] internal property on an extensible object guard that doesn’t already
have one. It is an error to use Object.setBrand on a guard object that already
has a [[Brand]] internal property.
Suppose I
wanted MyType to be only positive even integers. Perhaps MyType is a
can only be a function that takes a single argument that is a string
and returns an integer. Perhaps MyType has to be an object with two
function properties named alpha and beta.
Exactly! Some in TC39 want to research contract systems for JS. We have a
research intern at Mozilla building such a prototype this summer. The plan was
to build a library without syntax, but Waldemar's proposal would give nice
syntax (we think -- details to hash out of course) for this work.
What about maybe types? Could MyType be defined so that null is not an
allowed value? All the manually written not-null parameter checks in
Java are an unfortunate result of its type checking system.
A static type system could perhaps be built on top of Harmony modules. Sam
Tobin-Hochstadt's Typed Racket work seems helpful here, although it uses
contracts too. This is all good research work.
The point is it is research, not ready to be standardized.
One use case I could see would be using guards in development and then
having the minifier strip the guards for production. Then the guard
definitions could be stripped as well.
As runtime checkers, you can't erase guards. If you knew a particular use of
guards as proposed was a static system that permitted erasure (I have no idea
whether this is realistic), then sure. We're a long way from anything like that.
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On May 27, 2011, at 1:39 AM, David Bruant wrote: I do not see anything about proxies. If I remember well, a lot of decisions had been delayed from the previous meeting to this one. Did something happened about proxies? Tom kindly agreed to move these issues to the July meeting, since Proxies are in Harmony and ES.next and we needed the time this meeting to go over strawmen. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May the defineProperty method of a proxy handler throw a TypeError?
2011/5/26 David Bruant david.bru...@labri.fr
Le 26/05/2011 18:44, David Flanagan a écrit :
On 5/26/11 6:51 AM, Sean Eagan wrote:
Is think it would beneficial to replace all this.* calls in the
default trap implementations with Object.* methods and syntax that
subsequently triggers the this.* calls. This would guarantee that
none of the internal object semantics are being missed, and
implementations could still optimize just as easily.
We have been discussing whether this.trap was equivalent to Object.trap
(shorthand notation) and the conclusion was that there was no way to
distinguish both cases. I think there actually is.
If, in a handler, I do this.defineProperty(23, {value:1}), there is no
conversion of the first argument to a string while there is if I
internally call Object.defineProperty(proxy, 23, {value:1})
There are probably other such cases.
And I agree with Sean. this.trap calls should be replaced with Object.*
calls
The current API doesn't allow this as changing |this.*| to |Object.*|
requires the handler to have access to the |proxy| in all traps. But if
http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy is
accepted, this seems like a good suggestion.
With specification text as if by calling the primordial Object.*
function? So that user modifications to Object.* are not observable?
I would argue so.
(by the way, ES5 terminology says built-in where you say primordial)
Wouldn't that mean that a pure-JavaScript implementation of the
default traps would not be possible from a module that could not run
at interpreter startup? (That may not be a goal that anyone has, of
course.)
Is it a goal at all?
There are plenty of things that are not possible anymore after one
starts messing around with built-in. I wouldn't be shocked by adding
this one.
I will always be in favor that derived traps should be implementable
with pure JS in a fresh environment, but when the environment isn't
fresh, it don't think it's worth worrying about such a guarantee.
I agree. I think it would be good to specify the built-in implementation of
derived traps to always invoke the built-in Object.* methods. This allows
engines to fully optimize. It is still possible for JS programmers to
faithfully implement the default behavior in JS, given a consistent
environment (consistent meaning here that Object.* methods may even have
been monkey-patched, but remain faithful to their ES5 semantics).
Personally, I think that proxies would be easier to reason about if no
distinction was made between fundamental and derived traps.
Based on my experience with proxies, there are very few cases which
really require to re-implement all traps. Reimplementing the
fundamentals and letting the engine handle inheritance + hasOwn trap is
handy.
I'd put that distinction in an abstract Proxy.Handler class and then
rename the current Proxy.Handler to Proxy.ForwardingHandler.
What do you call a class is is a constructor with some arguments?
Could you provide a code snippet of how you'd see it work.
Also, I think that this strawman
(
http://wiki.ecmascript.org/doku.php?id=strawman:derived_traps_forwarding_handler
)
is a first step toward what you're asking.
I've also raised the idea of renaming what is currently called
Proxy.Handler. It's still in discussion I think. I remember that Tom had
an idea, but I don't remember which.
My latest suggestion was to rename Proxy.Handler to Proxy.Forwarder
(Proxy.ForwardingHandler is a mouthful).
The idea of the cited strawman would be that Proxy.Forwarder inherits from
Proxy.BaseForwarder. BaseForwarder implements a forwarding implementation of
all the fundamental traps. Forwarder then adds a forwarding implementation
for the derived traps. Programmers can then create handlers that inherit
from either one of these prototypal handlers, and override only a select
number of traps, relying on the inherited implementation for the other
traps. This seems to be in line with what David F. is proposing.
Cheers,
Tom
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On May 26, 2011, at 4:22 PM, Waldemar wrote:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
The return will return out of f. Note also that the implementation of
forEach could have a try-finally statement that catches and revokes the
return. This kind of cross-function return catching is new.
And some on TC39 3 this Tennent sequel feature, to quote dherman. Others
cited the new as potentially too much for average users to grok. No one hated
it overtly.
The cage around block lambda is too tight.
Luke: Concern about call syntax strangeness. This kind of syntax only works
if it's designed holistically.
Debate about completion value leaks.
Waldemar: Use of | conflicts with common use of trademarks.
Alex: Objects to new little pieces of cleverness. Too many things to teach
to people.
Not advanced to Harmony.
More was said here that is good feedback for Harmony, no matter what gets into
ES.next.
We talked about how shorter function syntax is hard to do well and standardize.
The traps include:
* do too little by ignoring 'return', jumping a syntax shark and claiming a
sigil wanted otherwise (# as shorthand for 'function'),
* create completion value leak hazards (# + completion reform as in
http://brendaneich.com/2011/01/harmony-of-my-dreams/#functions),
* take on new grammar formalism challenges
(http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax),
* take on other costs (and benefits) by adding semantic value
(http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival).
We didn't get our act together in time to get shorter function syntax into
ES.next at this meeting, which I regard as a personal failure in part. But we
will keep trying. It's important, as Alex Russell argued.
I took a straw poll:
Block lambda revival with feedback issues fixed, in favor (whether 2nd or 1st
choice): 6 hands up.
Arrow function syntax, with grammar formalism addressed: 8 hands up.
There can be only one (of the above): 9 hands up.
Therefore I'll work on the
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax strawman
(I'll update
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival based on
feedback as well, to keep it up to date).
Peter Hallam kindly offered to help come up with a new grammar formalism for
the spec that can pass the Waldemar test (if that is possible; not as hard as
the Turing test). IIRC Peter said he was (had, would) adding arrow support per
the strawman to Traceur (http://code.google.com/p/traceur-compiler/). We talked
about Narcissus support too, to get more user testing.
User testing would be most helpful in providing negative results, for usability
or any other bug (parsing complexity, etc.). To get arrow function syntax into
Harmony we still need a non-LR(1) approach, because the LR(1) way parses too
broad (or even the wrong) a cover grammar: Expression as the arrow formal
parameter list.
So more to do for arrows, but that seems like the winning direction, with block
lambdas a close second.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
Le 27/05/2011 04:13, Mark S. Miller a écrit : On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu mailto:cor...@cs.ucsc.edu wrote: [documenting/expanding some ideas briefly discussed at today's meeting] The current proxy proposal has a method to create a new proxy: var proxy = Proxy.create(handler, proto); We could extend this proposal to allow an existing object to be converted to a proxy, via: var proxy = Proxy.createFrom(object, handler, proto); I am surprised by this proposal since a design goal of proxies was to not be able to turn existing objects into proxies. 4th driving force of the proxy proposal: security: avoid enabling arbitrary ES objects to be able to intercept the properties of another object The API itself (Proxy.create, Proxy.createFunction) seems to have been design with this in mind. Here, the return value 'proxy' is the same address as the argument 'object'. The original object thus becomes a proxy. Any state of the original object is discarded. The notion of object state is not defined anywhere in the ES5 spec. What is your definition of an object state ? This extension appears to support additional applications, such as registering an observer on an existing object. The target object would first be cloned, then the target object would be converted into a proxy that dispatches to the cloned object, but which also notifies observers about accesses/updates to the (now proxified) object. Is this the only use case? If so, would it rather make sense to provide a specific Object event API for existing objects? It would allow to observe accesses/updates without turning the object into a proxy with arbitrary handler methods. There are a number of open issues relating to security etc: In particular, what objects can be proxified in this way - perhaps not frozen object, or objects with non-configurable properties or with unique names. In today's meeting, I made two suggestions along these lines: * Given the current proxy semantics, we should allow this only if the object-to-be-proxified is extensible and has no non-configurable own properties. * We have on occasion discussed modifying the proxy proposal so that individual properties could be fixed rather than just the proxy as a whole. (Note: I am not in favor of such a change, but it could be done soundly.) Given that this change to proxies were done, then we should allow proxification only if the object-to-be-proxified is extensible, period. In both cases, as you state, one effect of the operation is to remove all configurable own properties from the object. In both cases, we can adopt the rationale that the object-to-be-proxified could not have taken any action inconsistent with it always having been a proxy. In both cases, we need the further restriction that it is a kind of object that can be emulated by a proxy. Today, this is technically only objects of [[Class]] Object or Function, but we're talking about relaxing that in any case. A design goal is that for any object that could be proxified, we can replace it with a proxy in a way that is semantically transparent. If you provide the ability to put any functions in the handler object, there in no such thing as semantically transparent. The handler methods can do whatever they wants; they are functions. Moreover with an API like Proxy.createFrom(object, handler, proto), the handler methods would need some help to initialize their internal proxy state in order to align with the object passed as argument. Maybe that what you were suggesting was to use a forwarding handler by default as handler and to put the handler argument as this.target? Even in this case, if creating proxies, an external user of the same object has no guarantee whatsoever of seeing no semantic difference since, for instance, any handler trap could throw an error when called. My very first (mis)understanding of proxies was that they were an object access/update event API and that the handler functions were nice event handler. They are not. They are much more powerful. They are not an /addition/ to regular internal object methods. They are a /replacement/ of it. However, I agree that an object event API is a valid use case (I have actually had a need for that a couple of days ago), but I don't think it should be a proxy extension. In my opinion, it should be its own library/API. Maybe implementable/standardizable with proxies + become internal function (see slide 56 at [1]), but its own thing. I would be much more in favor of something like: Object.observe(o, observers); Observers would be an object that looks like a proxy handler called on every object interactions, but wouldn't be able to interact with the object internal methods. It would just be an addition to internal methods rather than a replacement
Re: Converting an existing object to a proxy
On May 27, 2011, at 2:26 AM, David Bruant wrote: Le 27/05/2011 04:13, Mark S. Miller a écrit : On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu wrote: [documenting/expanding some ideas briefly discussed at today's meeting] The current proxy proposal has a method to create a new proxy: var proxy = Proxy.create(handler, proto); We could extend this proposal to allow an existing object to be converted to a proxy, via: var proxy = Proxy.createFrom(object, handler, proto); I am surprised by this proposal since a design goal of proxies was to not be able to turn existing objects into proxies. 4th driving force of the proxy proposal: security: avoid enabling arbitrary ES objects to be able to intercept the properties of another object That is not the same as avoid turning an object into a proxy, though. The idea of permitting this becomes operation only for extensible objects with configurable properties is crucial. The motivation is to unify ideas in proxies (in Harmony) with those proposed in http://wiki.ecmascript.org/doku.php?id=strawman:observe. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On 27/05/2011, at 11:01, Brendan Eich wrote:
On May 26, 2011, at 4:22 PM, Waldemar wrote:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
The return will return out of f. Note also that the implementation of
forEach could have a try-finally statement that catches and revokes the
return. This kind of cross-function return catching is new.
And some on TC39 3 this Tennent sequel feature, to quote dherman. Others
cited the new as potentially too much for average users to grok. No one hated
it overtly.
It's not that it's too much to grok, it's that as I like that (blocks) syntax
so much, I'd prefer to use it for (shorter) functions (syntax) instead of the
(ugly, extraneous, imho) arrow syntax proposal, not for blocks.
Also, I wonder if in order to make blocks first class, do we need any new
syntax ?
function f() {
a.forEach({ return 3 });
}
?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
Since I gather this proposal is meant primarily to support observable objects, two remarks: 1) Are proxies the appropriate building block performance-wise? From the notes, it seems that current proxies are not a good building block because of performance issues. Are the performance issues related to the membraning needed for maintaining object identity, or are they more fundamental? 2) IIUC, one of the more interesting uses of observables would be to make e.g. DOM nodes observable. That raises the issue of whether Proxy.createFrom can be applied to Host objects, and of so, how to deal with built-in [[...]] properties. I tend to agree with David about having a separate observable API, if that is indeed the driving use case. That API can be very similar to the Proxy API though. Racket's chaperones come to mind: a chaperone is a strictly less powerful kind of proxy, one that is not allowed to arbitrarily change the result of the original operation (and IIRC, a chaperone also cannot stop the original operation from taking place on the target object). Cheers, Tom 2011/5/27 David Bruant david.bru...@labri.fr Le 27/05/2011 04:13, Mark S. Miller a écrit : On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.eduwrote: [documenting/expanding some ideas briefly discussed at today's meeting] The current proxy proposal has a method to create a new proxy: var proxy = Proxy.create(handler, proto); We could extend this proposal to allow an existing object to be converted to a proxy, via: var proxy = Proxy.createFrom(object, handler, proto); I am surprised by this proposal since a design goal of proxies was to not be able to turn existing objects into proxies. 4th driving force of the proxy proposal: security: avoid enabling arbitrary ES objects to be able to intercept the properties of another object The API itself (Proxy.create, Proxy.createFunction) seems to have been design with this in mind. Here, the return value 'proxy' is the same address as the argument 'object'. The original object thus becomes a proxy. Any state of the original object is discarded. The notion of object state is not defined anywhere in the ES5 spec. What is your definition of an object state ? This extension appears to support additional applications, such as registering an observer on an existing object. The target object would first be cloned, then the target object would be converted into a proxy that dispatches to the cloned object, but which also notifies observers about accesses/updates to the (now proxified) object. Is this the only use case? If so, would it rather make sense to provide a specific Object event API for existing objects? It would allow to observe accesses/updates without turning the object into a proxy with arbitrary handler methods. There are a number of open issues relating to security etc: In particular, what objects can be proxified in this way - perhaps not frozen object, or objects with non-configurable properties or with unique names. In today's meeting, I made two suggestions along these lines: * Given the current proxy semantics, we should allow this only if the object-to-be-proxified is extensible and has no non-configurable own properties. * We have on occasion discussed modifying the proxy proposal so that individual properties could be fixed rather than just the proxy as a whole. (Note: I am not in favor of such a change, but it could be done soundly.) Given that this change to proxies were done, then we should allow proxification only if the object-to-be-proxified is extensible, period. In both cases, as you state, one effect of the operation is to remove all configurable own properties from the object. In both cases, we can adopt the rationale that the object-to-be-proxified could not have taken any action inconsistent with it always having been a proxy. In both cases, we need the further restriction that it is a kind of object that can be emulated by a proxy. Today, this is technically only objects of [[Class]] Object or Function, but we're talking about relaxing that in any case. A design goal is that for any object that could be proxified, we can replace it with a proxy in a way that is semantically transparent. If you provide the ability to put any functions in the handler object, there in no such thing as semantically transparent. The handler methods can do whatever they wants; they are functions. Moreover with an API like Proxy.createFrom(object, handler, proto), the handler methods would need some help to initialize their internal proxy state in order to align with the object passed as argument. Maybe that what you were suggesting was to use a forwarding handler by default as handler and to put the handler argument as this.target? Even in this case, if creating proxies, an external user of the same object has no guarantee whatsoever of seeing no semantic difference since, for
Re: Converting an existing object to a proxy
I tend to agree with David about having a separate observable API, if that is indeed the driving use case. That API can be very similar to the Proxy API though. Racket's chaperones come to mind: a chaperone is a strictly less powerful kind of proxy, one that is not allowed to arbitrarily change the result of the original operation (and IIRC, a chaperone also cannot stop the original operation from taking place on the target object). Spoke too soon: from http://web.mit.edu/drracket_v501/share/racket/doc/reference/chaperones.html I learn that chaperones can throw exceptions, and thus presumably abort an intercepted operation early. Still, the idea of a tamed kind of proxy is worth exploring. Cheers, Tom 2011/5/27 David Bruant david.bru...@labri.fr Le 27/05/2011 04:13, Mark S. Miller a écrit : On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.eduwrote: [documenting/expanding some ideas briefly discussed at today's meeting] The current proxy proposal has a method to create a new proxy: var proxy = Proxy.create(handler, proto); We could extend this proposal to allow an existing object to be converted to a proxy, via: var proxy = Proxy.createFrom(object, handler, proto); I am surprised by this proposal since a design goal of proxies was to not be able to turn existing objects into proxies. 4th driving force of the proxy proposal: security: avoid enabling arbitrary ES objects to be able to intercept the properties of another object The API itself (Proxy.create, Proxy.createFunction) seems to have been design with this in mind. Here, the return value 'proxy' is the same address as the argument 'object'. The original object thus becomes a proxy. Any state of the original object is discarded. The notion of object state is not defined anywhere in the ES5 spec. What is your definition of an object state ? This extension appears to support additional applications, such as registering an observer on an existing object. The target object would first be cloned, then the target object would be converted into a proxy that dispatches to the cloned object, but which also notifies observers about accesses/updates to the (now proxified) object. Is this the only use case? If so, would it rather make sense to provide a specific Object event API for existing objects? It would allow to observe accesses/updates without turning the object into a proxy with arbitrary handler methods. There are a number of open issues relating to security etc: In particular, what objects can be proxified in this way - perhaps not frozen object, or objects with non-configurable properties or with unique names. In today's meeting, I made two suggestions along these lines: * Given the current proxy semantics, we should allow this only if the object-to-be-proxified is extensible and has no non-configurable own properties. * We have on occasion discussed modifying the proxy proposal so that individual properties could be fixed rather than just the proxy as a whole. (Note: I am not in favor of such a change, but it could be done soundly.) Given that this change to proxies were done, then we should allow proxification only if the object-to-be-proxified is extensible, period. In both cases, as you state, one effect of the operation is to remove all configurable own properties from the object. In both cases, we can adopt the rationale that the object-to-be-proxified could not have taken any action inconsistent with it always having been a proxy. In both cases, we need the further restriction that it is a kind of object that can be emulated by a proxy. Today, this is technically only objects of [[Class]] Object or Function, but we're talking about relaxing that in any case. A design goal is that for any object that could be proxified, we can replace it with a proxy in a way that is semantically transparent. If you provide the ability to put any functions in the handler object, there in no such thing as semantically transparent. The handler methods can do whatever they wants; they are functions. Moreover with an API like Proxy.createFrom(object, handler, proto), the handler methods would need some help to initialize their internal proxy state in order to align with the object passed as argument. Maybe that what you were suggesting was to use a forwarding handler by default as handler and to put the handler argument as this.target? Even in this case, if creating proxies, an external user of the same object has no guarantee whatsoever of seeing no semantic difference since, for instance, any handler trap could throw an error when called. My very first (mis)understanding of proxies was that they were an object access/update event API and that the handler functions were nice event handler. They are not. They are much more powerful. They are not an /addition/ to regular internal object methods. They are a /replacement/ of
Re: Converting an existing object to a proxy
Le 27/05/2011 11:35, Brendan Eich a écrit : On May 27, 2011, at 2:26 AM, David Bruant wrote: Le 27/05/2011 04:13, Mark S. Miller a écrit : On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu mailto:cor...@cs.ucsc.edu wrote: [documenting/expanding some ideas briefly discussed at today's meeting] The current proxy proposal has a method to create a new proxy: var proxy = Proxy.create(handler, proto); We could extend this proposal to allow an existing object to be converted to a proxy, via: var proxy = Proxy.createFrom(object, handler, proto); I am surprised by this proposal since a design goal of proxies was to not be able to turn existing objects into proxies. 4th driving force of the proxy proposal: security: avoid enabling arbitrary ES objects to be able to intercept the properties of another object That is not the same as avoid turning an object into a proxy, though. I actually thought that it's what it meant, but you're right. I think it should be clarify, because the way the API is design, it's quite clear that only new objects can be proxies. In the presentation you gave, it's clear that proxies can only go from trapping to fixed and that there is no way to go in the opposite direction The idea of permitting this becomes operation only for extensible objects with configurable properties is crucial. Is it? The first time I heard about the become operation was in the context of the proxy fix trap. Second time was this message. It doesn't sounds crucial yet to me. The motivation is to unify ideas in proxies (in Harmony) with those proposed in http://wiki.ecmascript.org/doku.php?id=strawman:observe. I hadn't read this proposal yet. Thanks. I think that this discussion raises the following question: Should all usages of the become operation be associated with proxies? I would answer no because they sound like orthogonal concerns, but I'm interested in listening to arguments saying otherwise. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On 27/05/2011, at 11:36, Jorge wrote:
On 27/05/2011, at 11:01, Brendan Eich wrote:
On May 26, 2011, at 4:22 PM, Waldemar wrote:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
The return will return out of f. Note also that the implementation of
forEach could have a try-finally statement that catches and revokes the
return. This kind of cross-function return catching is new.
And some on TC39 3 this Tennent sequel feature, to quote dherman. Others
cited the new as potentially too much for average users to grok. No one
hated it overtly.
It's not that it's too much to grok, it's that as I like that (blocks)
syntax so much, I'd prefer to use it for (shorter) functions (syntax) instead
of the (ugly, extraneous, imho) arrow syntax proposal, not for blocks.
Also, I wonder if in order to make blocks first class, do we need any new
syntax ?
function f() {
a.forEach({ return 3 });
}
?
I have edited (a copy of) the arrow_function_syntax strawman wiki page, to see
side-by-side the current function syntax, the arrow syntax and the blocks
(applied to functions) syntax:
http://jorgechamorro.com/blocks.html
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On May 27, 2011, at 2:36 AM, Jorge wrote:
Also, I wonder if in order to make blocks first class, do we need any new
syntax ?
function f() {
a.forEach({ return 3 });
The problem is that a block statement is ambiguous with an object initialiser.
See
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes
in particular the To enable unparenthesized ObjectLiteral expressions as
bodies of arrow functions, without ambiguity with Block bodies, restrict
LabelledStatement as follows... section.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
On Fri, May 27, 2011 at 5:45 AM, Tom Van Cutsem tomvc...@gmail.com wrote: I tend to agree with David about having a separate observable API, if that is indeed the driving use case. That API can be very similar to the Proxy API though. Racket's chaperones come to mind: a chaperone is a strictly less powerful kind of proxy, one that is not allowed to arbitrarily change the result of the original operation (and IIRC, a chaperone also cannot stop the original operation from taking place on the target object). Spoke too soon: from http://web.mit.edu/drracket_v501/share/racket/doc/reference/chaperones.html I learn that chaperones can throw exceptions, and thus presumably abort an intercepted operation early. Still, the idea of a tamed kind of proxy is worth exploring. I believe that the semantics of observers allow for throwing exceptions, and thus terminating an operation, at least according to the wiki page. -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
On 5/27/11 5:40 AM, Tom Van Cutsem wrote: 2) IIUC, one of the more interesting uses of observables would be to make e.g. DOM nodes observable. That raises the issue of whether Proxy.createFrom can be applied to Host objects, and of so, how to deal with built-in [[...]] properties. How useful would observables be for DOM nodes? I guess you could notice expandos being added or removed, but that's about it, right? -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
On May 27, 2011, at 3:04 AM, David Bruant wrote: The idea of permitting this becomes operation only for extensible objects with configurable properties is crucial. Is it? The first time I heard about the become operation was in the context of the proxy fix trap. Second time was this message. It doesn't sounds crucial yet to me. The crucial applied to both only for extensible objects with configurable properties in that sentence. ;-) The issue as I understand it is not becomes per se (more below), rather that an extensible object with configurable (own) properties could have those properties wrapped by accessors to emulate some of the intercessive power of proxies. From the security point of view, you want frozen and sealed objects, at least, to be immune to proxification because they are immune to such property-by-property wrapping with accessors, today. See Mark's reply on the list dated 7:33pm yesterday. The motivation is to unify ideas in proxies (in Harmony) with those proposed in http://wiki.ecmascript.org/doku.php?id=strawman:observe. I hadn't read this proposal yet. Thanks. I think that this discussion raises the following question: Should all usages of the become operation be associated with proxies? We are not exposing becomes in the language -- certainly not for two arbitrary live objects. In both the proxy fix case, and in this Proxy.createFrom case, one of the two objects is a newborn, not yet accessible. We brain-transplant between the accessible and inaccessible, swapping the objects' data. The identity is preserved but the internal and own properties are exchanged. Questions about the proxify-existing-object case: 1. Won't the proxy want the original brain, the one transplanted into a newborn proxy (now become the regular object)? 2. Will the costs here be acceptable compared to something unstratified requiring no extra object, a la strawman:observe? /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
I think the separation between proxies and regular objects is too much. I would prefer to think of proxies as just a special kind of object. All objects could be thought of as having a handler ( [[Handler]] ), and proxy objects could be those objects whose handler is an actual ES object as opposed to an abstract language specification object. This would be similar to the distinction betweeen data and accessor properties, since you could think of a default abstract [[Set]] and [[Get]] implementation for property descriptors. Then fixing a proxy object could just be thought of as setting the object's [[Handler]] to an abstract specification handler, and Proxy.createFrom can just be thought of as setting the object's [[Handler]] to an actual ES object. The abstract [[Handler]] could either be implemented via pseudocode similar to the ES5 spec or by actual ES code if a testable / executable object spec is desired. I've been working on a concept called object descriptors which are an object level equivalent of property descriptors. One of the object descriptor attributes I'm including is handler. Object descriptors could also have a configurable attribute which could control whether an object's handler (and other attributes) can be changed. On Fri, May 27, 2011 at 9:21 AM, Brendan Eich bren...@mozilla.com wrote: On May 27, 2011, at 3:04 AM, David Bruant wrote: The idea of permitting this becomes operation only for extensible objects with configurable properties is crucial. Is it? The first time I heard about the become operation was in the context of the proxy fix trap. Second time was this message. It doesn't sounds crucial yet to me. The crucial applied to both only for extensible objects with configurable properties in that sentence. ;-) The issue as I understand it is not becomes per se (more below), rather that an extensible object with configurable (own) properties could have those properties wrapped by accessors to emulate some of the intercessive power of proxies. From the security point of view, you want frozen and sealed objects, at least, to be immune to proxification because they are immune to such property-by-property wrapping with accessors, today. See Mark's reply on the list dated 7:33pm yesterday. The motivation is to unify ideas in proxies (in Harmony) with those proposed in http://wiki.ecmascript.org/doku.php?id=strawman:observe. I hadn't read this proposal yet. Thanks. I think that this discussion raises the following question: Should all usages of the become operation be associated with proxies? We are not exposing becomes in the language -- certainly not for two arbitrary live objects. In both the proxy fix case, and in this Proxy.createFrom case, one of the two objects is a newborn, not yet accessible. We brain-transplant between the accessible and inaccessible, swapping the objects' data. The identity is preserved but the internal and own properties are exchanged. Questions about the proxify-existing-object case: 1. Won't the proxy want the original brain, the one transplanted into a newborn proxy (now become the regular object)? 2. Will the costs here be acceptable compared to something unstratified requiring no extra object, a la strawman:observe? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Sean Eagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Date.prototype.format
This may of been thrown though the ringer already but I thought I'd ask. http://blog.stevenlevithan.com/archives/date-time-format This is some awesome work on date formatting. What do we think about having a native Date Format implementation in es.next? Complications? Seems like this a very commonly needed option. Especially w/ SSJS now getting more popular. -- Marc (@wavded) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
On Fri, May 27, 2011 at 10:10 AM, Sean Eagan seaneag...@gmail.com wrote: I think the separation between proxies and regular objects is too much. I would prefer to think of proxies as just a special kind of object. All objects could be thought of as having a handler ( [[Handler]] ), and proxy objects could be those objects whose handler is an actual ES object as opposed to an abstract language specification object. We could instead say that all objects have a [[DefaultHandler]] which contains the default trap implementations. Then object's that have a [[Handler]] are proxy objects. For trap resolution if an object has a [[Handler]] and the [[Handler]] has the given trap, invoke it. If an object does not have a [[Handler]] or [[Handler]] does not have the given trap, then, for derived traps invoke the object's [[DefaultHandler]]'s trap, for fundamental traps perform the abstract spec defined pseudocode for the given internal method. Then proxy fixing would mean that the object will no longer have a [[Handler]], and Proxy.createFrom means that the object will now have a [[Handler]]. We could also define default handler's for object types which override certain internal methods such as Arrays and Functions. These would inherit the trap implementations from Object's default handler. Thanks, Sean Eagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Date.prototype.format
On Fri, May 27, 2011 at 11:48 AM, Marc Harter wav...@gmail.com wrote: This may of been thrown though the ringer already but I thought I'd ask. http://blog.stevenlevithan.com/archives/date-time-format This is some awesome work on date formatting. What do we think about having a native Date Format implementation in es.next? Complications? Seems like this a very commonly needed option. Especially w/ SSJS now getting more popular. See http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api Note that it is rarely useful to format with a fixed pattern, because different locales have different norms for ordering of the fields, separators, etc. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
On May 27, 2011, at 8:10 AM, Sean Eagan wrote: I think the separation between proxies and regular objects is too much. I would prefer to think of proxies as just a special kind of object. All objects could be thought of as having a handler ( [[Handler]] ), and proxy objects could be those objects whose handler is an actual ES object as opposed to an abstract language specification object. This is a way of thinking about proxies in the context of JS, for sure. Please see this slide http://brendaneich.com/brendaneich_content/uploads/selective-interception.png from Tom and Mark. This would be similar to the distinction betweeen data and accessor properties, since you could think of a default abstract [[Set]] and [[Get]] implementation for property descriptors. Then fixing a proxy object could just be thought of as setting the object's [[Handler]] to an abstract specification handler, and Proxy.createFrom can just be thought of as setting the object's [[Handler]] to an actual ES object. The abstract [[Handler]] could either be implemented via pseudocode similar to the ES5 spec or by actual ES code if a testable / executable object spec is desired. The problem is making the VM handlers (to use the slide's terms) concrete, not abstract. No VM implementor wants that. Nor do security folks -- at least not read/write VM handler access. When we first started discussing catch-alls, before Proxies were proposed, TC39 members stopped progress on catch-alls by citing the climbing the meta ladder problem. This is where the spec and real code, instead of bottoming out at unspoofable core semantics, trap back into user code doing meta-programming of arbitrary objects. This is why VM implementors object. They can't optimize as well if they have to check more potentially varying invariants of ES1-5. This is why Proxies are a special kind of object. The security issue is similar. If an attacker can vary invariants the VM needs to enforce via a built-in handler to preserve integrity or other safety properties, that's a security hole. It may be that frozen and sealed objects being immune is enough, for some operations such as watching gets and sets. As noted, for a non-sealed object, those could be done by wrapping each property in an accessor after transplanting it to an inner object or a peer property with a private name. But intercession at the VM handler layer may be strictly more powerful than get, set, or even delete trapping. I've been working on a concept called object descriptors which are an object level equivalent of property descriptors. One of the object descriptor attributes I'm including is handler. Object descriptors could also have a configurable attribute which could control whether an object's handler (and other attributes) can be changed. This helps but the VM implementors may still object to reflecting currently-hidden VM handlers. There may be security issues we are missing. And unless the built-in objects of Clause 15 all have non-configurable handlers, you are talking about climbing the meta ladder in the spec. /be On Fri, May 27, 2011 at 9:21 AM, Brendan Eich bren...@mozilla.com wrote: On May 27, 2011, at 3:04 AM, David Bruant wrote: The idea of permitting this becomes operation only for extensible objects with configurable properties is crucial. Is it? The first time I heard about the become operation was in the context of the proxy fix trap. Second time was this message. It doesn't sounds crucial yet to me. The crucial applied to both only for extensible objects with configurable properties in that sentence. ;-) The issue as I understand it is not becomes per se (more below), rather that an extensible object with configurable (own) properties could have those properties wrapped by accessors to emulate some of the intercessive power of proxies. From the security point of view, you want frozen and sealed objects, at least, to be immune to proxification because they are immune to such property-by-property wrapping with accessors, today. See Mark's reply on the list dated 7:33pm yesterday. The motivation is to unify ideas in proxies (in Harmony) with those proposed in http://wiki.ecmascript.org/doku.php?id=strawman:observe. I hadn't read this proposal yet. Thanks. I think that this discussion raises the following question: Should all usages of the become operation be associated with proxies? We are not exposing becomes in the language -- certainly not for two arbitrary live objects. In both the proxy fix case, and in this Proxy.createFrom case, one of the two objects is a newborn, not yet accessible. We brain-transplant between the accessible and inaccessible, swapping the objects' data. The identity is preserved but the internal and own properties are exchanged. Questions about the proxify-existing-object case: 1. Won't the proxy want the original brain, the one transplanted into a newborn proxy
Re: Date.prototype.format
On Fri, May 27, 2011 at 11:08 AM, John Tamplin j...@google.com wrote:
On Fri, May 27, 2011 at 11:48 AM, Marc Harter wav...@gmail.com wrote:
This may of been thrown though the ringer already but I thought I'd ask.
http://blog.stevenlevithan.com/archives/date-time-format
This is some awesome work on date formatting. What do we think about
having a native Date Format implementation in es.next? Complications?
Seems like this a very commonly needed option. Especially w/ SSJS
now getting more popular.
See http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api
Thanks!
Note that it is rarely useful to format with a fixed pattern, because
different locales have different norms for ordering of the fields,
separators, etc.
By fixed pattern do you mean like d.format('YY/mm/dd')? If so,
doesn't that allow for more expressive power?
--
John A. Tamplin
Software Engineer (GWT), Google
--
Marc (@wavded)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
I have no intention of bike-shedding, but the following example keeps
popping up:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
...And I wonder if forEach was _only_ used to illustrate an example of the
block lambda syntax? If this was meant to serve as an actual representation
of a real world use case, I would be negligent if I didn't speak up and note
that the use of a.forEach({| | return 3}); is incorrect. a.forEach(
callback ) returns undefined per spec.
Forgive me if I've misunderstood the use of forEach in this example.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Date.prototype.format
On Fri, May 27, 2011 at 12:21 PM, Marc Harter wav...@gmail.com wrote:
Note that it is rarely useful to format with a fixed pattern, because
different locales have different norms for ordering of the fields,
separators, etc.
By fixed pattern do you mean like d.format('YY/mm/dd')? If so,
doesn't that allow for more expressive power?
To illustrate the problem, consider formatting a date next week with
M/d/y, giving 6/1/2011. US readers will understand that readily.
However, if a European user sees that, they will interpret it as if it were
d/M/y, and they will think it is in January. Also, many locales have
different separators for the portions of the date, or insert additional
words in the longer formats, which won't be present if you just used a fixed
format pattern.
Instead, you should use a skeleton pattern of Mdy saying that you want a
format with numeric values for month day and year. Then, you get the proper
format for the locale your user is running your app in. Even better, though
more restrictive, is to use a predefined format where experts in each locale
have said this is a good short date format for that locale, since there
are different conventions.
For examples from CLDR, see:
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en.xml#L1259
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en_GB.xml#L57
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/zh.xml#L1166
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/en.xml#L1217
-
http://unicode.org/cldr/trac/browser/tags/release-2-0/common/main/zh.xml#L1123
Certainly, there are cases where you do want a fixed format (and in fact you
don't want localized names, but rather the English month/day names), such as
when formatting an RFC2822 date, and in those cases you do want to be able
to use a fixed format string.
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
This example was all about return in block-lambda returning from enclosing
function (the function f). That's all. Yeah, it was not useful code ;-).
/be
On May 27, 2011, at 9:42 AM, Rick Waldron wrote:
I have no intention of bike-shedding, but the following example keeps popping
up:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
...And I wonder if forEach was _only_ used to illustrate an example of the
block lambda syntax? If this was meant to serve as an actual representation
of a real world use case, I would be negligent if I didn't speak up and note
that the use of a.forEach({| | return 3}); is incorrect. a.forEach(
callback ) returns undefined per spec.
Forgive me if I've misunderstood the use of forEach in this example.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
Thanks, I wasn't aware of that history. I'm not suggesting that default handlers or traps even should exist from an implementation perspective, just that they could be a nice specification mechanism now that we have proxies. Otherwise we need to separately maintain pseudocode and ES versions of the derived traps. The default handlers would specify the required *effective* behavior of internal methods corresponding to derived traps. Each of the internal spec methods would still be abstract, and allowed to perform additional behavior, but internal methods corresponding to derived traps would need to also perform the behavior specified by the default trap when the object does not have a [[Handler]] with that trap. It would need to behave as if the original bindings of the builtin objects referenced within the default trap implementation were used, except that even if the implementation allows property access watching, no such notifications would be sent for property access on builtins that occur within the default trap's code. On Fri, May 27, 2011 at 11:12 AM, Brendan Eich bren...@mozilla.com wrote: On May 27, 2011, at 8:10 AM, Sean Eagan wrote: I think the separation between proxies and regular objects is too much. I would prefer to think of proxies as just a special kind of object. All objects could be thought of as having a handler ( [[Handler]] ), and proxy objects could be those objects whose handler is an actual ES object as opposed to an abstract language specification object. This is a way of thinking about proxies in the context of JS, for sure. Please see this slide http://brendaneich.com/brendaneich_content/uploads/selective-interception.png from Tom and Mark. This would be similar to the distinction betweeen data and accessor properties, since you could think of a default abstract [[Set]] and [[Get]] implementation for property descriptors. Then fixing a proxy object could just be thought of as setting the object's [[Handler]] to an abstract specification handler, and Proxy.createFrom can just be thought of as setting the object's [[Handler]] to an actual ES object. The abstract [[Handler]] could either be implemented via pseudocode similar to the ES5 spec or by actual ES code if a testable / executable object spec is desired. The problem is making the VM handlers (to use the slide's terms) concrete, not abstract. No VM implementor wants that. Nor do security folks -- at least not read/write VM handler access. When we first started discussing catch-alls, before Proxies were proposed, TC39 members stopped progress on catch-alls by citing the climbing the meta ladder problem. This is where the spec and real code, instead of bottoming out at unspoofable core semantics, trap back into user code doing meta-programming of arbitrary objects. This is why VM implementors object. They can't optimize as well if they have to check more potentially varying invariants of ES1-5. This is why Proxies are a special kind of object. The security issue is similar. If an attacker can vary invariants the VM needs to enforce via a built-in handler to preserve integrity or other safety properties, that's a security hole. It may be that frozen and sealed objects being immune is enough, for some operations such as watching gets and sets. As noted, for a non-sealed object, those could be done by wrapping each property in an accessor after transplanting it to an inner object or a peer property with a private name. But intercession at the VM handler layer may be strictly more powerful than get, set, or even delete trapping. I've been working on a concept called object descriptors which are an object level equivalent of property descriptors. One of the object descriptor attributes I'm including is handler. Object descriptors could also have a configurable attribute which could control whether an object's handler (and other attributes) can be changed. This helps but the VM implementors may still object to reflecting currently-hidden VM handlers. There may be security issues we are missing. And unless the built-in objects of Clause 15 all have non-configurable handlers, you are talking about climbing the meta ladder in the spec. /be On Fri, May 27, 2011 at 9:21 AM, Brendan Eich bren...@mozilla.com wrote: On May 27, 2011, at 3:04 AM, David Bruant wrote: The idea of permitting this becomes operation only for extensible objects with configurable properties is crucial. Is it? The first time I heard about the become operation was in the context of the proxy fix trap. Second time was this message. It doesn't sounds crucial yet to me. The crucial applied to both only for extensible objects with configurable properties in that sentence. ;-) The issue as I understand it is not becomes per se (more below), rather that an extensible object with configurable (own) properties could have those properties wrapped by accessors to
Re: Converting an existing object to a proxy
On Fri, May 27, 2011 at 12:18 PM, Sean Eagan seaneag...@gmail.com wrote: Thanks, I wasn't aware of that history. I'm not suggesting that default handlers or traps even should exist from an implementation perspective, just that they could be a nice specification mechanism now that we have proxies. Otherwise we need to separately maintain pseudocode and ES versions of the derived traps. Of course you could go the other way, and remove the default trap implementations. All objects could have the same internal method implementation regardless of whether or not they are a proxy. Within each internal method there could be a check as to whether the object is a proxy (has a [[Handler]]) AND has the trap, if so, it is invoked, otherwise the default pseudocode is performed. Thanks, Sean Eagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
I'm puzzled about this idea. I thought that one of the main design goals of proxies was that they are transparent, i.e. you cannot tell a proxy apart from a proper object. How can this be maintained for Proxy.createFrom? AFAICS, there is no way you can perform this operation on an object that already is a proxy. /Andreas On 27 May 2011 04:13, Mark S. Miller erig...@google.com wrote: On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu wrote: [documenting/expanding some ideas briefly discussed at today's meeting] The current proxy proposal has a method to create a new proxy: var proxy = Proxy.create(handler, proto); We could extend this proposal to allow an existing object to be converted to a proxy, via: var proxy = Proxy.createFrom(object, handler, proto); Here, the return value 'proxy' is the same address as the argument 'object'. The original object thus becomes a proxy. Any state of the original object is discarded. This extension appears to support additional applications, such as registering an observer on an existing object. The target object would first be cloned, then the target object would be converted into a proxy that dispatches to the cloned object, but which also notifies observers about accesses/updates to the (now proxified) object. There are a number of open issues relating to security etc: In particular, what objects can be proxified in this way - perhaps not frozen object, or objects with non-configurable properties or with unique names. In today's meeting, I made two suggestions along these lines: * Given the current proxy semantics, we should allow this only if the object-to-be-proxified is extensible and has no non-configurable own properties. * We have on occasion discussed modifying the proxy proposal so that individual properties could be fixed rather than just the proxy as a whole. (Note: I am not in favor of such a change, but it could be done soundly.) Given that this change to proxies were done, then we should allow proxification only if the object-to-be-proxified is extensible, period. In both cases, as you state, one effect of the operation is to remove all configurable own properties from the object. In both cases, we can adopt the rationale that the object-to-be-proxified could not have taken any action inconsistent with it always having been a proxy. In both cases, we need the further restriction that it is a kind of object that can be emulated by a proxy. Today, this is technically only objects of [[Class]] Object or Function, but we're talking about relaxing that in any case. A design goal is that for any object that could be proxified, we can replace it with a proxy in a way that is semantically transparent. - Cormac -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
On Fri, May 27, 2011 at 2:26 AM, David Bruant david.bru...@labri.fr wrote: On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu wrote: A design goal is that for any object that could be proxified, we can replace it with a proxy in a way that is semantically transparent. If you provide the ability to put any functions in the handler object, there in no such thing as semantically transparent. The handler methods can do whatever they wants; they are functions. What I meant was that by writing the handler functions in the appropriate way, we can create a proxy that is semantically transparent -- not that all proxies must be semantically transparent. - Cormac ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On Fri, May 27, 2011 at 1:44 AM, Brendan Eich bren...@mozilla.com wrote:
On May 26, 2011, at 9:36 PM, Peter Michaux wrote:
I'm looking at the strawman for guards.
http://wiki.ecmascript.org/doku.php?id=strawman:guards
I don't quite see how they are created.
I understand this part about how they would be used
function f(p :: String, q :: MyType) :: Boolean { ... }
but there is no specific example of how MyType is defined. Is that
related to classes at all? I'm hoping it is not related to classes and
that it is more akin to some kind of interface definition.
From http://wiki.ecmascript.org/doku.php?id=strawman:guards#creating_guards,
Optionally we may have an Object.setBrand(guard, brand) method that creates
a [[Brand]] internal property on an extensible object guard that doesn’t
already have one. It is an error to use Object.setBrand on a guard object
that already has a [[Brand]] internal property.
I did see this when reading the strawman. It seems I missed the following bit
The brand object (the value of the [[Brand]] internal property) can
be anything. To be useful, it should be an object with a coerce method.
So would the following code be possible? (I've added Object.hasBrand(o).)
var positiveNumberGuard = {};
Object.setBrand(positiveNumberGuard, {
coerce: function(specimen) {
if (typeof specimen !== 'number') {
throw new Error('must be a number');
}
if (specimen = 0) {
throw new Error('must be positive');
}
return specimen;
}
});
var nonEmptyStringGuard = {};
Object.setBrand(nonEmptyStringGuard, {
coerce: function(specimen) {
if (typeof specimen !== 'string') {
throw new Error('must be a string');
}
if (specimen.length = 0) {
throw new Error('must be non-empty');
}
return specimen;
}
});
var identityGuard = {};
Object.setBrand(identityGuard, {
coerce: function(specimen) {
return specimen;
}
});
var guardGuard = {};
Object.setBrand(guardGuard {
coerce: function(specimen) {
if (!Object.hasBrand(specimen)) {
throw new Error('must be a guard');
}
return specimen;
}
});
var makeDoubler = function(guard = identityGuard :: guardGuard) {
return function(x :: guard) {
return x + x;
};
};
var positiveNumberDoubler = makeDoubler(positiveNumberGuard);
positiveNumberDoubler(1); // 2
positiveNumberDoubler(a); // throws must be a number
var nonEmptyStringDoubler = makeDoubler(nonEmptyStringGuard);
nonEmptyStringDoubler(1); // throws must be a string
nonEmptyStringDoubler(a); // aa
var doubler = makeDoubler();
doubler(1); // 2
doubler(a); // aa
I'm impressed with the following if this is what would actually be possible...
function(guard = identityGuard :: guardGuard)
What we have to write now in ES3 can be so long to achieve this kind
of default value and parameter checking functionality.
--
The spec also has a bit about the return value of coerce.
Call brand.coerce(s). This will either return a value (either s or
possibly a coerced version of s) or throw an exception.
So the return value is actually what the parameter is set to before
the function body executes in the case of a guarded parameter?
Suppose I
wanted MyType to be only positive even integers. Perhaps MyType is a
can only be a function that takes a single argument that is a string
and returns an integer. Perhaps MyType has to be an object with two
function properties named alpha and beta.
Exactly! Some in TC39 want to research contract systems for JS.
This is an alternate proposal to the guards, correct? I don't see
anything in the wiki index about contracts.
We have a
research intern at Mozilla building such a prototype this summer. The plan
was to build a library without syntax, but Waldemar's proposal would give
nice syntax (we think -- details to hash out of course) for this work.
I'd be interested in such a library. Is there any more information
what it might look like to use it?
I sort of hacked at one myself to do type checks but my work wasn't
very compelling.
function foo(a, b) {
assertNumber(a, 'some optional message');
assertString(a, 'some optional message');
// body of function
};
The throw was coming from the assert function rather than the foo
function itself which was not so great.
What about maybe types? Could MyType be defined so that null is not an
allowed value? All the manually written not-null parameter checks in
Java are an unfortunate result of its type checking system.
A static type system could perhaps be built on top of Harmony modules.
Just in case, I didn't mean to imply a static type system.
Re: Converting an existing object to a proxy
On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote: Of course you could go the other way, and remove the default trap implementations. All objects could have the same internal method implementation regardless of whether or not they are a proxy. Within each internal method there could be a check as to whether the object is a proxy (has a [[Handler]]) AND has the trap, if so, it is invoked, otherwise the default pseudocode is performed. The pseudocode for checking if the object has a [[Handler]], and if that [[Handler]] has a trap, and then invoking the trap could all be factored out into a [[Trap]] (or something) internal method, which takes a trap name, and a list of arguments to pass to the trap, and returns whether or not the object has the trap, and if so, also a return value from the trap. This would make for a very concise and clear spec with regard to proxies, and it would be relatively easy to update the current proposal to do this. Thanks, Sean Eagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
On Fri, May 27, 2011 at 1:05 PM, Sean Eagan seaneag...@gmail.com wrote: On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote: Of course you could go the other way, and remove the default trap implementations. All objects could have the same internal method implementation regardless of whether or not they are a proxy. Within each internal method there could be a check as to whether the object is a proxy (has a [[Handler]]) AND has the trap, if so, it is invoked, otherwise the default pseudocode is performed. The pseudocode for checking if the object has a [[Handler]], and if that [[Handler]] has a trap, and then invoking the trap could all be factored out into a [[Trap]] (or something) internal method, which takes a trap name, and a list of arguments to pass to the trap, and returns whether or not the object has the trap, and if so, also a return value from the trap. This would make for a very concise and clear spec with regard to proxies, and it would be relatively easy to update the current proposal to do this. For expository purposes it might still be useful to have actual ES versions of the default pseudocode sections of the internal methods somewhere. This could either be via a non-normative addendum to the spec, or left up to the community to provide outside the spec. The latter option might be better since it could be updated independent of the spec in case of any bugs found. Thanks, Sean Eagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On 05/27/11 02:01, Brendan Eich wrote: More was said here that is good feedback for Harmony, no matter what gets into ES.next. We talked about how shorter function syntax is hard to do well and standardize. The traps include: * do too little by ignoring 'return', jumping a syntax shark and claiming a sigil wanted otherwise (# as shorthand for 'function'), * create completion value leak hazards (# + completion reform as in http://brendaneich.com/2011/01/harmony-of-my-dreams/#functions), * take on new grammar formalism challenges (http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax), * take on other costs (and benefits) by adding semantic value (http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival). We didn't get our act together in time to get shorter function syntax into ES.next at this meeting, which I regard as a personal failure in part. But we will keep trying. It's important, as Alex Russell argued. I took a straw poll: Block lambda revival with feedback issues fixed, in favor (whether 2nd or 1st choice): 6 hands up. Arrow function syntax, with grammar formalism addressed: 8 hands up. There can be only one (of the above): 9 hands up. Therefore I'll work on the http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax strawman (I'll update http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival based on feedback as well, to keep it up to date). What that poll didn't indicate is the soundness of the reasons for choosing one or the other. I slightly prefer A to B is different from if we choose B then we'll need to spend months coming up with a new formalism for the spec. Peter Hallam kindly offered to help come up with a new grammar formalism for the spec that can pass the Waldemar test (if that is possible; not as hard as the Turing test). IIRC Peter said he was (had, would) adding arrow support per the strawman to Traceur (http://code.google.com/p/traceur-compiler/). We talked about Narcissus support too, to get more user testing. If we need to come up with a new formalism, that's a very powerful signal that there's something seriously flawed in the design. Even if it happens to work now, it will produce surprises down the road as we try to extend the expression or parameter grammar. The places where the grammar is not LR(1) up in C++ are some of the most frustrating and surprising ones for users to deal with, and C++ does not even have the feedback from the parser to the lexer. Perl does and its grammar is both ambiguous and undecidable as a result. Note that implementations of Perl exist, which in this case simply means that the documented Perl spec is not sound or faithful -- all implementations are in fact taking shortcuts not reflected in the spec. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux petermich...@gmail.com wrote:
A minifier could, couldn't it?
function foo(a::MyType) {}
would be minified to
function foo(a) {}
These are not the same function at all.
--
sam th
sa...@ccs.neu.edu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux petermich...@gmail.com wrote:
A minifier could, couldn't it?
function foo(a::MyType) {}
would be minified to
function foo(a) {}
These are not the same function at all.
Why?
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Converting an existing object to a proxy
On Fri, May 27, 2011 at 1:05 PM, Sean Eagan seaneag...@gmail.com wrote: On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote: Of course you could go the other way, and remove the default trap implementations. All objects could have the same internal method implementation regardless of whether or not they are a proxy. Within each internal method there could be a check as to whether the object is a proxy (has a [[Handler]]) AND has the trap, if so, it is invoked, otherwise the default pseudocode is performed. The pseudocode for checking if the object has a [[Handler]], and if that [[Handler]] has a trap, and then invoking the trap could all be factored out into a [[Trap]] (or something) internal method, which takes a trap name, and a list of arguments to pass to the trap, and returns whether or not the object has the trap, and if so, also a return value from the trap. This would make for a very concise and clear spec with regard to proxies, and it would be relatively easy to update the current proposal to do this. [[Trap]] would also need to take a boolean throw argument as to whether it should throw if the object has the handler, but does not have the trap. This argument would be set to true for fundamental traps, and false for derived traps. It would not need to take an argument corresponding to the trap proxy argument since that could be appended within [[Trap]] itself. Thanks, Sean Eagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On Fri, May 27, 2011 at 4:03 PM, Peter Michaux petermich...@gmail.com wrote:
On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux petermich...@gmail.com
wrote:
A minifier could, couldn't it?
function foo(a::MyType) {}
would be minified to
function foo(a) {}
These are not the same function at all.
Why?
Because foo(7) produces a TypeError in one, and |undefined| in the
other (assuming that MyType isn't Number).
--
sam th
sa...@ccs.neu.edu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On Fri, May 27, 2011 at 1:24 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, May 27, 2011 at 4:03 PM, Peter Michaux petermich...@gmail.com wrote:
On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux petermich...@gmail.com
wrote:
A minifier could, couldn't it?
function foo(a::MyType) {}
would be minified to
function foo(a) {}
These are not the same function at all.
Why?
Because foo(7) produces a TypeError in one, and |undefined| in the
other (assuming that MyType isn't Number).
Yes but I was thinking of the use of guards as a debugging/development
tool. During development you can verify that foo is never called with
bad values. Then during production, those checks do not need to be
performed. By removing the debugging checks for production, this would
save wire and execution time.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Date.prototype.format
I like the idea of putting .format() on the Date; it would allow for
quick and easy access to a handy formatter. However, would it make
more sense to use the set that php uses to format dates?[0] I would
assume that developers would be more familiar with that.
[0]: http://us3.php.net/manual/en/function.date.php
On Fri, May 27, 2011 at 11:21, Marc Harter wav...@gmail.com wrote:
On Fri, May 27, 2011 at 11:08 AM, John Tamplin j...@google.com wrote:
On Fri, May 27, 2011 at 11:48 AM, Marc Harter wav...@gmail.com wrote:
This may of been thrown though the ringer already but I thought I'd ask.
http://blog.stevenlevithan.com/archives/date-time-format
This is some awesome work on date formatting. What do we think about
having a native Date Format implementation in es.next? Complications?
Seems like this a very commonly needed option. Especially w/ SSJS
now getting more popular.
See http://wiki.ecmascript.org/doku.php?id=strawman:i18n_api
Thanks!
Note that it is rarely useful to format with a fixed pattern, because
different locales have different norms for ordering of the fields,
separators, etc.
By fixed pattern do you mean like d.format('YY/mm/dd')? If so,
doesn't that allow for more expressive power?
--
John A. Tamplin
Software Engineer (GWT), Google
--
Marc (@wavded)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Adam Shannon
Web Developer
University of Northern Iowa
Sophomore -- Computer Science B.S.
http://ashannon.us
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Date.prototype.format
On Fri, May 27, 2011 at 4:59 PM, Adam Shannon a...@ashannon.us wrote: I like the idea of putting .format() on the Date; it would allow for quick and easy access to a handy formatter. However, would it make more sense to use the set that php uses to format dates?[0] I would assume that developers would be more familiar with that. [0]: http://us3.php.net/manual/en/function.date.php Since that isn't the format used in CLDR, you would have to translate the localized formats to that. Also, you can't properly localize date formats for all the locales given that, since for example it doesn't support the concept of standalone vs non-standalone month names. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On Fri, May 27, 2011 at 4:43 PM, Peter Michaux petermich...@gmail.comwrote: Yes but I was thinking of the use of guards as a debugging/development tool. During development you can verify that foo is never called with bad values. Then during production, those checks do not need to be performed. By removing the debugging checks for production, this would save wire and execution time. Sure, until a user typed in a value you never tried during development. You can either rely on these for validating arguments, in which case they have to stay, or you can't, in which case you can treat them like asserts. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On May 27, 2011, at 12:27 PM, Waldemar Horwat wrote:
Peter Hallam kindly offered to help come up with a new grammar formalism for
the spec that can pass the Waldemar test (if that is possible; not as hard
as the Turing test). IIRC Peter said he was (had, would) adding arrow
support per the strawman to Traceur
(http://code.google.com/p/traceur-compiler/). We talked about Narcissus
support too, to get more user testing.
If we need to come up with a new formalism, that's a very powerful signal
that there's something seriously flawed in the design.
Or the spec.
LR(1) is good, I like it, but all the browser JS implementations, and Rhino,
use top-down hand-crafted parsers, even though JS is not LL(1). That is a big
disconnect between spec and reality.
As you've shown these can look good but be future hostile or downright buggy,
so we need a formalism that permits mechanical checking for ambiguities. We
don't want two ways to parse a sentence in the language.
But this does not mean we must stick with LR(1).
Even if it happens to work now, it will produce surprises down the road as
we try to extend the expression or parameter grammar. The places where the
grammar is not LR(1) up in C++ are some of the most frustrating and
surprising ones for users to deal with, and C++ does not even have the
feedback from the parser to the lexer. Perl does and its grammar is both
ambiguous and undecidable as a result. Note that implementations of Perl
exist, which in this case simply means that the documented Perl spec is not
sound or faithful -- all implementations are in fact taking shortcuts not
reflected in the spec.
The problem is we are already cheating.
AssignmentExpression :
ConditionalExpression
LeftHandSideExpression = AssignmentExpression
LeftHandSideExpression AssignmentOperator AssignmentExpression
This produces expressions such as 42 = foo(), which must be handled by semantic
specification. Why can't we have a more precise grammar?
Building on this, destructuring assignment parses more of what was formerly
rejected by semantic checking: {p: q} = o destructures o.p into q (which must
be declared in Harmony -- it is an error if no such q was declared in scope).
We can certainly write semantic rules for destructuring to validate the object
literal as an object pattern; ditto arrays. But the LR(1) grammar is not by
itself valid specifying sentences in the language, just as it did not all these
years for assignment expressions.
Now, for arrow functions (you already know this, just reciting for the
es-discuss list) we could parse the ArrowFormalParameters : Expression and then
write semantics to validate that comma expression as arrow function formal
parameters.
Right now, the expression grammar and the formal parameter list grammar are
close. They have already diverged in Harmony due to rest and spread not being
lookalikes: spread (http://wiki.ecmascript.org/doku.php?id=harmony:spread)
allows ... AssignmentExpression while rest wants only ... Identifier.
But we still can cope: the Expression grammar is a cover grammar for
FormalParameterList.
Of course, the two sub-grammars may diverge in a way we can't parse via parsing
a comma expression within the parentheses that come before the arrow. Guards
seem like they will cause the parameter syntax to diverge, unless you can use
them in expressions (not in the strawman).
The conclusion I draw from these challenges, some already dealt with
non-grammatically by ES1-5, is that we should not make a sacred cow out of
LR(1). We should be open to a formalism that is as checkable for ambiguities,
and that can cope with the C heritage we already have (assignment expressions),
as well as new syntax.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
On May 27, 2011, at 10:59 AM, Peter Michaux wrote: I'm impressed with the following if this is what would actually be possible... function(guard = identityGuard :: guardGuard) What we have to write now in ES3 can be so long to achieve this kind of default value and parameter checking functionality. That is the idea. Notice there's no type system or contract system spec here. This is just syntax plus an extension mechanism for coercing (which can throw). Call brand.coerce(s). This will either return a value (either s or possibly a coerced version of s) or throw an exception. So the return value is actually what the parameter is set to before the function body executes in the case of a guarded parameter? Yes. Suppose I wanted MyType to be only positive even integers. Perhaps MyType is a can only be a function that takes a single argument that is a string and returns an integer. Perhaps MyType has to be an object with two function properties named alpha and beta. Exactly! Some in TC39 want to research contract systems for JS. This is an alternate proposal to the guards, correct? I don't see anything in the wiki index about contracts. No, the guards proposal is not contracts only, nor is it runtime nominal typing only (see http://wiki.ecmascript.org/doku.php?id=strawman:trademarks which was not promoted), nor is it runtime structural types. It's syntax + a plugin system for coercion. We have a research intern at Mozilla building such a prototype this summer. The plan was to build a library without syntax, but Waldemar's proposal would give nice syntax (we think -- details to hash out of course) for this work. I'd be interested in such a library. Is there any more information what it might look like to use it? Not yet -- more when the intern starts, I imagine. Dave may know more. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Guards
To a first, approximation, it would look something like this: http://doc.racket-lang.org/reference/contracts.html ;-) Seriously, the idea is to create contracts that can check structural properties by wrapping values with proxies that lazily do the checking. The core idea, known as higher-order contracts, was first published by Robby Findler: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.4081 Cormac's student, Tim Disney, will be joining us for the summer starting in June, and we'll work on building such a library for JS using proxies. We'll also look into building the syntax into Narcissus. Dave On May 27, 2011, at 4:21 PM, Brendan Eich wrote: On May 27, 2011, at 10:59 AM, Peter Michaux wrote: I'm impressed with the following if this is what would actually be possible... function(guard = identityGuard :: guardGuard) What we have to write now in ES3 can be so long to achieve this kind of default value and parameter checking functionality. That is the idea. Notice there's no type system or contract system spec here. This is just syntax plus an extension mechanism for coercing (which can throw). Call brand.coerce(s). This will either return a value (either s or possibly a coerced version of s) or throw an exception. So the return value is actually what the parameter is set to before the function body executes in the case of a guarded parameter? Yes. Suppose I wanted MyType to be only positive even integers. Perhaps MyType is a can only be a function that takes a single argument that is a string and returns an integer. Perhaps MyType has to be an object with two function properties named alpha and beta. Exactly! Some in TC39 want to research contract systems for JS. This is an alternate proposal to the guards, correct? I don't see anything in the wiki index about contracts. No, the guards proposal is not contracts only, nor is it runtime nominal typing only (see http://wiki.ecmascript.org/doku.php?id=strawman:trademarks which was not promoted), nor is it runtime structural types. It's syntax + a plugin system for coercion. We have a research intern at Mozilla building such a prototype this summer. The plan was to build a library without syntax, but Waldemar's proposal would give nice syntax (we think -- details to hash out of course) for this work. I'd be interested in such a library. Is there any more information what it might look like to use it? Not yet -- more when the intern starts, I imagine. Dave may know more. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Object.defineProperty shorthand
Sorry Mike, just saw your response. I think it would use the same parsing technique as destructuring, the left hand side would need to be post-processed. My grammar might need to be updated to make that work though. The pattern matching strawman [1] has a note about this: Destructuring assignment is parsed as an LHSExpression but then post-processed as a Pattern(false). Note that this non-terminal represents a subset of LHSExpression. [1] http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching On Thu, May 26, 2011 at 4:06 PM, Mike Shaver mike.sha...@gmail.com wrote: On Thu, May 26, 2011 at 11:54 AM, Sean Eagan seaneag...@gmail.com wrote: On Thu, May 26, 2011 at 1:43 PM, Mike Shaver mike.sha...@gmail.com wrote: On Thu, May 26, 2011 at 11:37 AM, Sean Eagan seaneag...@gmail.com wrote: // ! implies non-writable, ~ implies non-enumerable // all assignment operators can be used ! a.b += c Legal parse today, though I'm not sure you can get runtime semantics that aren't an error. Correct, I was intending for it to no longer be an error. I don't understand how that could work. By the time you get the runtime error (trying to increment a boolean value), we have already performed a property access, which can have side-effects. More practically, an engine would have to reconstruct the original syntactic form from the runtime result. addto(c, not(get(a, b))) Mike Thanks, Sean Eagan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On 05/27/11 16:00, Brendan Eich wrote:
On May 27, 2011, at 12:27 PM, Waldemar Horwat wrote:
Peter Hallam kindly offered to help come up with a new grammar formalism for the spec
that can pass the Waldemar test (if that is possible; not as hard as the
Turing test). IIRC Peter said he was (had, would) adding arrow support per the strawman
to Traceur (http://code.google.com/p/traceur-compiler/). We talked about Narcissus
support too, to get more user testing.
If we need to come up with a new formalism, that's a very powerful signal that
there's something seriously flawed in the design.
Or the spec.
LR(1) is good, I like it, but all the browser JS implementations, and Rhino,
use top-down hand-crafted parsers, even though JS is not LL(1). That is a big
disconnect between spec and reality.
As you've shown these can look good but be future hostile or downright buggy,
so we need a formalism that permits mechanical checking for ambiguities. We
don't want two ways to parse a sentence in the language.
But this does not mean we must stick with LR(1).
Even if it happens to work now, it will produce surprises down the road as we try to
extend the expression or parameter grammar. The places where the grammar is not LR(1) up
in C++ are some of the most frustrating and surprising ones for users to deal with, and
C++ does not even have the feedback from the parser to the lexer. Perl does and its
grammar is both ambiguous and undecidable as a result. Note that implementations of Perl
exist, which in this case simply means that the documented Perl spec is not
sound or faithful -- all implementations are in fact taking shortcuts not reflected in
the spec.
The problem is we are already cheating.
/AssignmentExpression/ :
/ConditionalExpression/
/LeftHandSideExpression/ = /AssignmentExpression/
/LeftHandSideExpression/ /AssignmentOperator/ /AssignmentExpression/
This produces expressions such as 42 = foo(), which must be handled by semantic
specification. Why can't we have a more precise grammar?
This is an entirely different issue. The LeftHandSideExpression is still
evaluated as an expression; you just don't call GetValue on it. We chose to
prohibit 42 = foo(); we could equally well have chosen to prohibit foo = 42(),
but neither situation has much to do with the grammar.
Building on this, destructuring assignment parses more of what was formerly
rejected by semantic checking: {p: q} = o destructures o.p into q (which must
be declared in Harmony -- it is an error if no such q was declared in scope).
We can certainly write semantic rules for destructuring to validate the object
literal as an object pattern; ditto arrays. But the LR(1) grammar is not by
itself valid specifying sentences in the language, just as it did not all these
years for assignment expressions.
Now, for arrow functions (you already know this, just reciting for the
es-discuss list) we could parse the /ArrowFormalParameters/ : /Expression/ and
then write semantics to validate that comma expression as arrow function formal
parameters.
Right now, the expression grammar and the formal parameter list grammar are
close. They have already diverged in Harmony due to rest and spread not being
lookalikes: spread (http://wiki.ecmascript.org/doku.php?id=harmony:spread) allows ...
/AssignmentExpression/ while rest wants only ... /Identifier/.
But we still can cope: the /Expression/ grammar is a cover grammar for
/FormalParameterList/.
Of course, the two sub-grammars may diverge in a way we can't parse via parsing
a comma expression within the parentheses that come before the arrow. Guards
seem like they will cause the parameter syntax to diverge, unless you can use
them in expressions (not in the strawman).
The conclusion I draw from these challenges, some already dealt with
non-grammatically by ES1-5, is that we should not make a sacred cow out of
LR(1). We should be open to a formalism that is as checkable for ambiguities,
and that can cope with the C heritage we already have (assignment expressions),
as well as new syntax.
Given that LR(1) is the most general grammar available before you start getting
into serious complexity (it subsumes LALR and other commonly studied grammars),
there is a big cliff here and I think it's foolish to plan to jump off it
without completely understanding the consequences. This is especially true
because there are other paths available for compact function syntax that do not
involve jumping off that cliff.
I realize that C++ and Perl put up with ambiguity, and it seriously bites them.
Quick, what's the difference between the following in C++?
int x(int());
int x(-int());
Waldemar
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On Fri, May 27, 2011 at 9:20 PM, Waldemar Horwat walde...@google.com wrote: Given that LR(1) is the most general grammar available before you start getting into serious complexity (it subsumes LALR and other commonly studied grammars), This is simply begging the question on what is serious complexity. There are plenty of parsers for widely-used programming languages (other than Perl and C++) which use lookahead greater than 1, for example. -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On May 27, 2011, at 6:20 PM, Waldemar Horwat walde...@google.com wrote: This produces expressions such as 42 = foo(), which must be handled by semantic specification. Why can't we have a more precise grammar? This is an entirely different issue. The LeftHandSideExpression is still evaluated as an expression; you just don't call GetValue on it. We chose to prohibit 42 = foo(); we could equally well have chosen to prohibit foo = 42(), but neither situation has much to do with the grammar. That dodges the big cover grammar vs. Precise Grammar issue before us. It assumes the conclusion tha semantics such as Reference internal types are the way to go, because LR(1) can't hack it. Given that LR(1) is the most general grammar available before you start getting into serious complexity (it subsumes LALR and other commonly studied grammars), Again, *all* real JS engines use top-down parsers, including v8. there is a big cliff here and I think it's foolish to plan to jump off it without completely understanding the consequences. Agreed. Let's understand them, or use Expression as a cover grammar -- just like LetHandSideExpression (which produces NewExpression, a real jswtf). This is especially true because there are other paths available for compact function syntax that do not involve jumping off that cliff. Such as? I realize that C++ and Perl put up with ambiguity, and it seriously bites them. Quick, what's the difference between the following in C++? int x(int()); int x(-int()); Yet C++ is wildly successful inside Google and outside. Trade-offs... /be Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On May 27, 2011, at 6:42 PM, Brendan Eich wrote: On May 27, 2011, at 6:20 PM, Waldemar Horwat walde...@google.com wrote: This produces expressions such as 42 = foo(), which must be handled by semantic specification. Why can't we have a more precise grammar? This is an entirely different issue. The LeftHandSideExpression is still evaluated as an expression; you just don't call GetValue on it. We chose to prohibit 42 = foo(); we could equally well have chosen to prohibit foo = 42(), but neither situation has much to do with the grammar. That dodges the big cover grammar vs. Precise Grammar issue before us. It assumes the conclusion tha semantics such as Reference internal types are the way to go, because LR(1) can't hack it. Again, real browser JS engines use top-down parsing and no Reference type, instead specializing the AST for LeftHandSideExpressions to be precise, with early errors per ES5 (and even in ES3 era) for nonsense-LHS-expressions. This is not an argument to remove Reference types from the spec. Maybe we should if we get a better parsing algorithm and grammar. There is a web of trade-offs. I realize that C++ and Perl put up with ambiguity, and it seriously bites them. Quick, what's the difference between the following in C++? int x(int()); int x(-int()); Yet C++ is wildly successful inside Google and outside. Trade-offs... I hasten to add that I'm not endorsing the undecideable crazyland of C++ syntax. Simply pointing to trade-offs taken differently in other languages that are surely successful in spite of lack of precise-enough LR(1) (cover) grammars. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
