Re: Allen's lambda syntax proposal
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only
use it half as often as I should.
Chris
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ES3.1 Draft: 01 Dec 2008 version available
I have uploaded to the wiki (linkhttp://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft) the 01 Dec 2008 draft of the specification for ES3.1. This is in the form of in-place edits and markups to the ES3 specification. Revision history is at the end of the document. The main changes in this draft are: (1) Reverting the Statement/SubStatement distinction (refer my email on Chap 12 edits on 11/18 to the discuss lists) (2) Reverting Decimal. Note that I have not yet applied the rest of the feedback from the Kona meeting or the feedback I have recv'd over email. pratap ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 2:06 AM, Chris Pine [EMAIL PROTECTED] wrote:
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only use it
half as often as I should.
What is to be made of that last sentence? If you have a choice between
the following, The lambda version is still shorter.
function() {}
lambda() {}
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Peter Michaux wrote:
On Mon, Dec 1, 2008 at 2:06 AM, Chris Pine [EMAIL PROTECTED] wrote:
Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
Looks like Ruby to me, so you know I love it. :)
Nice lambda syntax really matters. If that tool is too heavy, I only use it
half as often as I should.
What is to be made of that last sentence? If you have a choice between
the following, The lambda version is still shorter.
function() {}
lambda() {}
{||}
Not from where I'm sitting... 'lambda' is shorter than 'function', but
'{||}' is shortest of all... or perhaps I don't understand you?
Chris
___
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 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.
function () {
var foo = 42;
{|| var foo = 3; }();
return foo;
}
and:
function () {
var foo = 42;
{ var foo = 3; }
return foo;
}
do give the same answer.
--
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Newbie Q's
Aaron Gray wrote: Hi, I have been beginning to read the ML reference implementation and have a few basic questions. What is REPL and what does it stand for ? What is a RIB and does it stand for anything ? What are FIXTURES ? REPL stands for read, eval, print loop. It's lisp slang for interactive programming-language prompt. A fixture (in ES4-ese) is a fixed property -- either of a scope, an object type, or a class -- known at definition-time. A rib (in ES4-ese) is a static map from names to fixtures. It's not an acronym. This is all written up in the last draft of the ES4 proto-speclets. But at this point it doesn't matter. Considering how much of the ES4 design is now either permanently off the table or in indefinitely deferred status awaiting re-appraisal in the future ES-harmony effort, I'd recommend *against* reading the existing ES4 RI. It's more likely to confuse than to illuminate. Probably we should take the links to it down, at least for the time being. Sorry to be the bearer of bad news. -Graydon ___ 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: Newbie Q's
Aaron Gray wrote: Hi, I have been beginning to read the ML reference implementation and have a few basic questions. What is REPL and what does it stand for ? What is a RIB and does it stand for anything ? What are FIXTURES ? REPL stands for read, eval, print loop. It's lisp slang for interactive programming-language prompt. Yes I found that one, cheers :) A fixture (in ES4-ese) is a fixed property -- either of a scope, an object type, or a class -- known at definition-time. A rib (in ES4-ese) is a static map from names to fixtures. It's not an acronym. Okay, I get that now. Strange terms. This is all written up in the last draft of the ES4 proto-speclets. But at this point it doesn't matter. Considering how much of the ES4 design is now either permanently off the table or in indefinitely deferred status awaiting re-appraisal in the future ES-harmony effort, I'd recommend *against* reading the existing ES4 RI. It's more likely to confuse than to illuminate. Probably we should take the links to it down, at least for the time being. Sorry to be the bearer of bad news. No I should have joined the mailing list sooner than I did ! Its a great shame I was very looking forward to the pre harmony ES4. I have been reading Tamarin source on and off for a couple of months or so, and had just started with the RI. Luckily for me I am only really interested on an academic level and seeing how far static/dynamic language divide can be pushed. Looks like order and attribution problems of text based scripting languages in general. Had ECMAScript progressed onto a binary bytecoded distribution format like ActionScript then maybe these problems could have been solved, but then I am forgetting ES3.1. Order dependance is a difficult one. Many thanks for the reply, Aaron ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Understanding reasons for Harmony
Brendan,
Great shame, but as you say its a broken design.
Many thanks for the full explanation,
Aaron
- Original Message -
From: Brendan Eich
To: Aaron Gray
Cc: es-discuss@mozilla.org
Sent: Monday, December 01, 2008 1:06 AM
Subject: Re: Understanding reasons for Harmony
On Nov 30, 2008, at 10:49 AM, Aaron Gray wrote:
Well as announced in August the ECMAScript 4 language is being heavily
watered down. Both packages (April)
https://mail.mozilla.org/pipermail/es-discuss/2008-April/006183.html
I cannot actually see what is wrong here, AFAICS package Q's usage of x
should be an error as x is actually defined in R as external and there is no
other definition of x in scope.
Package Q contains
import R.*;
which brings (or should bring) R.x into scope under the name x in Q.
Note that external does not mean what extern in C means. It was a
proposed ES4 built-in namespace meaning defined in this package but visible
outside of it.
Could someone explain or give a better example.
I can see how the decisions are hard to understand without close reading,
including knowing what external was proposed to mean (I can't find a trace of
it in the wiki -- it was cut too well), and thinking through the meaning of
parenthetical asides such as Lars's consider that public::x is introduced in
some later file, at a later time and consider flagging the reference to x in
P as ambiguous.
Even more important than these fine points was the big-picture point that
packages were intended to be sugar for namespaces. Lack of a desugaring meant
ES4 was at risk of being all of late, incomplete, and inconsistent.
If there were no conflict about the meaning of x in P, then we would have not
had such a problem.
Avoiding a conflict by making the reference to x ambiguous (an error) was
considered arcane because the nesting and order of package fragments should
not introduce or eliminate such an error. As with namespaces (more below),
package-based name lookup must agree between compile time and runtime. They
must not be subject to complicated and hard-to-follow rules.
Plus, we had a schedule for ES4 that was being slipped with every open
problem of this order. The right thing to do per sane requirements management
is to cut, with additions such as the built-in internal namespace added to
palliate the loss of packages in a future-proof way.
Therefore the example Lars gave is sufficient -- you don't need a better
example. That one was sufficient to kill packages as sugar in the time-frame we
had for ES4.
and now namespaces have been jetisoned too.
https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html
Again could someone give a good example of whats wrong with namespaces.
The fundamental problem with namespaces was the lack of a module system by
which to prioritize namespaces during name lookup.
This need for prioritization (one idea was a first-name-wins reservation
system) affected both unqualified name lookup due to the extensible global
object, and name lookup among superclasses.
Consider just the global object case, with two namespaces, both open in the
same lexical scope, where a namespace ns is defined at first in only one of
the namespaces (note how namespaces can qualify namespace names along with
other names):
namespace A;
namespace B;
use namespace A, namespace B;
A namespace ns;
Let's say there's a use of ns to qualify an identifier x, in the same lexical
scope (top-level content in a script tag, in a web page):
... ns::x ...
Assume x resolves in ns. The question is: what does ns mean? Let's refine the
reference to be in a function body:
function foo() {
... ns::x ...
}
and close this lexical scope (program defined as a script tag's inline
content or out-of-line src=URL content). Then in a later program evaluated in
the same global object, we add
B namespace ns;
foo();
What effect, if any, does the B::ns namespace have on the meaning of ns::x in
foo's body?
We don't want any effect, even an ambiguity error -- otherwise name integrity
is gone and information leaks if not hijacking attacks are too easy. Lexical
scope means the name lookoup judgments at compile time and runtime should
agree, and foo's scope should be static in all senses.
But how do we implement this? ES4 had only the reservation system idea
whereby:
A namespace ns;
would reserve ns in *all* namespaces, even ones not seen yet, for the life
of the global object being mutated by the definitions. This was considered
broken-as-designed.
An alternative would treat each top-level scope as a module, either by giving
it its own global object (as is done in AS3, IIRC), or at least a subjective
prioritization mechanism by which to make ns mean only A::ns when used in
foo, no matter what B::ns might be defined later. But such
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 7:31 AM, P T Withington [EMAIL PROTECTED] wrote:
On 2008-11-30, at 01:30EST, Brendan Eich wrote:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I would rather have a more literate syntax, lest we degenerate to where
practically any comic book blasphemy is a valid program.
I agree with this sentiment. The phrase ASCII vomit comes to mind
and becomes a worry.
Take an ES program and replace all if-else with ?: and then most
functions with {||} and it starts to look quite cryptic.
A reader would have a difficult time even knowing what to look up in a
book index to find out what the {||} that they see in some code is
supposed to be. It wouldn't necessarily be clear that the {} and the
|| are related.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 1, 2008, at 10:17 AM, Peter Michaux 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.
I agree with this sentiment. The phrase ASCII vomit comes to mind
and becomes a worry.
I don't think it's a big worry. It seems to me ES3 (never mind new
syntax) is far from Perl, but not nearly Python or an even more
pedagogical language in which
There should be one-- and preferably only one --obvious way to do
it.
There are already several ways to say the same thing, for many values
of thing, in JS.
Take an ES program and replace all if-else with ?: and then most
functions with {||} and it starts to look quite cryptic.
But functions remain. I doubt lambdas in any synax will replace them.
A reader would have a difficult time even knowing what to look up in a
book index to find out what the {||} that they see in some code is
supposed to be. It wouldn't necessarily be clear that the {} and the
|| are related.
A novice reader, you mean. Readers who know the language may prefer
brevity. This is not a simple read over write optimization issue.
/be
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 10:24 AM, Brendan Eich [EMAIL PROTECTED] wrote:
On Dec 1, 2008, at 10:17 AM, Peter Michaux wrote:
Take an ES program and replace all if-else with ?: and then most
functions with {||} and it starts to look quite cryptic.
But functions remain. I doubt lambdas in any synax will replace them.
Actually, I think the combination of Object.create, lambda, rest
parameters and class will probably eliminate function and prototype
from most code.
lambda will be slightly faster and lighter than function. Programmers
like faster and lighter when it comes at no cost.
People seem to want to think in terms of classes and not the prototype
property of a function object. Colin Moock's book on AS2 recommended
against using prototype after the introduction of class to that
language.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How much sugar do classes need?
Peter Michaux wrote:
On Sat, Nov 29, 2008 at 9:49 PM, Mark S. Miller [EMAIL PROTECTED] wrote:
var self = {
to toString() {
return '' + self.getX() + ',' + self.getY() + '';
},
to getX() { return x; },
to getY() { return y; }
let pubInstVar: 4,
const pubInstConst: -4
};
return self;
The to isn't a typo, but wasn't explained. It creates a non-writable,
non-enumerable, non-configurable property whose value is a frozen function.
What is the motivation for choosing the string to?
It is used in E to introduce a method.
(It was also used in Logo to introduce a procedure declaration, but that
may be a coincidence.)
I am not attached to the specifics of my object/public block. But what
this thread has already taught me is that it is instances that need sugar,
not classes. Enhancing the object literal notation is one way to get there.
The object literal notation shouldn't be burdened with freezing the
actual function object. The object literal should at most allow
specifying that it's own property reference is frozen. The object
literal freezing the function object itself seems like going a step to
far.
The problem is that functions are mutable, which we are stuck with for
backward compatibility. But there is no such backward compatibility
constraint on lambdas, which can and should be immutable. So, given
Allen Wirfs-Brock's syntax for lambda, we can do something like:
var self = {
method toString: {|| '' + self.getX() + ',' + self.getY() + ''},
method getX: {|| x},
method getY: {|| y},
field pubInstVar: 4,
const pubInstConst: -4,
};
return self;
where the extensions to the object literal syntax used here are:
- a 'field' modifier to declare a property non-[[Configurable]],
- a 'const' modifier to declare a property non-[[Configurable]]
and non-[[Writable]],
- a 'method' modifier to declare a property non-[[Configurable]],
non-[[Writable]] and non-[[Enumerable]].
Note that modifiers on object literal properties do not need to be
reserved keywords ('get' and 'set' are already in this category).
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Allen's lambda syntax proposal
Just to clarify some speculation, the syntax I proposed ({||}) was solely
inspired by Smalltalk and tempered by the parsing realities of a C-like syntax.
Any similarities to Ruby constructs are probably examples of parallel
evolution under similar environmental pressures. I suspect that designers of
other languages with C-like syntax (C# comes to mind with its () = expr
lambda syntax) did not have the experience or goal of using closures to
create control abstractions (which often requires passing multi-statement
closures) and so arrived at a more function-like concise closure syntax.
(more below)
-Original Message-
From: [EMAIL PROTECTED] [mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Peter Michaux
Sent: Monday, December 01, 2008 10:17 AM
To: P T Withington
...
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I would rather have a more literate syntax, lest we degenerate to
where
practically any comic book blasphemy is a valid program.
I agree with this sentiment. The phrase ASCII vomit comes to mind
and becomes a worry.
The use of {} as grouping syntax is inherent in the early (and irrevocable)
decision for JavaScript to use a C-like syntax rather than an Algol/Pascal or
Lisp like syntax. We already overload {} to bracket both statement blocks and
object constructors so it doesn't seem too burdensome to have another
syntactically distinct form that from some perspectives is the semantic union
of the other two forms.
JavaScript already has a concise ASCII vomit syntax for constructing arrays
and objects. Given the direction the language seems to be heading, having a
similar concise syntax for constructing closures seems quite appropriate.
Allen
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 12:19 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
JavaScript already has a concise ASCII vomit syntax for constructing arrays
and objects.
I didn't mean to imply that JavaScript currently deserves the ASCII
vomit label. I also didn't mean to imply the {||} was so bad as to
deserve name calling. It is more the potential for the cumulative
effect to cause trouble.
Given the direction the language seems to be heading,
Can you expand on what you mean by that please?
having a similar concise syntax for constructing closures
seems quite appropriate.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote:
At the TC39 meeting two weeks ago in Kona, we had a brief
bikeshedding discussion about lambda syntax and why it matters.
Observation: blocks in Smalltalk being lightweight means users don't
mind writing them for control abstractions, compared to JS functions
in ES3. In Smalltalk, ignoring JS, it's hard to beat [ and ] as
overhead, although one must count the message selector and its
punctuation too.
Allen Wirfs-Brock put his proposal, which will not shock you who
know Smalltalk or Allen, on the whiteboard:
// Instead of lambda (a, b, c) { ... }, why not:
{ |a, b, c| ... } ?
I like the brevity, but having the formals inside the block and in ||
delimiters seems like it will look weird in an ECMAScript program. For
function declarations the parameters go in parentheses, and for calls
(presumably also for lambda calls), the arguments go in parens. If
brevity is important, why not lift the lambda syntax from modern pure
functional languages:
\(a, b, c) { ... }
That's backslash as a lambda operator. This has one more character
than your version, but will make formals and parameters look the same
for functions, lambdas, and calls, and will avoid putting the formals
inside the body which I think is confusing and visually hard to scan.
Regards,
Maciej
___
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: 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: Trac issue reports
You two have trac accounts at http://bugs.ecmascript.org/ -- and it turns out a bunch of others (yrchen, wycats, voracity, et al.) were added over the last 13+ months. Anyone who wants to file a ticket on an ES3.1 spec bug (after searching for dups, of course ;-), please mail me. /be On Nov 27, 2008, at 5:54 PM, David-Sarah Hopwood wrote: Brendan Eich wrote: On Nov 16, 2008, at 8:48 PM, David-Sarah Hopwood wrote: Allen Wirfs-Brock wrote: I intend to propose at the Kona meeting that we have reached a point where we need to move to a strict ticket driven process for the ES3.1 endgame. Hopefully, we can just adopt and start using the ES4 Trac server Just as non-TC39-members can't currently edit the wiki, they can't submit Trac issues, either. That was not true for the longest time. Then we got spammed. We've added access to those who request it and have good rep. We're not throwing things open to the world. I still haven't heard back from you whether you want access, BTW. In case you didn't see my private email, I do. But I also think that everyone who reports a bug on the mailing lists should be given access (on the principle that anyone who submits one bug report that way is quite likely to submit more, and unlikely to be a spammer). Currently, a lot of bugs are being reported on the lists, and there is a risk of them getting lost if they can't be promptly submitted as Trac issues. -- David-Sarah Hopwood ___ 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: Trac issue reports
On Mon, Dec 1, 2008 at 2:18 PM, Brendan Eich [EMAIL PROTECTED] wrote: You two have trac accounts at http://bugs.ecmascript.org/ - Thanks. Hopefully non-committee members can be of some assistance. Peter ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RE: Allen's lambda syntax proposal
Allen Wirfs-Brock wrote:
{|a,b,c| ...} or
\(a,b,c) {...} or
{\(a,b,c) ...}
The use of \ slightly bothers me because it is takes a character
that now is exclusively used in the lexical (token) grammar
( Unicode escapes, string escapes, line continuations)
and gives it syntactic significance. This is probably not a
fatal flaw but it would mean that the lexical uses of \ become less
visually distinctive.
The language overuses / recklessly, and still it didn't die.
I suppose it could survive the overuse of \ as well.
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.
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
@ is unused
@(a, b, c){}
Douglas Crockford wrote:
Allen Wirfs-Brock wrote:
{|a,b,c| ...} or
\(a,b,c) {...} or
{\(a,b,c) ...}
The use of \ slightly bothers me because it is takes a character
that now is exclusively used in the lexical (token) grammar
( Unicode escapes, string escapes, line continuations)
and gives it syntactic significance. This is probably not a
fatal flaw but it would mean that the lexical uses of \ become less
visually distinctive.
The language overuses / recklessly, and still it didn't die.
I suppose it could survive the overuse of \ as well.
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.
___
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: 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
oh, right, forgot e4x.
ok, one objection to \(){} is that it looks
too much like a function.
in particular, it feels like I should write
var a = \(x){ return x; };
but that isn't right, {||} is sufficiently
different that it feels like I should write
var a = {|x| x};
Brendan Eich wrote:
On Dec 1, 2008, at 3:47 PM, Felix wrote:
@ is unused
@(a, b, c){}
@ is already used by ECMA-357 (E4X). Also some tradition of denoting
dereference (Cyclone, managed C++ IIRC).
Hard to beat \ if we want the parenthesized formal parameter list in front.
/be
Douglas Crockford wrote:
Allen Wirfs-Brock wrote:
{|a,b,c| ...} or
\(a,b,c) {...} or
{\(a,b,c) ...}
The use of \ slightly bothers me because it is takes a character
that now is exclusively used in the lexical (token) grammar
( Unicode escapes, string escapes, line continuations)
and gives it syntactic significance. This is probably not a
fatal flaw but it would mean that the lexical uses of \ become less
visually distinctive.
The language overuses / recklessly, and still it didn't die.
I suppose it could survive the overuse of \ as well.
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.
___
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: RE: Allen's lambda syntax proposal
-Original Message-
From: [EMAIL PROTECTED] [mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Douglas Crockford
...
because you can think of the \ as being an abbreviation of function.
\ name(a,b,c) {}
Just don't start your function name with u.
Exactly, that's why I didn't mention this possibility. I don't think it would
be acceptable to have that \u ambiguity.
Smalltalk does not have a way (other than variable assignment) to name closures
for recursive reference and it rarely has proven to be a problem. If you
really want to pass a recursive lambda to a function g you could define it
using a const:
const fact = {|n| (n=1) ? 1 : fact(n-1)* n};
g(fact)
or more perversely:
g({||const fact = {|n| (n=1) ? 1 : fact(n-1)* n}; fact}() );
(the second statement of the outer lambda wouldn't be needed if const evaluates
to the value of its initialization expression)
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Dec 1, 2008, at 2:32 PM, Allen Wirfs-Brock wrote:
{|a,b,c| ...} or
\(a,b,c) {...} or
{\(a,b,c) ...}
I could be happy with any of them and can find pros and cons with
each. I think the high order bit should be that a concise closure
syntax is possible and desirable. If we agree on that then we just
need to pick one.
The use of \ slightly bothers me because it is takes a character
that now is exclusively used in the lexical (token) grammar
( Unicode escapes, string escapes, line continuations) and gives it
syntactic significance. This is probably not a fatal flaw but it
would mean that the lexical uses of \ become less visually
distinctive.
Whether someone prefers the parameters inside or outside the braces
may be another symptom of whether they are focusing on control
abstraction or functional abstraction. With control abstraction you
use closures as blocks of code that form pieces of the abstraction
so it may seems natural from that perspective for the braces to
surround the entire block. This is closer to the syntactic feel of
the built-in control statements. If you are building functional
abstractions then you are probably thinking about the closures as
functions so placing the formals before the body seems natural.
Can you give an example? Since ECMAScript's built-in control
structures already have special syntax, it's hard to make anything
look *exactly* like them.
Here's my best shot at an example. Let's pretend you have a
withOpenFile function that opens a file, does some work using the
resulting file handle (assuming there were such things in some host
extension), and guarantees the file handle will be closed whether on
normal exit or exception, but passing exceptions through. How would a
site of use look?
withOpenFile(fileName, { |handle|
doSomething(handle);
doSomethingElse(handle);
});
withOpenFile(fileName, \(handle) {
doSomething(handle);
doSomethingElse(handle);
});
Both look a little odd but I'd say the latter resembles built-in
constructs like for..in a tiny bit more.
It's fairly common with control abstractions to use 0 argument
closures so the readability of {||...}, \(){...}, and {\()...} are
probably also worth considering. Ideally a 0 argument closure would
be written as {...} but resolution of the syntactic ambiguities
between object literal and such closures (particularly in the
presence of statement labels) seems too difficult to contend with.
Perhaps with the backslash idea, a 0-argument lambda could have a
short form of just \ {...}. I'm trying to think of a useful control
construct that takes thunks. Maybe implementing memoized lazy lists, a
la scheme, so you can do stuff like:
lazyPair(val1, \ { computeRestOfList(); } );
var fibonacciNumbers = \ {
let fib = \(a, b) { lazyPair(b, \ { fib(b, a + b) }) };
lazyPair(0, fib(0, 1));
}();
(I'm skipping the definition of lazyPair and the lazyCar / lazyCdr
you'd need to walk the stream).
Seems adequately readable.
For comparison:
lazyPair(val1, { || computeRestOfList(); } );
var fibonacciNumbers = { ||
let fib = { |a, b| lazyPair(b, { || fib(b, a + b) }) };
lazyPair(0, fib(0, 1));
}();
Maybe it's just lack of familiarity but the second version seems less
readable and natural to me.
My focus on supporting control abstraction may be mute. While
Smalltalk and Ruby show that power of such abstraction mechanisms it
takes more than just a concise block-like closure notation to
achieve it. The complexity of the BGGA Java closure proposal (and
the associated controversy) shows how hard it can be to fully
support control abstraction using C syntax (and, of course, Java
semantics).
I think it's possible to build useful control abstractions with a
concise block-like syntax. But an important factor here is making
these look natural in the context of the language as well as concise.
Ruby and Smalltalk have overall designs that make them friendly to a
smalltalkish block syntax, so your custom control constructs look just
like the built-in ones (or conversely you could claim none are built
in). In ECMAScript you can't have them look exactly the same, but I
think the Haskellish backslash style fits in a little better.
Regards,
Maciej
Allen
-Original Message-
From: [EMAIL PROTECTED] [mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak
Sent: Monday, December 01, 2008 12:59 PM
To: Brendan Eich
Cc: es-discuss@mozilla.org
Subject: Re: Allen's lambda syntax proposal
On Nov 29, 2008, at 10:30 PM, Brendan Eich wrote:
At the TC39 meeting two weeks ago in Kona, we had a brief
bikeshedding discussion about lambda syntax and why it matters.
Observation: blocks in Smalltalk being lightweight means users don't
mind writing them for control abstractions, compared to JS functions
in ES3. In Smalltalk, ignoring JS, it's hard to beat [ and ] as
overhead, although one
Re: Allen's lambda syntax proposal
On Dec 1, 2008, at 5:37 PM, Allen Wirfs-Brock wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Douglas Crockford
...
because you can think of the \ as being an abbreviation of function.
\ name(a,b,c) {}
Just don't start your function name with u.
Exactly, that's why I didn't mention this possibility. I don't
think it would be acceptable to have that \u ambiguity.
I think requiring a space after the \ if a name is provided would
remove the potential ambiguity.
Smalltalk does not have a way (other than variable assignment) to
name closures for recursive reference and it rarely has proven to be
a problem. If you really want to pass a recursive lambda to a
function g you could define it using a const:
const fact = {|n| (n=1) ? 1 : fact(n-1)* n};
g(fact)
or more perversely:
g({||const fact = {|n| (n=1) ? 1 : fact(n-1)* n}; fact}() );
(the second statement of the outer lambda wouldn't be needed if
const evaluates to the value of its initialization expression)
g(\ fact(n) { (n=1) ? 1 : fact(n-1) * n });
That seems sweeter.
- Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: RE: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 5:37 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:es-discuss-
[EMAIL PROTECTED] On Behalf Of Douglas Crockford
...
because you can think of the \ as being an abbreviation of function.
\ name(a,b,c) {}
Just don't start your function name with u.
Exactly, that's why I didn't mention this possibility. I don't think it
would be acceptable to have that \u ambiguity.
I agree that the ambiguity is not acceptable. It is too confusing.
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
Breton Slivka wrote:
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.
Too ambiguous, even with the space.
well if we're thinking about lambdas as blocks++, then why not
name: {|a,b,c| }
Since we already have labeled blocks.
Because '{|a,b,c| }' is an expression, and labelling an
ExpressionStatement already has a different meaning.
--
David-Sarah Hopwood
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Allen's lambda syntax proposal
Below
-Original Message-
From: Maciej Stachowiak [mailto:[EMAIL PROTECTED]
Can you give an example? Since ECMAScript's built-in control
structures already have special syntax, it's hard to make anything
look *exactly* like them.
Here's my best shot at an example. Let's pretend you have a
withOpenFile function that opens a file, does some work using the
resulting file handle (assuming there were such things in some host
extension), and guarantees the file handle will be closed whether on
normal exit or exception, but passing exceptions through. How would a
site of use look?
withOpenFile(fileName, { |handle|
doSomething(handle);
doSomethingElse(handle);
});
withOpenFile(fileName, \(handle) {
doSomething(handle);
doSomethingElse(handle);
});
Both look a little odd but I'd say the latter resembles built-in
constructs like for..in a tiny bit more.
Just so everybody knows where I'm coming from with this, in Smalltalk this
might look something like:
FileHandle forName: filename do: [:handle|
self dosomething: handle.
Self doSomethingElse: handle]
Which is syntactically very similar to the built-in control constructs such
as:
1 to: max do: [:n| self doSomething: n].
The BGGA Java closure proposal attempts to support control abstractions that
look like built in control constructs by allowing trailing literal closure
arguments to appear after the parenthesized argument list (shades of Ruby). If
we did something similar in JavaScript you might then code your example as:
withOpenFile(fileName) { |handle|
doSomething(handle);
doSomethingElse(handle);
};
which (to me) feels a little more like a built-in control structure than
withOpenFile(fileName) \{handle) {
doSomething(handle);
doSomethingElse(handle);
};
However, neither one is perfect. The Java closure proposal has some additional
syntactic embellishments that attempt to make it even a bit closer but in my
opinion they may have exceeded to point of diminishing returns.
...
I think it's possible to build useful control abstractions with a
concise block-like syntax. But an important factor here is making
these look natural in the context of the language as well as concise.
Ruby and Smalltalk have overall designs that make them friendly to a
smalltalkish block syntax, so your custom control constructs look just
like the built-in ones (or conversely you could claim none are built
in). In ECMAScript you can't have them look exactly the same, but I
think the Haskellish backslash style fits in a little better.
I largely agree with this view. Preserving the existing feel of a language is
very important and it is hard to retrofit control abstraction facilities into a
language that didn't have them in its initial design. Neither the backslash or
vertical bar syntax is a perfect fit with the existing language and I could
live with either although I personally like the vertical bar's homage to
Smalltalk.
Allen
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Allen's lambda syntax proposal
On Mon, Dec 1, 2008 at 9:33 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
The BGGA Java closure proposal attempts to support control abstractions that
look like built in control constructs by allowing trailing literal closure
arguments to appear after the parenthesized argument list (shades of Ruby).
If we did something similar in JavaScript you might then code your example as:
withOpenFile(fileName) { |handle|
doSomething(handle);
doSomethingElse(handle);
};
I find the idea that a lambda comes after the argument list, but that
it is somehow still an argument, an inconsistent and bad idea. I've
used it in Ruby and don't like it there. In Ruby, I believe these
trailing {||} blocks are the only place where the {||} syntax will
create a lambda and so there is appeal to those who like the extremely
compact notation. They cannot get that compact notation elsewhere. In
ES we won't have that restriction.
One problem is if the argument list needs to take two lambdas, then
where would the second lambda go? One inside the arguments list and
one after? Why is one lambda more important or deserving of a special
place compared with the other lambda?
Some API designers won't like the trailing lambda syntax and some
will. Then we end up with inconsistent APIs. If all arguments go in
the argument list then this problem will not arise.
The following is better
withOpenFile(fileName, {|handle|
doSomething(handle);
doSomethingElse(handle);
});
and the following is better still
withOpenFile(fileName, lambda(handle) {
doSomething(handle);
doSomethingElse(handle);
});
Peter
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
