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

Re: May 24-26 rough meeting notes

On May 27, 2011, at 6:20 PM, Waldemar Horwat 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 exp

Re: May 24-26 rough meeting notes

On Fri, May 27, 2011 at 9:20 PM, Waldemar Horwat 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

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 (ha

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 assignme

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-

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 checkin

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

Re: Guards

On Fri, May 27, 2011 at 4:43 PM, Peter Michaux wrote: > 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 d

Re: Date.prototype.format

On Fri, May 27, 2011 at 4:59 PM, Adam Shannon 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

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/fun

Re: Guards

On Fri, May 27, 2011 at 1:24 PM, Sam Tobin-Hochstadt wrote: > On Fri, May 27, 2011 at 4:03 PM, Peter Michaux wrote: >> On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt >> wrote: >>> On Fri, May 27, 2011 at 1:59 PM, Peter Michaux >>> wrote: A minifier could, couldn't it? >>

Re: Guards

On Fri, May 27, 2011 at 4:03 PM, Peter Michaux wrote: > On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt > wrote: >> On Fri, May 27, 2011 at 1:59 PM, Peter Michaux >> wrote: >>> >>> A minifier could, couldn't it? >>> >>> function foo(a::MyType) {} >>> >>> would be minified to >>> >>> func

Re: Converting an existing object to a proxy

On Fri, May 27, 2011 at 1:05 PM, Sean Eagan wrote: > On Fri, May 27, 2011 at 12:43 PM, Sean Eagan 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 ar

Re: Guards

On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt wrote: > On Fri, May 27, 2011 at 1:59 PM, Peter Michaux 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 _

Re: Guards

On Fri, May 27, 2011 at 1:59 PM, Peter Michaux 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 m

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 cl

Re: Converting an existing object to a proxy

On Fri, May 27, 2011 at 1:05 PM, Sean Eagan wrote: > On Fri, May 27, 2011 at 12:43 PM, Sean Eagan 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 ar

Re: Converting an existing object to a proxy

On Fri, May 27, 2011 at 12:43 PM, Sean Eagan 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

Re: Guards

On Fri, May 27, 2011 at 1:44 AM, Brendan Eich 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

Re: Converting an existing object to a proxy

On Fri, May 27, 2011 at 2:26 AM, David Bruant wrote: > On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan 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 fu

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 alrea

Re: Converting an existing object to a proxy

On Fri, May 27, 2011 at 12:18 PM, Sean Eagan 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

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 t

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: > > A

Re: Date.prototype.format

On Fri, May 27, 2011 at 12:21 PM, Marc Harter 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

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

Re: Date.prototype.format

On Fri, May 27, 2011 at 11:08 AM, John Tamplin wrote: > On Fri, May 27, 2011 at 11:48 AM, Marc Harter 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 format

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 th

Re: Date.prototype.format

On Fri, May 27, 2011 at 11:48 AM, Marc Harter 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 impl

Re: Converting an existing object to a proxy

On Fri, May 27, 2011 at 10: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

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 co

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 oppo

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 thi

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 wo

Re: Converting an existing object to a proxy

On Fri, May 27, 2011 at 5:45 AM, Tom Van Cutsem 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 pow

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

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

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 > wrote: [documenting/expanding some ideas briefly discussed at today's

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 arbitraril

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 relate

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 tha

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 wrote: >> [documenting/expanding some ideas briefly discussed at today's meeting] >> >> The current proxy proposal has a method to create a new

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

Re: May the defineProperty method of a proxy handler throw a TypeError?

Good catch. I count 5 occurrences of 'reject' on the page, 4 of these are called when the corresponding trap is not defined on the handler. For these cases, we should probably throw a TypeError, like we do for other traps (like for fix() in Object.freeze and getOwnPropertyNames in Object.getOwnProp

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 cros

Re: May the defineProperty method of a proxy handler throw a TypeError?

2011/5/26 David Bruant > 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

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 Prox

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) :

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 Comprehen

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 i