I would think we'd use the ghastly syntax of Java as a cautionary tale rather than something from which to draw inspiration...
On 7 Jul, 2010, at 11:26 AM, Jürg Lehni wrote: > To pick up the lambda discussion again, it is maybe of interest to have an > eye on the recent developments around the introductions of Lambda in Java: > > http://www.infoq.com/news/2010/06/lambda-syntax-debate > http://stronglytypedblog.blogspot.com/2010/06/so-you-find-java-7-closure-syntax-nasty.html > > Jürg > > On 29 Apr 2010, at 18:03, Brendan Eich wrote: > >> On Apr 29, 2010, at 12:25 AM, Alex Russell wrote: >> >>> Some small, pre-colored panels for the shed. Given that these are mostly >>> matters of syntax and not semantics, please believe me when I suggest that >>> the warts discussed herein present sharp edges that should be rounded off >>> by the committee -- not because they're interesting in any way but because >>> the primary users of the language are shipping (bad) fixes around the >>> network billions of times a day. Such rank inefficiency needs sunset date. >> >> This is not just about syntax. Let's ignore the threat of being accused of >> bikeshedding and evaluate holistically. >> >> >>> Summary of proposals: >>> --------------------- >>> >>> // 1.) Really generic generics >>> >>> ArrSubtype = function() { }; >>> ArrSubtype.prototype = Object.create(Array.prototype); >>> >>> var nas = new ArrSubtype(); >>> nas.push("howdy", "pardner"); >>> >>> nas.slice(0) instanceof Array; // currently true >>> nas.slice(0) instanceof ArrSubtype; // will be true after fix >> >> An incompatible change, but would it break much code? Hard to say without >> trying it at scale. Here are some codesearch results: >> >> http://www.google.com/codesearch?hl=en&lr=&q=%22prototype+%3D+[]%3B%22+lang%3Ajavascript&sbtn=Search >> http://www.google.com/codesearch?hl=en&lr=&q=%22prototype+%3D+new+Array%3B%22+lang%3Ajavascript&sbtn=Search >> >> How would it work exactly? More below on "subtyping". >> >>> // 2.) Shorthand for "function", aka the "not lambda" >>> >>> node.addEventListener("click", #(e){ e.preventDefault(); }); >>> node.removeEventListener("click" obj!#(e){ ... }); // see #3 >> >> The hash or number sign is not obviously all about functions. I've tried out >> the other alternatives in recent talks. No one is really enthusiastic about >> any of >> >> λ foo() (bar + baz) >> ƒ foo() (bar + baz) >> \foo() (bar + baz) >> >> (the foo name is optional but should be expressible). >> >> The Greek lowercase lambda is actually an incompatible change from ES3 >> (perfectly legal identifier there). It's also hard to type on most keyboards. >> >> The florin is easier (alt-f on my Mac) but maybe a bit visually light and >> hard to scan for quickly, and it's arguably harder for newcomers to divine >> its meaning. >> >> The \ does not make much sense, but it was proposed first among all of these >> on es-discuss, IIRC. >> >> One wag replied after I had people vote on these "what about voting on >> function"? Many hands then went up, more than for any of the above. This set >> the cat among the shorthand-promoting pigeons. >> >> >>> // 3.) Shorthand for Function.prototype.bind >>> >>> var boundMethod = obj!method; >>> node.addEventListener("click", obj!method); >>> node.removeEventListener("click", obj!method); >> >> There's some precedent for ! as non-blocking send, returning a promise. >> >> >>> NodeList.prototype.parents = function() { >>> // should return a NodeList >>> return this.map(function(n) { return n.parentNode; }); >>> } >> >> IIRC a NodeList is a "live array", sort of a query-as-array or cursor that >> is continuously updated when the DOM mutates. It's really not an Array. >> >> >>> * Kill code in libraries that exists only to wrap built-in methods thanks >>> to existing mis-specification of generics >>> * Sub-types of Array suffer many warts, but making Array.prototype methods >>> return instances of subtypes will allow DOM-side changes to make subtyping >>> much more natural in real-world systems >> >> "Subtype" is not well-defined in JS. Prototype-based delegation is not the >> <: relation from type theory, because of mutation, both of the prototype >> object and of the future binding of f in a scope and f.prototype in >> user-defined function f. >> >> This isn't just a pedantic point. If we don't have a well-defined relation, >> how can we evaluate proposals that want to improve support for that >> relation, whatever it is? >> >> In this case it seems to me you might want the result of Array generics to >> be created by calling (new this.constructor). For nas.slice(0), the generic >> slice code would then put elements got from |this| into the result of (new >> this.constructor). Is this the spec you want? >> >> If so, it seems like an improvement, but again constructor has low integrity >> (none for user-defined constructor functions) without freeze, so there's no >> subtype relation in the formal <: sense. Still, it seems to me an >> improvement, ignoring the incompatibility. >> >> >>> // equivalent: >>> function(){ return 10; } >>> #(){ return 10; } >>> #{ return 10; } // no args, optionally elide () >> >> This does several things at once, and we have discussed one of them: turning >> the completion value of the body into the return value. >> >> The objection to this, voiced clearly by Waldemar, is the unintended >> completion value in tail position leaking out as a return value. This is >> hard to see and test for, and it requires ugly void operator usage, or a >> dummy final value, to control. >> >> Dave Herman has recently proposed >> http://wiki.ecmascript.org/doku.php?id=strawman:let_expressions, which >> include an explicit "completion value here" prefix: => 10; in tail position >> would result in 10, and without => the result would be the undefined value. >> >> >>> * equivalent semantics to the function(){} syntax >> >> No, not equivalent because tail position completion values are not return >> values with functions. Again semantics matter, not just syntax. >> >> >>> 3.) Syntax for bound function de-reference >>> [snip] So why does this suck? Two reasons: it's long-ish to type, and it >>> doesn't do what the dot operator does -- i.e., return the same function >>> object every time. >> >> The lack of memoization is a good point. I've written at length about the >> challenges for implementations to "join" function objects as an optimization: >> >> https://mail.mozilla.org/pipermail/es-discuss/2010-February/010830.html >> https://mail.mozilla.org/pipermail/es-discuss/2010-February/010832.html >> >> >>> What to do? We propose the bang operator -- ! -- as a new form of binding >>> de-reference of function objects. It's one character and even includes a >>> dot. It has the following additional properties: >>> >>> 1.) all de-references via bang from an object/function pair return the >>> *same* function object (modulo #4). >>> 4.) bang-bound functions are weakly referenced. If GC would otherwise >>> remove a function object from memory, having previously bang-bound a >>> function should not keep the function object alive >> >> This is a tricky area. We have experience with such ephemeral objects. >> Problem is, sometimes users decorate them with ad-hoc properties >> ("expandos"), which by your proposed rules will not keep them alive. The GC >> runs, and the decorator is surprised to see the ad-hoc properties gone. >> >> Apart from the ! as promise-send and weak-vs.-expando issues, the big >> objection here is that you make each reference specify bound-ness and >> require memoization on the fly. An alternative would be to bind at method >> definition point. Then you could only extract the bound method, no matter >> how used, and via the conventional . operator. See >> >> http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_methods >> >> i'm against "invoke-only" methods, but bound method definition syntax is >> easier for users and implementors to swallow, and preserves dot as the one >> operator needed for extraction. It would also make the method reference >> strong, which would avoid the too-weak loss of expando problem. >> >> Glad to see this proposed for discussion -- good suggestions, directionally >> and in some details. >> >> /be >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
