WeakMap not the weak needed for zombie views
Hi, I've been reading about WeakMap in the draft. To my surprise, it is not at all what I thought it would be or what I was hoping to use. At least that is my understanding. My use case is in MV* architectures. With current MV* frameworks, a model holds strong references to the views observing that model. If a view is removed from the DOM, all other references in the application are lost to that view, but the view never stopped observing the model object, that strong reference from model to view results in a zombie view. Avoiding this means views need to have `destroy` methods that unsubscribes the view from the model. It is easy for the application programmer to forget to call a view's `destroy` method and the application leaks memory. As a result of the leak, the user experience and ultimately the reputation of the Web suffers. If a model could hold weak references to its observers, this would safeguard against accidental and inevitable application programmer forgetfulness. It appears that WeakMap cannot help solve the current MV* zombie view problem. Or did I miss something? I was expecting WeakMap to hold its values weakly and set them to undefined or delete the associated key when the value was garbage collected. Does anything exist or is coming to help solve the zombie problem? Smalltalk Squeak models use a WeakIdentityKeyDictionary which holds its keys weakly. The difference compared with the ECMAScript WeakMap is that instances of WeakIdentityKeyDictionary have an iterator so the observers can be stored as the keys and still discoverable without keeping other strong references. The ECMAScript standard specifically disallows in iterator. Thanks, Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set Objects
On Fri, Mar 29, 2013 at 5:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 29, 2013, at 3:02 PM, Peter Michaux wrote: 15.16.4.6 Why will callbackfn be called with the first two parameters being the same? That does not seem like the most practical or intuitive behavior for a set. The intent is that all forEach methods use the same callback signature. This is explained in the second note. The third NOTE about visiting elements that are deleted or added during iteration is excellent. Browsers have certainly varied in their behavior. Yes, but this is just a note. The specification algorithm normatively exhibit this behavior which is where it really counts. In that case, I think the second note might be an error. The specification algorithm has the following 8.a.i) Let funcResult be the result of calling the [[Call]] internal method of callbackfn with T as thisArgument and a List containing e and S as argumentsList. That means the callback function is called with only two arguments not three as mentioned in the second note. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set some, every, reduce, filter, map methods
The order of iteration of a set is the order of insertion of elements into the set. So reduce and reduceRight would actually be different. I should have included reduceRight in my list. Peter On Sat, Mar 30, 2013 at 5:06 AM, Herby Vojčík he...@mailbox.sk wrote: Definitely, +1. Also, add reduceRight as well, even if it would only do the same as reduce. Peter Michaux wrote: In another thread, I'm told there is currently no plans to add the following to Set.prototype. some every reduce filter map These seem like very natural additions and the type of operations that one would want to do on sets. Peter ___ 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
Set Objects
Some comments and questions about the Set draft specification... - - - Section 15.16 begins with the following which seems to need an English clean-up. Set objects are collections of ECMAScript language values. A distinct value may only occur once as elements of a Set’s collection. Distinct values as discriminated using the a comparision algorithm that is selected when the Set is created. Set objects are collections of ECMAScript language values. A distinct value may only occur once as an element of a Set. Distinct values are discriminated using the comparison algorithm that is selected when the Set is created. - - - Section 15.16.1 it initializes its this value with the internal state necessary to support the Set.prototype internal methods. What does that mean? Cannot the caller set the value of this using the call or apply methods? - - - Section 15.16.1 The Set constructor is designed to be subclassable. It may be used as the value in an extends clause of a class definition. Subclass constructors that intend to inherit the specified Set behaviour must include a super call to Set. Why is this in section 15.16.1 which is about calling Set as a function? Isn't inclusion of the above in 15.16.2 sufficient? - - - Section 15.16.1.1 step 4 missing [[ step 10 font size smaller inside [[]] NOTE mentions Map, key, value which seems like it might be a copy and paste error from the Map section of the specification. Does the iterator really need to return two-element array-like objects in this case? - - - Section 15.16.2.1 step 2 be the be the NOTE mentions an iterable parameter but there is no indication in this section where that would be in the parameter list. NOTE mentions values but section 15.16.1.1 doesn't indicate how that would be used rather than @@iterator. - - - 15.16.4.2 I think it would be useful if Set.prototype.add could take multiple values Instead of set.prototype.add(a); set.prototype.add(b); set.prototype.add(c); allow the following set.prototype.add(a, b, c); It would be useful to know if the set was modified as a result of the add call. Step 8.a.i return false. Step 9 return true. This would allow a model layer in an MVC application to know if a change event needs to be fired or not. - - - 15.16.4.3 Should 15.16.4.2's step 5 be inserted between 15.16.4.3's steps 4 and 5? This would define the content of entries. It would be useful to know if the set was modified as a result of the clear call. For a previously empty set, clear would return false. Otherwise true. - - - 15.16.4.4 Delete is good because it returns true or false indicating if the set was modified or not. The add, clear, and delete method's have very inconsistent return values. Returning true or false for all depending if the set was modified or not would be great. Could delete take multiple arguments, all of which will be deleted from the set? - - - 15.16.4.6 Why will callbackfn be called with the first two parameters being the same? That does not seem like the most practical or intuitive behavior for a set. The third NOTE about visiting elements that are deleted or added during iteration is excellent. Browsers have certainly varied in their behavior. The length property of forEach is defined to be 1. The length of other Set.prototype methods is not defined. - - - 15.16.4.8 A set has no concept of keys. The existence of Set.prototype.keys seems inappropriate for a set. - - - Will the following methods be added to Set.prototype? some every reduce filter map toArray union intersection difference (other Mathematical set operations?) - - - What is and where is section 16.15.5? - - - Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Add intersections and unions to Set
On Mon, Mar 4, 2013 at 10:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 4, 2013 at 10:08 AM, al...@instantbird.org wrote: It would be useful to be able to form the intersection and the union of two Sets. These are natural operations that are currently not part of the API (http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets). Similar methods would make sense for Map, but one would have to think about what to do in the case where the key but not the value matches. An intersection is equivalent to a particular filter, so an alternative might be to add a method like Array.filter to Sets instead. (I filed bug 847355 for this and was told this mailing list was the right place for this suggestion.) Yes please, and also minus (remove from set A all elements it shares with set B). All three of these are fairly vital for a lot of code using sets. I agree that these methods would be useful. They are common set operations and they do seem missing from the Set draft spec. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Set some, every, reduce, filter, map methods
In another thread, I'm told there is currently no plans to add the following to Set.prototype. some every reduce filter map These seem like very natural additions and the type of operations that one would want to do on sets. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On Mon, Mar 25, 2013 at 2:55 AM, Marius Gundersen gunder...@gmail.com wrote: One thing which is impossible to make in JavaScript today is a weakly referenced event listener system. In such a system an event listener is not strongly referenced by the event system, so events are only dispatched to it as long as another object holds a reference to it. Being able to make an observable subject that keeps a weak list of observers would be very useful to ease memory management within an application and avoid accidental memory leaks at the application level. Sometimes the application programmer may forgot to remove a observer from an observable subject, for example. With regard to the MVC architecture, this could be the best addition to the language to make application development easier. A view might mistakenly not unsubscribe from its associate model when the view is destroyed, for example. That or the view's destroy method is never even called because the application programmer forgot to call it. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
I listed quite a few suggestions in a variety of emails to this list. I think this is a list of all of them... https://mail.mozilla.org/pipermail/es-discuss/2012-February/020460.html https://mail.mozilla.org/pipermail/es-discuss/2012-February/020480.html https://mail.mozilla.org/pipermail/es-discuss/2012-February/020481.html https://mail.mozilla.org/pipermail/es-discuss/2012-February/020483.html https://mail.mozilla.org/pipermail/es-discuss/2012-February/020523.html https://mail.mozilla.org/pipermail/es-discuss/2012-February/020575.html https://mail.mozilla.org/pipermail/es-discuss/2012-February/020607.html https://mail.mozilla.org/pipermail/es-discuss/2012-February/020609.html Set union, difference, and intersection methods were in one post but I don't see that in the archives. Peter On Fri, Mar 30, 2012 at 8:10 AM, Mark S. Miller erig...@google.com wrote: Dave and I decided to collaborate on this and will present it at the May meeting. So no, not yet. As always, suggestions welcome. On Thu, Mar 29, 2012 at 10:22 PM, Peter Michaux petermich...@gmail.com wrote: On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org wrote: The January 19 2012 meeting notes recorded here: https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html include At next meeting MarkM will present a tiny API proposal for maps and sets. Has this meeting happened yet? If so are the results about Map and Set posted somewhere? Thanks, Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set polyfill with a has method more efficient than O(n)
On Thu, Mar 29, 2012 at 10:20 PM, Brendan Eich bren...@mozilla.org wrote:
Peter Michaux wrote:
I've worked on a generic Set polyfill. It is quite a simple task to
build one but determining if an object is in the set is O(n) with the
following has method.
Set.prototype.has = function(element) {
for (var i = 0, ilen = this._elements.length; i ilen; i++) {
if (element === this._elements[i]) {
You need Object.is here, not ===, per
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
Object.is spec:
http://wiki.ecmascript.org/doku.php?id=harmony:egal
Thanks for mentioning this.
What is the license on the is function implementation shown in the
wiki? I'd like to include it in a file that is 2-clause BSD licensed.
I see the wiki itself is under the CC non-commercial license which
seems incompatible.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set polyfill with a has method more efficient than O(n)
On Fri, Mar 30, 2012 at 12:44 AM, David Bruant bruan...@gmail.com wrote: One idea would be that each Set puts a unique marker on each object it contains I thought about an approach like this but am looking to avoid mutating the elements in the set. Thanks though. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Set polyfill with a has method more efficient than O(n)
I've worked on a generic Set polyfill. It is quite a simple task to
build one but determining if an object is in the set is O(n) with the
following has method.
Set.prototype.has = function(element) {
for (var i = 0, ilen = this._elements.length; i ilen; i++) {
if (element === this._elements[i]) {
return true;
}
}
return false;
};
It seems like a long shot but is there some trick that someone has
discovered that allows for a more efficient generic Set polyfill?
Thanks,
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set length property
On Sun, Feb 12, 2012 at 7:08 PM, Brendan Eich bren...@mozilla.org wrote: The January 19 2012 meeting notes recorded here: https://mail.mozilla.org/pipermail/es-discuss/2012-January/019784.html include At next meeting MarkM will present a tiny API proposal for maps and sets. Has this meeting happened yet? If so are the results about Map and Set posted somewhere? Thanks, Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Second arguments for Array.prototype.sort: map function
On Mon, Feb 20, 2012 at 11:52 AM, Xavier MONTILLET xavierm02@gmail.com wrote: what I would like is to be able to do this: var sortedArray = array.sort( compare, f ); I think the above is not very readable. The following is more readable and shows the order in which the more modular parts are being applied. var sortedArray = array.map(f).sort(compare); Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
On Thu, Feb 23, 2012 at 12:35 PM, Mark S. Miller erig...@google.com wrote:
if (arr.contains(foo)) {
vs
if (arr.indexOf(foo) !== -1) {
The readability of the above two options is very different. The first
option is far superior as it expresses what the programmer wants to
know. The second options is an expression of how it can be
accomplished and requires understanding of indexOf's return values.
I think the addition Array.prototype.contains would be a good, simple
one that would improve programs. The fact that this function exists in
libraries means it is useful in a general in the opinion of at least
several programmers.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Second arguments for Array.prototype.sort: map function
I think I misunderstood your intent. Is what you want equivalent to
the following?
arr.map(function(el){return {a:el,b:f(el)};}).sort(function(x, y)
{return x.b y.b;}).map(function(el){return el.a;});
Peter
On Thu, Feb 23, 2012 at 6:12 PM, Peter Michaux petermich...@gmail.com wrote:
On Mon, Feb 20, 2012 at 11:52 AM, Xavier MONTILLET
xavierm02@gmail.com wrote:
what I would like is to be able to do this:
var sortedArray = array.sort( compare, f );
I think the above is not very readable.
The following is more readable and shows the order in which the more
modular parts are being applied.
var sortedArray = array.map(f).sort(compare);
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.contains
How about obsoleting indexOf, adding something better with a different
name, and then building a contains method on top of that?
Peter
On Thu, Feb 23, 2012 at 6:49 PM, Mark S. Miller erig...@google.com wrote:
My point is that if we bother to add any contains method, that it shouldn't
be broken the same way that indexOf is, making it an improvement over
indexOf both in looks and in functionality. In other words, do you want
[3.0, NaN, 4.0].contains(NaN)
to return false? I don't. I wish
[3.0, NaN, 4.0].indexOf(NaN)
didn't return -1, but it is now too late to fix that.
only a bit tongue in cheek
Think this kind of stupidity isn't dangerous? Here's a riddle: Say a
JavaScript implementation, when asked to run the following program, instead
kills the user. Does it conform to the spec?
[3.0, NaN, 4.0].sort(function compare(a, b) { return a b ? -1 : a ===
b ? 0 : 1; })
When sorting a valid packed array of valid IEEE floating point values, you
take your life in your hands.
/only a bit tongue in cheek
On Thu, Feb 23, 2012 at 6:18 PM, Peter Michaux petermich...@gmail.com
wrote:
On Thu, Feb 23, 2012 at 12:35 PM, Mark S. Miller erig...@google.com
wrote:
if (arr.contains(foo)) {
vs
if (arr.indexOf(foo) !== -1) {
The readability of the above two options is very different. The first
option is far superior as it expresses what the programmer wants to
know. The second options is an expression of how it can be
accomplished and requires understanding of indexOf's return values.
I think the addition Array.prototype.contains would be a good, simple
one that would improve programs. The fact that this function exists in
libraries means it is useful in a general in the opinion of at least
several programmers.
Peter
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
set.reset method
I don't know how rich the committee wants to make objects in ES.next.
For example, what about a set.reset method?
Set.prototype.reset = function() {
this.empty();
for (var i = 0, ilen = arguments.length; i ilen; i++) {
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.reset method
Sorry. Incomplete message before and premature send.
Set.prototype.reset = function() {
this.empty();
for (var i = 0, ilen = arguments.length; i ilen; i++) {
this.add(arguments[i]);
}
};
Peter
On Wed, Feb 15, 2012 at 10:39 PM, Peter Michaux petermich...@gmail.com wrote:
I don't know how rich the committee wants to make objects in ES.next.
For example, what about a set.reset method?
Set.prototype.reset = function() {
this.empty();
for (var i = 0, ilen = arguments.length; i ilen; i++) {
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
set.add and set.delete arguments
Can set.add and set.delete take multiple arguments? This would go
nicely with the spread of operation on an iterate that was discussed
for multiple arguments to the Set constructor.
var set0 = new Set('alpha', 'beta');
set0.add('gamma', 'delta');
var set1 = new Set('epsilon', 'zeta');
set0.add(...set1);
set0.count; // 6
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.add and set.delete arguments
If add and delete take multiple arguments, the return value could be
changed from a boolean to the number of elements added or deleted, or
to the set of elements added or deleted?
Peter
On Wed, Feb 15, 2012 at 10:54 PM, Peter Michaux petermich...@gmail.com wrote:
Can set.add and set.delete take multiple arguments? This would go
nicely with the spread of operation on an iterate that was discussed
for multiple arguments to the Set constructor.
var set0 = new Set('alpha', 'beta');
set0.add('gamma', 'delta');
var set1 = new Set('epsilon', 'zeta');
set0.add(...set1);
set0.count; // 6
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Tue, Feb 14, 2012 at 12:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? I think that should be a set with one element. The element is an array of length three. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
set.empty() method
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very inefficient.
set.forEach(function(element) {
set['delete'](element);
});
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
I expected a set would have an undefined iteration order to give implementations the opportunity to make optimizations that maintaining order would not allow. On Mon, Feb 13, 2012 at 8:06 PM, Adam Shannon a...@ashannon.us wrote: I thought that Set wasn't going to even have insertion order as a possible. The idea behind any Set (outside of ES even) is that it is just a collection of elements, unordered. On Mon, Feb 13, 2012 at 19:32, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Feb 12, 2012, at 4:52 PM, Peter Michaux wrote: In the proposal, iterators for Set are listed as todo. If engine implementers have decided to start moving forward implementing Sets, then it would be great if they could get iteration going sooner than later. http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Before getting too deep into iteration protocol for Sets (and Maps) there is a more fundamental issues: Will Set define a standard, implementation independent ordering of elements? If so, what is the basis for the ordering? Is it iteration order? Is so this will add likely add space overhead to the internal representation of Set and Map and/or time overhead to insert/delete operations. Also, for specializations of Set such as Integer Sets insertion order may not be the most desirable iteration ordering. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Adam Shannon Developer University of Northern Iowa Sophomore -- Computer Science B.S. Mathematics http://ashannon.us ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
set.add and set.delete return values
The return value set.delete tells the caller if the set was modified or not. It would be useful if the return value of set.add did the same. For example, this way a model in MVC could efficiently know if and notify observers that a real change to the set actually happened. http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: set.delete method name
I was talking about shims.
PEter
On Sun, Feb 12, 2012 at 1:50 PM, Oliver Hunt oli...@apple.com wrote:
Are the Set, Map, etc types going to be implemented in any engine that
doesn't already have ES5 unreserved property name semantics?
Or are we talking about implementing shims in non-ES6 engines (and so
possibly ES5)?
--Oliver
On Feb 12, 2012, at 1:46 PM, Brendan Eich wrote:
Agreed, my remove is the best all-around name was biased toward the past.
We can hang tough. This isn't a huge hardship. Indeed way back in 1996 when
Nick Thompson and I connected JS and Java at Netscape, some Java APIs
required, e.g. file['delete']() instead of file.delete(). I wish I had not
reserved property names in '95. Fixed in ES5!
/be
Mark S. Miller wrote:
I feel strongly that delete is the right name for this. Currently, all
the method names (get, set, has, delete) relate directly to the names
associated with these operations when applied to properties, making them
more mnemonic.
The need to say collection['delete'](...) rather than
collection.delete(...) is only a temporary measure until the ES3 browsers
fade out enough to either 1) be ignored, or 2) be supported only as the
target of an ES5/6 - ES3 translation. Granted this will take years. But
we'll be living with these choices for many more years after that.
On Sat, Feb 11, 2012 at 11:11 PM, Peter Michaux petermich...@gmail.com
mailto:petermich...@gmail.com wrote:
The Set proposal has a delete method. Old ECMAScript implementations
do not allow delete to appear as a bare method name like
set.delete('foo') and it is necessary to write the awkward
set['delete']('foo'). Because of this and knowing polyfills will be
written to support Set in older implementations, would it be better to
choose remove as the method name so that set.remove('foo') can be
written in the older implementations? I think this would save a lot of
unnecessary debugging for cross-browser programming.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
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
___
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
Set length property
In the proposal, set objects have no length property. It is common to
want to know the length of a set.
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
For example, it would be good to be able to do the following.
var s = new Set();
s.add('alpha');
s.add('beta');
s.length; // 2
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Set iterators
In the proposal, iterators for Set are listed as todo. If engine
implementers have decided to start moving forward implementing Sets,
then it would be great if they could get iteration going sooner than
later.
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
Looking at the Array iterators...
It doesn't seem very difficult to specify forEach as a proposal
sketch. It just has to do the following, doesn't it?
var s = new Set();
s.add('alpha');
s.add('beta');
s.forEach(function(element){});
reduce, every, and some seem similarly easy. reduceRight is
unnecessary as a set has no order.
filter and map are similarly easy but would return set objects.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
set.delete method name
The Set proposal has a delete method. Old ECMAScript implementations
do not allow delete to appear as a bare method name like
set.delete('foo') and it is necessary to write the awkward
set['delete']('foo'). Because of this and knowing polyfills will be
written to support Set in older implementations, would it be better to
choose remove as the method name so that set.remove('foo') can be
written in the older implementations? I think this would save a lot of
unnecessary debugging for cross-browser programming.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: prototype focus
On Thu, Jun 30, 2011 at 4:46 PM, Axel Rauschmayer a...@rauschma.de wrote:
What problem have you solved by giving the prototype a name?
The names I choose makes it clear to the reader that the prototype is
one element (zero) in a set of elements (complex numbers).
A name gives a reference to the object that is not related to any
constructor function. Constructor functions are something separate
from the prototype object (zero).
The proposal is
not (just) about giving prototypes names.
Understood but it seemed that the proposal started from the idea that
JavaScript needs to get back to its prototype roots. I don't think
JavaScript has ever been far from its prototype roots especially if
the programmer shifts to thinking about a prototype object instead of
thinking about a functions prototype property.
Problems that both prototypes-as-classes (PAC) and class literals (CL) are
trying to solve are:
- Subclassing is hard and not directly supported by the language: connecting
prototypes, chaining constructors, super-references.
Object.getPrototypeOf(this).foo.call(this) is pretty long.
- Class properties are not inherited
Class property inheritance is definitely a secondary issue compared
with the instance objects themselves.
(CoffeeScript copies them “manually”).
Which I think is unsatisfactory and has a lot of gotchas when some
properties are arrays and other properties have primitive values.
--
It seems to me that perhaps the PaC drifted too far or perhaps started
too far from what JavaScript has already. If the idea is to shift the
focus more towards prototypes, then starting from something like what
I've written and adding super syntax would be more consistent with
what JavaScript already has.
Peter
If none of these issues are involved then today’s constructor functions are
OK.
Pros of each approach:
(1) Pro CL: no need to support two kinds of classes: prototypes *and*
constructor functions.
(2) Pro PAC: look the same as class literals, but don’t need an extra
translation step.
(1) weighs heavily and will probably make it impossible to sell PAC to TC39.
There is the precedent of Python having two styles of classes [1] at the
same time, but I don’t think they diverged as heavily as constructor
functions and PAC.
If you want to argue against PAC benefits, take a look at Sect. 3 here:
http://www.2ality.com/2011/06/prototypes-as-classes.html#3
[1] http://stackoverflow.com/questions/54867/old-style-and-new-style-classes-in-python
Axel
On Jul 1, 2011, at 1:07 , es-discuss-requ...@mozilla.org wrote:
From: Peter Michaux petermich...@gmail.com
Date: June 30, 2011 21:54:47 GMT+02:00
To: es-discuss es-discuss@mozilla.org
Subject: prototype focus
There seems to have been a lot of fuss here about focusing on
prototypes first rather than on constructor functions. As it stands
now, I don't see how JavaScript makes focusing on prototypes
difficult.
// focus on the prototype first
// Make it non-abstract.
// Call it zero not number.
// (Another example: Call the object adam not person.)
var zero = {
realPart: 0,
imagPart: 0,
getMagnitude: function() {
return Math.sqrt(this.realPart * this.realPart +
this.imagPart * this.imagPart);
}
};
// JavaScript makes it possible to have a variety of constructors
// for objects that have zero as their prototype.
// Yes the constructor property is gone. Is that actually a problem?
function Real(r) {
this.realPart = r;
}
Real.prototype = zero;
function Imaginary(i) {
this.imagPart = i;
}
Real.prototype = zero;
function Complex(r, i) {
this.realPart = r;
this.imagPart = i;
}
Complex.prototype = zero;
// Now make some objects.
var two = new Real(2);
var i = new Imaginary(2);
var oneone = new Complex(1, 1);
Isn't that prototype-focused enough?
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: minimal classes
On Mon, Jun 27, 2011 at 10:13 PM, Brendan Eich bren...@mozilla.com wrote: On Jun 27, 2011, at 10:00 PM, David Herman wrote: I've been concerned about the schedule risk of classes for ES.next Is the timeline posted somewhere? - providing idiomatic syntax for calling the superclass constructor But what about subclass method calling superclass method(s)? I think this is an essential feature for a class syntax. Calling super for methods is one of the features that JavaScript libraries prioritize very highly. They all have some way of calling super for a method. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Making super work outside a literal?
On Wed, Jun 22, 2011 at 8:28 AM, Sean Eagan seaneag...@gmail.com wrote: On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote: On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote: I don't think we need any safety check when assigning a method or accessor getter or setter that uses super to an object. The concept of super seems to be a relative one, That is what we are arguing about. It's not a conclusion we all share. In ES, functions are first class objects not owned by any one object, an absolute super breaks this. I agree that dynamic this but static super seems odd but maybe symmetry with this is not desired. Maybe we should have static super and be looking for symmetry with a static self. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 52, Issue 117
On Mon, Jun 20, 2011 at 1:27 PM, Axel Rauschmayer a...@rauschma.de wrote: Terminology (created by me, but I think it explains well what is going on): - |this| points to the object where property lookup starts. It always points to the beginning of the prototype chain. - |here| points to the object where a property was found. |here| can point to any object in the prototype chain. |super| starts property lookup in the prototype of |here|, but does not change |this|. That is, a method invoked via |super| still has the same |this| and property lookup via |this| is unchanged. If the super-method again uses |super|, then property lookup will begin in the prototype of |here| (= where the super-method has been found). Etc. It doesn't seem quite right that an upward call like Object.getPrototypeOf(here).foo.call(this) has sugar super.foo() but sideways calls like here.foo.call(this) don't have any sugar. By the way, I like this idea that super is available all the time (not just in an initializer) like this is always available; however, adding another implicit variable here which is dynamic like this is disconcerting as this has been quite a wild beast in JavaScript to say the least. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Making super work outside a literal?
On Mon, Jun 20, 2011 at 3:23 PM, Axel Rauschmayer a...@rauschma.de wrote: What is the use case for sideways calls? Can you point me to an example? You want to allow the API (a.k.a. public methods) of an object to be overridden, but you don't want the functionality of any non-overidden API methods to change. In short, you want to avoid the template pattern. I gave a synthetic example in the sideways calls thread I started. If you are after data that is private to a given prototype, consider using an IIFE, instead. There are various interesting ideas in other programming languages when it comes to combining methods while overriding: - Cooperative methods: force overriding methods to call them. - Before/after/around methods: are invoked before/after/before+after a method that they override: http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node285.html But that would be overkill for ES.next. By the way, I like this idea that super is available all the time (not just in an initializer) like this is always available; however, adding another implicit variable here which is dynamic like this is disconcerting as this has been quite a wild beast in JavaScript to say the least. I framed things in terms of |here|, because that value can be easily produced, as a byproduct of looking for a property. It might also, some day, give us the ability to *set* a property that is not at the beginning of a property chain. Perhaps useful in combination with __noSuchMethod__. More efficient to dynamically generate a method on the here object once then on all the this inheriting objects one-by-one. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Making super work outside a literal?
On Sun, Jun 19, 2011 at 10:56 AM, Axel Rauschmayer a...@rauschma.de wrote:
Exactly!
One way to do this is to give methods an implicit parameter here (the
object in which a method was found during dispatch), in addition to this.
In some variant, here might make it possible to do what I was
describing as sideways calls?
http://www.mail-archive.com/es-discuss@mozilla.org/msg08069.html
Then
super.foo(x, y)
would desugar to
Object.getPrototypeOf(here).foo.call(this, x, y)
With call() and apply(), you would have here === this.
When the prototype chain is three or more objects long, I'm wondering
what would happen.
With here I'd expect and think people would expect the following
behavior (but I don't think it is what your proposal of here would
do.)
function Alpha() {}
Alpha.prototype.one = function() {return 'Alpha.one';};
Alpha.prototype.two = function() {return 'Alpha.two';};
Alpha.prototype.three = function() {return super.one() + ' ' +
here.one() + ' ' + this.one();};
function Beta() {}
Beta.prototype = Object.create(Alpha.prototype);
Beta.prototype.one = function() {return 'Beta.one';};
Beta.prototype.two = function() {return super.one() + ' ' + here.one()
+ ' ' + this.one();};
function Gamma() {}
Gamma.prototype = Object.create(Beta.prototype);
Gamma.prototype.three = function() {return super.one() + ' ' +
here.one() + ' ' + this.one();};
var a = new Alpha();
var b = new Beta();
var g = new Gamma();
a.three(); // Alpha.one Alpha.one Alpha.one
b.two(); // Alpha.one Beta.one Beta.one
g.two(); // Alpha.one Beta.one Gamma.one
g.three(); // Beta.one Gamma.one Gamma.one
Peter
On Jun 19, 2011, at 19:44 , Peter Michaux wrote:
On Sun, Jun 19, 2011 at 10:20 AM, Axel Rauschmayer a...@rauschma.de wrote:
It would be nice if super could work in any method and not just those
methods that are defined inside an object literal. Then, a method would
have to know what object it resides in, e.g. via an implicit parameter.
So you want super to be dynamic but tied to the value of this
inside that function? Something like...
function fn() {
return this.alpha + super.beta();
}
function Foo() {}
Foo.prototype.alpha = function() {return 1;};
Foo.prototype.beta = function() {return 2;};
function Bar() {}
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.beta = function() {return 5;};
var b = new Bar();
fn.call(b); // 1 + 2 = 3
Peter
--
Dr. Axel Rauschmayer
a...@rauschma.de
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Prototypes as the new class declaration
On Tue, Jun 14, 2011 at 10:08 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
The correspondence is even closer if we slightly extend the new operator.
Using current new operator semantics and my alternative way of defining
SkinnedMeesh and then executing:
let aSM = new SkinnedMesh(aGeo, aMat);
we would get a TypeError because SkinnedMesh does not have a [[Construct]]
internal method. However, it would be a small extension to the new operator
for it to invoke its operand's constructor method if the operand is an
object that is not a function (alternative, we could give every object
created using an object literal a [[Construct]] internal method that invokes
the constructor method, its really just an alternative way to specify the
same thing.
Interesting extension of new.
BTW, I believe that somebody else recently on one of these
threads also suggested allowing the new operator to be applied to any object
so feel free to take credit.
Don't need credit but perhaps you were referring to my email...
http://www.mail-archive.com/es-discuss@mozilla.org/msg07968.html
On Wed, Jun 15, 2011 at 8:20 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Alternatively, if there was a more complex set of methods or there was an a
strong reason why you didn't want instances to share the behavior. You would
create a separate singleton helper/factory object to hold the methods, EG,
StringBulider.fromCharCode(1,2,3,4,5)
StringBuilder.fromStrings(abc,def,xyz)
Of course, such an object could participate in its own inheritance hierarchy
that was decoupled from Strings, EG,
let I18NStringBuilder = StringBuilder |
{fromLocaleString(template,locate) {...}};
It would be nice to see constructors heading in this direction of
being methods on objects that can inherit.
These examples seem to suggest that there are plenty of reasonable ways to
approach what currently would be constructor methods. However, they all
require some rethinking that starts with the concept that you name the
prototype and not the constructor. The biggest hurdle to me seems to be
that the existing built in objects don't follow that pattern.
and host objects?
On Sat, Jun 18, 2011 at 8:09 AM, Brendan Eich bren...@mozilla.com wrote:
For me, this does not close the deal that we don't need classes.
But it is getting close, and it is working in the right direction.
Do I smell a strawman?
but I think we all (Harmony types
at least) want to minimize additions to the language and prefer
orthogonal primitives that have good usability, and
which compose cleanly.
+1
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
block lambda proposal in light of compiling to JavaScript
Recently, I've invested time looking at current compiling-to-JavaScript developments. Although people have been doing this for many years now, it seems CoffeeScript is making it clear that being a target of compilation is at least part of JavaScript's future. The pending additions in browsers of support for debugging original source language seems to reinforce this future direction as a serious possibility. JavaScript doesn't have macros to allow programmers to tune the language to their likes and needs. So it seems that developers have decided that compiling to JavaScript is the route to go because they can do that right now. They are, however, limited by the features that are part of JavaScript with regard to what features the source language can have that are efficient in the compiled JavaScript. Additions to JavaScript, especially low-level functionality, will open doors for the source languages. The most interesting part of the block lambda proposal is adding lambdas to JavaScript. Regardless of syntax, this would mean a lot of possibilities open for languages targeting JavaScript. Often a heavy function is not a good idea in the compiled code and the lack of Tennent's Correspondence Principle for functions means the compilers need to do big tricks to get the compiled code to do what is desired. As a trivial example, if JavaScript had lambdas but no let blocks then a source language could add efficient let blocks quite easily. What is the current feeling about the block lambda proposal in TC39? What can be done to help move the block lambda proposal towards Harmony? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda proposal in light of compiling to JavaScript
On Sat, Jun 18, 2011 at 11:53 AM, Brendan Eich bren...@mozilla.com wrote: On Jun 18, 2011, at 10:33 AM, Peter Michaux wrote: Yet CoffeeScript does not need lambdas with TCP control effects today. It translates in a straightforward (mostly) transpiling way. Even its expression-language mapping of statements as expressions does not require lambdas. Maybe CoffeeScript doesn't need it today. Another source language could benefit from JavaScript having lambdas. JavaScript doesn't have macros to allow programmers to tune the language to their likes and needs. So it seems that developers have decided that compiling to JavaScript is the route to go because they can do that right now. They are, however, limited by the features that are part of JavaScript with regard to what features the source language can have that are efficient in the compiled JavaScript. Additions to JavaScript, especially low-level functionality, will open doors for the source languages. Sure. The problem is drawing the line, as we've discussed in this list since 2006 (when Nicholas Cannasse brought up call/cc). Drawing the line in the right place is important of course. I was trying to contribute to the case that drawing the line with lambdas in would be beneficial to some and perhaps a growing group in the future. The most interesting part of the block lambda proposal is adding lambdas to JavaScript. Regardless of syntax, this would mean a lot of possibilities open for languages targeting JavaScript. That's not yet evident. Yes, some source languages (and some compiler writers) would want lambdas. Not all, and the compiler writers seem to be doing fine working around lack of lambdas: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS I don't think that list proves too much. Many of those languages are sufficiently far from JavaScript's semantics that the compiled JavaScript code is too inefficient to run in a production system. In fact, this may be partly why CoffeeScript is the first language that compiles to JavaScript to draw major attention. CoffeeScript is just a thin skin over JavaScript and so the compiled code can perform well. Often a heavy function is not a good idea in the compiled code and the lack of Tennent's Correspondence Principle for functions means the compilers need to do big tricks to get the compiled code to do what is desired. As a trivial example, if JavaScript had lambdas but no let blocks then a source language could add efficient let blocks quite easily. How efficient is wide open to question. VMs implementing let can more readily optimize without having to optimize lambdas in full (TCP effects included). Fair enough. I don't know which VM implementations would benefit or suffer. It seems to me you are using the expressive power of lambda to argue for efficiency, which is makes a category mistake. I didn't intend that. What is the current feeling about the block lambda proposal in TC39? What can be done to help move the block lambda proposal towards Harmony? I noted the reaction here and in talks I've given, citing the straw poll I took about arrow functions, lambdas, there-can-be-only-one. 8/6/unanimous (some abstained). IOW, TC39 wants at most one lambda-or-just-shorter-function syntax (lambda carries semantics). The committee was mixed on arrow functions with Waldemar concerned about grammatical issues I've tried to address in the strawman. Others were quite in favor of arrows. Block lambdas were more divisive, in part because of the syntax, but in larger part (IMHO) because of the novel TCP semantics. Some on the committee decried excessive bits of cleverness. Others said won't this confuse n00bs? (Meta-discussion #27 from http://www.slideshare.net/BrendanEich/txjs-talk). More than a few were quite in favor, though (Allen, Dave Herman, Mark Miller). So, a mixed reaction and no consensus for ES.next. So what can be done to help move the block lambda proposal towards Harmony? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes: suggestions for improvement
On Mon, Jun 13, 2011 at 12:31 PM, Brendan Eich bren...@mozilla.com wrote: The language to emulate is Smalltalk, though. +1 to that; however, the ES class proposal is not very similar to Smalltalk classes. Others are far more qualified to enumerate the differences than I am. For example, how can we do desugared class variable and method inheritance? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
super, self, and sideways durable vs. template
Something I try to do when designing constructors is to ensure the
constructed objects will be durable. That is, if some code modifies or
breaks parts of the constructed object's exposed interface, the other
parts of the exposed interface should continue working the same as
before. Part of what I use for this is what I term sideways calls
because I don't know any better. I don't know if there is a proper
name for this type of call but it is different than super and self
calls. Using sideways calls allows subclasses to still override
interface methods but doesn't allow subclasses to change the behavior
of non-overridden interface methods.
If anyone knows a name for this kind of call I'd be interested to know
it and if there are class-based languages that have support for this
type of call. It can be done by using very obscure method names,
perhaps involving the class name as a namespacing technique, but this
is not as elegant as what JavaScript, Scheme, etc allow as shown in
the example below.
The following example shows that m3 in makeB is brittle because it
uses a self call but that m4 is durable because it uses a sideways
call. How would one make a durable m4 with the class syntax while
still allowing m4 to be overridden in subclasses that choose to over
ride it.
My primary reason for asking here is I'm curious if there is any
allowance for sideways calls in the proposed class syntax. By that I
mean using the prototype parts of the proposed syntax rather than the
closure based parts of the syntax (since the syntax can do both.)
Thanks,
Peter
function makeA() {
return {
m1: function() {return 'm1 in A';},
m2: function() {return 'm2 in A';},
m3: function() {return 'm3 in A';}
};
}
function makeB() {
var self = makeA();
var superM1 = self.m1;
var m1 = self.m1 = function() {
return superM1(); // calling up the inheritance chain
// (durable)
};
var m2 = self.m2 = function() {
return 'm2 in B';
};
self.m3 = function() {
return self.m2(); // calling down the inheritance chain
// (template pattern brittle)
};
self.m4 = function() {
return m2(); // calling sideways in the inheritance chain
// (durable)
};
return self;
}
// The makeC constructor breaks the m3 method even though it doesn't
override the m3 method.
//
function makeC() {
var self = makeB();
self.m2 = function() {
throw new Error('aa');
};
return self;
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
class sugar: static inheritance
Are static members inherited? What happens in the last line of the
following code?
class Monster {
static allMonsters = [];
constructor() {
Monster.allMonsters.push(this);
}
}
class Dragon extends Monster {
constructor() {}
}
new Monster();
Monster.allMonsters.length; // 1
Dragon.allMonsters.length; // 0, 1, or error?
Based on my understanding of what the desugared code would be, the
last line above would be an error because Dragon.allMonsters is
undefined. That is, static members are not inherited at all which does
not seem very class-like.
function Monster() {
Monster.allMonsters.push(this);
}
Monster.allMonsters = [];
function Dragon() {}
Dragon.prototype = Object.create(Monster.prototype);
Dragon.prototype.constructor = Dragon;
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote: As promised/threatened: http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival The examples on the wiki page feature calling a function that takes one block argument and also feature Tennent's correspondence principle nicely; however, I don't see examples of how to define functions taking one or more block arguments or how to call a function with two or more block arguments. Could someone add an example? Perhaps a Boolean.prototype.ifTrueIfFalse definition equivalent to Smalltalk's ifTrue:ifFalse: would fill these example gaps? Thanks, Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Different semantics should have different-looking syntax
On Sat, May 21, 2011 at 12:37 PM, Brendan Eich bren...@mozilla.com wrote:
For http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival I
have written up the Ruby-inspired {|x| x * x} syntax.
Alternatives (ignoring keyword issues) that look more like function syntax
(Peter's suggestion of lambda (x) { x * x }, e.g.) seem worse in this light:
block lambdas do follow the correspondence principle, which is novel to JS
with its C statements for control effects heritage.
In this light, the use of | | to bracket formal parameters seems better than
anything using (...) {...}. This is not an overriding concern, but it seems
worth mentioning. We want block-lambdas or any such TCP-pure new thing to
have syntax that says look! something new here.
I don't think this idea of needing different syntax for different
semantics is a strong point in favour of the {||} syntax. ECMAScript
programmers are already accustomed to the keyword(){} syntax template
and have *no* trouble understanding the difference between the
following two bits of code and what return means in each.
if(a){return a;}
function(a){return a;}
And, since the strawman builds on block syntax, we want the new form to have
syntax that looks like a block, in which you'd expect TCP purity for break,
continue, return, |this|, and arguments.
Lambdas are useful for more than just blocks in control structures. I
don't think that use should be the sole force behind choosing the
syntax.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival, now with semantics
On Sun, May 22, 2011 at 9:17 PM, Brendan Eich bren...@mozilla.com wrote:
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
Suppose we have a host API to open and close files and we write the
following two functions.
var withFile = function(filename, fn) {
var file = openFile(filename);
fn(file);
file.close();
};
var fileContains = function(filename, needle) {
withFile('path/to/file.txt', {|file|
return needle.test(file.getContent()));
});
};
I believe the file will not be closed in this case.
This problem is not introduced because of lambdas. This problem exists
already if fn throws an error.
Would we be able to do the following to ensure the file is closed if
fn is either a function that throws or is a lambda that returns?
var withFile = function(filename, fn) {
var file = openFile(filename);
try {
fn(file);
}
finally {
file.close();
}
};
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
PTC and SHOULD vs MUST
http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls I notice that in the proper tail calls wiki page that a compliant interpreter SHOULD implement a call in proper tail position as a PTC. In order for a programmer to use proper tail calls for arbitrarily deep recursion, the programmer needs a guarantee that the interpreter will use proper tail calls. This would mean the SHOULD needs to be a MUST. Otherwise what does the proper tail calls proposal gain the programmer? For example, R5RS has much stronger language compared with SHOULD about Scheme using proper tail calls. Implementations of Scheme are required to be properly tail recursive. With that language the programmer using Scheme can then depend on that feature. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: May 24-26 rough meeting notes
On Thu, May 26, 2011 at 4:22 PM, Waldemar walde...@google.com wrote:
Versioning:
script type=application/ecmascript;version=6 (RFC 4329)
use version 6;
module LOL {
...
}
/script
There are good reasons to have the metadata both externally (in the script
tag) and internally (in the script). External versioning allows
implementations to avoid fetching a script at all if they won't understand
it. Internal versioning helps in the case where the external version is
detached.
Brendan's idea:
script-if type=...
...
script-elif type=...
...
script-else
...
/script
Consensus on moving some form of versioning into Harmony. The strawman is a
bit light at this time, so no specifics yet.
A lot of the above looks like HTML. Isn't versioning that depends on
HTML out of scope for the ECMAScript standard?
Peter
___
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: 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: 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
Guards
From: Waldemar walde...@google.com
Date: Thu, May 26, 2011 at 4:22 PM
Subject: May 24-26 rough meeting notes
Guard Syntax:
Technical aspects ok, but some are worried about the effects of this
change on the ECMAScript style.
What aspects of ECMAScript style were cause for concern? Fear of Java?
Cormac's student Tim will work with
DaveH to prototype this this summer. Not advanced to Harmony, pending
more user experience.
How will more user experience be generated? Through a compiler to ES5?
--
The idea of guards in general seems extremely useful and could
potentially save reams and reams of parameter checks that have been
manually written in a large-ish project (20,000 lines) over a
long-ish time period (2yrs) I'm working on with multiple people. The
project is large enough and long enough that I forget parts of the
code. I used to think just don't send the wrong type of argument to a
function but now that I'm forgetting the code myself and reviewing
the code of others daily, I see the large benefit of having the code
complain with a clear message when the wrong parameter is sent.
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. 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.
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.
Would there be a way to check that too many arguments have been sent
to a function?
--
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. I've written the following kind
of thing with the intention of stripping code inside the debug block
for production.
var double = function (a) {
/* DEBUG BEGIN */
if (typeof a !== 'number') {
throw new Error('a must be a number');
}
/* DEBUG END */
return 2*a;
};
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Sat, May 21, 2011 at 7:43 AM, Brendan Eich bren...@mozilla.com wrote:
On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote:
An essential part of this proposal is a paren-free call syntax
Why is that essential?
When I wrote essential, I was not claiming that there's a logical proof of
necessity. Rather I was declaring that this strawman includes paren-free
block-argument-bearing call expressions as an essential design element.
Chopping it out chops down the whole strawman.
I understand what you're writing above but I think that ties this
proposed short syntax for functions (or lambdas) to something the
arrow syntax is not tied to and so makes it a do you like apples or
oranges? choice. In another thread, some people were suggesting {||}
as an exact alternative to the thin arrow.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Sat, May 21, 2011 at 7:56 AM, Rick Waldron waldron.r...@gmail.com wrote:
Brendan,
Thanks for the clarification on that.
I've been following the shorter function syntax discussions pretty closely,
as well as reading the strawman proposals, so please forgive me if this has
been addressed or refuted.
Given your example: b = a.forEach (x) { x * x } And the issues you noted
there, would the same issues apply here:
b = a.forEach( (x) { x * x } )
^ ^
I don't see a prefix being a problem to reduce ambiguity. It would
actually be beneficial for readability.
b = a.forEach( lambda(x) { x * x } )
It seems this strawman is proposing true lambdas so the name is apt.
It sure is easy to Google JavaScript lambda or search code for
lambda.
functionreturn is 14 characters. lambda is 6 characters. That is a
8/14 character savings which is pretty good for those worried about
character count. I don't know why we have to be so extreme and get the
savings up to 12/14. In the case that the lambda has a few possible
return points the savings on repeated return would be repeated
savings.
This strawman is much more interesting because it is not just sugar.
It introduces something JavaScript does not have now which is a real
lambda and that could take JavaScript in positive directions in the
future. Many syntax possibilities and macros need to desugar to a real
lambda that obeys Tennent Correspondence Principle, correct? Opening
that door for the future would be beneficial.
I'm understanding the intention of the strawman correctly?
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function syntax
Alex, That is not what I wrote at all because I didn't write the it could be better. The analogy that Nathan was making does not apply to JavaScript. He wrote that C# delegates were not popular in C# 2.0. Functions are already popular in JavaScript. Peter On Sat, May 21, 2011 at 10:25 AM, Alex Russell a...@dojotoolkit.org wrote: I'm sorry, this this argument is entirely circular: - we have something that works - it could be better - but it works, so we don't need anything better ? On May 21, 2011, at 10:08 AM, Peter Michaux wrote: On Thu, May 19, 2011 at 12:44 PM, Nathan Stott nrst...@gmail.com wrote: Having worked a lot with C#, my experience was that very very few people used the C# 2.0 delegate syntax and now a large portion of the community learned and uses the C# 3.0 syntax. Syntax matters. JavaScript functions have not suffered neglect due to the length of their syntax. Function expressions are already wildly popular in JavaScript. So this C# data does not really support the necessity for change in JavaScript. -- Alex Russell slightly...@google.com slightly...@chromium.org a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function syntax
On Sat, May 21, 2011 at 10:46 AM, Brendan Eich bren...@mozilla.com wrote: Saying JS has function expressions that are wildly popular is jumping to a conclusion. How is that jumping to conclusions? All the JavaScript code that I read uses function expressions. JS is popular in that it's the only built-in browser language, but let's say it is popular on its own these days (NodeJS, e.g.). Not sure how this relates to the success of functions in JavaScript code. It still does not follow that function expressions are popular enough that shorter syntax would not make the language more usable for enough developers that shorter syntax is worth adding. JavaScript function expressions are not suffering neglect due to their length. I doubt shorter syntax will increase their popularity because function expressions seem to be used where the concept is appropriate even. Separately from that I don't think JavaScript needs shorter function syntax but that is up for debate. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Sat, May 21, 2011 at 10:50 AM, Brendan Eich bren...@mozilla.com wrote:
On May 21, 2011, at 9:50 AM, Peter Michaux wrote:
In another thread, some people were suggesting {||}
as an exact alternative to the thin arrow.
Yes, I cited the thread in the strawman. So what? Chopping proposals into
little pieces does not help, we've seen this before.
But the two strawmans conflate ideas unnecessarily. Someone out there
may want thin arrow lambdas without paren free calling. If they do
then how do they choose between the {||} lambda paren free verses the
arrow function strawmans. They cannot.
There are several issues that can be dealt with separately.
1) Should new syntax be introduced for functions?
2) Should lambdas be introduced? If so what would there syntax be?
3) Should paren free calls be introduced?
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Sat, May 21, 2011 at 10:38 AM, Jorge jo...@jorgechamorro.com wrote: Why the (sudden) urge to copy so many bits ( paren-free, - // =, etc ) of coffee's syntax ? I agree. I don't see how Coffeescript deserves to be such a strong influence with such a short history and limited use. (does JS have an identity crisis now ?) JavaScript has always had an identity crisis, hasn't it? ;-) Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Sat, May 21, 2011 at 11:09 AM, Brendan Eich bren...@mozilla.com wrote: 'lambda' is not reserved and still overlong. TC39 and this list have been over this ground before. I don't see anything new in your post to change the outcome. TC39 will not introduce *any* new keywords to the language? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Sat, May 21, 2011 at 11:20 AM, David Herman dher...@mozilla.com wrote:
Previously, you argued against the importance syntactic convenience, but it
seems what you really were opposed to was a new function form that wasn't a
true lambda. But now that there is one back on the table, you're OK with
counting conciseness as a win.
I must not have been clear enough with what I wrote with regard to
conciseness. I wrote the following...
functionreturn is 14 characters. lambda is 6 characters. That is a
8/14 character savings which is pretty good for those worried about
character count.
The for those worried about character count part was intentional and
did not include me with regard to reducing the length of function
literals. I don't see how that is motivation
Peter
I don't mean to single you out on this-- it's a general phenomenon on
es-discuss that really frustrates me. Design discussions are dysfunctional
when they're treated as a zero-sum game between opponents. Design requires
being honest about trade-offs. When people feel threatened that their
concerns aren't being taken into account, they get defensive and start
discounting others' concerns, and then the whole thing becomes a negative
feedback loop.
For my part, I will do my best to at least listen to people's concerns and
register them as part of the equation, even if not every design can fulfill
every constraint. I haven't always succeeded at that, but I'll do my best. I
hope everyone will try to do the same.
Dave
On May 21, 2011, at 10:05 AM, Peter Michaux wrote:
On Sat, May 21, 2011 at 7:56 AM, Rick Waldron waldron.r...@gmail.com wrote:
Brendan,
Thanks for the clarification on that.
I've been following the shorter function syntax discussions pretty closely,
as well as reading the strawman proposals, so please forgive me if this has
been addressed or refuted.
Given your example: b = a.forEach (x) { x * x } And the issues you noted
there, would the same issues apply here:
b = a.forEach( (x) { x * x } )
^ ^
I don't see a prefix being a problem to reduce ambiguity. It would
actually be beneficial for readability.
b = a.forEach( lambda(x) { x * x } )
It seems this strawman is proposing true lambdas so the name is apt.
It sure is easy to Google JavaScript lambda or search code for
lambda.
functionreturn is 14 characters. lambda is 6 characters. That is a
8/14 character savings which is pretty good for those worried about
character count. I don't know why we have to be so extreme and get the
savings up to 12/14. In the case that the lambda has a few possible
return points the savings on repeated return would be repeated
savings.
This strawman is much more interesting because it is not just sugar.
It introduces something JavaScript does not have now which is a real
lambda and that could take JavaScript in positive directions in the
future. Many syntax possibilities and macros need to desugar to a real
lambda that obeys Tennent Correspondence Principle, correct? Opening
that door for the future would be beneficial.
I'm understanding the intention of the strawman correctly?
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Sat, May 21, 2011 at 11:36 AM, Brendan Eich bren...@mozilla.com wrote: What part of integrated design was unclear? None of it. If somehow the whole is rejected, we can pluck out parts and propose them separately, or better: as part of alternative integrated designs. Understood. Neither of the two strawmen proposals as wholes appeal to me. You invited feedback. I've given mine. The general public has no official say in the matter. I can only hope some on the committee agree. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda revival
On Fri, May 20, 2011 at 5:54 PM, Brendan Eich bren...@mozilla.com wrote: As promised/threatened: http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival From page: An essential part of this proposal is a paren-free call syntax Why is that essential? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Tue, May 17, 2011 at 10:50 AM, Axel Rauschmayer a...@rauschma.de wrote: On May 17, 2011, at 4:57, Peter Michaux petermich...@gmail.com wrote: The goal of pleasing compiler writers should be to make it possible to compile existing languages like Perl, Ruby, Python and Scheme to JavaScript. These languages are the ones that people know and really want to use and target their compilers to JavaScript. You sound like you really hate JavaScript and can’t imagine working with it unless some other language is compiled to it. Actually the opposite is true. I write in JavaScript all day and like it a lot. I wouldn't want to compile to JavaScript with today's possibility. What I was trying to express is that I believe dream of people who want to compile to JavaScript is to write in their server-side language of choice (e.g. Perl, Python, Ruby, Scheme, Java, etc) and compile that to JavaScript. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Mon, May 9, 2011 at 6:02 PM, Brendan Eich bren...@mozilla.com wrote: Yes, and we could add call/cc to make (some) compiler writers even happier. But users would shoot off all their toes with this footgun, and some implementors would be hard-pressed to support it. The point is *not * to do any one change that maximizes benefits to some parties while harming others. By the nature of their task and its complexity, compiler writers targeting JavaScript need JavaScript to have features that make it possible to generate efficient compiled code. Without the big features like call/cc there are many things that just cannot be compiled well enough...which ultimately means all the languages that compile to JavaScript are just thin sugar layers that really aren't even worth the bother. Those languages, like Coffeescript, are obscure and known by only a few people. The goal of pleasing compiler writers should be to make it possible to compile existing languages like Perl, Ruby, Python and Scheme to JavaScript. These languages are the ones that people know and really want to use and target their compilers to JavaScript. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 4:17 PM, David Herman dher...@mozilla.com wrote:
But we are going to have to make a decision, and it simply won't
be perfect. We're going to listen to everyone, consider the
technical issues, and at the end of the day, make the best
decision we can with imperfect information.
I hope the committee keeps in mind that it can choose not to include
any short function syntax. I know the committee knows that but I hope
it is near the top of the list as one of the options.
On Sat, May 7, 2011 at 4:40 PM, Kyle Simpson get...@gmail.com wrote:
But, JSConf has just 150-200 JavaScript developers in attendance. While they
are certainly some of the most passionate (and intelligent) developers of
the community, no doubt, they are definitely not a representative sampling
of the overall community. Making language decisions based on the vocal
support of JSConf alone is not sufficient.
Agreed. I think the personality type of hundreds of developers that
attend conferences is quite different than the tens of thousands of
developers that don't attend.
I think I could easily come up with a dozen examples of patterns in
JavaScript coding which are shorter, but which most of the community would
say is *not* more readable. So I take issue with the assertion that
shorter==better unequivocally.
Agreed. There shouldn't be the feeling that shorter function syntax is
desperately needed and that it has to go into the next ES even if it
is not perfect.
On Sat, May 7, 2011 at 5:18 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Brendan once said JS is a curly-brace language and it always will be. I
think the - looks works very nice with a pythonic-like forced indentation
like Coffeescript has. However, I believe # looks better with curly braces,
so I'd keep #(x) { x * x }.
I also think familiarity should be considered and that #(x) { x * x } would
be more familiar to the casual JS programmer.
I agree with this type of thinking about keeping syntax similar with
arguments in parens and the body in braces more than introducing
something so foreign to JavaScript like the arrow syntax.
On Sat, May 7, 2011 at 7:33 PM, Isaac Schlueter i...@izs.me wrote:
It has been my experience that professional JavaScripters will cheer
*any* idea that shortens the spelling of function and return :)
There are professional JavaScript programmers in *this* thread that
aren't cheering. That is why this thread started.
On Sat, May 7, 2011 at 7:58 PM, Kyle Simpson get...@gmail.com wrote:
So I felt like it was important to voice early that not everyone feels
universally so lovey-dovey over that syntax. In fact, a recent tweet I read
sums up my feelings: If I wanted to be using Coffeescript, I'd be using
Coffeescript. I prefer JavaScript.
Exactly! There are syntactic features that some developers want that
are so far from JavaScript that they shouldn't or can't be
incorporated into the language. This is why compilers exist and I hope
that the to-JavaScript compiler community grows if people want to do
that sort of thing.
I've talked with some JavaScript developers and asked them What do
you think of Coffeescript? without biasing my question. I've had a
100% negative response. They aren't interested in using Coffeescript
_at_all_. So just because Coffeescript has some vocal fans, it has not
caught on like wildfire. In the big scheme of things it has virtually
not caught on at all. It is a very fringe group that is experimenting.
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sun, May 8, 2011 at 11:34 AM, Irakli Gozalishvili rfo...@gmail.com wrote: I'd like to point out that coffeescript has a huge success and in the end it's just syntax sugared js. Can someone give evidence that Coffeescript is actually a success? Has anyone crawled the web to determine the rate of Coffeescript adoption? (Assuming there is some way to identify Coffeescript's compiled code.) Will adoption plateau at a small percentage of total browser scripts? People cannot just reiterate this idea that Coffeescript is popular and use that as support for arrows without evidence that Coffeescript is actually popular. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Fri, May 6, 2011 at 10:49 PM, Andrew Dupont mozi...@andrewdupont.net wrote: On May 7, 2011, at 12:42 AM, Peter Michaux wrote: Yes and readability counts. JavaScript's function syntax is already *highly* usable and readable. Many people, including me, would disagree. Do you really struggle using or reading the current function syntax? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Fri, May 6, 2011 at 11:05 PM, Andrew Dupont mozi...@andrewdupont.net wrote: I don't want to get too deep into matters of taste, but I do think the current syntax is annoyingly verbose for passing lambdas as arguments in other functions. The fact that it's so verbose ends up hurting readability when the function itself is short. I think that this is what compilers and projects like coffeescript are for. In my opinion, JavaScript itself doesn't need this new syntax. I think improving JavaScript as a compilation target is a good goal. For example, a real lambda with guaranteed proper tail calls, no arguments, no need for return, etc would make is possible to compile Scheme to JavaScript without using something inefficient like trampolines. It would also open up recursive programming options in plain JavaScript so it would be win-win. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 6:04 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sat, May 7, 2011 at 2:22 AM, Peter Michaux petermich...@gmail.com wrote: I think that this is what compilers and projects like coffeescript are for. In my opinion, JavaScript itself doesn't need this new syntax. I think improving JavaScript as a compilation target is a good goal. This argument comes up time and again: We don't need to make JavaScript a good programming language, JavaScript is already a good programming language. It can use improvements but it has good covered. just a good compilation target. I did not write that it needs to be just a good compilation target. I don't use a compiler to enable me to write source in another language and then serve JavaScript to the browser. I write in JavaScript. So I do want JavaScript to remain a good language. That said, improving JavaScript as a compilation target does expose areas where the language could use features it does not have at all (in any syntax.) Adding those features makes JavaScript objectively a more capable language. I think it's really wrong-headed. Me too. First, JavaScript is a language used by millions of people as a programming language, and we should give them a great language to program in. JavaScript already has great covered too. :-) I'd be willing to go for even better but the arrow syntax isn't even a significant contribution to this cause. Real features would be. A weak map, for example, is a great idea because we just cannot do anything like that now without implementing our own garbage collection. Second, JavaScript as source rather than target has been a huge enabler of the Web as an open platform, which I certainly don't want to move away from. So, even though we've worked hard in the module system to better support compilation to JavaScript, I think the our fundamental goal should be to make JavaScript a great language to write all kinds of programs in. That wasn't one of Brendan's stated goals; however, it is a good goal. I think the arrow syntax is not helpful in this goal. For example, a real lambda with guaranteed proper tail calls, no arguments, no need for return, etc would make is possible to compile Scheme to JavaScript without using something inefficient like trampolines. It would also open up recursive programming options in plain JavaScript so it would be win-win. And hey, it turns out we've done this too -- at least with the - syntax. :) It has been confirmed that the arrow syntax is *only* syntactic sugar for existing function syntax. That means introducing the arrow syntax does *not* improve the compilation Scheme to JavaScript *at all*. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 51, Issue 5
On Sat, May 7, 2011 at 9:16 AM, Thaddee Tyl thaddee@gmail.com wrote: I believe that David Bruant has a good point. We *need* a shorter syntax because we advocate the use of map/reduce, etc., which require simple anonymous functions. No. We don't need syntactic sugar. The current function syntax is working and we are talking a few characters difference, not hundreds. Map/reduce don't require syntactic sugar. You may want shorter syntax but we've been getting by well without it. I think framing it as a need or a requirement is dishonest to the discussion. As to why we should choose # rather than coffescript's -, there are two points: [long discussion ensues based on taste] There are so many more important issues to address. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Sat, May 7, 2011 at 9:56 AM, Thaddee Tyl thaddee@gmail.com wrote: JavaScript is still seen as a badly object-oriented programming language by those who still think it is java with a weird syntax. I think that concpetion has declined a lot as rich clients have forced people to become better acquainted with JavaScript and a lot more has been written on the language. I do hope it grows to be known as an outstanding functional programming language. JavaScript won't ever be known as a outstanding functional programming language until it has proper tail calls. This would give the language new capabilities it doesn't have now. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
arrow syntax unnecessary and the idea that function is too long
I read Brendan's recent article http://brendaneich.com/2011/05/my-jsconf-us-presentation/ He asked for community members to make their feelings known and the es-discuss list as one of the places to do it. In his article, Brendan shows a slide with the following content -- The Harmony goals * Be a better language for writing: * complex applications * libraries (including the DOM) shared by those applications * code generators targeting the new edition * Better tests, if not a testable (executable) specification * Adopt de facto standards where possible * Keep versioning as simple and linear as possible * Support a statically verifiable, object-capability secure subset -- He also discusses the arrow syntax for functions. If the arrow syntax is only syntactic sugar for the existing function forms then I don't see how it achieves any of the goals he outlined. The only possible category is be a better language but the arrow syntax won't make JavaScript a better language for complex applications or libraries in comparison to any other kind of JavaScript code. I would argue that the arrow syntax will make JavaScript a worse language anyway as there are already perfectly good forms using the function keyword now. We don't need new syntax and we don't need multiple ways to do the same thing just for the sake 6 characters. Please keep JavaScript simple. Look at all the complex/subtle edge cases mentioned in the wiki page about arrow function syntax. Do we really want to have that much trickiness added to the language? http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax Brendan later writes the following as part of the discussion about arrow syntax. I’ve been talking about better function syntax for a while. function is too long (I wish I’d used fn in 1995 and preempted this issue). I'd like to ask when is function too long? I never type it thanks to my text editor's features so I know it is not too long for developers with a good editor. It is not a labor to read the word function either. It is never sent over the wire because gzip reduces its size so it is not too long from a performance perspective. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arrow syntax unnecessary and the idea that function is too long
On Fri, May 6, 2011 at 6:39 PM, Brendan Eich bren...@mozilla.com wrote: But again, you can use 14 characters if you want. The problem is that the author of the code that I'm reading may have used the arrow syntax and then I'm stuck reading it. This is shorthand, and only shorthand. And usability counts, so shorthands are in Harmony (e.g., destructuring) Yes and readability counts. JavaScript's function syntax is already *highly* usable and readable. Having many ways to write the same thing is a burden to readers of code because they have to know a larger set of forms and all of the gotchas that come along with them. A lot of languages have a lot of cool syntax and then the communities come up with best practices that prohibit the use of them anyway often for reasons only discovered after their introduction. My hunch is that arrow syntax will be one of these cases. JavaScript can use attention in many of areas. Devoting time to adding sugary function syntax seems like a misappropriation of resources. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
access to Unicode SMP?
ES5 Section 7.8.4 discusses UnicodeEscapeSequence which have four hexidecimal digits (i.e. \u to \u) and allows specification of characters on the Unicode Basic Multilingual Plane. Is it possible in ECMAScript to specify characters on higher planes like the Supplementary Multilingual Plane? If not, why was that access excluded? Thanks, Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Operators ||= and =
On Tue, May 5, 2009 at 2:59 PM, Brendan Eich bren...@mozilla.com wrote: On May 5, 2009, at 11:37 AM, Peter Michaux wrote: On Mon, May 4, 2009 at 10:26 PM, Brendan Eich bren...@mozilla.com wrote: People often write the following at the beginning of functions for optional parameters optionalParam = optionalParam || defaultVal; I believe what they are really trying to write is optionalParam = optionalParam === undefined ? defaultValue : optionalParam; which is what ??= would do. You could be right, but the fact is people use ||, which equates falsy values to not short-circuit the defaultVal evaluation. This is what the code does, not necessarily what was meant. It might be better to pave this cowpath and not try to sell the ?? super-highway ;-). A lot of people don't understand JavaScript falsey value equality and since || works in their server-side language they assume it works the same way in JavaScript. It compiles and runs after all! ;-) A small marketing campaign to encourage the ?: version above might change what people use. I think optional parameters are the nuisance use case that is fueling any discussion about a ||= or ??= operator. Nuisance to you, useful to others I think I was unclear. Optional parameters are definitely useful. It is the following idiom's verbosity that is the nuisance (to be possibly alleviated by a new operator.) optionalParam = optionalParam || defaultValue; (though I think they are probably worth adding.) Both? I don't think ||= and ??= are very difficult to define clearly. Perhaps just a line each in terms of the expanded syntax. I don't think they would add much bloat to engines. Perhaps just better to add them both and move on to discussing classes, lambdas, or processes. And in this syntax will default values be used if the parameter is falsey or only if it is undefined? Only if the actual parameter is absent. Well that is more useful than the ||= or ??= idioms at the top of the function body anyway. Someone passing the value undefined to a function causes problems for the idioms. Someone may want to still use the ||= or ??= idioms for testing properties inside an object passed to the function. I do that when the last parameter to a function is a bunch of different named optional parameters. Unfortunately simple idiom tests for properties inside an object could still be fooled if someone sets a property to undefined. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving ECMAScript as a compilation target
On Mon, May 4, 2009 at 2:34 PM, Brendan Eich bren...@mozilla.com wrote: I finally found time to write up a proposal, sketchy and incomplete, but ready for some ever-lovin' es-discuss peer review ;-). http://wiki.ecmascript.org/doku.php?id=strawman:catchalls Comments welcome. Thanks for posting your proposal. I agree with Allen Wirfs-Brock: at first look, this seems like a nice general design direction giving the programmer control over all the different otherwise internal methods on an object. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Operators ||= and =
On Mon, May 4, 2009 at 10:26 PM, Brendan Eich bren...@mozilla.com wrote: ??= and ?? are too narrowly typed for JS. I had the impression from the previous thread that you were more in favor of ??= than ||=. People often write the following at the beginning of functions for optional parameters optionalParam = optionalParam || defaultVal; I believe what they are really trying to write is optionalParam = optionalParam === undefined ? defaultValue : optionalParam; which is what ??= would do. I think optional parameters are the nuisance use case that is fueling any discussion about a ||= or ??= operator. I think other use cases are less common and probably would not warrant adding a new operator. The reason I mention this is if there is another sugar plan for default parameter values then perhaps ||= and ??= aren't needed at all (though I think they are probably worth adding.) I thought default parameters were going to be something like the following. function(a=1, b=defaultVal); And in this syntax will default values be used if the parameter is falsey or only if it is undefined? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Ecma Press Release regarding ECMA-262, 5th Edition Candidate Specificaiton
On Thu, Apr 9, 2009 at 5:29 PM, Allen Wirfs-Brock allen.wirfs-br...@microsoft.com wrote: Ecma has published their press release announcing that the next version of the ECMAScript standard will be known as ECMA-262, Fifth Edition Four is an unlucky number in Japan anyway ;-) Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving ECMAScript as a compilation target
On Thu, Feb 12, 2009 at 9:17 PM, Brendan Eich bren...@mozilla.com wrote: On Feb 12, 2009, at 8:07 PM, Peter Michaux wrote: SpiderMonkey has had __noSuchMethod__ for years. The Ten years complaint you make seems to be against the ECMAScript committee, Not at all and it is unfortunate it came across that way. It is at the whole chain of events which is long: for the ECMAScript committee to standardize methodMissing, for browsers to implement it and for old browsers to disappear. Is it inevitable that browser makers and/or the ECMAScript standard group will add features to ECMAScript specifically to make it a better compilation target or expose actual byte code? By making ECMAScript engines faster, browser makers have already started. Should the effort to make the browser a better compilation target be encouraged and expedited so the long drawn out eventually can come sooner? Why do you assume something not in evidence? Who says eventually or inevitabl[y] there will be standard bytecode? Even if you end up accurately predicting some future event, doing so prematurely based on a hunch does not help us now in any way. Projecting enthusiastically about hypothetical outcomes does not accelerate the process of developing a suitable common language for hand-coders and code-generators. I didn't make predictions. I asked questions on purpose. If a common language for hand-coders and code-generators is desirable, isn't it necessary to consider the code-generator part? That was really the question of my whole post: should we be considering the code-generation part perhaps more than we are. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Improving ECMAScript as a compilation target
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich bren...@mozilla.com wrote: On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote: Not at all and it is unfortunate it came across that way. It is at the whole chain of events which is long: for the ECMAScript committee to standardize methodMissing, for browsers to implement it and for old browsers to disappear. Standardizing a target bytecode or even AST encoding would take no less time, almost certainly more. We should talk about methodMissing for Harmony. Great but to be clear, methodMissing was just an example of a feature some desire. I could have used classes, continuations, threads, etc all of which people have tried to add to ES. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Preliminary draft of ES-Harmony modules proposal
On Sun, Feb 8, 2009 at 1:06 PM, Dave Herman dher...@ccs.neu.edu wrote: I like many aspects of Ihab and Kris's proposal, but not all. For example which parts do you like or dislike? The reason I ask, it would be great if the ServerJS project could use a reasonably liked subset of the proposal. The ServerJS discussions are using only a small part of the whole Ihab Kris proposal. Mainly modules have a scope, exports object and a require function. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Preliminary draft of ES-Harmony modules proposal
On Thu, Jan 22, 2009 at 10:00 PM, ihab.a...@gmail.com wrote: Hi folks, Kris Kowal and I plan to present a proposal for ES-Harmony modules in the upcoming Mountain View meeting. In the interests of giving everyone a chance to read through our ideas ahead of time, we are sharing a draft of our document, which is a work in progress: http://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v Since the above post was made, Ihab and Kris' proposal has become what seems to be the leading proposal in the ServerJS project. The appeal appears to be almost unanimous. https://wiki.mozilla.org/ServerJS/Modules/SecurableModules http://groups.google.com/group/serverjs/browse_frm/thread/d2dc85a2725992be The ServerJS project is a bright light in the server-side JavaScript world. Knowing sooner than later if this module idea is appealing to the ECMAScript group would be useful information. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: obsoleting the new keyword
On Wed, Jan 14, 2009 at 11:58 AM, Juriy Zaytsev kan...@gmail.com wrote:
On Jan 14, 2009, at 1:51 PM, Peter Michaux wrote:
[...]
Yes.
Needing new makes some things unnecessarily bulky.
var pts = getRows().map(function(r) {return new Point(r);});
verses just
var pts = getRows().map(Point);
This is indeed a frequent annoyance.
It wouldn't be so bad if there was `Function.prototype.construct` or
`Function.prototype.new` (or something along these lines).
Are there any plans to include such facility in ES3.1 (or any objections
against it?)
[...]
Ding, ding, ding! I was hoping someone would suggest this but I don't
know how it can work.
In order to be able to do the following, the Point.new function would
need to be bound to Point and that is not the way properties work in
JavaScript (which is unfortunate in some cases but beneficial in
others.)
var pts = getRows().map(Point.new);
When Point.new is called inside map, the this object will be the
global object, not the Point object.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
obsoleting the new keyword
The requirement that JavaScript needed to look like Java has long been lamented. One of the key looks was the new keyword. Many people don't like the use of the new keyword. Although new is here to stay, could we obsolete it when using a class sugar? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: obsoleting the new keyword
On Wed, Jan 14, 2009 at 9:40 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Jan 14, 2009 at 9:19 AM, Peter Michaux petermich...@gmail.com
wrote:
The requirement that JavaScript needed to look like Java has long been
lamented. One of the key looks was the new keyword. Many people
don't like the use of the new keyword. Although new is here to
stay, could we obsolete it when using a class sugar?
I should have omitted when using a class sugar. I'd like to see
new completely unnecessary.
I agree. For *all* the desugaring of classes I've posted, the constructor is
merely a function, not using this, that constructs are returns a new
instance. Thus, you get the same effect whether new is used on these or
not. Both Point(3, 5) and new Point(3, 5) return the same thing.
Yes.
Needing new makes some things unnecessarily bulky.
var pts = getRows().map(function(r) {return new Point(r);});
verses just
var pts = getRows().map(Point);
Unfortunately some of the ES constructors behave differently when
called without new. This is a reasonably major problem with the
language, in my opinion. Is there anything that can be done about this
problem?
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Semantics and abstract syntax of lambdas
On Thu, Dec 18, 2008 at 8:43 AM, Brendan Eich bren...@mozilla.com wrote:
On Dec 18, 2008, at 6:45 AM, Lex Spoon wrote:
x = x+1
x = {{ var y = x+1; y*2 }}
There's no need to double braces in the = syntax if we require an object
initialiser to be parenthesized:
x = ({p: 1, q: true})
Why cause such extra confusion for programmers?
Unfortunately I've lost most of my interest in this discussion as some
folks seem to be desperately in need of some sort of new syntax. I
just don't get it. The lambda(){} syntax would work just fine without
any new feature conflicts. Even if all known conflicts have kludge
workarounds to enable some terse sugary syntax, isn't anyone worried
about the conflicts that will appear later?
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Simple tail calls
I think tail calls is really an es-discuss (i.e. not es3.x-discuss)
topic so I've added that list.
Brendan commented to me about tail calls
https://mail.mozilla.org/pipermail/es-discuss/2008-July/006566.html
I created a Mozilla ticket in response and one of my comments there
talks about the arguments.caller problem
https://bugzilla.mozilla.org/show_bug.cgi?id=445363
I'm all for tail calls. I'd like to see implicit tail calls. Implicit
tail calls would be necessary if tail calls are used in lambdas as
there is no return statement in a lambda.
Peter
On Fri, Dec 5, 2008 at 4:17 PM, Michael Day [EMAIL PROTECTED] wrote:
Hi,
[Apologies in advance if this proposal has been made before]
Idea: the JavaScript specification could require implementations to treat as
tail calls any ReturnStatement containing a CallExpression.
function f()
{
return g(); // -- tail call!
}
ADVANTAGE: Very easy to specify and very easy to implement.
It does not require tail calls for CallExpressions which occur outside of a
ReturnStatement, eliminating a big chunk of specification devoted to
figuring out exactly what is or isn't a tail call position.
It does not require scanning through a function to identify tail positions,
so even the most basic interpreter operating directly on abstract syntax
trees could still implement them easily.
I believe that this pattern would also be easier for users to learn and
harder to get wrong than tail calls which can occur outside of return
statements:
ADVANTAGE: It makes tail calls explicit.
Using return f() is as close as you can get to introducing a new keyword,
without introducing a new keyword. It makes it immediately obvious whether a
call is a tail call or not. EIBTI.
ADVANTAGE: Explicit tail calls preserve correctness.
The only point of requiring tail call optimisation rather than leaving it
optional is because the correctness of some code depends upon it. However,
implicit tail calls are easily lost as code changes. Consider a tail call
within a deeply nested block:
function f()
{
if (cond)
{
if (cond)
{
...
g(); // -- supposed to be a tail call, but is it?
}
}
minorCleanup(); // -- oh no! someone added this!
}
If tail calls use an explicit return, it is much harder to accidentally
break them, or overlook them. If tail calls are essential to ensure the
correctness of some code, they should be explicit in that code.
NOTE: Does not preclude fancier optimisations.
Implementations would be required to treat return calls as tail calls.
However, they would be free to treat other calls as tail calls as well, or
perform more complex optimisations such as introducing accumulator arguments
to transform code into tail-recursive form.
DISADVANTAGES: None! Honestly, this proposal is made of 100% awesome :)
It has minimal specification burden, minimal implementation burden, is
really easy to explain, teach, and learn, improves maintainability and helps
preserve correctness, while increasing speed and decreasing memory usage.
What's not to like?
Best regards,
Michael
--
Print XML with Prince!
http://www.princexml.com
___
Es3.x-discuss mailing list
[EMAIL PROTECTED]
https://mail.mozilla.org/listinfo/es3.x-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/4 Mark S. Miller [EMAIL PROTECTED]: Welcome to the syntax races. lambda takes an early lead, but drops back because of too much weight. For a while, it's neck and neck between || and ^, with \ following closely and fn, , and other trailing. Many old timers (including your commentator) are rooting for || because of its previous historic performances. But || trips up over ambiguities not present on its original track. ^ is now in the lead. Oh no! It trips on a different ambiguity. This track seems riddled with more ambiguities than any of these contenders have ever trained on. Seeing ^ stumble, and other contenders saddled with binary operatorness, drop back and concede. \ has taken the lead I have my money on lambda. I'm thinking it has the endurance necessary. It has already lasted longer in history than all the others. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/11/29 Brendan Eich [EMAIL PROTECTED]: At the TC39 meeting two weeks ago in Kona, we had a brief bikeshedding discussion about lambda syntax and why it matters. Who would have thought a discussion about lambda syntax in JavaScript would go over 120 posts while a simultaneous thread about class syntax has had little attention outside a handful of posters? Would this have been reverse 10 years ago? Sign of the paradigm shift? Maybe folks want an immutable cons cells too? Modern attention span? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/3 Michael [EMAIL PROTECTED]:
If I understand the proposals correctly, then of the following e4x:
Why do you mention e4x? I'm not familiar with it but thought it only
adds XML literals to the language.
Peter
var doc = {{|a,b,c|...}(d,e,f)}
var doc = {^(a,b,c){...}(d,e,f)}
var doc = {{||...}()}
var doc = {^(){...}()}
I honestly don't see the clarity of one over the other especially if someone
writes larger, asinine e4x.
At least with the vertical bars it has similarities/inspiration from other
languages as mentioned. This may be important for those migrating
from one of those languages. When I first saw ^(){...}, the vision that came
to my head was the pointer operator in Visual C++
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Summary of what I've read:
The syntax \(){} has a named lambda problem if the lambda name starts
with a 'u'. Depending on whitespace between the backslash and the
identifier seems like it will cause bugs
\u03c0(){}
\ u03c0(){}
The syntax ^(){} has a semicolon insertion ambiguity. What does the
following mean?
x = x
^(){}
The {||} syntax has an optional parameters problem. What does the
following mean?
{|a, b = 1 | c | d}
The other suggestion which seems to be on the table has been a new
keyword lambda or something shorter.
lambda() {}
lmbd() {}
ld() {}
Any parsing problems are already ones programmers know how to work
around. The only whinge has been that lambda is too long. Changing
from the 6 character lambda keyword to something shorter would work
technically. I think just a one character keyword would be too short
as they are commonly used for loop variables. I think the sometimes
used fn can't be used because function is already taken. Both
lmbd or ld are abbreviations which are not in the character of ES
language keywords. var is the only keyword abbreviation in ES3. All
other keywords are complete words and the word for the concept desired
here is lambda.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/3 Yuh-Ruey Chen [EMAIL PROTECTED]: The control abstractions just don't look right, regardless of which lambda syntax we choose. I'd rather wait for a more powerful macro system, instead of choosing the syntax based off how it would look in control abstractions. I agree completely. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Wed, Dec 3, 2008 at 7:16 PM, Eric Suen [EMAIL PROTECTED] wrote: Yes, it doesn't contain a lambda expression, just like: a = x /x/i is not same as: a = x; /x/i they both right but has different meaning... Is adding more confusion like this in the language desirable? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
2008/12/2 Jeff Watkins [EMAIL PROTECTED]: Since the goal seems to be allowing control structures like Smalltalk (yay!), how about specifying that one lambda that follows a function invocation is passed as the final argument to the invocation. Brendan seemed to reject the idea that this could be passed as the first argument to a constructor, so that this could be explicitly named, on the grounds that the parameter lists would not match. I agree that parameter lists should match. I was just asking. https://mail.mozilla.org/pipermail/es-discuss/2008-November/008203.html If a trailing block outside the parameter list is passed as the last argument, then what happens when there is a rest parameter as the last argument in the parameter list? It gets a bit messy to determine if the last argument passed in was the last argument of some rest parameters or an optional trailing lambda. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How much sugar do classes need?
On Tue, Dec 2, 2008 at 1:40 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
#{ ... } is an object initializer where all of the initialized
properties are non-configurable.
The use of '#' makes me think of reader macros. I like the idea of
reader macros for ES. (I don't know if '#' can be used because of
sharp variables which I believe are part of JavaScript.)
I think it would be good to be able to use custom quotes on regular
expressions and strings
#r(some/regexp/containing/slashes)
#s/a string containing quotation ' marks/
'enum' (or something similar) is a property modifier that makes the
property enumerable.
'const' continues to have the same meaning (non-configurable and
non-enumerable). Where 'const' appears inside #{ ... }, the
non-configurable aspect is redundant.
var self = #{
const toString: {|| '' + self.getX() + ',' + self.getY() + ''},
const getX: {|| x},
const getY: {|| y},
enum pubInstVar: 4,
enum const pubInstConst: -4
};
It's more verbose than Peter's syntax, but it doesn't overload the
array index syntax,
I used [] just as an example. It could have been many different separators.
and although the #{ ... } initializer
unfortunately introduces new syntax, I think its functionality is
genuinely (and generally) useful. I'd imagine that most real-world
uses of { ... } could be replaced by #{ ... }, since initialized
properties are usually expected to stick around.
On the other hand:
enum const get foo () { ... }
... is odd.
I think if there are to be modifiers than just have the modifiers and
not the #{}. Having all the modifiers with the property seems like a
better way to go to me. Also what if #{} is used to create the object
and later a property is added and is to be configurable? Is that
possible? Either decision seems arbitrary.
If there are going to be modifiers config, enum, and const then
there may be no harm in having other modifiers which represent a
combination of these modifiers (like the suggestions of field and
method though I don't really like those names for the reasons I
wrote before.)
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Tue, Dec 2, 2008 at 4:08 PM, Yuh-Ruey Chen [EMAIL PROTECTED] wrote: (As a side note, sometimes I wonder if all this talk about sugar is moot, because I suspect more and more languages will start compiling down to ES.) I keep a list of all the X-ES3 compilers I encounter in the middle of the following page http://peter.michaux.ca/articles/compiling-down-to-javascript-1-5 This list has grown quite long with the majority of popular and revered languages included. I wonder how many companies are using these technologies and if that group is growing very quickly. ES is good enough for most developers that I think the attraction is low given the extra difficulties in development process and compiled code speed (i.e. trampolines for tail calls are slow.) If ES is the byte code of the browser then the better ES is, the better the compiled code can be. Tail calls and continuations would be valuable additions to ES. Threads are probably a trickier issue. If these features cannot be added to ES directly then it would be great if ES ran on a VM which exposed these features. Then all languages could compile to that VM's byte code. I vaguely recall a web page where Brendan Eich listed some of these features as part of JavaScript 3 (perhaps ES5). I can't find the page at the moment. The really unfortunate part is the time lines to reach such goals are likely very long...available in 95% of browsers in the year 2020? Who knows? Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Tue, Dec 2, 2008 at 7:11 PM, Neil Mix [EMAIL PROTECTED] wrote: How's this for a strawman: the choice is to follow either Objective-C or Smalltalk. Or Scheme which, after all, was the first Lisp with lexical scoping and first-class lambdas. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 2:06 AM, Chris Pine [EMAIL PROTECTED] wrote:
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only use it
half as often as I should.
What is to be made of that last sentence? If you have a choice between
the following, The lambda version is still shorter.
function() {}
lambda() {}
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 7:31 AM, P T Withington [EMAIL PROTECTED] wrote:
On 2008-11-30, at 01:30EST, Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I would rather have a more literate syntax, lest we degenerate to where
practically any comic book blasphemy is a valid program.
I agree with this sentiment. The phrase ASCII vomit comes to mind
and becomes a worry.
Take an ES program and replace all if-else with ?: and then most
functions with {||} and it starts to look quite cryptic.
A reader would have a difficult time even knowing what to look up in a
book index to find out what the {||} that they see in some code is
supposed to be. It wouldn't necessarily be clear that the {} and the
|| are related.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 10:24 AM, Brendan Eich [EMAIL PROTECTED] wrote:
On Dec 1, 2008, at 10:17 AM, Peter Michaux wrote:
Take an ES program and replace all if-else with ?: and then most
functions with {||} and it starts to look quite cryptic.
But functions remain. I doubt lambdas in any synax will replace them.
Actually, I think the combination of Object.create, lambda, rest
parameters and class will probably eliminate function and prototype
from most code.
lambda will be slightly faster and lighter than function. Programmers
like faster and lighter when it comes at no cost.
People seem to want to think in terms of classes and not the prototype
property of a function object. Colin Moock's book on AS2 recommended
against using prototype after the introduction of class to that
language.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 12:19 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
JavaScript already has a concise ASCII vomit syntax for constructing arrays
and objects.
I didn't mean to imply that JavaScript currently deserves the ASCII
vomit label. I also didn't mean to imply the {||} was so bad as to
deserve name calling. It is more the potential for the cumulative
effect to cause trouble.
Given the direction the language seems to be heading,
Can you expand on what you mean by that please?
having a similar concise syntax for constructing closures
seems quite appropriate.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Trac issue reports
On Mon, Dec 1, 2008 at 2:18 PM, Brendan Eich [EMAIL PROTECTED] wrote: You two have trac accounts at http://bugs.ecmascript.org/ - Thanks. Hopefully non-committee members can be of some assistance. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RE: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 5:37 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Douglas Crockford
...
because you can think of the \ as being an abbreviation of function.
\ name(a,b,c) {}
Just don't start your function name with u.
Exactly, that's why I didn't mention this possibility. I don't think it
would be acceptable to have that \u ambiguity.
I agree that the ambiguity is not acceptable. It is too confusing.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
