Re: Unifying Block and ObjectLiteral (was: Re: block-lambda revival)
Ooo that's exciting! And so, if I'm not being too presumptuous, Does
this mean that constructions like if, while, etc become prefix
operators that can invoke a block lambda?
I've been flat out and haven't been able to look at this so it''s
exciting to see some progress on it. Just in case:
I hereby relinquish all copyright, trademark and patent rights I may
possibly hold, to the idea of unifying the object literal and block
grammar constructions to the TC39 group and its constituent members,
so help me god.
-Breton Slivka
On Wednesday, June 29, 2011, Brendan Eich bren...@mozilla.com wrote:
On Jun 23, 2011, at 3:27 PM, Brendan Eich wrote:
Also, if any { block } could be a lambda, perhaps we won't need that (nor any
new) syntax for block-lambdas.
We would need new syntax still, for formal parameters.
Making blocks be expressions requires unifying the ObjectLiteral and Block
productions. I don't know how to do this in without at least two-token
lookeahead, and it is not a backward compatible change if done for all places
where Statement : Block in the current grammar.
Apologies for not crediting Breton Slivka, who suggested working this
approach here:
https://mail.mozilla.org/pipermail/es-discuss/2011-June/014933.html
Here's an attempt to formalize the unification grammatically.
Block: { UnlabeledStatementFirstList } { WellLabeledStatement
StatementList? }
UnlabeledStatementFirstList: UnlabeledStatement
UnlabeledStatementFirstList Statement
Statement: UnlabeledStatement LabeledStatement
UnlabeledStatement: Block VariableStatement EmptyStatement
ExpressionStatement ContinueStatement ReturnStatement
LabelUsingStatement DebuggerStatement
LabelUsingStatement: IfStatement IterationStatement BreakStatement
WithStatement SwitchStatement ThrowStatement TryStatement
LabeledStatement: Identifier : Statement
WellLabeledStatement: Identifier : LabelUsingStatement Identifier :
WellLabeledStatement
(I'm using the American spelling of labeled and unlabeled. Can't help
myself!)
Notice the right recursion in WellLabeledStatement's rule.
The idea is to allow
javascript:42
and other such not-well-labeled statements for backward compatibility, but
only at top level in SourceElement context. Not after a { that starts a Block.
After a { that starts a Block, you can have a label only if it is followed by
a statement that could possibly use that label (labels may nest in such a
WellLabeledStatement).
Any expression after a label that follows a { therefore must be the value
part of a PropertyNameAndValueList in an ObjectLiteral.
This is a mostly-compatible change. Again props to crock for suggesting
restrictions to label usage as a spark that kindled this fire.
If I have this right, then we could add a new production:
PrimaryExpression: Block
to allow blocks as expressions. We'd still need the [lookahead ∉ {{,
function}] restriction in ExpressionStatement.
Making blocks be expressions allows us to treat them as zero-parameter
block-lambdas: ({statements}) instead of the ugly ({|| statements}). The
semantics would be the same as with a block-lambda: evaluation of the Block
is deferred until it is called, typeof says function, reformed completion
value is implicit return value, etc. See:
http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival
(I haven't unified the above with the block lambda revival grammar yet; one
step at a time.)
Grammar nerds, please validate!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Classes: suggestions for improvement
Perhaps I am overlooking something obvious, but is there something wrong with calling a constructor function `constructor`, rather than class or proto or prototype? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: statements that could be expressions?
If I could demonstrate my idea working in Narcissus (or your parser of
choice), would that be helpful or useful to anyone?
I was thinking about the ambiguity of {x,y} with relation to the
key/value shortcut, and it seems that there's a lot of ambiguities
around the { symbol that are causing some problems. My idea basically
boils down to embracing the ambiguities as special cases of the same
underlying semantic structure.
To put this another way, this is my thought exercise: pretend that
we're scientifically observing the state of javascript today, and we
decided to operate under the assumption that *all* structures that
begin with { and end with } compile and evaluate into the same type of
semantic structure (instead of multiple different kinds, function
bodies, objects, blocks with labels, and what have you) what kind of
structure is it that we are observing? It would seem like that as the
language stands we get access to a subset of this structure's
capabilities. In terms of moving forward, what kind of properties can
we extrapolate from what we know about this structure type already?
Looking backwards, what sort of properties does this structure have
currently that would produce the behaviour we see today?
There needs to be a lot more practical work done on this idea to make
it particularly compelling, but as I said, I'm willing to tinker with
getting it working in an existing javascript parser/evaluator if
anyone on this list thinks it is worth the time to investigate.
On Sat, Jun 4, 2011 at 9:04 AM, Brendan Eich bren...@mozilla.com wrote:
On Jun 3, 2011, at 3:11 PM, Waldemar Horwat wrote:
On 06/02/11 20:12, Brendan Eich wrote:
- Conflict between blocks and statements:
a = {x: while (x) { ... break x;}}
is either an object initializer or a block containing a labeled while
statement.
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax based
on feedback from Jorge here on the list mentions a block that cannot start
with a label. Two-token lookahead restriction, why not?
Don't you also want to allow (either now or in the future) for the shorthand
{x, y} to mean {x:x, y:y}? There are also getters, setters, and various
other stuff that can be put into object initializers now or in the future,
so there are more possibilities than just an identifier followed by a colon.
True, and {x, y} is noted somewhere (or was in a past version) as a problem.
http://wiki.ecmascript.org/doku.php?id=strawman:object_initialiser_shorthand
did not get promoted yet, and I forgot to keep this pot boiling.
The accessors are not ambiguous, but the proposed !, ~, and # property
prefixes for writable, enumerable, and configurable false-setting do make
trouble.
Perhaps Breton's more radical idea of unifying objects and block (lambdas)
deserves a look, instead of trying to separate syntaxes that start with { at
this late date.
/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: Re: Object.prototype.* writable?
whoah! I didn't know that. Why doesn't that work with:
function o () {}; o.prototype=null; new o();
?
As for the current discussion, I should think that some way to
instantiate a new clean global object, and inject it into the
current scope would be somewhat more useful, as it would enable newly
written scripts to depend on the assumption that those global
constructors are a particular shape, and leave old scripts which
depend on the mutable behavior alone. It would even enable new scripts
to depend on mutable global constructors- Their own mutated copies
that is. I vaguely remember some proposal along these lines. And some
libraries make their own copies of the globals to mutate.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Bringing setTimeout to ECMAScript
I can't think of a single way to simulate setTimeout in ES5. Correct me if
I'm wrong, but I don't think ES5 exposes a single way of defining a
mechanism like:
--
var x = 4;
function f(){ x = 5; print(x); }
timer(f, 1);
print(f);
--
Such that it would output 4 before 5. That's what I meant with didn't have
any asynchronism, fwiw.
while (!programHasQuit()) {
timers= (function () {
var timers = [];
var id=0;
timer=function (f,t) {
timers.push({func:f, interval:t, id:id++});
return id;
}
return timers;
})
runScript(myscript.js);
handleEvents(timers,otherevents);
}
and there you go, in pure JS. If this is a gui program, you may expose
a queue of GUI events to this master script, but I believe that the
event loop is best left to the embedding. If setTimeout etc are
implemented in the core JS engine, the JS engine can simply expose the
pool of timers as some data structure to the embedded C/C++ program to
do with what you wish- The standard would presumably specify some
guidelines for this.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Bringing setTimeout to ECMAScript
never write code on no sleep.
that code sample should be :
timers= (function () {
var timers = [];
var id=0;
timer=function (f,t) {
timers.push({func:f, interval:t, id:id++});
return id;
}
return timers;
})
runScript(env.js);
runScript(program.js);
ev=getEvents();
while (!programHasQuit()) {
handleEvents(timers,ev);
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: natively negotiating sync vs. async...without callbacks
On Wed, Dec 8, 2010 at 8:48 AM, Getify Solutions get...@gmail.com wrote:
I am aware that I'm kicking a potentially angry beehive by bringing up this
topic, but I wanted to just have some discussion around if there's any
possibility that JavaScript can, in the near term, have a native mechanism
added to it for better managing of sync vs. async coding patterns, without
nested callbacks.
snip
http://blog.getify.com/2010/12/native-javascript-sync-async/#proposal
Briefly, in summary, I'm suggesting a statement like this in JavaScript:
X(1,2)Y(3,4)Z(foo);
`X`, `Y`, and `Z` are all possibly function calls which will not complete
synchronously, but may defer their fulfillment asynchronously until a later
time/event.
The spirit of the proposal is that this special type of statement be a
linear sequence of function executions (as opposed to nested
function-reference callbacks delegating execution to other code).
The special behavior is that in between each part/expression of the
statement, evaluation of the statement itself (NOT the rest of the program)
may be suspended until the previous part/expression is fulfilled. This
would conceptually be like a yield/continuation localized to ONLY the
statement in question, not affecting the linear execution of the rest of the
program.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I haven't found anyone else that has worked this out, and I have been
keeping it kind of a secret, but seeing as I haven't yet done anything with
it, I will reveal that what you propose is more or less possible with plain
vanilla ecmascript 3. To modify your syntax proposal, what the syntax would
look like is something like this:
$(document).X(1,2).Y(3,4).Z(foo);
this call returns an object, with a call, and an apply method (possibly a
function object?) that when called, starts a chain of execution that is
suspended at the finishing of each operand. Most of the time this suspension
would be caused by a simple call to setTimeOut(next, 0); With other
functions that are obviously asyncronous, such as XHR calls, the suspension
is resumed at the point when the callback would normally be called.
This would be made possible by a library, I will call MND for the purposes
of this discussion. You start by passing MND an object with a set of
related methods:
var MyMonad = MND.make(MyObject);
the MyMonad object has methods with all the same names as the object that
you passed in, but when you call them, the names and arguments are simply
placed on an internal stack, and an object with call/apply methods is
returned.
When the call function is invoked, it loops through the version of the stack
stored on that particular object, by executing each method in turn, and in
the spot where each method requires a callback, it places an additional
helper function to continue execution of the stack. Additionally, the return
value of the previous method call is passed in a parameter (perhaps as a
property of this) to the next function to be executed. The initial
function call (above, as $(document)), allows you to pass in some starting
value for this chain of execution.
The only drawback is that the call/apply method would itself require a
callback function, for when the whole chain finishes, but that is still far
preferable than multiply nested callbacks, which is, I presume, the problem
you are attempting to solve.
I think the syntax for this type of library is simple enough to not require
new syntax. In fact it's pretty similar to jQuery, which as you probably
know is quite popular specifically for its simplicity.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: array like objects
On Tue, Dec 15, 2009 at 6:29 AM, Mike Samuel mikesam...@gmail.com wrote:
(3) If (!1), should future EcmaScript drafts define iteration order
for arrays as index order and possibly recommend to array like host
objects that the define iteration order similarly.
I would suggest that this change would be mostly useless to me in my
day to day work. The fact that past ecmascripts made the mistake of
enumerating over properties that should not be enumerated over (such
as monkey patched functions) is a fact of life that spawned two
patterns:
1. The crockford iteration:
for(var i in o) {
if(o.hasOwnProperty(i)){
//iteration code
}
}
2. The array-like iteration:
for(var i = 0; io.length; i++) {
//iteration code
}
When I iterate over an array or array like, I want JUST the numbered
indexes and none of the named indexes. I cannot think of a pattern
that uses for( x in y) which can gaurantee that, and I can't figure
out how I would use it in day to day work. The iteration code would
need to be prepared for either a numeric i, or a string i, so I
couldn't safely do arithmetic OR string operations on it without
deciding which I was dealing with first. Even if I did so, I can't
think of a situation where such code would be useful. not to mention,
would not changing the order break compatibility with existing
programs?
A far more useful direction for iteration is the generalization of the
forEach, map, and filter array extras. As others have pointed out,
there is an implicit contract in these methods. These are methods that
actually make programming easier, rather than just being useless
appendixes like some rigging of for-in iteration order would be. I
have no opinion on whether they should be static methods or not.
My suggestion would be that if an object can function as the this
argument within Array.prototype.slice, and slice returns a non empty
array, then it is array like, and should be acceptable within any of
the other array extras, as that's what I expect. This includes user
defined objects such as the jQuery object, host collections, the
arguments object, arrays from other frames, etc. This matches with
patterns that I use, patterns used in jquery, the pattern of calling
Array.prototype.slice on arguments objects, it renders moot the
trouble with arrays from external frames, and so on.
The only pitfall, which I've already pointed out, is that it also
includes strings, and may, if naively defined ( as I did earlier)
include functions, or objects in the style of {width:20, height:40:
length:60}. When I write templating functions, or dom tree walking
functions, I often need to distinguish between a host collection, an
array or array like, and a string, to decide whether I simply pass the
object on as is, or iterate over it. (is it singular or multiple in
nature?)
The fact is, javascript libraries, and programmers will use any
language construct they can grab a hold of to make reasonable
decisions that work within the program their writing. I'm not sure
what value there would be in TC-39 decreeing a pattern as blessed,
because programmers are just as likely to ignore it and just use what
works for them, today, right now, no matter how technically wrong it
is.
However, the discussion here has revealed one interesting thing: Both
ES3 and ES5 are inadequate for efficiently determining one particular
property of an object that would be useful in the accuracy of these
decisions. That is, it is difficult to determine whether an object has
numeric properties or not without iterating over [length] elements. If
there was some flag in an object that gets set on *insertion* of a
numeric property, a flag which is observable in some way from user
code, or something that gets observed by a built in isArrayLike, that
would, I believe, close this gap. Does it make sense to try and unset
the flag once it is set? I don't think that would be necessary.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: array like objects
On Tue, Dec 15, 2009 at 10:34 AM, Mike Samuel mikesam...@gmail.com wrote:
2009/12/14 Breton Slivka z...@zenpsycho.com:
On Tue, Dec 15, 2009 at 6:29 AM, Mike Samuel mikesam...@gmail.com wrote:
(3) If (!1), should future EcmaScript drafts define iteration order
for arrays as index order and possibly recommend to array like host
objects that the define iteration order similarly.
I would suggest that this change would be mostly useless to me in my
day to day work. The fact that past ecmascripts made the mistake of
enumerating over properties that should not be enumerated over (such
as monkey patched functions) is a fact of life that spawned two
patterns:
1. The crockford iteration:
for(var i in o) {
if(o.hasOwnProperty(i)){
//iteration code
}
}
2. The array-like iteration:
for(var i = 0; io.length; i++) {
//iteration code
}
Does the performance of this on large sparse arrays pose problems for
you in your day to day work?
E.g. for (o = new Array(1e100)).
No it does not. While I know that large sparse arrays are possible, I
do not encounter them very often. The only time I've used a sparse
array is in a representation of a timeline, where I did not expect to
visit N indexes in greater than linear time. I would not consider this
large on the order of your example, though. I have never encountered
anything like that. My performance expectations are about the length
of the array, not how many elements are properly stored in it. I lie a
little bit here, there is one situation where I expect greater than
linear time: Serializing the timeline into JSON, I convert the sparse
array representation to an array like object representation before
serializing (to save space). In this case I explicitly use for/in
without identifying the type of the object first. I already have a
reasonable assurance about what it's going to be since I created the
object myself, it will either be an array, or undefined.
I will concede though, a way to efficiently iterate over a sparse
array in numeric order might be useful in some cases. I suggest the
forEach (and other) array methods for this though. The efficiency and
implementation of that does not have to be visible to the user, as
long as the interface remains the same, and does not need to involve
the ecmascript committee.
Do you use jquery in day to day work? I ask because that's one
library that already seems to dynamically switch between the two.
Yes I do use jquery. I'm unsure about what you're referring to here
when you say the two though.
Can you think of any existing programs that rely on the current
(undefined but something like insertion order) order for arrays?
No I can't. I only know that standardising the order of iteration for
objects was brought up as a compatiblity issue during the ES4/ES5
standardization process, since all popular interpreters behave in the
same way. It would seem silly to me to then change the order after all
that fuss.
A far more useful direction for iteration is the generalization of the
forEach, map, and filter array extras. As others have pointed out,
there is an implicit contract in these methods. These are methods that
actually make programming easier, rather than just being useless
appendixes like some rigging of for-in iteration order would be. I
have no opinion on whether they should be static methods or not.
My suggestion would be that if an object can function as the this
argument within Array.prototype.slice, and slice returns a non empty
I think basing the definition on what Array.prototype.slice does is a
decent criterion.
array, then it is array like, and should be acceptable within any of
the other array extras, as that's what I expect. This includes user
defined objects such as the jQuery object, host collections, the
arguments object, arrays from other frames, etc. This matches with
Only if those collections are not empty. Calling slice on an empty
array obviously returns an empty array which would fail your test
above.
I'm not married to the nonempty criterion. What I mean here is to
exclude objects like {width:10, height:10, length:10}, or function
objects. The non empty criterion is simply a heuristic, a naive
solution to this tricky logic problem. But the empty set is still a
set after all. I am open to better solutions, and I don't even mind
considering such an object array like. I just thought I would try, out
of consideration of the arguments of other posters.
patterns that I use, patterns used in jquery, the pattern of calling
Array.prototype.slice on arguments objects, it renders moot the
trouble with arrays from external frames, and so on.
The only pitfall, which I've already pointed out, is that it also
includes strings, and may, if naively defined ( as I did earlier)
include functions, or objects in the style of {width:20, height:40:
length:60}. When I write templating functions, or dom tree walking
functions, I often need
Re: array like objects
The one that I use is
function isArrayLike(i){
return (typeof i !==string) i.length !== void (0);
}
It might not be perfect, but it allows me to make certain assumptions
about the input that are useful enough. Keep in mind that an Array may
have a length of 5, and all those values are undefined, so {length:4}
could be used as a valid arrayLike, and that seems reasonable to me.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: array like objects
On Tue, Dec 8, 2009 at 1:29 PM, Breton Slivka z...@zenpsycho.com wrote:
The one that I use is
function isArrayLike(i){
return (typeof i !==string) i.length !== void (0);
}
It might not be perfect, but it allows me to make certain assumptions
about the input that are useful enough. Keep in mind that an Array may
have a length of 5, and all those values are undefined, so {length:4}
could be used as a valid arrayLike, and that seems reasonable to me.
On Tue, Dec 8, 2009 at 1:18 PM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
Curiously, I don’t believe any of the “generic” functions for arrays and
array-like objects in section 15.4.4 actually depend upon such an
“array-like” test. They all simply use ToUint32 applied to the value of the
length property. If the length property doesn’t exist or its value isn’t
something that an a convertible representation of a number, the value 0 is
used as the length and not much happens. By this definition, all objects
are essentially array-like but many have no array-like elements.
You've encapsulated here some of the reasoning behind my earlier test-
Anything that passes my test is acceptable to any of the array
prototype functions, but filters out two situations that I've found I
didn't intend an object to be treated as an array. My usecase is
overloaded functions that may also accept objects, and strings, and
arraylikes, but I want a way to distinguish array-likes from objects
and strings.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: AST in JSON format
On Tue, Dec 8, 2009 at 3:57 PM, David-Sarah Hopwood david-sa...@jacaranda.org wrote: snip That would however depend on an assessment of whether browser implementors had succeeded in implementing secure and correct ES5-AST parsers (with a mode that accepts exactly ES5 as specified, not ES5 plus undocumented cruft and short-cuts for edge cases). -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com would it make sense to abandon our attachment to using the browser native parser, and just implement an ES5 parser/serializer as a seperate standard unit, without ties to the js engine itself? Would there be significant disadvantage to having two parsers in one ES interpreter? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arguments.callee in Harmony
On Fri, Sep 25, 2009 at 9:26 AM, Brendan Eich bren...@mozilla.com wrote:
On Sep 24, 2009, at 4:06 PM, Charles Jolley wrote:
I'm curious, why not just give anonymous functions a default name like
callee. Or perhaps have callee defined in a function scope to represent
the function? That seems to be exactly the same as the above; it just makes
it easier for developers. Is there a perf issue here?
No, there's simply a backward compatibility problem. Anonymous functions do
not inject any such name on the scope chain (in any object, new or expected,
on the scope chain). Changing the language to inject callee (even in an ES5
declarative envirnment frame) is not backward compatible and probably will
break some content out there that uses callee in an outer scope to mean
something else.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
this discussion reminds me a little bit of the aspect oriented pattern
that has been used in javascript on occasion. The idea there is that
it's possible to replace a function with a wrapped version of the
function that has the original function in the outer scope.
So for instance:
var myarray = [3,4,5];
myarray.toString = (function () {
var ofunc = myarray.toString;
return function () {
return Extended toString: +ofunc.apply(this,arguments);
}
})()
myarray.toString(); //returns Extended toString: 3,4,5
This pattern can be generalised:
function extendFunc (object, methodname, func) {
var ofunc = object[methodname];
object[methodname]=function () {
return func.apply(object,[ofunc].concat(arguments));
}
}
you can see that in that version, the new function recieves the old
function as its first parameter.
Now, my specific implementation has almost certainly got some flaws in
it (not a lot of error checking or robustness), I'm sure- and people
will argue about the details. It's the basic idea of aspect
orientation that I'm trying to get at here.
The reason I'm bringing this up though is that this is a simple highly
general building block that can be used to build the super
abstraction, I believe (among many other useful abstractions). It's
also implementable in current ecmascript, and it's something that
could become canonized as a native function in a future version of
ecmascript- similar to the array extras that were first in the
prototype library, but are now in ecmascript 5.
There might be even more clever ways to build it so that it doesn't
require an extra parameter (using with perhaps?) that could be used
now, but built in native code and optimised in future editions.
Anyway, I just thought I would put that out there for discussion.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: arguments.callee in Harmony
x On Fri, Sep 25, 2009 at 9:31 AM, Yehuda Katz wyc...@gmail.com wrote: What I'd like to know is what the rationale for removing arguments.callee from strict mode is. Is it a performance problem? If so, have implementors tried other solutions at compile-time before agitating for the removal of a language feature? The argument that this is simply a strict mode change falls flat when we're also told that Harmony will be built on ES5 strict mode. As far as I'm concerned, anything missing in strict mode is effectively being removed from the language. -- Yehuda https://mail.mozilla.org/pipermail/es-discuss/2009-March/008970.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: arguments.callee in Harmony
On Fri, Sep 25, 2009 at 10:49 AM, Breton Slivka z...@zenpsycho.com wrote: x On Fri, Sep 25, 2009 at 9:31 AM, Yehuda Katz wyc...@gmail.com wrote: What I'd like to know is what the rationale for removing arguments.callee from strict mode is. Is it a performance problem? If so, have implementors tried other solutions at compile-time before agitating for the removal of a language feature? The argument that this is simply a strict mode change falls flat when we're also told that Harmony will be built on ES5 strict mode. As far as I'm concerned, anything missing in strict mode is effectively being removed from the language. -- Yehuda https://mail.mozilla.org/pipermail/es-discuss/2009-March/008970.html Apologies with the curt message. I seem to have suddenly lost my ability to operate my computer competantly. I meant to say, that the rational has been discussed at length in the past. Here's the link to the mailing list thread about it: https://mail.mozilla.org/pipermail/es-discuss/2009-March/008970.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why decimal?
People generally expect math to work how they've been taught in school. When javascript violates their expectations, that is the very definition of a bug. It is true that binary might be more precise for certain kinds of applications, and if it's a native machine type there's performance advantages. These are facts that a novice programmer does not know or care about in the slightest. All they know is that even their desktop calculator can do this work properly, it must be javascript, or apple, or whatever that is broken. This is obvious to anyone that doesn't look at the world through nerd colored glasses. It's a fact so painful that microsoft even went to the trouble of pouring in an epic amount of research and development into their calc.exe so it doesn't display this broken looking behavior, as it displayed in earlier versions. A programmer might take the trouble to learn these esoteric computer facts, but end users won't. A less informed programmer might not even notice anything is wrong, until some unsuspecting user comes across it. Depending on the programmer, they may not know how to deal with it. And finally, it's highly likely that javascript will be used more and more on the server side in years to come, so javascript being a client side language no longer works as a credible excuse. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.prototype.inspect ?
On Fri, Mar 13, 2009 at 11:14 AM, P T Withington p...@pobox.com wrote:
snip
function subclass () { this.constructor = arguments.callee; }
I don't want to smash mysub.prototype.constructor, because that is how I
implement 'super': constructor.prototype.constructor.
I don't think we can change this, anyway -- it's an incompatible change.
More, since constructor can be deleted or overwritten, counting on it for
inspection is probably a bad idea.
Yeah, I'm sure you are right. And in my case, since I control the
Javascript that is getting written, I can live with it. But, I can't for
the life of me think of a use case for the existing way that constructor
works.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
So is there a reason the workaround is intolerable? You could go
further with this workaround in es3.1 and define it as a readonly
property, and also shadow its toSource to output a call to the
constructor function, with appropriate values. This puts the
responsibility for the housekeeping on those who care about the
accuracy of the constructor, without burdening those of us who use
strategies that don't depend on the value being accurate.
As long as we're talking roundtripping, might I just point out that
creating a full roundtripping toSource() for a function value is a
minefield? As has already been pointed out, there's the issues with
callable host objects, and private data. But let's not forget
closures, and enumerable (or even non enumerable) function properties.
functions are objects too! I cannot think of a particularly tidy way
to serialize either of those into a single expression.
What about arrays with defined properties? You can convert them to the
object notation, but how do you deserialize it to have the array
prototype? (well, you could have __proto__ defined I suppose)
It would be nice if this all worked, and there was syntax for it, but
I have the feeling that roundtripping has got to be a non goal. the
tc39 crew may have time for one or two improvements, but going all the
way is a big- maybe even impossible job.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: parseInt and implicit octal constants
On Mon, Feb 23, 2009 at 10:13 AM, Garrett Smith dhtmlkitc...@gmail.com wrote:
On Sun, Feb 22, 2009 at 9:30 AM, Allen Wirfs-Brock
allen.wirfs-br...@microsoft.com wrote:
David-Sarah Hopwood wrote:
Herman Venter wrote:
Finally, there is another approach to resolving this issue. Define a new
global function, parseInteger, that does the right thing and relegate
parseInt to Annex B.
That is a good idea, but I wonder: Would programs use that?
a program could use:
i = parseInt(x)
- which can result in undesirable behavior. That is fixed by:-
i = parseInt(x, 10)
- or the proposal:-
if(typeof parseInteger == function) {
i = parseInteger(x);
} else {
i = parseInt(x, 10);
}
-which seems a bit clunky.
How about this:
parseInt(x, 10) is already the compatible version parseInteger.
You could define the function parseInt to simply throw a typeError if
the second argument is missing. Or perhaps to break less existing
programs- to throw some kind of error should it recieve a string with
a leading zero in the first argument, and there is no supplied second
argument. This essentially turns a silent bug into a noisy bug, which
may be desirable.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Can an Array have array indexed accessor properties and other curiosities??
1) It's disallowed, Array instances can't have own accessor properties with array index names. (and since Array.prototype is an Array instance it can't either. An array instance could only inherit an accessor property with an array index name from Object.prototype) (snip) My preference is #1. Accessor properties are new to the standard and we get to decide where they are and aren't allowed. ... (snip) Opinions? Arrays already have a magical length property. may as well make indexes magic as well. As a user, I can't think of any particular use for making certain array indexes read only. Here's another one. What happens if the length field is set [[Writable]]: false and an attempt is subsequently make to define an array indexed property (using either [[Put]] or Object.defineProperty) whose name is = than length? I suggest it fails (silently or not depending upon the Throw parameter). I like this. It means you can make essentially fixed length arrays. Perhaps there is even room for implementation optimisation here if the user does this? What happens if the length is explicitly reduced such that an array indexed property that is [[Configurable]]: false would be deleted by the ES3 array [[Put]] algorithm? Alternatives: 1) The undeletable property is left undisturbed. (This tosses out the ES3 invariant that length is than the name of any array indexed own properties. 2) The redefinition of length fails (silently or not depending upon the Throw parameter). My preference is #1. #2 might be more consistent with my read-only length recommendation but I'm concern that it requires implementations to use a two pass algorithm to ensure atomicity. I'd prefer that not to impose that on implementers. what if you had #1, but the length property, rather than being set to the new value, gets set to the index of the last undeletable property + 1. That's what I would expect to happen. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Semantics and abstract syntax of lambdas
Okay, is it possible to introduce lambdas with no new syntax at all?
possibility 1:
for instance, suppose that we have a function that doesn't use
arguments or this. Can the implementation statically analyze a
function to determine whether a function uses those, and if it does
not, optimise it? Can we do stack optimized tail calls using the
return keyword, via static analysis? Are there other ways for an
implementation to examine how a function is used to optimize
performance, without altering syntax or semantics?
possibility 2:
This is probably a silly question, but, can we reuse object literal syntax?
mylambda = { let: {a:null, b:null, c:0}, call: { a+b+c } };
mylambda.call(2,2); //4
mylambda.call(3,3,3); //9
in this case, assigning a block to a property in an object literal is
invalid. I must admit ignorance of how the parser/interpreter works
here. Is it possible to take this context as a special case, and treat
the block as a lambda body, and a let property as a parameters list
with default values? I'm thinking about treating code as data here.
Kind of like lisp's S-expression syntax: originally designed for data,
but adapted to express programs.
are there other possibilities for expressing the lambda functionality
using only the syntax that ecmascript already has?
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Fri, Dec 5, 2008 at 9:35 AM, Brendan Eich [EMAIL PROTECTED] wrote: On Dec 4, 2008, at 2:31 PM, Breton Slivka wrote: I admit this seems ludicrous at its face, but admittedly I have not really seen the arguments against λ as an abbreviated lambda syntax yet. Not compatibly: ES3 already allows Unicode identifiers, including Greek Lambda. Other Mathematical Lambda characters are not in the BMP: http://www.mail-archive.com/[EMAIL PROTECTED]/msg15581.html It's still too hard to type. /be http://picasaweb.google.com/eileen.world.traveler/EileenBestOfGreece#5139474493916668850 ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Fri, Dec 5, 2008 at 1:10 PM, Brendan Eich [EMAIL PROTECTED] wrote: I thought this might be the answer. It's clearly too much to ask of all lambda-coders and would-be lambda-coders in the world. My two cents, perhaps I'm wrong and the Schemers and others will switch their kbd configs. Or the code generators will rise and exterminate lambda-coding humans. But I doubt it. /be approaching it from the other side of the question, it seems that people with german keyboards would have a similarly difficult time with the pipe character. example: http://forums.macosxhints.com/archive/index.php/t-29410.html It's the same issue with possibly any of the other symbols that have been discussed for the syntax. It doesn't really matter what you pick. If it's not lambda, you're inconveniencing someone. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Thu, Dec 4, 2008 at 9:28 AM, Michael [EMAIL PROTECTED] wrote: This may be a stupid question, but is the current let expression syntax defined in JavaScript 1.7 too fundamentally different from the sought out lambda expression to be repurposed? Or would this wreak havoc on current uses? I had kind of a similar thought about let statements. Would it be possible to simply turn a let statement into an assignable/callable value? Would that just break too many things? would it get us at least close to the lambda functionality we seek? ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Question: How would I write a recursive function with that syntax? Is
there a way to name the lambda, other than var = {||}; ?
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RE: Allen's lambda syntax proposal
Is recursion still desirable in this form. If so, then of the three I like
\(a,b,c) {}
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.
well if we're thinking about lambdas as blocks++, then why not
name: {|a,b,c| }
Since we already have labeled blocks. This also slides neatly into an
object literal
{
name: {|a,b,c| }
}
Or does this horribly break parsing again?
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Hey, I like that. In the spirit of fun, here's something that does
something weird and random.
var fsm = {
r: {|| Math.random()0.5},
f: {|a| print(a); ( fsm.r() ? fsm.s : fsm.r() ? fsm.m : {||} )(f);},
s: {|a| print(a); ( fsm.r() ? fsm.m : fsm.r() ? fsm.f : {||} )(s) },
m: {|a| print(a); ( fsm.r() ? fsm.f : fsm.r() ? fsm.s : {||} )(m);}
}
fsm.f();
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Date literals
On Thu, Nov 20, 2008 at 9:40 AM, David-Sarah Hopwood
[EMAIL PROTECTED] wrote:
Peter Michaux wrote:
All the data types in ES3 listed in section 15 have literals version
(e.g. {} for Object, [] for Array etc) except for Date. Is there any
reason that the Kona 15.9.1.15 Date Time string format could not be
a literal form for date objects?
-MM-DDTHH:mm:ss.sssTZ
The 'T' in the middle makes this identifiable as a date literal
similar to how the 'e' or 'E' of an exponential number literal works.
When lexing this syntax, the lexer would recognize the tokens
N - N - N : N : N .
where N is a NumericLiteral, before seeing that the next 'sssTZ'
is invalid and then having to backtrack 10 tokens. This requires
something like an LL(*) parser; it is not LL(k) for any finite k
(because each NumericLiteral can be an arbitrary number of
characters), or in any similar nicely-behaved grammar category.
Please don't add syntax like this.
I'm a little confused. I don't suppose it makes a difference to what
sort of parser is required, but I wouldn't have thought that the
parser would recognize something like 12T06 as a numeric literal.
Wouldn't the T in the middle tip the parser off a little bit earlier
than 10 tokens?
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Sugar
One reason I brought them up now was that Java-style classes were discussed. Significant parts of this class functionality could instead be offered by third-party library vendors using these keywords. We'd get more variation, greater freedom, and much faster adaptability, than if it's defined in a standards body. At the great expense of interoperability. In the grand scheme of things, I don't need greater freedom, variation, or adaptability in the way that I define a class. Especially if it means I have to tack on many kilobytes of library code to use widget X, and then many more Kb's to use widget Y, and cross my fingers they don't eat eachother. Much better to have a single built in implementation for that feature that everyone codes against- So I can use code without having to include any libraries. The end user ultimately doesn't care that you used a clever class library, only that the application works, is fast, easy to use, and bug free. Language features should be aimed squarely at helping programmers achieve those goals, and I don't see how building a new tower of babel helps. But you know, just my opinion as a lowly developer. ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: local
On Fri, Aug 22, 2008 at 1:21 AM, Peter Michaux [EMAIL PROTECTED] wrote:
On Thu, Aug 21, 2008 at 6:31 AM, Brendan Eich [EMAIL PROTECTED] wrote:
More helpful would be
comments on the utility of let blocks (a.k.a. let statements) and let
expressions. Also comparisons to the several let forms in Scheme (Jon
Z. posted something a while ago on this topic).
Hello, I am a javascript end-user (and occasional abuser). I've been
following this fascinating conversation, and I figure since Brenden is
polling for comments, I thought I would throw mine in. Let expressions
and let statements seem like they might help speed the writing of some
kinds of code, but it looks to me like they complicate reading code
back. In the case of let statements, as I understand it, the current
proposal, and how let works in firefox is that
let (x = 2, y = x) {
print(y);
}
desugars to
{
let x = 2, y = x;
print(y);
}
This makes sense to me, and I could possibly even be convinced that
the first form organizes code a bit better, by keeping all the
variables in one place, and distinct from the code that operates on
those variables.
The let expression on the other hand
z = let (x = 2, y = x) x + y;
it spooks me out because it's a language construct that uses
parentheses being used kind of like an operator. Similar things can be
done with the if statement, and that usage can easily lead to bugs.
Javascript 1.8's similar treatment of function spooks me in the same
way- because it suddenly becomes more difficult for me as a reader to
determine what code is part of the function, or the let statement, or
the if statement, and which parts are not. At least if there are { }
braces then it's visually obvious where the effect starts and where it
ends.
Though I suppose for some, saving two keystrokes is important.
I was reading the resulting ticket a few days ago.
http://bugs.ecmascript.org/ticket/375
I think that the let statement
let (x = 2, y = x) {
print(y);
}
should desugar to exactly
(function(x, y) {
print(y);
})(2, x)
Also the let expression
z = let (x = 2, y = x) x + y;
should desugar to exactly
z = (function(x, y) x + y)(2, x);
I think that intruducing function semantics to the world of let
would cause undue confusion, since what we are essentially talking
about is a drop in replacement for var, plus some additional syntax
to make block scopes easier to create. As has already been covered by
brendan, functions bring with them a boatload of baggage that I don't
necessarily want in just a simple block scope. This is especially
important considering that javascript closures are actually quite an
advanced subject. It would be much easier to explain the let statement
on its own terms, than to try to explain it in terms of everything
that a javascript function does.
But at the same time, I can agree that I woudln't mind some kind of
syntactic sugar for those function patterns. I just don't think let
Is the right sugar. I feel that there could be much less verbose ways
of declaring a function in place than what is currently on offer. It
is quite common to declare a function as a callback, and define it in
place as a parameter to another function, and the current syntax for
doing that is quite bulky. In addition, the syntax for declaring a
function, and calling it in place is bulky as well. (though for many
of the cases where you'd need to do it, a let statement without the
function baggage would work just as well).
When I saw the notes for javascript 1.8 I was quite excited about
syntactic sugar for function declarations, but was quite dissappointed
by what was delivered. I've already sounded off about my anxiety from
function (a, b) a+b;, What I was expecting, and would have prefered
was something more along the lines of (a, b){ a+b; }; or even fn(a,
b){ a+b; }; it's really the function keyword, which cannot even be
properly aliased, that really gets to me. Especially when I just need
to quickly define a function parameter in place.
Though if I supposed that let statements, or some other construct
implemented the real lambdas that Brendan has been mentioning, I would
be just as happy with those, if it could make my code a bit less
bulky, and more readable.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
