Re: Automatic Semicolon Insertion: value vs cost; predictability andcontrol; alternatives
On 2011-04-18, at 13:48, Brendan Eich wrote: Do popular minifiers still not parse and insert semicolons (and remove newlines) as needed? Only the broken ones! :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Dynamic Scope [Was: Existential operator]
On 2011-04-15, at 21:48, Mark S. Miller wrote: Why dynamic scoping was attractive and why it turns out to be bad is one of the most important lessons from the history of language design. It's a power tool, and can be misused, but it still has adherents. Scheme (and Dylan) have a more-controlled version in their `fluid-let` construct (which leaves out the pervasive special feature of Lisp). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator
On Apr 14, 2011, at 20:48, Brendan Eich bren...@mozilla.com wrote: Seems to me Tucker was pretty clearly arguing that ?. should be explicit as in CoffeeScript, not implicit and inevitable via . as in AS2. That's all. Yes. Our experience was that implicitly short-circuiting on dereferencing undefined had benefits, but was more trouble than it was worth. I want the best of both worlds — an error when I don't expect undefined, and a way to explicitly permit short-circuiting on undefined. A syntax like Dmitry's proposal would make duck typing and lazy allocation patterns more succinct. — Sent from my device that I decline to endorse blindly. Nor do I request absolution for any typographical sins. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Existential operator
On 2011-04-13, at 15:23, Brendan Eich wrote: in my view, the operator is not ?. (i.e. a question followed by a dot), but still just ?. The following dot is already about property accessor: foo.bar?.baz again, bar? is separated, and only after that it's accessed to `baz` via casual dot notation. ?. is doable as a new operator And ?( as an operator, too? , but we need a better quantification of how useful it is in CS. Or look for the patterns it would simplify in JS? Seems like a lot of these patterns come from duck-typing, from continue down this path if it applies. On 2011-04-14, at 11:55, John J. Barton wrote: Perhaps there is no better solution, but often I find that I want to say call this chain of functions and use the bottom value, but if any of them return undefined, then just be undefined, don't get all pissed off and throw an exception. Being undefined is how JavaScript is. I was imagining that this was the feature being discussed. This is the way AS2 worked. If at any point an undefined value was hit (whether property access or call), the evaluation stopped and undefined was returned. The experience of OpenLaszlo was that this led to many myserious bugs. We ended up making our compiler insert annotations in debug mode to detect and warn when an expression failed due to an undefined value. That experience makes me believe that the current behavior in ES is a better default; but having a shorthand for stop now if this is undefined, seems like it would be a nice addition. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removing labels
On 2011-04-09, at 04:33, Peter van der Zee wrote: Am I missing anything? Or are there cases where labels allow you do something that's impossible without labels? They let you write more literate code? I agree labels should be eschewed, except where necessary. But sometimes, you just need them. Here's some fairly complex algorithms from the OpenLaszo source that I think would be even more difficult to understand without their judicious use of labels: http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/services/LzCSSStyle.lzs Sure there are plenty of other ways to write this code, but I'm not convinced they are more maintainable. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript Object equivalence classes proposal
On 2011-04-07, at 13:27, Brendan Eich wrote: On Apr 5, 2011, at 2:19 PM, David Bruant wrote: What I'm worried about is the memory cost of such an implementation. The current [[HasInstance]] implementation has a constant memory cost. Keeping references has a linear memory cost in terms of instance number. My favorite real-world memory-intensive use case is the one-page Standard HTML (http://www.whatwg.org/specs/web-apps/current-work/). Right now, it contains 125684 DOM Elements. If trying to implement EventTarget [[HasInstance]] internal method, it would require as many entries in the WeakMap. First, there's no free lunch. Either the DOM objects need internal fields (vptrs in C++ sense, plus static shared vtbls) or brands or trademarks, which is per-object overhead. Or we need an entry in a weakmap for each object, which can be quite efficient (better if the map were a set, but still). Second, although the details do matter, the asymptotic space complexity is the same, ignoring static or singleton costs which amortize to epsilon: k*n for constant k and n objects, or O(n). The time complexity to test is-a would be O(1), but of course as David Bacon likes to point out, small constant factors can matter: a field load and compare beats a hashtable lookup. A C++ virtual call to QueryInterface or the like is slower than a well-implemented hashtable lookup. Again, big-O does not distinguish even if some benchmarks run on different implementations could tell. An oldie, but a goodie, perhaps relevant to this discussion: http://www.cs.purdue.edu/homes/jv/pubs/oopsla97.pdf ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A few more module questions
On 2011-04-04, at 12:40, Sam Tobin-Hochstadt wrote:
Renaming:
- I find this syntax slightly unintuitive: import Geometry.{draw: drawShape}
At first glance this would mean for me: rename drawShape to draw. draw
feels to me like the result of the import.
This is based on the destructuring syntax, where this:
let {draw: drawShape} = ... some expression ...;
also binds the identifier |drawShape|.
FWIW, I read these destructuring patterns backwards too. Must be a left/right
brain thing. Something I will have to learn the hard way to make it stick.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On 2011-03-29, at 17:52, Allen Wirfs-Brock wrote: On Mar 29, 2011, at 1:12 PM, P T Withington wrote: If I had a vote, it would be for a way to explicitly name the `-1th` argument to a function. And I would wish for it to be available in all function forms, defaulting to using the legacy name `this`, if not otherwise specified. I believe it not only addresses the issue in this thread, but leaves the way open for generic functions. [As a user, I infer I fall into your functional proponent camp, but I claim to also be an o-o proponent. I just find it much easier to think in generic functions and consider the distinguished receiver of message passing as being a degenerate case of that, which has a layer of syntactic sugar to let you express foo(a, b, c) as a.foo(b, c), if you like to think the other way.] Yes, the generic function camp largely coming out of the Lisp world has always been much more closely assigned with the functional world than with the object-oriented world. To us objectivists a.foo(b,c) really does carry a very different meaning than foo(a,b,c). The OO design process centers on identify the objects that will make up a system, not the functions that make up the system. While I appreciate this is a religious battle, IWBNI there were a solution that allowed alternative religions, rather than only the mainstream one. Hence my vote. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On 2011-03-29, at 17:38, Brendan Eich wrote:
[...]
We did not discuss allowing |this| to be bound otherwise, *except*
#foo(this = this| arg1, arg2) {...}
Am I right in understanding the above to be an idiom for trampolining the outer
`this` binding into the closure? (With the hazard that someone could override
that binding.) Or are you just giving an example, not endorsing a particular
idiom?
[...]
The other use-case, what Alex Russell calls soft-bind, also wants |this| not
|^this|.
Is there an example of what 'soft-bind' means somewhere?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On 2011-03-29, at 08:52, Sam Tobin-Hochstadt wrote: I agree entirely that it goes with the existing fixed implicit |this| binding -- I just think that cuts the other way. The reason we're having this discussion is that the existing behavior of |this| isn't always what you want, and is hard to get around because of its fixed and implicit nature. I think we should alleviate *that* problem, not just the worst symptom. Way back in https://mail.mozilla.org/pipermail/es-discuss/2008-August/007273.html I raised the `this` problem: When you write a function you can choose the names of all your parameters (for maximum legibility of your code) except the implicit one, where you are forced to accept the name `this`. If you could specify a different name, specifying which implicit binding you meant in the presence of multiples would be simplified. I won't propose a syntax for specifying an alternative name for `this`, for fear of being taken out to the (bike)shed and getting caned, but I do think it worth considering: why must that implicit parameter have a fixed name? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Inner functions and outer 'this' (Re: That hash symbol)
On 2011-03-29, at 14:19, Allen Wirfs-Brock wrote: I'll leave it to reader to weigh the above pros and cons. But I do have a closing statement: There is a decades long disagreement among designers/users of function and object-oriented languages. OO proponents think there is something special about the receiver of a method call and that self-calls have special significance. If I had a vote, it would be for a way to explicitly name the `-1th` argument to a function. And I would wish for it to be available in all function forms, defaulting to using the legacy name `this`, if not otherwise specified. I believe it not only addresses the issue in this thread, but leaves the way open for generic functions. [As a user, I infer I fall into your functional proponent camp, but I claim to also be an o-o proponent. I just find it much easier to think in generic functions and consider the distinguished receiver of message passing as being a degenerate case of that, which has a layer of syntactic sugar to let you express foo(a, b, c) as a.foo(b, c), if you like to think the other way.] ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Standardizing __proto__
You wouldn't need to reset the __proto__ of result if construction and
initialization were separated, if the __proto__ of objects were only set by
`new constructor`. If `constructor.apply` did _not_ create a new object, only
initialized it according to the arguments.
[The pattern you give is essentially how OpenLaszlo creates its class system,
although we manually separate construction from initialization.]
Yes, I know that many constructors are already defined in the spec as creating
a new object when called as a function. That's unfortunate, IMO, since in
general, ES has avoided there's more than one way.
On 2011-03-18, at 13:00, Oliver Hunt wrote:
I kind of dislike the proliferation of .create methods. It's seems
inelegant. What if we had (use __proto__ for semantic description)
Object.subclass = function(constructor) {
use strict;
function cons() {
var result = constructor.apply(this, arguments);
result.__proto__ = cons.prototype;
return result;
}
cons.prototype = Object.create(constructor.prototype);
return cons;
}
This would provide a function that does that allows arbitrary subclassing
of any function. Obviously there are issues (call vs. construct behaviour,
etc), but I think it's not too far off being a decent generic solution.
--Oliver
On Mar 18, 2011, at 9:46 AM, Mike Shaver wrote:
On Fri, Mar 18, 2011 at 9:29 AM, John-David Dalton
john.david.dal...@gmail.com wrote:
@Mike Shaver
For other possible uses please check out:
http://msdn.microsoft.com/en-us/scriptjunkie/gg278167
https://github.com/jdalton/fusebox#readme
Those all look like they are needing custom-initialization, not
arbitrary mutation at any point. Would you agree? For symmetry with
Object.create, you might want Boolean.create, Date.create and so
forth, but that's still initialization-time, and TBH I would be
surprised if there were actually many collisions between libraries
that augment those prototypes.
Preserving (or adding to other engines) arbitrary prototype chain
mutation in order to work around name collisions seems wrong to me.
Mutable proto just happened to be the hack that worked (though so did
iframes), and I can't really find anything other than Fuse that uses
it on the web today. The solution to name collisions is simple
modules, IMO, not monkeypatching of the builtin prototype hierarchy.
I think you can also achieve what you want with Harmony proxies, so
you'll have that option in the next edition of ES.
Mike
___
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
Re: Extended Object Literals to review
On 2011-03-13, at 18:15, Juan Ignacio Dopazo wrote:
@Brendan My mistake was thinking that setting enumerable to false also made
it return false on hasOwnProperty().
The idea behind it was to be able to walk down the prototype chain by doing
o.constructor.prototype.contructor.proto... But then I realized that's not
the case even in today's javascript.
I agree that we need this. Can something like:
On Sat, Mar 12, 2011 at 4:36 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
good point, the desugaring should be:
function c() {};
c.prototype=Object.create(s,protoype,{'constructor': { value:c, enumerable:
false, writable: false, configurable:false}});
make 'walking the prototype chain' work _without_ giving each instance a
constructor property?
see = new c();
see.constructor = c
see.constructor.prototype.constructor = s
?
ES3 does not have the luxury of Object.create, so to get the same effect I
_have_ put the constructor value in each instance. This is what OpenLaszlo
does today. I'm looking forward to the day when I won't have to any more.
It seems the desugaring quoted above should do this for you (assuming `s` is
similarly defined).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: iteration order for Object
On 2011-03-11, at 18:40, Charles Kendrick wrote: These developers didn't take a calculated risk. They saw it worked with the implementations at the time and hoped it would be so in the future. That is precisely the calculated risk they took. FWIW, OpenLaszlo does not take that risk, because we want to work across many platforms. When we care about iteration order, we don't use Object. What we do use depends on the application: Usually when we care about iteration order, random access is not an issue, so we just use a plist (an array of alternating keys and values). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A proposal to add String.prototype.format
On 2011-03-09, at 13:20, Shanjian Li wrote: It doesn't specify how to print objects, except for %s, which says that if the argument is not a string, convert it to string using .toString(). If the format specifier does not apply to the argument given, it should raise exceptions. Except string conversion, no other conversion will be done. Disagree. Since ECMAScript knows the type of the arguments, it does _not_ need the format specifier to tell it the type (as C does). Apparent mismatches should be left open as extensions. For example, the `x` formatter should simply specify that numeric values should be expressed in base 16, not that the value _must_ be a number. That way, you could pass an Array of numbers to `x` and see the numbers in base 16. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Additional language features
On 2011-03-05, at 14:38, Christian Mayer wrote: Am 05.03.2011 17:31, schrieb Brendan Eich: On Mar 5, 2011, at 5:41 AM, Christian Mayer wrote: 1) A printf compatible format string http://wiki.ecmascript.org/doku.php?id=strawman:string_format http://wiki.ecmascript.org/doku.php?id=strawman:quasis Both handle nicely the placement of external values into a string at given positions. But this is only one part of an printf-format string. What I'm still missing is the feature to define the format of the inserted data. This is for me more important, as that can't be easily achieved by the current ECMAScript. FWIW, OpenLaszlo has a fairly complete implementation of 'printf': http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/compiler/LzFormatter.lzs created long before the quasis proposal (which is quite nice). I agree there needs to be a way to direct _how_ the value is interpolated, and I suspect this is what the comment Meta data can be attached using a syntactic convention chosen by the quasi function is meant to hint at. An example along the lines of printf format control might be nice... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: LOG10E mystery constant
On 2011-02-21, at 00:47, Mark S. Miller wrote: But they convert to back to two different floating point numbers, at least on all the browsers I quickly tried. 0.43429448190325176 === 0.4342944819032518 false 0.43429448190325176 0.4342944819032518 true 0.43429448190325176 0.4342944819032518 false A little more testing reveals that the two numbers seem to be consecutive, in the sense that there are no intermediate representable numbers. Have we forgotten this lesson: http://portal.acm.org/citation.cfm?id=93559 ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: idea: try/catch and rethrow...?
[Interested bystander 2p.] The thing you are looking for is common in other advanced dynamic languages (mostly Lisp derivatives, see http://en.wikipedia.org/wiki/Exception_handling#Condition_systems). It is the concept of handling the condition in the context where the condition is signaled, rather than magically unwinding the stack looking for catch blocks to throw to. DOM2 has a similar distinction, whether to handle an event in the 'capturing' phase or the 'bubbling' phase. try/catch can be implemented in terms of condition handling, but not the other way around. I would be all in favor of adding condition handling to JS, and recasting try/catch as syntactic sugar. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: idea: try/catch and rethrow...?
Us old geezers have a tendency to repeat ourselves... If you remind me often enough, perhaps I'll stop. But it _is_ seductive! On 2011-02-01, at 14:14, Brendan Eich wrote: Deja vu all over again: https://mail.mozilla.org/pipermail/es-discuss/2007-March/004076.html /be On Feb 1, 2011, at 11:09 AM, P T Withington wrote: [Interested bystander 2p.] The thing you are looking for is common in other advanced dynamic languages (mostly Lisp derivatives, see http://en.wikipedia.org/wiki/Exception_handling#Condition_systems). It is the concept of handling the condition in the context where the condition is signaled, rather than magically unwinding the stack looking for catch blocks to throw to. DOM2 has a similar distinction, whether to handle an event in the 'capturing' phase or the 'bubbling' phase. try/catch can be implemented in terms of condition handling, but not the other way around. I would be all in favor of adding condition handling to JS, and recasting try/catch as syntactic sugar. ___ 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
Question on + and type conversions
If I define an object with both valueOf and toString methods:
var color = {
valueOf: function () { return 0xff; }
,toString: function () { return 'red'; }
}
The rules of `+` result in:
color + 1 = 16711681
color + '' = '16711680'
This is because of:
11.6.1 The Addition operator(+)
...
7. If Type(lprim) is String or Type(rprim) is String, then
a. Return the String that is the result of concatenating ToString(lprim)
followed by ToString(rprim)
...
Is it intentional that after discovering that one of the operands' primitive
value is a string, that toString is called on the other operand's primitive
value, rather than its (original) value? Because I was hoping:
color + '' = 'red'
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Nov 18 notes
On 2010-11-22, at 02:37, David Herman wrote:
if we allowed for-in to be overloaded, I would tell people that they should
deprecate the legacy for-in and replace it with an explicit iterator such as:
for (x in keys(obj))
I have learned a mnemonic for for-in: that it is iterating using the `in`
operator. You propose that I unlearn that? Or in your new hypothetical world
does the `in` operator also get overloaded?
Ramdom thought: Can I use destructuring in for-in?
for ({key:value} in enumerable)
for ([value] in iterable)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Nov 18 notes
On 2010-11-23, at 14:14, Brendan Eich wrote:
On Nov 23, 2010, at 5:19 AM, P T Withington wrote:
On 2010-11-22, at 02:37, David Herman wrote:
if we allowed for-in to be overloaded, I would tell people that they should
deprecate the legacy for-in and replace it with an explicit iterator such
as:
for (x in keys(obj))
I have learned a mnemonic for for-in: that it is iterating using the `in`
operator. You propose that I unlearn that? Or in your new hypothetical
world does the `in` operator also get overloaded?
Excellent question. One (Java extension language) answer:
http://www.cs.cornell.edu/Projects/jmatch/
Python allows unstratified meta-programming of both its for-in
loop/comprehension syntax *and* its |in| operator.
Harmony Proxies allow meta-programming of |in| already, via the |has| trap.
So the answer to your quesiton does the `in` operator also get overloaded?
is Yes, but you have to write two traps, iterate and has.
How does the `in` in for-in decide which of it's overloaded meanings applies?
Based on the type of the operand? Based on the existence of the enumerate or
iterate trap on the operand?
And despite the `in` in for-in either enumerating or iterating, the `in`
operator only has a single associated trap. The non-parallelism is bugging me.
Ramdom thought: Can I use destructuring in for-in?
for ({key:value} in enumerable)
for ([value] in iterable)
Absolutely. Destructuring (separate proposal but composes well) applies to
all LHS and binding forms.
I was being too subtle. I was suggesting something like your JS 1.7 example,
where the 'top-level' destructuring is a pattern for the `in` operation.
`{key: value}` means I want the property keys and their values, `[value]` means
I want the values, and `key` is (backward-compatible) shorthand for `{key: _}`.
Destructuring iteration over an hash of triples:
for ({key: [s, v, o]} in tripledb) ...
Too cute?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Guards are now ready for discussion (was: Nov 18 notes)
On 2010-11-22, at 13:13, Brendan Eich wrote: That, plus the relative rarity of annotated initialisers (in my best guess -- we can argue about this or try to estimate by adding guards to existing code), make me still favor (2). The idea of guards as adjectives (ala C) is a non-starter? Would keyword arguments ever be added to JS? Any chance that would influence the choices made here? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Guards are now ready for discussion (was: Nov 18 notes)
On 2010-11-22, at 14:33, Brendan Eich wrote:
Is losing the braces really worth the added complexity?
Perhaps not. Braces are surely as good a way to denote keyword args as any
other flag. It occurred to me that there is no equivalent of object literals
in the languages I know that have keyword arguments. There are strong
parallels, which is probably why the discussion of the guarded literal syntax
brought it to my mind. But that makes me wonder how I would write a function
with keyword arguments that were both guarded and had default values?
function f (a:V, b:W=w {c:X=x, d:Y=y}) ...
or, the less parallel:
function f (a:V, b:W=w {(c:X):x, (d:Y):y}) ...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Spread and non objects
[2p. from the Lisp world, the putative inventor of the rest/spread operator.] In Lisp, arglists are lists instead of arrays, the operator is `.`, and conveniently, the empty list, `()`, and Lisp null, `NIL`, are just two ways to write the same atom. In Lisp, option B just falls out: (f . NIL) === (f . ()) === (f) +1 for B as the best approximation (in the absence of a List data type). We can't really have the symmetry that Zeppieri is looking for because you want the rest operator to return an empty array when there are no rest args (rather than null), so you don't need to test for null before manipulating a rest arg. On 2010-11-04, at 20:54, Erik Arvidsson wrote: We've run into an edge case with the spread operator. What should happen if we try to spread null or undefined? f(...undefined); A. Throw an error B. Follow the path of Function.prototype.apply and others and special case null and undefined and just call f with 0 arguments -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Usage for weak-maps
On 2010-10-29, at 04:50, Peter van der Zee wrote: What's the use case for weak maps? What would you do with it that currently impossible and why is the workaround (if any) problematic enough to warrant a weak map implementation? Another use case was mentioned in the New topic regarding Proxies: intercession for === thread. If you want to write a value type, the constructor needs to return the same object for identical parameters for === to work, which means it needs a table of all the objects it has ever made, but it doesn't need (or want) to hang on to objects that are no longer in use. [The alternative being discussed in the proxy thread is to be able to customize === to give the same illusion.] ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Concerns about weak refs and weak maps.
On 2010-10-28, at 17:10, Hudson, Rick wrote: GC implementation Software stacks on multicores will need GCs to become increasingly concurrent and latency free. Weak maps cause concurrent GCs and additional mutator synchronizations. While a concurrent GC already has to do some synchronization, each additional synchronization point impedes scalability. My concern is that the number of synchronization points might be proportional to the number of k, v pairs in the weak maps (see below). This is old information, but perhaps relevant. Basically handling weak references in a standard hardware by emulating what a Lisp Machine would have done [From http://bit.ly/b4xidb] [...] AWL has another special power: it enables better handing of barrier hits on weak objects. To explain the benefit we need to describe a problem first. The MPS uses a read-barrier to perform incremental garbage collection [@@ link to canned-for-client explanation of how a garbage collector works in broad terms]. When the client tries to read an object containing weak references the MPS may have protected it so that the MPS can process the object before the client gets to see it. The problem for weak objects is that the client may try and access the object at a point in the collection cycle when the MPS cannot yet determine the status of the objects that the weak object refers to. What the MPS does in this situation is assume that all the referenced objects are going to live. This assumption is correct but conservative; it may result in objects that are weakly referenced staying alive for longer than they need to. In the worst case this can result in a very large amount of memor y being used by objects that are no longer needed. In order to combat this problem the MPS sometimes does the following: Instead of processing the entire weak object and unprotecting it so that the client can access the object the MPS may emulate the processor instruction. When this happens the MPS doesn't process the entire weak object, it only processes the exact location that was being accessed (typically a single word), it emulates the processor instruction, and it keeps the object protected. This happens invisibly from the client's perspective, it's exactly as if the instruction executed as normal. The MPS instead of processing the entire object processes just a single word. [...] ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New topic regarding Proxies: intercession for ===
On 2010-10-27, at 17:09, Brendan Eich wrote: JS will never be as simple as Self, but with proxies and value types based on them, it seems we might have get very close to the right answer to David's question. 2p. from the Dylan POV: Dylan only had equality and identity (thinking Lisp had just way too many equivalences). Dylan's MOP let you override (the equivalent of) `new` and `==`, but not `===`. If you wanted value objects that were indistinguishable, you wrote a `new` implementation that always returned the identical object for parameters that would otherwise create `==` values (using a weak-key table). If you only cared about equality, you wrote a `==` method that implemented your equality test. You chose based on whether you expected to do more constructing or more comparing. Is a proxy enough of a power tool that you just have to warn the user they must know what they are doing to use it? I.e., if you override the MOP in some inconsistent way, it's not our fault? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: if O is an Array object
On 2010-09-24, at 18:11, Jorge wrote: So b is truly a subclass of Array, not a fake one. I stand corrected. At some time in the past, this did not work for me. Apparently things have improved! Thanks. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Syntax for Efficient Traits is now ready for discussion (was: Classes as Sugar is...)
On 2010-09-14, at 17:39, Tom Van Cutsem wrote: It is true that original traits are always stateless. This is not so much to avoid name conflicts as to avoid the whole problem of diamond inheritance (duplicate state inherited via different inheritance paths, cf. C++'s virtual inheritance). Off topic, but the problem of diamond inheritance is a myth IMO. It come's from C++'s premature optimization[*] of property access in instances to base+offset and shared methods -- it is not an intrinsic problem of OOP. In many OOP languages (most with a Lisp lineage), what C++ calls virtual inheritance is the norm, not the exception. Original traits, again IMO, propagated this myth by declining to include state. --- [*] Or less generously, compiler's simplicity. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Syntax for Efficient Traits is now ready for discussion (was: Classes as Sugar is...)
On 2010-09-15, at 14:44, Tom Van Cutsem wrote: It's the easiest way though (Python e.g. uses linearization too to avoid diamonds issue). The way with warning a user about naming conflicts (in particular, in your implementation too) seems also good. From the other hand we don't warn a user if he overrides (in JS) a parent method with the same name. Linearization is indeed a well-known approach to resolve the diamond, but it doesn't adequately 'solve' the problem from a software evolution point of view: small changes in one part of a large code base (i.e. changing the order of two 'include' or 'extends' statements) may end up impacting a totally different part of the code base - usually without warning. I can recommend Alan Snyder's classic 1986 OOPSLA paper titled Encapsulation and Inheritance in Object-oriented Programming Languages, where he explains this and related issues with inheritance. See also: http://en.wikipedia.org/wiki/C3_linearization and its antecedents. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Syntax for Efficient Traits is now ready for discussion (was: Classes as Sugar is...)
On 2010-09-14, at 04:56, Tom Van Cutsem wrote: If we want to stick to reserved keywords, implements seems the most appropriate (although this similarly confuses trait composition with interface implementation). Alternatively, you could repurpose the (now disparaged) `with` keyword. That's what OpenLaszlo uses for its paint: class sundae extends icecream with jimmies, chocolatesauce, cherry implements dessert; ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On 2010-09-09, at 06:13, Tom Van Cutsem wrote: There's no mistake that dedicated syntax for traits would help users and implementors alike. However, while I (or others) could definitely come up with a 'traits-as-sugar', or even a 'traits-as-a-new-value' proposal, that still wouldn't solve the version evolution problem associated with trait composition (or any other traditional inheritance mechanism). As long as this remains a deal-breaker, I don't think it's worth looking into alternative traits proposals. As Dave said, traits.js is out there for people to experiment with. Any feedback on usability issues of the design in its current form are highly appreciated. I have on my to-do list to try re-casting the OpenLaszlo class framework as traits. Of the proposals for better class support in harmony, traits seems the most feasible to me for my work (we already translate to Ecmascript 3 and Actionscript 3). Clearly, I've got to actually implement it to test that theory. I certainly don't know any solution to the version evolution problem. AFAIK, it's why no one uses DLL's any more (or if they do, each app ships with its own private copy of every DLL it depends on). It's great that we can experiment with Traits without standardizing. It would be a shame to end up standardizing on an inferior proposal because of that feature of Traits. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On 2010-09-05, at 10:33, Mark S. Miller wrote: http://wiki.ecmascript.org/doku.php?id=strawman:classes_as_sugar Of the three straw contenders for this niche, my preference order continues to be * Traits If I had a vote, it would be +1 * Classes as Sugar * Enhanced Object Literals But since Traits seems to be blocked from advancing, Is there someplace I should read to understand why Traits cannot advance? I have now finally put the Classes as Sugar strawman on the agenda for consideration by the committee. It is now ready for discussion. This: Inheritance using the prototype chain does not work since the members are added to the instance and not the prototype. This makes this proposal non compatible with existing JavaScript paradigms. This in turn leads to classes becoming something completely new that exists on the side of existing best practices of doing OOP in JS. seems damning, without further explanation. Enough so that I would say the proposal should not use the word class to describe what it does. From a users point of view, it is baffling why you would want to standardize something so non-standard, when there is a clear call from use cases for a standard for doing normal OOP in Javascript. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar is now ready for discussion
On Sep 8, 2010, at 15:52, David Herman dher...@mozilla.com wrote: libraries should generally be very widely used and very stable before they are added to the ES standard library. That would seem like an unfair penalty. Am I to infer classes-as-sugar OS preferred because it _can't_ be implemented as a library (despite being a more experimental approach, and at odds with existing OOP libraries)? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.eq is ready for discussion
On 2010-09-07, at 12:02, Brendan Eich wrote: 3. identical If I had a vote, +1 Is there someplace that concisely explains the cost of just fixing `===` so I could understand why that is not a choice? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 41, Issue 9
On 2010-07-04, at 04:09, Brendan Eich wrote: Likewise for hashcode: if the object's address is one-way hashed to the hashcode() result, but the GC moves the object, then the object will need to grow a field to store its invariant hashcode. FWIW Dylan (and its ancestors) gets around this by having object-hash return 2 values: a hash code and a hash state. You can only compare hash codes associated with the 'same' state. The hash state is an opaque object with operations for comparing and accumulating (e.g., to compute the hash state of a table of objects). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: We need to name EphemeronTable (was: Do we need an experimental extension naming convention?)
Coming late to the party: 'alias' might be intuitive (from it's dictionary definition and use in filesystems as a non-preserving way to give an alternate name). On 2010-07-03, at 00:57, Brendan Eich wrote: On Jul 2, 2010, at 8:58 PM, David Herman wrote: Cool. I'm warming to WeakMap as well. Do we have any objections to WeakMap? +1 I 3 WeakMap. The Force is strong with WeakMap! ;-) +1 or more /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: modules proposal
On 2010-05-15, at 11:22, Brendan Eich wrote:
On May 15, 2010, at 7:53 AM, David Herman wrote:
[...]
FWIW, the rename on import looked backwards to me at first glance, but I
think I can learn.
Yeah, I'm not thrilled about how hard it is to remember which way it goes. I
meant for it to be consistent with the syntax of destructuring:
let { draw: d } = obj;
import M.{ draw: d };
One has to grok destructuring, but once past that, this is the only sane way.
The shorthand applies.
Ah, destructing `.`, I missed that. Perhaps I would have gotten it with a
closer parallel like
let { draw: d } = import M;
or
import { draw: d } from M;
Alternatively, we could a) disallow leaving off the '.{...}' for importing a
single binding and 'import x1.---.xn' would only be allowed to specify a
module-binding and would import all its exports, or b) allow leaving off the
'.{...}' but specify that it imports just the single binding when it's a
value-binding and imports-all when the path indicates a module-binding. I am
a little concerned that the former is too restrictive and the latter too
subtle. IMO. the extra '.*' is only a two-character hardship and EIBTI.
+1, or more -- agree on always requiring .{x} for lone x being too
restrictive, and the subtlety of .x meaning import-all sometimes, import just
x from left-context module other times, is even worse! EIBTI FTW ;-)
I guess `.*` is there for a purpose: to remind me that it's very likely I
don't want to say that. :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: names [Was: Approach of new Object methods in ES5]
On 2010-04-17, at 00:06, David Herman wrote: PS Still, I have my doubts about using any such mechanisms for versioning. The topic is not versioning in full, rather hiding properties added to built-in prototypes. I had the impression Tucker was thinking about versioning, but I may have imagined it. I guess I'm not clear on what desiderata the names proposal as-is doesn't address. Tucker mentions enumeration, but I'm not sure how important that is. It doesn't seem like a common need, but might be an interesting reflective operation. I was just thinking about ways to use private names to create distinct namespaces (sets of names). The benefit of names being leaf nodes would seem to outweigh being able to annotate names. Introspection could be supported by just keeping track of the names in my namespace, although it would be more convenient if there were a capability to enable `for in` to iterate over my names -- that's what led me down the sub-type path. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
names [Was: Approach of new Object methods in ES5]
On 2010-04-16, at 13:07, Brendan Eich wrote: Another Harmony idea: http://wiki.ecmascript.org/doku.php?id=strawman:names for unforgeable property names not equated to any string. These cannot collide, and with sugar to let them be used with . (not only in computed property accesses using []), we may have a complete solution for injecting new names into standard prototypes without breaking existing code. Comments welcome on the names proposal. There are open issues at the bottom, and the private keyword syntax is straw for sure, although we don't have a better proposal AFAIK. Name sounds like a stripped-down uninterned symbol (http://bit.ly/bY3Jkg) to me. It's an object with a magic attribute that says, unlike any other object you might try to use it as a property name, it is not coerced into a string first. And it is compared by identity when looked up. And it is invisible to (all?) enumerations of property names. I have to wonder if it would be a worthwhile generalization to be able to confer these magical attributes on arbitrary objects? This might allow more experimentation with namespace ideas. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: names [Was: Approach of new Object methods in ES5]
On 2010-04-16, at 14:31, David Herman wrote:
Tucker: if the property-nameness attribute weren't transferrable but names
were objects with property tables, do you think that would be powerful
enough? Or would you want the ability to define custom constructors, e.g.:
function MyCustomKindOfNamespace() {
Object.becomePropertyName(this);
// ...
}
I was thinking that for exploratory purposes, you might want a custom
constructor so you could, say, enumerate all the names in your custom
namespace, or test for a name being in your namespace. But I could do that
with just properties by (something like):
private customnames = [];
private custom;
function CustomName (pretty) {
let name = new Name;
name[custom] = pretty;
name.toString = function () { return custom:: + this[custom]; }
customnames.push(name);
return name;
}
function isCustom(name) { return name.hasOwnProperty(custom); }
etc.
A conundrum is that you don't want private names to be revealed by property
enumeration in general, but IWBN if they could be enumerated by someone with
access to the namespace. Using the idea of names having properties themselves,
if there were a way to say enumerate the properties that have some property,
you could use a private property as a capability to get at private names. I'm
sure we can have hours of fun suggesting how to extend the `for` syntax to
handle that. :)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: quasi-literal strawman
On 2010-04-05, at 17:37, Mike Samuel wrote: You can find my slides at file:///home/msamuel/svn-changes/clean/google-caja/doc/html/es-macros.html . I'd love to see your presentation, but I can't seem to reach your home dir from my LAN. Any chance there is a more public copy somewhere? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Traits library
On 2010-02-17, at 18:49, Tom Van Cutsem wrote:
As a unit of code reuse, trait composition is more flexible than class
inheritance.
+1
On 2010-02-17, at 19:30, Mark S. Miller wrote:
Of the three, I would rather see Tom's traits than either my
classes-as-sugar or Allan's extended object literal syntax.
+1
On 2010-02-18, at 00:29, Brendan Eich wrote:
Add to this tax revolt the plain desire for better syntax-as-user-interface.
If you want const f(){}, why //wouldn't// you want declarative trait syntax?
+1
On 2010-02-17, at 18:49, Tom Van Cutsem wrote:
As a unit of classification, interface types are more flexible than class
types (of course ES doesn't have interfaces, so I think a solid
object-type-testing mechanism would be a more useful addition to ES than
classes would be).
This seems like an important loose end to me. If Harmony adopts a declarative
trait syntax, is there still a reason to have an orthogonal type mechanism,
rather than traits being types?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Traits library
On 2010-02-16, at 17:55, Tom Van Cutsem wrote: Hi, Mark Miller and I have been working on a small traits library for Javascript. It is documented here: http://code.google.com/p/es-lab/wiki/Traits Nicely done. A couple of high-level questions. [Full disclosure: I'm with OpenLaszlo, and we have our own class/mixin implementation based on prototypical inheritance, built around some extra syntax, transformed by our compiler, and a runtime library; all running in es3 (and as2 and as3). We haven't yet thought about how we might take advantage of es5.] 1) I understand the motivation for traits (removing some of the magic of mixins), but I don't understand why that needs to be anything more than a lint-like tool, rather than insinuating itself into the implementation. The fact that you provide the order-sensitive `override` compositor weakens the case for strict traits. If override combination somehow made the overridden property accessible with a standard name (`super`), it seems to me you would have mixins. What am I missing? 2) Could you elaborate on this: The renaming performed by resolve is shallow: it only changes the binding of the property. If the property is a method, it will not change references to the renamed identifier within the method body. It seems to me that this 'feature' could lead to more magic than mixins. If I read this correctly, overriding a method in a trait will be visible to methods outside the trait, but not to methods inside the trait. That doesn't seem to follow the original traits composition principles. 3) In our usage, being able to test that an object is an instance of a mixin is quite important. In your description, you imply that type testing is an exercise left to the future. Has this not been an issue in applying your traits library? 4) Your 'stateful trait' example shows why I would call 'class state' and 'each-subclass state' (with the latter recommended, but the former could have applications). Because your implementation allows any type of property (not just methods), you also have 'instance state' in your traits. I think this is a good thing. Perhaps you should make that more explicit, since it diverges from the traits references. 5) I've lost track of where Harmony is heading with classes, but do you have any thoughts on that? Do you see you traits as an alternative to any other class proposal, or would it be intended as an extension of classes (as the original traits proposal was), should they ever arrive? P T Withington OpenLaszlo.ORG/Laszlo Systems ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Friday afternoon scoping quiz
On 2010-02-05, at 18:08, Dmitry A. Soshnikov wrote:
Scope chain (test): [
global,
{foo: undefined, bar: undefined},
{foo: 20, test: function () {...}}
]
This is the key that I was missing, as Brendan made clear. Despite `foo` and
`bar` being declared inside the `with`, because declarations are hoisted, the
`var foo` is shadowed by the `with (this)` when the assignment `foo = 42` is
evaluated.
Thanks for the clarifying illustrations.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Friday afternoon scoping quiz
({
'foo': 20,
'test': function () {
var f = function () {
alert(foo:+ foo);
alert(this.foo:+ this.foo);
alert(bar:+ bar);
}
with (this) {
var foo = 42;
var bar = 21;
f.call(this);
}
}
}).test();
--
By my reading, `foo` and `bar` are declared and initialized in `test`, and
closed over by `f`. I expect to see:
foo:42
this.foo:20
bar:21
But in Rhino, Firefox, Safari and Opera I am seeing:
foo:undefined
this.foo:42
bar:21
Flash 10 gives me the answer I expected. I have not tested other JS engines.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Friday afternoon scoping quiz
On 2010-02-05, at 17:25, Brendan Eich wrote:
On Feb 5, 2010, at 2:14 PM, P T Withington wrote:
({
'foo': 20,
'test': function () {
var f = function () {
alert(foo:+ foo);
alert(this.foo:+ this.foo);
alert(bar:+ bar);
}
with (this) {
var foo = 42;
var bar = 21;
f.call(this);
}
Doctor, it hurts when I use 'with' in JavaScript!
Indeed!
}
}).test();
--
By my reading, `foo` and `bar` are declared and initialized in `test`, and
closed over by `f`. I expect to see:
foo:42
this.foo:20
bar:21
But in Rhino, Firefox, Safari and Opera I am seeing:
foo:undefined
this.foo:42
bar:21
This is correct. The vars are hoisted but the initialization of foo puts 42
where it found foo on the scope chain, in this.foo. There's no 'bar' property
in |this| so that goes in the var.
Interesting! I couldn't convince myself that var hoisting would be quite so
literal.
Flash 10 gives me the answer I expected. I have not tested other JS engines.
Flash 10 bug.
I will report. Thanks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Friday afternoon scoping quiz
On 2010-02-05, at 17:42, P T Withington wrote: Flash 10 gives me the answer I expected. I have not tested other JS engines. Flash 10 bug. I will report. Thanks. FTR, appears to be already reported as: https://bugs.adobe.com/jira/browse/ASC-2257 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typed array strawman proposal
On 2010-01-27, at 12:17, Brendan Eich wrote: On Jan 27, 2010, at 8:16 AM, Peter van der Zee wrote: new ArrayMapping(arrBuf, intBits, intStart, intFinish); The WebGL use-case cannot tolerate scaling by a variable intBits element width. It wants constant (compile-time) element size. Really? In these days of the JIT-compiler, when is compile-time? I'd rather see a simple interface like the above, or like Lisp's displaced arrays, and just know that if I pick normal byte-sizes and offsets that I'm likely to trigger an optimization that turns my indirect array access into just a few hardware instructions (just a load if I am lucky, otherwise load/shift/mask). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typed array strawman proposal
On 2010-01-27, at 13:06, Brendan Eich wrote: Anyway, we do not want to require exotic techniques. We want to allow C++ implementations, which require constants to avoid obvious performance hits for no good reason. Competition will kill any browser foolish enough to take such hits. That seems inconsistent with the philosophy that classes can be syntactic sugar on closures that will be magically optimized. I'm just seconding the suggestion that you could have a flexible syntax that would allow specifying any byte width and offset and optimize the cases where the byte width and offset are known at compile time. Instead of guessing which of the n*m combinations you should cast in stone as built-in types. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typed array strawman proposal
On 2010-01-27, at 13:17, Brendan Eich wrote: On Jan 27, 2010, at 10:15 AM, P T Withington wrote: On 2010-01-27, at 13:06, Brendan Eich wrote: Anyway, we do not want to require exotic techniques. We want to allow C++ implementations, which require constants to avoid obvious performance hits for no good reason. Competition will kill any browser foolish enough to take such hits. That seems inconsistent with the philosophy that classes can be syntactic sugar on closures that will be magically optimized. That philosophy cannot possibly implement native GPU-oriented fixed-size machine-int-element-typed arrays! I must be missing something. You can optimize: new Int16Array(foo, n) but not: new IndirectArray(foo, 'int', 16, 0); ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: typed array strawman proposal
On 2010-01-26, at 13:43, Vladimir Vukicevic wrote: Howdy, At Brendan's request, I've just added a new strawman proposal for ES typed arrays to the wiki. This proposal comes from the WebGL group, which needed a way of efficient access to and manipulation of native machine-type arrays; once we came up with a reasonable baseline API, it looked like something that would be generally useful as more interop and performance demands are placed on ES. Typed arrays is probably not the best name; but that's probably an easy bikeshed. The strawman page is at http://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays and the associated [rough] draft spec is available at http://people.mozilla.com/~vladimir/jsvec/TypedArray-spec.html Thoughts comments appreciated; not sure if this is something that could be considered for the core language, or for a standard library of sorts -- feels more like something that should go in the latter. So, like Lisp displaced arrays (http://www.lispworks.com/documentation/lw50/CLHS/Body/f_mk_ar.htm)? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: subclassof
On 2010-01-18, at 15:41, Mark S. Miller wrote: On Mon, Jan 18, 2010 at 7:32 AM, P T Withington p...@pobox.com wrote: In the various classes-as-sugar proposals, is there a way to test if one class is a subclass of another? Is it as simple as: classa.prototype instanceof classb ? In some of them, yes. For the desugaring presented at https://mail.mozilla.org/pipermail/es-discuss/2008-August/006941.html, WobblyPoint.prototype instanceof Point would work for the right reason. Yeah, I saw (and liked) that. In OpenLaszlo we allow mixins (which are flattened into a single-inheritance prototype chain + multiple-inheritance interfaces), and we adopted the AS3 `is` operator, so we say: subclass.prototype is superclass and superclass can be either a class or a mixin. [Sadly this doesn't work in AS3!] In some later proposals, no, because the concept of subclassing is being replaced by the concept of trait combination. Since this gives non-tree-like subtype relationships, it can't accommodate instanceof. Should there be a `subclassof` operator? Do you have a pointer to the later proposals? I guess my question stands. Even if I implement classes using traits, I would want to be able to ask if a class had a particular trait. I guess that would have to be part of the class protocol then, not a language primitive. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: array like objects
On 2009-12-15, at 23:28, Brendan Eich wrote: Something more like Self, in other words. I still wonder if we can't recover that lost form, enable prototype-based composition as Tucker wanted, and banish host objects to the ninth circle of hell, in a future edition. We can dream! :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak references and destructors
On 2009-12-12, at 18:14, Mark S. Miller wrote: In my experience, it is always a bad idea for the GC to invoke user-code. Always? E uses async post mortem finalization to implement distributed acyclic GC. Without some way for GC to invoke user code, I don't see how this is possible. Without it, the resulting memory leak is severe enough to discourage many good distributed programming patterns. I guess it depends on how you define user code. And I should never say 'always'. My main point was to not give up weak-key tables just because finalization semantics are messy. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak references and destructors
On 2009-12-11, at 12:43, Brendan Eich wrote: It would be more than nice. It is important that the spec not mandate any particular schedule. We have seen endless over-coupling to GC implementation details where programmers who can hook into finalization or another GC phase do so for all the wrong reasons: to close fds, free database cursors, send a message, update UI, etc. Crazy stuff. +n In my experience, it is always a bad idea for the GC to invoke user-code. Please don't throw out the weak-key tables with the finalization bathwater. But if there is no guarantee of when the notification might happen, then programmers should not expect any scheduling akin to setTimeout with a timeout of zero. I initially mis-read this as saying setTimeout with a timeout of 0 might never be scheduled. But that's not what you said. -- I was amused by this aside from the strawman: Since I can never remember the black/white polarity of traditional gc descriptions, I will use retained for black, fringe for gray, and untraced for white. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 and Error Object properties
Sure would be nifty to have #file and #line directives, now that
Javascript is the new C.
FWIW, OpenLaszlo generates annotations like so:
Filename, line, column:
/* -*- file: lpp-8534.lzx#10.7 -*- */
Same file, but line numbering needs to be reset (because output has
more or less lines corresponding to source):
/* -*- file: #15 -*- */
No corresponding source file (i.e., generated code follows):
/* -*- file: -*- */
I can see merits to one gigantic comment up front with a mapping table
ala Caja, but we found interspersing them worked better for humans
staring at Javascript assembly in a Javascript debugger.
IWBNI @sourceurl could be expanded in some form to work with loaded
files...
On 2009-11-04, at 14:39, Patrick Mueller wrote:
Coincidently, I posted a blog entry on SyntaxError and eval()
yesterday:
http://pmuellr.blogspot.com/2009/11/evil-eval.html
On Nov 4, 2009, at 11:10 AM, Kevin Curtis wrote:
This has probably been chewed over but -
The ES5 spec defines 'name' and 'message' as properties of the
Error -
and ReferenceError, SyntaxError etc - objects.
Currently engines have useful additional non-standard properties:
Mozilla - fileName, lineNumber and stack.
V8 - stack (and type, arguments). (The string returned by 'stack' is
not in the same format as Mozilla).
JSC - line, sourceId, sourceURL, expressionBeginOffset,
expressionCaretOffset ,expressionEndOffset - and a few others for
Statement errors.
Any chance for ES6 on standardizing Error object property/ies which
report back the error location.
Maybe a property 'location' on the Error object which returns an
object. e.g
e.location -
{fileName:filename, pos: character posNumber, line:lineNumber ,
lineEnd:lineNumber, col:colNumber , colEnd:colNumber, stack:
stackString}
With maybe pos and line being mandatory properties and the other
properties set if they can be set.
Patrick Mueller - http://muellerware.org/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 and Error Object properties
On 2009-11-04, at 15:28, Brendan Eich wrote: On Nov 4, 2009, at 12:26 PM, Brendan Eich wrote: SpiderMonkey, when you set the JSOPTION_ATLINE runtime option flag, understands a comment of this form: //@line n //@line n f Can I enable this option from my script (preferably, or Firebug as a second choice)? I'm happy to adopt this syntax as being as good as any other. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 and Error Object properties
On 2009-11-04, at 16:27, Brendan Eich wrote: Alas not in content script. It seems the original bug that depended on //@line infrastructure (which is in SpiderMonkey, ready to be used), the bug to enable //@line *only* for our browser UI (chrome) and similar such (XBL, XPCOM component) scripts, has stalled: https://bugzilla.mozilla.org/show_bug.cgi?id=246286 I will get this bug going again, including the ability to set _options.atline = true; in the first script in a document, in order to get //@line support in the rest of the scripts. Cool! Thanks. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Operator overloading revisited
On 2009-07-01, at 03:48EDT, Christian Plesner Hansen wrote:
Methods live on objects and their prototypes.
Only if you co-opt the word method to mean that. I would claim this
is just shorthand for instance method. There is also class method
or static method. There are other definitions (see below).
On 2009-07-01, at 10:23EDT, Brendan Eich wrote:
How much sweeter could this be sugared?
function +(a :Point, b :Number) {
return new Point(a.x + b, a.y + b);
}
function +(a :Number, b :Point) {
return new Point(a + b.x, a + b.y);
}
function +(a :Point, b :Point) {
return new Point(a.x + b.x, a.y + b.y);
}
(Here the quoted operator names imply multimethod addition, where
previously I used |generic function| to Tucker's enthusiastic +∞).
Indeed.
Not to suggest paint, but I think the syntactic sugar of Dylan has a
nice color:
`a + b` is sugar for `\+(a, b)`
`\+` is a generic function (of 2 arguments) to which you can add
methods. Methods are just syntactic sugar for specifying the
branches of a dispatch algorithm (http://portal.acm.org/citation.cfm?id=236338.236343
). [That is since `+` is not a legal identifier, you have to escape
it to use it as an identifier, to name a generic function.]
If method has to be used uniquely in Javascript as the word that
means a computation attached to an instance, maybe we just need a new
word to mean dispatch element of a generic function. I would have
said generic function method, which (ambiguously) gets abbreviated
to method, and may be the source of objection?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Operator overloading revisited
On 2009-06-30, at 01:26EDT, Brendan Eich wrote: http://www.norvig.com/design-patterns/ +∞ The flip side of the diffusion of responsibility is the solipsism of encapsulation, which falls down as soon as there is more than one self (or `this` :P). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Operator overloading revisited
On 2009-06-30, at 14:06EDT, Brendan Eich wrote:
These are nice generic functions. With type annotations or guards,
you could imagine them as adding to generic function +:
generic function +(a :Point, b :Point) {
return new Point(a.x + b.x, a.y + b.y);
}
Syntax is not the point, please hold fire and spare the bikeshed --
the unencapsulated (no |this| or |self|) nature of these functions
is what I'm stressing.
+∞ again
If the reason is to assign responsibility to the different
constructors [*]
I don't understand the assign responsibility argument. Is this
about aligning (conflating?) security/access-control with classes/
instances?
Isn't a generic function a class that you could assign responsibility
to?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: extension modules
On 2009-06-27, at 22:12EDT, Alex Russell wrote: But this has demonstrated, to me at least, that the important language optimizations can be done well under the hood, without hinting. IMHO this is a good use of human capital, compared to the alternative of unleashing pragmas and machine types on the web developer masses, where the pragmas and types add complexity and often bite back. I'd just like to double +1 this point. Me 3. Compiler cycles we have plenty of, it's programmer cycles we need to optimize. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Another de-facto insecurity we need to fix in ES5
Does making an object not extensible imply/require than the object's prototype is also not extensible? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Classes as Sugar -- old threads revisited
These two are reversed, aren't they? The const should have the getter
rather than the value?
On 2009-03-30, at 22:41EDT, Mark S. Miller wrote:
pubInstVar: {get: Object.freeze(function{return pubInstVar;}),
enumerable: true},
pubInstConst: {value: pubInstConst,
enumerable: true}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Pretty function expression names
Assuming we're allowed to speculate on futures here...
I was thinking about improving debug-ability by adding descriptive
names to function expressions thusly,
var myFun = function my description here (...) { ... };
I.e., be able to use an arbitrary string as the name of a function
expression. It seems to me this would be an unambiguous extension,
only giving up an unlikely syntax error. No runtime is required to do
anything with the name, although it would be encouraged to make it
available as the .name property of the function object. Comments?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Pretty function expression names
On 2009-05-04, at 17:39EDT, Brendan Eich wrote:
On May 4, 2009, at 2:00 PM, P T Withington wrote:
On 2009-05-04, at 14:46EDT, Brendan Eich wrote:
On May 4, 2009, at 10:45 AM, P T Withington wrote:
Assuming we're allowed to speculate on futures here...
I was thinking about improving debug-ability by adding
descriptive names to function expressions thusly,
var myFun = function my description here (...) { ... };
Is this better for your purposes than
var myFun = function (...) { ... };
myFun.prettyName = my description here;
Just that it's shorter and easier to type. It would be a shorthand
notation for setting the .name property of the function object
created. I wouldn't expect the function to be referenceable by the
name, but I'd want Function.toString to display it (as a string
literal).
As Michael Haufe and Mike Wilson point out, this might leave some
wanting to call the function by that name within its own body. I'm
interested in why you wouldn't care about that use case -- because
you can guarantee that myFun never varies?
An intrinsic name for toString and reflection is a fine thing, but
people tend to expect functions with names to be callable in some
scope. There's the rub.
My real use case is passing an anonymous (non-recursive) function as
an argument. I don't actually know what identifier my function will
be bound to when it is called. If I need a recursive function _and_ a
pretty name, presumably I could use either your proposal or:
let x = function pretty name () { ... x() ... }
I see that people might expect to be able to say:
pretty name()
but I wasn't asking for that. (OTOH, there is precedent for using
string literals for attribute names that are not valid identifiers.)
I'm adding strawman and harmony pages to the wiki based on existing
discussions, so I'll roll up the function name proposal thread and
add this item. Thanks.
Thanks!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Announcement: ES3.1 renamed to ES5
Worse yet, you have inspired my managers to rename OpenLaszlo 4.2.1 to OpenLaszlo 4.3. Granted we are behind ECMA in our absolute value, but we make up for it in total decimals. I have just now released OpenLaszlo 4.2.0.2! Can 4.2.0.2.1 be far behind? :) On 2009-03-30, at 19:05EDT, Zachary Carter wrote: I honestly thought this was an early April fools. On Mon, Mar 30, 2009 at 6:40 PM, Mark S. Miller erig...@google.com wrote: On Mon, Mar 30, 2009 at 2:42 PM, Mark S. Miller erig...@google.com wrote: I don't want to jump the gun, steal anyone's thunder, nor mix metaphors, but to avoid confusion in some posts I'm about to make, I thought I'd go ahead and announce this now: Apparently, the issue of announcing this numbering change publicly was discussed at the same EcmaScript meeting. Somehow I missed it. My previous post violated the agreed protocol for no good reason. My sincere apologies. -- 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
Re: Object.prototype.inspect ?
On 2009-03-12, at 14:28EDT, Jason Orendorff wrote: On Wed, Mar 11, 2009 at 6:20 AM, Tobie Langel tobie.lan...@gmail.com wrote: It is very useful to be able to specify the debugging representation of an object distinctively from it's toJSON or toString representation. No doubt. I've implemented similar functionality on every serious JavaScript project I've done. Same here, but I bet I did it differently. Which makes me think this is _not_ an area for standardization. As long as there is a standard way to enumerate the properties of an Object and a standard way to determine an Object's 'class' (i.e., constructor, which you can only do in ES3 if you annotate each object yourself), you can write your own inspect and this is a dandy place to allow innovation, IMO. toSource or repr can learn from Lisp, but if you really want to do it right, we have along way to go. There is a big difference between being able to inspect/debug an object for human legibility and expecting that you can convert an object to a source expression that when evaluated will be equal to the original object (for some definition of equal!). ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.inspect ?
On 2009-03-12, at 16:31EDT, Brendan Eich wrote: On Mar 12, 2009, at 11:57 AM, P T Withington wrote: [...] Same here, but I bet I did it differently. Which makes me think this is _not_ an area for standardization. As long as there is a standard way to enumerate the properties of an Object and a standard way to determine an Object's 'class' (i.e., constructor, which you can only do in ES3 if you annotate each object yourself), you can write your own inspect and this is a dandy place to allow innovation, IMO. This was Rok's argument against standardizing toSource/uneval in ES3 timeframe, and it's a good one if the intention is to serialize and deserialize all cases preserving private state, non-enumerable properties, etc. I think we are a long way from needing serialize/deserialize arbitrary Objects. Having JSON should suffice. On the other hand, if the intention is to provide an easily inspected string representation that gives obvious or overt property values, e.g., uneval([0,1,[2,3]]) = [0, 1, [2, 3]] instead of the muddled toString result 0,1,2,3, then there's benefit in a common standard. And I agree that toString is next to useless as a debugging tool. Which is why I wrote my own. In my experience of writing my own, I have found that I've changed what I want the 'representation' of an object to be, and continue to change that. (Since my output is intended to help the human programmer, and not be eval-ed, I continue to adjust how attributes of an object are sorted, labelled, abbreviated, hidden/revealed, re-inspected, etc. Since my users are programming in a language above Javascript, I'm starting to change the representation to be more like the high-level language they write in, rather than display the Javascript assembly language.) Those are some of the reasons I'm not in a rush to standardize what inspecting an object means. But, I would very much like to see a standard way to discover an Object's constructor, and a way to enumerate _all_ the properties of an object. I know there is a tension between security and introspection. I don't know if this is something that can be handled by the presumably already-overloaded strict mode. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: name property for built-in functions??
Personally, I always name my function expressions, (and don't use new Function) so I am not presented with this dilemma. And that works great for me except for the one runtime in the universe that makes a hash of named function experssions... For introspection purposes, I create an object identity table and assign unique identifiers to objects, so I'd find either undefined or acceptable for unnamed functions. On Mar 1, 2009, at 13:56, Brendan Eich bren...@mozilla.com wrote: It's hard to be sure without more user feedback ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-06, at 00:23EST, David-Sarah Hopwood wrote:
P T Withington wrote:
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
I think this is unambiguous, but I don't like it because it has no
symbol or combination of symbols that is specific to a lambda.
( {( can occur as the start of a block.)
^{(a, b) a +b}
Perhaps? An expression cannot start with `{(`, a statement cannot
start with `^`.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Would it work to move the parameter list inside the block (as in the
Smalltalk way, but as a regular parameter list, not using ||'s)?
{(a, b) a + b}
AFAICT, `{(` is a syntax error for an expression in es3.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-04, at 15:23EST, David-Sarah Hopwood wrote: Arguably, the problem here is that semicolon insertion is and always was a bad idea. whinge That and not requiring whitespace around operators, thus taking away a huge domain of possible multi-symbol names (such as := for initialization/assignment to preclude the =/== trap, or say, )\ for λ, and forcing camelCasing or carpal_tunnel_syndrome upon everyone who prefers descriptive-symbol-names...) /whinge ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-02, at 20:32EST, Peter Michaux wrote: 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 Clarification on: OpenLaszlo is the opposite direction: JavaScript compiled into Flash. OL compiles an XML language to a subset of ECMAScript4 (or ECMAScript3 with the more mainstream parts of ES4: classes, type declarations, parameter defaults, rest args, etc.) and has multiple back-ends that compile that ECMAScript4 subset to (for example) JavaScript, ActionScript 2, or ActionScript 3. So, in a sense, we use Javascript as both an intermediate language and as an assembly language. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-02, at 11:48EST, Maciej Stachowiak wrote:
As long as we're giving the bikeshed a few more coats of paint,
Objective-C is adding block-like closures with ^ as the prefix, so
we could take inspiration from that:
^(a, b, c) { ... }
That's cute. Mnemonic for Λ (capital λ), also 'pointer-ish',
implying an object reference.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
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.
(BTW, I'm pretty sure I have that same Byte issue, in a similar box,
with a similar musty smell, _and_ the blue book. Back then,
worrying that 'line noise' or the death throes of your modem hanging
up would write code for you was a legitimate concern. Today, it is
just my old eyes that might gloss over `{||` and wonder why the `var`s
in that block are not visible in the enclosing function...)
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-01, at 11:30EST, Mark S. Miller wrote:
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.
(BTW, I'm pretty sure I have that same Byte issue, in a similar
box, with a
similar musty smell, _and_ the blue book. Back then, worrying
that 'line
noise' or the death throes of your modem hanging up would write
code for you
was a legitimate concern. Today, it is just my old eyes that might
gloss
over `{||` and wonder why the `var`s in that block are not visible
in the
enclosing function...)
Since it's a lambda, the 'var's will be visible in the enclosing
function.
Eh? So:
function () {
var foo = 42;
{|| var foo = 3; }
return foo;
}
and:
function () {
var foo = 42;
{ var foo = 3; }
return foo;
}
Give the same answer?
The point of having a very compact syntax for lambda is too make it
pleasant
to write control abstractions, as one does casually in Smalltalk.
With the
verbose lambda spelling, people will avoid those, or invent macro
systems
(as Scheme programmers do) mostly so they can avoid seeing all those
extra
lambda letters in the code.
Think of lambdas as blocks plus a bit more, rather than function
minus a
bit. Viewed this way, their block-like syntax is a virtue.
I agree with the goal of compactness. I just don't like it to be too
compact. Call me a curmudgeon. I don't like that `not` is spelt `!`
or that it is so easy to make a one-letter misspelling of `eql` and
end up with `setq` either.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-01, at 11:54EST, Mark S. Miller wrote:
On Mon, Dec 1, 2008 at 8:47 AM, P T Withington [EMAIL PROTECTED] wrote:
Eh? So:
function () {
var foo = 42;
{|| var foo = 3; }
return foo;
}
and:
function () {
var foo = 42;
{ var foo = 3; }
return foo;
}
Give the same answer?
No, because you forgot to call it.
Cool. So I can use `{||` and `}` to comment out blocks of code... :P
function () {
var foo = 42;
{|| var foo = 3; }();
return foo;
}
and:
function () {
var foo = 42;
{ var foo = 3; }
return foo;
}
do give the same answer.
Ok, your suggestion of 'block plus' not 'function minus' is making
more sense to me. Still hard for me to understand the newspeak.
Trying to wrap my mind around `var` meaning free; I think I get it.
But, I still think `{||` looks like my cat stepped on the keyboard.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On 2008-12-01, at 15:59EST, Maciej Stachowiak wrote:
\(a, b, c) { ... }
+1
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: return when desugaring to closures
On 2008-10-11, at 08:34EDT, David Herman wrote: Thank you for pointing out, though, that try/catch isn't so easily defined on top of return-to-label, since it still needs special handling for finally. The options are either to define a lower-level primitive underlying try/finally (akin to Scheme's dynamic-wind), or to leave exceptions -- or at least try/finally -- as primitive. I lean towards the latter; dynamic-wind is a subtle beast. [For those interested in dynamic-wind, Flatt et al's ICFP 07 paper has a nice investigation into its semantics:http://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf ] My 2p: If introducing a lower-level primitive would mean the language could someday have handler-binding (the ability to handle a condition in the frame it is signaled in), I think that would be a big win. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)
On 2008-09-19, at 09:18EDT, Mike Shaver wrote: On Fri, Sep 19, 2008 at 12:26 AM, Garrett Smith [EMAIL PROTECTED] wrote: If a thrown native object did not already have a stack, what is the harm in adding one? What should be done with a sealed object that's thrown? Rather than throwing a whole stack, I'd rather see a mechanism to let handlers run in the error context. I.e., HANDLER-BIND ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Ye olde arguments argument (was: Topic list - pending changes and issues for the ES3.1 spec)
We use it for debugging/backtrace. If it could be had in non-strict or, as mentioned elsewhere in this thread, by constructing an error object. (Actually, it looks like our current debug compile inserts it's own annotation to maintain a backtrace. So apparently we don't _have_ to have arguments.callee.) On Sep 12, 2008, at 8:08 PM, Brendan Eich [EMAIL PROTECTED] wrote: Great -- good to have library authors / maintainers on this list. I hold no brief for callee. The only issue in its favor is the cost of migrating to strict mode. A new version of Prototype that loses internal arguments.callee uses and is otherwise compatible helps. Dojo and other Ajax folks on the list, please pipe up. / be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Es-discuss - several decimal discussions
On 2008-09-04, at 03:37EDT, Brendan Eich wrote: Not really, but eq has been used to refer to this operation for decades in both the Lisp and capability communities. I can live with Object.identical, but I'll always think of it as 'eq'. Ok. If `identical` is too long, try `id`? Or, since it is the equivalence predicate for Object/hash, maybe it should be an operator named `#=`. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Sugar
On 2008-09-03, at 02:24EDT, Yuh-Ruey Chen wrote: However, ES-Harmony shouldn't introduce anything either not tested in other languages or extensively researched in academia. I would place hygienic macros for procedural languages in that category. Maybe we ought to look in existing research papers for some inspiration: http://scholar.google.com/scholar?hl=enlr=safe=offq=hygienic+macro+proceduralbtnG=Search http://scholar.google.com/scholar?hl=enlr=safe=offq=hygienic+macro+proceduralbtnG=Search [The Java syntactic extender](http://portal.acm.org/citation.cfm?id=504282.504285 ) is the descendant of Lisp macros, adapted to Algol-like syntax via Dylan, and probably the best candidate for study, IMO. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: opt-out local scoping
On 2008-08-28, at 07:52EDT, Dave Herman wrote: Lexical scope is in the air. :) Please take a look at the lexical scope proposal on the wiki and offer any comments or suggestions: http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope Essentially, the above is a less radical proposal that simply uses the lexical scope that's already there in JavaScript, but as you suggest enforces it with a pragma. The result is a language where free variables, both in assignments and references, are a statically detectable error, but with otherwise essentially the same semantics that JavaScript already has. I like this, but wouldn't you want to provide escapes, like reformed with and/or a way to declare an individual reference to be free? ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: opt-out local scoping
On 2008-08-28, at 09:09EDT, Dave Herman wrote: As for free references, what can you do with a free variable? If you mean you want a way to look something up in the global object, then use `this.id' or `this[expr]' (or `let global = this' followed by global.id/global[expr]). It might be nice to have a standard library (called `global' or something) that's bound to the global object so you can have a less fragile binding to the global object than `this'. Exactly. I think it would be worthwhile to have a standard way to refer to the global object. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
