Re: That hash symbol
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where end users (engineers and
architects as well as scripters) could contribute to the developer experience
of using JavaScript without incurring the wrath
wrath? I may have failed to add a smiley, but c'mon. No wrath here.
of it's fathers, which appear to be more focused on the interpreter of the
language rather than the thrust of it's use cases (which almost always appear
to bottom out on library abstractions to solve the issues).
What do you mean? What library abstractions, and what issues? Please be
specific.
Remember, I'm the one pushing for new syntax more than many others involved in
TC39:
http://brendaneich.com/2011/01/harmony-of-my-dreams/
I really would have hoped that rather than assuming an asses POV that this
list would assume the best without requirement of over-qualification.
Skipping, I don't know how to read this and I really don't want to guess
(asses POV meaning ass's POV? Who said anything about ass here? Yeesh.)
Like it or not, JavaScript is the glue of the web. This language space has
been embroiled in vendor politics
There is no vendor politics in this thread, though.
since day one- end users need an effective forum to describe their
requirements- that is what I was espousing. Clear enough?
No, you have not made any requirement clear. Let's take your first post today:
Implicit functions?
globalMethod(argument)
{
// implementation
};
AnObject.prototype.method(value)
{
// whatevs
};
Dropping function as the leading keyword makes these examples ambiguous, due to
automatic semicolon insertion as Mike Samuel pointed out.
Sure, losing the heaviness of eight-letter 'function' is a goal, and we've
discussed it often:
http://www.google.com/search?q=site%3Amail.mozilla.org+shorter+function+syntax
The ecmascript.org wiki has a strawman on it:
http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
This is not going forward as-is, and the plan is to write a new strawman, but
the goal of shorter function syntax is getting attention.
We spent time yesterday at the TC39 meeting not only on shorter syntax but
exactly how to support better |this| handling for several distinct use-cases:
inner functions that want the outer |this|, callbacks that want a certain
|this|, and object methods that want the receiver when called as methods of a
given (receiver) object (else possibly a default such as the outer function's
|this|).
Anyway, there's more to do than fix syntax, but the syntax has to be
unambiguous. That's the first requirement, before we can go further.
Kevin Smith started this thread by objecting to #, and that's fair. It's a bit
chicken-scratchy. If we can find a better introductory keyword or formal
parameter bracketing form, I'm game. I don't think -bracketing is it, not
only due to E4X (who cares, right?) but mainly because that breaks symmetry
with call expression, which uses ()-bracketing.
CoffeeScript uses () for formal parameter bracketing (where there are formal
parameters; parameter-less functions start with - or =), but allows call
expressions to elide the ( and ) where there is no ambiguity -- no ambiguity
according to CoffeeScript's complex, evolving rules for disambiguation.
I had the chance to talk to Jeremy Ashkenas about this recently, and he does
not recommend trying to graft these rules onto JS and standardize them. I agree.
So a leading character instead of 'function' still seems like the cleanest
solution. Ideas other characters than '#' are welcome, since so long as they
are not used in the language already (either as punctuators, operators, or
identifier characters), they can't introduce ambiguity.
You do yourself a disservice by assuming idiocracy.
I did not assume anything.
(Good movie, though -- Mike Judge is great!)
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Inner functions and outer 'this' (Re: That hash symbol)
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object methods that
want the receiver when called as methods of a given (receiver)
object (else possibly a default such as the outer function's |this|).
That reminds me of an old solution looking for this problem.
Back in 1976, Klaus Berkling suggested to complement the
lambda calculus with an operator to protect variables from
the nearest enclosing binding [1].
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
If I may use '#' as a placeholder for a suitable protection
key, then this translates to Javascript as
function Outer() {
var x = outer;
function Inner() {
var x = inner;
log(x); // inner
log(#x); // outer
log(##x); // global scope, probably unbound
}
}
I've seen this in action in a functional language based on his
ideas, in the late 80s, and have since been repeatedly surprised
by general unawareness of Berkling's ideas. Variants have been
rediscovered occasionally - git's HEAD^ is a recent example:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
Of course, applying the idea to Javascript's 'this' is complicated
by dynamic scoping. Personally, I've found it useful to think of
'this' as an implicit, lexically scoped parameter - then I only have
to worry about which applications pass which implicit parameter.
I don't know whether that is sufficient to make Berkling's idea
applicable here, but I wanted to make sure it is known;-)
Claus
http://www.haskellers.com/user/claus
[1] The original report is hard to come by, the idea was also
published again in 1982, items 5/6 in this bibliography:
http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/b/Berkling:Klaus_J=.html
Here is the original report's abstract:
@techreport{Berkling76,
author = {Berkling, K.J.},
title = {{A Symmetric Complement to the Lambda Calculus}},
institution = GMD,
note= {ISF-76-7},
month = {September},
year= 1976,
abstract = {The calculi of Lambda-conversion introduced by A.Church
are complemented by a new operator lambda-bar, which is in
some sense the inverse to the lambda-operator. The main
advantage of the complemented system is that variables do
not have to be renamed. Conversely, any renaming of
variables in a formula is possible. Variables may, however,
appear with varied numbers of lambda-bars in front of them.
Implementations of the lambda calculus representation with
the symmetric complement are greatly facilitated.
In particular, a renaming of all variables in a formula to
the same one is possible. Variables are then distinguished
only by the number of preceding lambda-bars. Finally, we
give a four symbol representation of the lambda calculus
based on the above mentioned freedom in renaming. },
topics = {FP - Lambda Calculi}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute
to the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
Kevin Smith started this thread by objecting to #, and that's fair. It's a
bit chicken-scratchy. If we can find a better introductory keyword or formal
parameter bracketing form, I'm game.
I like Doug's florin idea from an aesthetic POV, but I have two problems
with it -- suddenly, I have to care what charset my editor is using -- but
more importantly, I can't figure out how to type it on my Sun keyboard or on
my Windows box. Also, what of JS which is delivered on the web using
something other than unicode?
Allowing both is an interesting option, but then I remember how annoying
ANSI tri-graphs were (history lesson for !brendan: not all terminals had {,
C programs allow ?? instead) and realise that would be a mistake.
I, too, find #(a,b) but frankly, there aren't many lead-char solutions which
aren't ugly, easy to type, and not used by identifiers (or as operators)
already. What have we got to chose from? I think `@#%^* -- none of these
are measurably better than # and some are worse. Maybe you could make the
point that looks like a melted lambda. But I see no point in bike shedding
over this.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }` -- I don't find syntax like this
clear from a coder's POV, and there is the re-tooling issue with
highlighting editors and the ability to trivially transform between the
styles for faster adoption and old code minification -- while these issues
certainly shouldn't be deciding factors for TC39 it is nice that
leading-char lparen...rparen makes most of them go away.
You do yourself a disservice by assuming idiocracy.
I don't think Brendan ever assumed that this place is governed by idiots.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute
to the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
Kevin Smith started this thread by objecting to #, and that's fair. It's a
bit chicken-scratchy. If we can find a better introductory keyword or formal
parameter bracketing form, I'm game.
I like Doug's florin idea from an aesthetic POV, but I have two problems
with it -- suddenly, I have to care what charset my editor is using -- but
more importantly, I can't figure out how to type it on my Sun keyboard or on
my Windows box. Also, what of JS which is delivered on the web using
something other than unicode?
Allowing both is an interesting option, but then I remember how annoying
ANSI tri-graphs were (history lesson for !brendan: not all terminals had {,
C programs allow ?? instead) and realise that would be a mistake.
I, too, find #(a,b) but frankly, there aren't many lead-char solutions which
aren't ugly, easy to type, and not used by identifiers (or as operators)
already. What have we got to chose from? I think `@#%^* -- none of these
are measurably better than # and some are worse. Maybe you could make the
point that looks like a melted lambda. But I see no point in bike shedding
over this.
Erik and I worked through most of these options, considering their placement on
US and non-US keyboard layouts and their relative does it look like a
function?-ness. # won, not because either of us loved it, but because it was
the least bad.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }` -- I don't find syntax like this
clear from a coder's POV, and there is the re-tooling issue with
highlighting editors and the ability to trivially transform between the
styles for faster adoption and old code minification -- while these issues
certainly shouldn't be deciding factors for TC39 it is nice that
leading-char lparen...rparen makes most of them go away.
You do yourself a disservice by assuming idiocracy.
I don't think Brendan ever assumed that this place is governed by idiots.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
2011/3/26 Wes Garland w...@page.ca:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute
to the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
I'd be happy to participate too.
If the goal is to, as Kevin suggested, provide an early vetting
service of ideas as to how the language *should be* by people who know
have a detailed knowledge of how the language *is*, would a ticket
system be more appropriate/additionally useful? A ticket system might
use scarce attention better since it is 1:1, not 1:n.
Kevin Smith started this thread by objecting to #, and that's fair. It's a
bit chicken-scratchy. If we can find a better introductory keyword or formal
parameter bracketing form, I'm game.
I like Doug's florin idea from an aesthetic POV, but I have two problems
with it -- suddenly, I have to care what charset my editor is using -- but
more importantly, I can't figure out how to type it on my Sun keyboard or on
my Windows box. Also, what of JS which is delivered on the web using
something other than unicode?
Allowing both is an interesting option, but then I remember how annoying
ANSI tri-graphs were (history lesson for !brendan: not all terminals had {,
C programs allow ?? instead) and realise that would be a mistake.
I, too, find #(a,b) but frankly, there aren't many lead-char solutions which
aren't ugly, easy to type, and not used by identifiers (or as operators)
already. What have we got to chose from? I think `@#%^* -- none of these
are measurably better than # and some are worse. Maybe you could make the
point that looks like a melted lambda. But I see no point in bike shedding
over this.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }` -- I don't find syntax like this
clear from a coder's POV, and there is the re-tooling issue with
highlighting editors and the ability to trivially transform between the
styles for faster adoption and old code minification -- while these issues
certainly shouldn't be deciding factors for TC39 it is nice that
leading-char lparen...rparen makes most of them go away.
You do yourself a disservice by assuming idiocracy.
I don't think Brendan ever assumed that this place is governed by idiots.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
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: Inner functions and outer 'this' (Re: That hash symbol)
2011/3/26 Claus Reinke claus.rei...@talk21.com:
We spent time yesterday at the TC39 meeting not only on shorter
syntax but exactly how to support better |this| handling for several
distinct use-cases: inner functions that want the outer |this|,
callbacks that want a certain |this|, and object methods that
want the receiver when called as methods of a given (receiver)
object (else possibly a default such as the outer function's |this|).
That reminds me of an old solution looking for this problem.
Back in 1976, Klaus Berkling suggested to complement the
lambda calculus with an operator to protect variables from
the nearest enclosing binding [1].
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
If I may use '#' as a placeholder for a suitable protection
key, then this translates to Javascript as
function Outer() {
var x = outer;
function Inner() {
var x = inner;
log(x); // inner
log(#x); // outer
log(##x); // global scope, probably unbound
}
}
To clarify, if I have the code
foo(#x)
and suddenly I realize that I need a to guard it with a condition,
if (bar) {
foo(#x)
}
this would ?not? change the binding of #x since, although I have
introduced a new let scoped block, x is not declared in that scope so
it is not counted against the stack of #'s.
It is not always easy to count scopes though without knowing a lot of
details. E.g. changing
function f() {}
(function () {
function () {
return f;
}
})()
requires two hashes
function f() {}
(function () {
function f() {
return ##f;
}
})()
since f was introduced both into the body scope, and into the outer
scope via the function declaration.
It seems brittle, and it seems that overloading labels to name scopes
would provide a less brittle alternative if this really is desired.
myScopeName: {
let x;
function f(x) {
g(x + myScopeName.x);
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
extends keyword instead of superclass ...
Hi,
Just a small note on
http://wiki.ecmascript.org/doku.php?id=strawman:super_in_object_initialisers
(reading currently)
Why not just to use already reserved `extends` keyword for specifying a
superclass? These XML-like braces looks not so elegant.
Coffee users the same classes syntactic sugar as planned for ES6:
http://jashkenas.github.com/coffee-script/#classes and also reuses
familiar (for all?) `extends` keyword of ES3.
P.S.:
This (XML-like syntax) relates also to other meta-properties/attributes
in object initialisers. I prefer to use @ instead:
let foo = {
@proto: bar,
@sealed,
move: # (x, y) {
...
}
};
Though, again, e.g. Coffee (on Ruby's style) users `@` for `this`. Does
JS need this sugar for `this`? In this case (since # is planned to be
used actively) meta-properties can be:
let foo = {
#proto: bar,
#sealed,
move: # (x, y) {
...
}
};
Dmitry.
___
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)
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
To clarify, if I have the code
foo(#x)
and suddenly I realize that I need a to guard it with a condition,
if (bar) {
foo(#x)
}
this would ?not? change the binding of #x since, although I have
introduced a new let scoped block, x is not declared in that scope so
it is not counted against the stack of #'s.
This would _not_ change the binding of #x, because it
does not introduce or remove any bindings for x. Both
bindings and protections are specific to variable names.
It is not always easy to count scopes though without knowing
a lot of details. E.g. changing
function f() {}
(function () {
function () {
return f;
}
})()
requires two hashes
function f() {}
(function () {
function f() {
return ##f;
}
})()
since f was introduced both into the body scope, and into
the outer scope via the function declaration.
The counting is (usually) just by enclosing binders, not by how
many constructs or nested scopes they affect. So, I would count
one intervening binding here, and one protection # to keep the
binding structure as before:
function f() {} // target this binding
(function () {
function f() { // skip this binding
return #f;
}
})()
We could have this instead, where there'd be two bindings
for f to skip, and two protections to keep the binding structure
intact:
function f() {} // target this binding
(function () {
var f = function f() { // skip these bindings
return ##f;
}
})()
It seems brittle,
Not usually (did your counting scopes cloud the idea, or
am I missing some Javascript-specific problem?) - it has
been the basis of soft- and hardware implementations
of functional (and functional-logic) languages.
If we can find the binding for an unprotected variable, we
can find the binding to skip for a protected variable; one
binding and one protection cancel each other; once an
unprotected variable has a binding, it is bound.
It is still just the usual lexical scoping in action - the only
change is that shadowed bindings can now be reached,
by protecting variables from shadowing bindings.
That is all one needs to know about the system at the
programmer-level, at least for a language like Javascript,
whose operational semantics isn't defined by rewrite
rules (*).
Hope this helps,
Claus
(*) As a student, I found programming with it very intuitive,
even though the language we were given did execute by
rewriting (so the protection keys adjusted to dynamically
changing program structure, e.g, when a function definition
was inlined at a call site);
implementers find it similar to deBruijn-Indices (if an
implementation renames all variables to be the same,
the resulting protection keys correspond directly to
indices for stack access), but those are not usually
palatable to programmers;
http://en.wikipedia.org/wiki/De_Bruijn_index
when reasoning about programs, or rewriting programs,
it means that names are less of a problem, because we
can always preserve the binding structure (no more
exceptions like you can wrap code in a function,
provided the code does not mention the function
name or parameters).
___
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)
2011/3/26 Claus Reinke claus.rei...@talk21.com:
The idea is simply that (lexically scoped) variables usually
are bound to the next enclosing binding of the same name,
while protected (lexically scoped) variables are bound to
the next _outer_ enclosing binding of the same name
(each protection key skips one level of binding, lexically).
To clarify, if I have the code
foo(#x)
and suddenly I realize that I need a to guard it with a condition,
if (bar) {
foo(#x)
}
this would ?not? change the binding of #x since, although I have
introduced a new let scoped block, x is not declared in that scope so
it is not counted against the stack of #'s.
This would _not_ change the binding of #x, because it
does not introduce or remove any bindings for x. Both bindings and
protections are specific to variable names.
It is not always easy to count scopes though without knowing a lot of
details. E.g. changing
function f() {}
(function () {
function () {
return f;
}
})()
requires two hashes
function f() {}
(function () {
function f() {
return ##f;
}
})()
since f was introduced both into the body scope, and into the outer scope
via the function declaration.
The counting is (usually) just by enclosing binders, not by how many
constructs or nested scopes they affect. So, I would count one intervening
binding here, and one protection # to keep the binding structure as before:
function f() {} // target this binding
(function () {
function f() { // skip this binding
The line directly above introduces two bindings in two scopes. Did
you mean that both of them are skipped, or just one?
return #f;
}
})()
We could have this instead, where there'd be two bindings
for f to skip, and two protections to keep the binding structure
intact:
function f() {} // target this binding
(function () {
var f = function f() { // skip these bindings
return ##f;
}
})()
It seems brittle,
Not usually (did your counting scopes cloud the idea, or
am I missing some Javascript-specific problem?) - it has
I have never used such a feature, and thanks for recounting your
experiences below. Counting scopes seems brittle to me because
changes to intervening scopes can break code that is distant from
them. That's, of course, always the case with introducing a variable
that may mask.
been the basis of soft- and hardware implementations
of functional (and functional-logic) languages.
If we can find the binding for an unprotected variable, we
can find the binding to skip for a protected variable; one binding and one
protection cancel each other; once an unprotected variable has a binding, it
is bound.
It is still just the usual lexical scoping in action - the only change is
that shadowed bindings can now be reached,
by protecting variables from shadowing bindings.
That is all one needs to know about the system at the
programmer-level, at least for a language like Javascript,
whose operational semantics isn't defined by rewrite
rules (*).
Hope this helps,
Claus
(*) As a student, I found programming with it very intuitive,
even though the language we were given did execute by
rewriting (so the protection keys adjusted to dynamically
changing program structure, e.g, when a function definition
was inlined at a call site);
implementers find it similar to deBruijn-Indices (if an implementation
renames all variables to be the same, the resulting protection keys
correspond directly to indices for stack access), but those are not usually
palatable to programmers; http://en.wikipedia.org/wiki/De_Bruijn_index
when reasoning about programs, or rewriting programs, it means that names
are less of a problem, because we can always preserve the binding structure
(no more exceptions like you can wrap code in a function,
provided the code does not mention the function
name or parameters).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute to
the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
This es-discuss group sounds exactly like that ES Tech group -- why make a
new one?
If there's too much noise in any group, new or old, the group becomes useless.
Asking for some simple ambiguity checks before posting syntax strawmen, and
pleading to avoid one-line followups that overcite, etc. is *not* wrath. It's
part of the well-known netiquette standard, but not enforced much these days.
Hence the decline of USENET and NNTP, the rise of stackoverflow and the like.
Still a lot of noise in all the reddits, slashdots, etc. Voting/ranking can
help but cliques do game the system.
For ES Tech, let's use es-discuss. If someone thinks I called them a name
when I didn't, that's just bad on them. If I was rude, bad on me. We can patch
things up and move on.
And to be fair, the JS grammar is subtle enough that it's fine to propose
somehting that *might* work, only to have grammarians debug it.
So don't let me rain on anyone's parade, but please don't shoot entirely from
the hip. Read a bit on parsing and study the grammar, or just consider whether
what you propose is indistinguishable from what is already a valid expression
or expression followed by a statement.
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an outer
function, the return is legal).
C#, CoffeeScript, and other languages use - to link a formal parameter list to
a function body, which requires bottom-up parsing in general (with comma as
operator, as JS, C++, and C have; plus Harmony's destructuring and default
parameter value proposals).
Requiring bottom-up parsing has bounced off of implementors in the past, and
with JavaScriptCore switching from a Bison grammar to a top-down hand-coded
parser, I expect it will again.
I don't find syntax like this clear from a coder's POV, and there is the
re-tooling issue with highlighting editors and the ability to trivially
transform between the styles for faster adoption and old code minification --
while these issues certainly shouldn't be deciding factors for TC39 it is
nice that leading-char lparen...rparen makes most of them go away.
That's the idea. We need to keep this simple or it will probably fall apart,
either due to ambiguities, or implementors balking at too much complexity in
parsing with more power than top-down parsers have.
/be___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
I've put examples of real world code chock-full of anonymous function
expressions in both leading-char (#) and angle-braketing styles here:
https://gist.github.com/67
Feel free to continue this discussion on that page, if inclined.
khs
On Sat, Mar 26, 2011 at 10:44 PM, Brendan Eich bren...@mozilla.com wrote:
On Mar 26, 2011, at 6:44 AM, Wes Garland wrote:
On Sat, Mar 26, 2011 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
On Mar 25, 2011, at 8:45 PM, David Foley wrote:
My response was simply this : assuming normative scope in conversational
tone, that I would welcome is a venue where
end users (engineers and architects as well as scripters) could contribute
to the developer experience of using JavaScript
I was going to suggest comp.lang.javascript, but I just had a look and it
seems to have been taken over by DOM questions and spam. David, why don't
you start an ES Tech group or something, and ban questions which aren't
related to JS? (Copy your charter from comp.lang.c, maybe). Announce it
here, and I will subscribe. Probably even participate.
This es-discuss group sounds exactly like that ES Tech group -- why make
a new one?
If there's too much noise in any group, new or old, the group becomes
useless. Asking for some simple ambiguity checks before posting syntax
strawmen, and pleading to avoid one-line followups that overcite, etc. is
*not* wrath. It's part of the well-known netiquette standard, but not
enforced much these days.
Hence the decline of USENET and NNTP, the rise of stackoverflow and the
like. Still a lot of noise in all the reddits, slashdots, etc.
Voting/ranking can help but cliques do game the system.
For ES Tech, let's use es-discuss. If someone thinks I called them a name
when I didn't, that's just bad on them. If I was rude, bad on me. We can
patch things up and move on.
And to be fair, the JS grammar is subtle enough that it's fine to propose
somehting that *might* work, only to have grammarians debug it.
So don't let me rain on anyone's parade, but please don't shoot entirely
from the hip. Read a bit on parsing and study the grammar, or just consider
whether what you propose is indistinguishable from what is already a valid
expression or expression followed by a statement.
Non leading-char solutions have the disadvantage of using some other kind
of bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an
outer function, the return is legal).
C#, CoffeeScript, and other languages use - to link a formal parameter
list to a function body, which requires bottom-up parsing in general (with
comma as operator, as JS, C++, and C have; plus Harmony's destructuring and
default parameter value proposals).
Requiring bottom-up parsing has bounced off of implementors in the past,
and with JavaScriptCore switching from a Bison grammar to a top-down
hand-coded parser, I expect it will again.
I don't find syntax like this clear from a coder's POV, and there is the
re-tooling issue with highlighting editors and the ability to trivially
transform between the styles for faster adoption and old code minification
-- while these issues certainly shouldn't be deciding factors for TC39 it is
nice that leading-char lparen...rparen makes most of them go away.
That's the idea. We need to keep this simple or it will probably fall
apart, either due to ambiguities, or implementors balking at too much
complexity in parsing with more power than top-down parsers have.
/be
___
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)
This is an interesting idea, never heard of it before. That said, it seems a better start for brainstorming than as an end of it. The previously-mentioned concerns about numbering being fragile seem real to me. Further, how would this interact with eval introducing (or in some systems even removing) lexical bindings? (Or maybe eval doesn't matter if this only applies in a new language mode with no eval-like construct -- I'm not up-to-date on how eval interacts with the latest language proposals.) Nevertheless this 35-year-old idea seems fresh in the context of ECMAScript development, and worth thinking about, so thanks for bringing it up. Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On 03/26/2011 07:44 PM, Brendan Eich wrote:
Non leading-char solutions have the disadvantage of using some other kind of
bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an outer
function, the return is legal).
I might be misreading, but I think Wes meant to have ` as a bracket-y character, such
that on seeing it you switch to argument-parsing mode until you hit '{', or something
like that, then end the entire thing with another ` (bracket-y character).
There's no ambiguity there that I can see, although it has other issues, and wasn't
seriously proposed anyway (as I read Wes).
Jeff
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: That hash symbol
On Mar 26, 2011, at 9:06 PM, Jeff Walden wrote:
On 03/26/2011 07:44 PM, Brendan Eich wrote:
Non leading-char solutions have the disadvantage of using some other kind
of bracketing -- e.g. `a,b { return a + b; }`
This is ambiguous too. A comma expression followed by a block (if in an
outer function, the return is legal).
I might be misreading, but I think Wes meant to have ` as a bracket-y
character, such that on seeing it you switch to argument-parsing mode until
you hit '{', or something like that, then end the entire thing with another `
(bracket-y character). There's no ambiguity there that I can see, although
it has other issues, and wasn't seriously proposed anyway (as I read Wes).
Oh, I took the `` as meta, not concrete. If concrete, they are already used for
quasis:
http://wiki.ecmascript.org/doku.php?id=strawman:quasis-smorgasboard
Any quote character delimiting suggest strings, not functions. JS doesn't have
to look like other languages in every corner of its syntax, but it does look
like some big ones in most respects already, and it's hard to argue for looking
like nothing ever seen before, here!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
