Blocks: minimal or multiple kinds?
Hello,
what is the policy and projected outcome (in spec, grammer-definition-wise
as well as described-abstraction-wise) of the diiferent kinds of {...}
blocks?
There is plain code block, an object-literal, module block, class block,
lambda-block. Maybe I missed some use case.
My question is whether will all of these blocks presented as a separate
concept, each with its own rules; or whether there is more a wish of minimal
system of {...} blocks where number of different kinds/abstractions is kept
to a minimum a each of aforementioned use is presented as only a use case of
a more general concept.
I feel having many kinds of blocks, each having their own rules makes the
language complicated and that having only a few kinds of blocks is enough.
For example, this shows two clearly distinguished abstractions/syntaxes of
{...} can be enough for the whole language:
All of:
- code block
- module block*
- lambda block**
could be use cases of one type of block - the code (imperative) block. An
imperative block should have its own structure and rules (statements,
var/function declarations. automatic semicolon insertion, sub-code-blocks,
...) and above mentioned items would only be special cases of it (see
footnotes). But all of them would share everything that is common for
imperative block - by design. So it can be defined once and used for every
case, without change.
All of:
- object literal
- class block***
could be use cases of one type of block - the data (descriptive) block. A
descriptive block should have its own structure and rules (properties,
const/non-enum/... modifiers, method definition syntax, ...) and and above
mentioned items would only be special cases of it (see footnotes). But all
of them would share everything that is common for declarative block - by
design. So it can be defined once and used for every case, without change.
I think this would bring less confusion of what kind of construct is
supported where and the borderline will be drawn very clearly (possible for
future {...} constructs, as well).
Herby
* can contain export keyword; appears in context of module keyword
** has |args| at the beginning; appears in expression context
*** can contain static keyword; appears in context of class keyword
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
I think introducing new language constructs for modules is good, because they are so fundamental. For incrementally migrating old code bases, it would make a lot of sense to allow ES.next modules to import AMDs and vice versa. Furthermore, npm’s ability to install modules locally and to let local modules shadow global ones is a very smart way out of version hell. It would be nice to have something similar for ES.next modules, but it’ll be harder to do for browsers (as opposed to for Node.js and local file access). On Jan 12, 2012, at 7:40 , James Burke wrote: I did a blog post on AMD that also talks about harmony modules. In the ECMAScript section I talk about some of the questions I have about with harmony modules: http://tagneto.blogspot.com/2012/01/simplicity-and-javascript-modules.html It is a fairly long post, not all of it applies to ECMAScript, but some of it ties into my comments on ECMAScript, so I think it is best to leave it in the blog post vs. reproducing here. Also, I do not expect answers to my questions right away, just throwing out things that would be nice to have answered as part of the final design. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
On Thu, Jan 12, 2012 at 1:40 AM, James Burke jrbu...@gmail.com wrote: I did a blog post on AMD that also talks about harmony modules. In the ECMAScript section I talk about some of the questions I have about with harmony modules: http://tagneto.blogspot.com/2012/01/simplicity-and-javascript-modules.html Thanks for writing this -- we appreciate the feedback. [As an aside, Dave and I still plan to address your point that module instance objects need to be usable as functions.] As to your current post, I think the fundamental disagreement is all encapsulated here: ES harmony may be able to do something a bit different, but the basic mechanisms will be the same: get a handle on a piece of code via a string ID and export a value. First, there are two things you might mean by piece of code. One is the source code for a library/script, which is necessarily identified by a URL on the Web (perhaps by a filename in other contexts, like Node). That stays as a string in every design. The other is a library that I know I have available, and that we're not using strings for. Instead, you refer to modules by name, just like variables are referred to by name in JS. Second, we don't want to just stop with export a value. By allowing the module system to know something ahead of time about what names a module exports, and therefore what names another module imports, we enable everything from errors when a variable is mistyped to cross-module inlining by the VM. Static information about modules is also crucial to other, long-term, desires that at least some of us have, like macros. Third, the basic mechanisms available for existing JS module systems require the use of callbacks and the event loop for loading external modules. By building the system into the language, we can not only make life easier for programmers, we statically expose the dependencies to the browser, enabling prefetching -- here, the basic mechanisms don't have to be the same. -- sam th sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Anonymous methods
cc es-discuss On Thu, Jan 12, 2012 at 7:58 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Forgot to add es-discuss to cc (original reply is below; the letter was sent yesterday and was the first reply); there I also proposed active blocks as callable blocks But in fact, if to recall the topic Everything is expression (which unfortunately became silent), it was already proposed including blocks to return values. Moreover, that's said since even in ES3 blocks (and in fact any statement) has completion result, it's easy to implement. Dmitry. On Wed, Jan 11, 2012 at 10:26 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: On Wed, Jan 11, 2012 at 10:10 PM, John J Barton johnjbar...@johnjbarton.com wrote: The blog post http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ makes the case for blocks that act like functions when passed as arguments but have loop-up rules more like nested blocks. Of course these are called 'block lambdas', and I suggest that this is a problem. Given that very few programmers understand lambda calculus (and this will not change), the word 'lambda' is equivalent to too difficult to understand. When I looked up lambda on http://en.wikipedia.org/wiki/Lambda I read In mathematical logichttp://en.wikipedia.org/wiki/Mathematical_logic and computer science http://en.wikipedia.org/wiki/Computer_science, lambda is used to introduce an anonymous functionhttp://en.wikipedia.org/wiki/Anonymous_function expressed with the concepts of lambda calculushttp://en.wikipedia.org/wiki/Lambda_calculus . and then Oh that is what they meant with all that 'block-lambda' stuff. If the discussion here were on a new ES feature anonymous methods, Yep, though the main difference b/w active blocks (is this naming is better than block lambdas?) is that by TCP, the block exits parent's context, whereas anonymous methods return the the caller. So, there should semantic difference in discussions and explanations. Active blocks is a good alternative to eliminate lambda. However, of course, more-less advanced programmer which want to know (and should know) computer science concepts will go later deeper and will tackle with lambdas again. And then she will say: Oh, that is what they mean by action blocks / anonymous methods. P.S.: small nit-pick,. from lambda calculus, the lambda is not necessary anonymous. The lambda is just an _abstraction_ -- the basic encapsulation block. Yes, it's a _function_ is the simplest view. Dmitry. then I guess many more developers would be interested. If this feature had the properties outlined in the blog post, then I think many developers would understand the value of this potential feature. As it is I guess they stop reading as soon as they see the word 'lambda'. jjb ___ 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
Octal literals have their uses (you Unix haters skip this one)
See https://github.com/jashkenas/coffee-script/pull/2021 -- strict mode support in CoffeeScript exposes a valid use-case, Unix-flavor file permissions (mode bits we used to say). Node.js APIs really want users to call with literals such as 0644. Strict mode says no way. For now CoffeeScript probably will support 0o644 and translate to hex or decimal literals to dodge the strict error. But ES5 still has octal in Annex B, and AFAIK octal support is still required for web compatibility. Strict mode is not being adopted widely enough, certainly not in node.js code, to kill octal literals. Killing octal literals is user-hostile when it comes to Unix permissions. So I think we should stop tilting at a friendly windmill, and either support octal literals (but not noctal -- no 08 or 09), or support 0o377 etc. as CoffeeScript looks like it will do. Some may object to lowercase o as prefix. It's clear enough in all fonts, but if we allow uppercase O too, then some might fear user confusion with 0 used instead of O. But if we support 0o377 and 0O377, we can continue to reject (in strict mode and therefore in Harmony) 00377. Anyway, there's no homograph phishing attack threat as with URLs. If the CoffeeScript experiment with 0o prefixes for octal works out, I think we should adopt that prefix. But at this point I wouldn't be surprised to see retention of 0377 support be demanded by CoffeeScript/Node.js users, and they have a point. CoffeeScript can certainly compile this to a strict hex or decimal literal to dodge the error, but then JS/Node.js is at a loss, and for no good reason. In this case I will argue for supporting octal literals in strict mode. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
parseInt(377, 8)? Assuming that performance isn’t an issue. On Jan 12, 2012, at 19:01 , Brendan Eich wrote: See https://github.com/jashkenas/coffee-script/pull/2021 -- strict mode support in CoffeeScript exposes a valid use-case, Unix-flavor file permissions (mode bits we used to say). Node.js APIs really want users to call with literals such as 0644. Strict mode says no way. For now CoffeeScript probably will support 0o644 and translate to hex or decimal literals to dodge the strict error. But ES5 still has octal in Annex B, and AFAIK octal support is still required for web compatibility. Strict mode is not being adopted widely enough, certainly not in node.js code, to kill octal literals. Killing octal literals is user-hostile when it comes to Unix permissions. So I think we should stop tilting at a friendly windmill, and either support octal literals (but not noctal -- no 08 or 09), or support 0o377 etc. as CoffeeScript looks like it will do. Some may object to lowercase o as prefix. It's clear enough in all fonts, but if we allow uppercase O too, then some might fear user confusion with 0 used instead of O. But if we support 0o377 and 0O377, we can continue to reject (in strict mode and therefore in Harmony) 00377. Anyway, there's no homograph phishing attack threat as with URLs. If the CoffeeScript experiment with 0o prefixes for octal works out, I think we should adopt that prefix. But at this point I wouldn't be surprised to see retention of 0377 support be demanded by CoffeeScript/Node.js users, and they have a point. CoffeeScript can certainly compile this to a strict hex or decimal literal to dodge the error, but then JS/Node.js is at a loss, and for no good reason. In this case I will argue for supporting octal literals in strict mode. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Anonymous methods
I named block-lambdas and wrote the proposal that Yehuda's blog is about, and I'm with Nathan and David here. If we approve block-lambdas then in clear contexts, most users will probably just say "block" and not "lambda". But lambda is pretty well-known and I do not agree that John's dichotomy between language design interest groups (design in abstract vs. in practice by millions of developers) is a hard-edged and overriding split. Block-lambdas will be learnt by people moving between the two groups (if such groups really exist as segregations of people, instead of modes or "hats" many people can wear interchangeably or even at the same time). Callable block is awkward (the ll-ble combination in the first word), and likely to be shortened to "block" in context anyway. Block statements are second class anyway, so not often mentioned by name (and then sometimes called compound statements or block statements in full). I chose block-lambda to have a clear and pithy handle that would not be confused with either block statements or other lambda sketches or proposals, and I suggest we stick with it for now. /be Nathan Stott January 11, 2012 3:19 PM Are we in 2012 seriously saying the word "lambda" is scary to developers? This sounds ridiculous. The word lambda is widely used by programmers in a variety of communities. ___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss David Bruant January 11, 2012 3:14 PM Le 11/01/2012 22:42, John J Barton a crit: On Wed, Jan 11, 2012 at 1:04 PM, David Bruant bruan...@gmail.com wrote: From your e-mail, it seems granted that "more developers interested" is a good thing. I can't really say whether I agree or not. So I guess I should ask the question: is more developers interested a good thing? If your interest in language design ends with design, then No, it does not matter how many developers are interested. If your interest in language design extends to seeing that design in practice by millions of developers, then Yes it does matter how many developers are interested. I think I disagree with the approach with which you're taking this issue. From your response I understand that _javascript_ language maintainer are responsible for bringing more developers to the discussion. To some extent, I agree and they actually do too apparently. There is an open mailing-list, a wiki. Some of the TC39 folks go at conferences, present what ES.next will be, present open questions, and do QA. So far, I have probably seen 10 40-60 minutes-long videos of this kind over the last 3 years. But this is not enough? Features would also need to have cute names to not scare developers? I'm sorry, but I think it's asking too much. I think there is also an effort on the developers side to show interest in the evolution of the language, understand its history, its flaws, etc. ... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
Sorry, are you seriously
proposing that Node.js users when they specify file permissions should
manually write that out? Come on! Sorry, that's just way too verbose and
ugly.
And performance can be an issue, but the readability and writability
problems are enough.
/be
Axel Rauschmayer
January 12, 2012
10:10 AM
parseInt("377", 8)?
Assuming that performance isn’t an issue.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Blocks: minimal or multiple kinds?
I think you are missing something important:
...; { S(); T(); }; ...
shows a block. It is eagerly evaluated in succession after the elided
code to the left.
...; {|| S(); T(); }; ...
is a block-lambda, which in this example is useless -- but crucially, it
is not invoked without suffixing (), as with any callable object.
Now, to make the examples more useful, suppose we could support blocks
as expressions without making an ambiguous or overcomplicated grammar:
...; b = { S(); T(); }; ...
given a declared b would mean what? It should not create a callable
object that must be invoked to evaluate S(); T(), because that breaks
symmetry with existing block-statement meaning, e.g.
if (C) { S(); T(); }
There's no () to invoke the consequent block -- if C evaluates to true
then control flows to the then clause which eagerly evaluates the block
statement.
There are other problems with unifying block and object literal syntax
(never mind semantics), but this one is enough to kill the idea. Blocks
as braced statement lists are not a single thing in JS, even in ES1:
function bodies are not block statements (consider var hoisting).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
Would it be hard to bring in Smalltalkish 8r377? Another (and similar to 0) special char for specific radix - well, wouldn’t it be better to include a letter for all radixes (CoffeeScript can maybe take it on, too). Herby -Pôvodná správa- From: Brendan Eich Sent: Thursday, January 12, 2012 7:21 PM To: Axel Rauschmayer Cc: es-discuss Subject: Re: Octal literals have their uses (you Unix haters skip this one) Sorry, are you seriously proposing that Node.js users when they specify file permissions should manually write that out? Come on! Sorry, that's just way too verbose and ugly. And performance can be an issue, but the readability and writability problems are enough. /be Axel Rauschmayer January 12, 2012 10:10 AM parseInt(377, 8)? Assuming that performance isn’t an issue. ___ 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: Octal literals have their uses (you Unix haters skip this one)
Maybe -- the precedent
from Python and Ruby for 0o377 is strong than Smalltalk precedent at
this point.
What's more, you seem to want a generalization to any radix, as if all
radixes are useful or even used. JS already has 0x for hex, which is
much more useful than octal. After octal would come binary, and
CoffeeScript, Python and Ruby precedents want 0b111. After that, there
really aren't any commonly-used (or all that useful, apart from
obfuscation exercises) radixes.
So we have a 0x precedent in JS, from C (by way of Java). We have
nearby/upstream scripting language precedents with Python, Ruby, and
CoffeeScript, for 0o and 0b. We have zero practical use-cases for
arbitrary radixes. Furthermore we won't see people migrate from 0x to
16r, ever.
So all of this says to me we should avoid generalizing for its own sake,
and follow nearby precedents first.
/be
Herby Vojčík
January 12, 2012
10:48 AM
Would it be hard to bring in
Smalltalkish 8r377? Another (and similar to 0)
special char for specific radix - well, wouldn’t it be better to
include a
letter for all radixes (CoffeeScript can maybe take it on, too).
Herby
-Pôvodná správa-
From: Brendan Eich
Sent: Thursday, January 12, 2012 7:21 PM
To: Axel Rauschmayer
Cc: es-discuss
Subject: Re: Octal literals have their uses (you Unix haters skip
this one)
Sorry, are you seriously proposing that Node.js users when they
specify file
permissions should manually write that out? Come on! Sorry, that's
just way
too verbose and ugly.
And performance can be an issue, but the readability and writability
problems are enough.
/be
Axel Rauschmayer
January 12, 2012 10:10 AM
parseInt("377", 8)? Assuming that performance isn’t an issue.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich
January 12, 2012
10:21 AM
Sorry, are you seriously
proposing that Node.js users when they specify file permissions should
manually write that out? Come on! Sorry, that's just way too verbose and
ugly.
And performance can be an issue, but the readability and writability
problems are enough.
/be
___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
Axel Rauschmayer
January 12, 2012
10:10 AM
parseInt("377", 8)?
Assuming that performance isn’t an issue.
Brendan Eich
January 12, 2012
10:01 AM
See
https://github.com/jashkenas/coffee-script/pull/2021 -- strict mode
support in CoffeeScript exposes a valid use-case, Unix-flavor file
permissions (mode bits we used to say). Node.js APIs really want users
to call with literals such as 0644. Strict mode says no way.
For now CoffeeScript probably will support 0o644 and translate to
hex or
decimal literals to dodge the strict error. But ES5 still has octal in
Annex B, and AFAIK octal support is still required for web
compatibility.
Strict mode is not being adopted widely enough, certainly not in
node.js
code, to kill octal literals. Killing octal literals is user-hostile
when it comes to Unix permissions. So I think we should stop tilting at
a friendly windmill, and either support octal literals (but not noctal
-- no 08 or 09), or support 0o377 etc. as CoffeeScript looks like it
will do.
Some may object to lowercase o as prefix. It's clear enough in all
fonts, but if we allow uppercase O too, then some might fear user
confusion with 0 used instead of O. But if we support 0o377 and 0O377,
we can continue to reject (in strict mode and therefore in Harmony)
00377. Anyway, there's no homograph phishing attack threat as with URLs.
If the CoffeeScript experiment with 0o prefixes for octal works out,
I
think we should adopt that prefix. But at this point I wouldn't be
surprised to see retention of 0377 support be demanded by
CoffeeScript/Node.js users, and they have a point.
CoffeeScript can certainly compile this to a strict hex or decimal
literal to dodge the error, but then JS/Node.js is at a loss, and for no
good reason. In this case I will argue for supporting octal literals in
strict mode.
/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: Octal literals have their uses (you Unix haters skip this one)
/cc es-discuss (sorry Brendan -- you always seem to be the target of my reply-all fails) On Thu, Jan 12, 2012 at 2:01 PM, Dean Landolt d...@deanlandolt.com wrote: On Thu, Jan 12, 2012 at 1:21 PM, Brendan Eich bren...@mozilla.com wrote: Sorry, are you seriously proposing that Node.js users when they specify file permissions should manually write that out? Come on! Sorry, that's just way too verbose and ugly. They don't have to, an octal string mode works just fine: fs.chmod(path, 0777) Octals can be little hazardous, and not just to noobs, but the hazard isn't with literals, it's with parseInt: parseInt(022) // 18 Better than losing octal literals would be to throw out the unary version of parseInt. Guessing the radix is crazy! I'm indifferent to whether octals stay the same or grow a o, but parseInt could really use some love! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
See https://github.com/jashkenas/coffee-script/pull/2021#issuecomment-3468606 -- quoted at bottom. /be *showell https://github.com/showell* /commented https://github.com/jashkenas/coffee-script/pull/2021#issuecomment-3468606 / /3 minutes ago https://github.com/jashkenas/coffee-script/pull/2021#issuecomment-3468606/ Here's the Python PEP on integer literals for Python 3000: http://www.python.org/dev/peps/pep-3127/ The main conclusion was that octal literals must now be specified with a leading 0o or 0O instead of 0. I would hope that CS follows Python's lead on this. The PEP seems well reasoned, and I think basically the same forces are at play in CS as Python. Python supports these radices with literal sugar: 2, 8, 10, and 16. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
[Resending reply with elaboration. /be] Yes, the ability to quote the octal literal with Node's APIs came up on the gist, but it's not enough. Quoting is easy to forget, and making the runtime convert string (literal) to number is inefficient compared to having JS do it at compile-time, and making the runtime (even via a call to parseInt) do it also increases bug habitat ever so slightly. Mainly, users don't have to shun octal in non-strict mode, and they do not in Node code I have seen. They won't be adopting strict mode as far as I can tell. Banning octal is just one more reason for those who *might* adopt strict mode to reject it. Agree on parseInt. Old dog, hard to change (runtime-only errors are migration- and user-hostile). Not sure what to do there. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Blocks: minimal or multiple kinds?
Hi,
I wasn't talking about unifying code and data blocks (here).
I was pointing to the fact that there seem to be lot more (different as to
syntax and as to general abstraction).
I was asking if it would be possible to postulate that there are only two
higher level kinds of blocks:
- imperative ones (list of statements, semicolon delimited and/or
structured)
(this would include code block, function body, module and lambda block)
- declarative ones (list of data productions, colon delimited and/or
structured)
(this would include object literal and class)
This is so the code/data line is sharply drawn (_unlike_ your example, I
proposed the opposite) and all syntactic elements and their general
underlying semantics (possible statements for imperative, member modifiers
for declarative, ...) be defined in one place and consistently used in all
use cases.
In other words b = { S(); T(); }; would be syntax error because { S();
T(); } cannot be parsed in expression context (as it is today), the same for
other examples.
My main point is to not have hybrid curly blocks (like class is today),
but define one for code and one for data, give it rich expressivity (like
allenwb is doing to object literal) and consistently define - this is code,
this is data, this is code, this is data for this or that language
construct.
Herby
P.S.: The other proposal I had does something like unifying them, but in
completely different way, not the one in which your examples are
problematic. None of them is problematic there, but it is on the other
thread, anyway. Here I only wanted to here about either code or data,
nothing in between idea.
-Pôvodná správa-
From: Brendan Eich
Sent: Thursday, January 12, 2012 7:35 PM
To: Herby Vojčík
Cc: es-discuss@mozilla.org
Subject: Re: Blocks: minimal or multiple kinds?
I think you are missing something important:
...; { S(); T(); }; ...
shows a block. It is eagerly evaluated in succession after the elided code
to the left.
...; {|| S(); T(); }; ...
is a block-lambda, which in this example is useless -- but crucially, it is
not invoked without suffixing (), as with any callable object.
Now, to make the examples more useful, suppose we could support blocks as
expressions without making an ambiguous or overcomplicated grammar:
...; b = { S(); T(); }; ...
given a declared b would mean what? It should not create a callable object
that must be invoked to evaluate S(); T(), because that breaks symmetry with
existing block-statement meaning, e.g.
if (C) { S(); T(); }
There's no () to invoke the consequent block -- if C evaluates to true then
control flows to the then clause which eagerly evaluates the block
statement.
There are other problems with unifying block and object literal syntax
(never mind semantics), but this one is enough to kill the idea. Blocks as
braced statement lists are not a single thing in JS, even in ES1: function
bodies are not block statements (consider var hoisting).
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Blocks: minimal or multiple kinds?
I wasn't talking about unifying code and data blocks (here). Ok, I must have misread. I thought you wrote All of: - code block - module block* - lambda block** could be use cases of one type of block. I don't see how that is possible given what I wrote in reply. Both syntax (|| is required for a block-lambda empty parameter list) and semantically (delayed evaluationg until invocation; completion reform also), block-lambdas and blocks are not one type of block. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
I'll chime in with my vote - I would LOVE to be able to use octal literals again in GPSEE for setting file permissions. chmod(filename, parseInt(777, 8)) just looks stupid when chmod(filename, 0777) would work just fine. Wes On 12 January 2012 14:11, Brendan Eich bren...@mozilla.com wrote: [Resending reply with elaboration. /be] Yes, the ability to quote the octal literal with Node's APIs came up on the gist, but it's not enough. Quoting is easy to forget, and making the runtime convert string (literal) to number is inefficient compared to having JS do it at compile-time, and making the runtime (even via a call to parseInt) do it also increases bug habitat ever so slightly. Mainly, users don't have to shun octal in non-strict mode, and they do not in Node code I have seen. They won't be adopting strict mode as far as I can tell. Banning octal is just one more reason for those who *might* adopt strict mode to reject it. Agree on parseInt. Old dog, hard to change (runtime-only errors are migration- and user-hostile). Not sure what to do there. /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- 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: Octal literals have their uses (you Unix haters skip this one)
To me this seems like an exception rather than a common problem. Most APIs / tools don't use octals for this type of thing. Seems unnecessary to add to the language for this one use case. Not a Linux hater by any means, just the parseInt thing doesn't bother me for this one situation. Or am I wrong and there are other common uses for octal literals? On Thu, Jan 12, 2012 at 2:51 PM, Wes Garland w...@page.ca wrote: I'll chime in with my vote - I would LOVE to be able to use octal literals again in GPSEE for setting file permissions. chmod(filename, parseInt(777, 8)) just looks stupid when chmod(filename, 0777) would work just fine. Wes On 12 January 2012 14:11, Brendan Eich bren...@mozilla.com wrote: [Resending reply with elaboration. /be] Yes, the ability to quote the octal literal with Node's APIs came up on the gist, but it's not enough. Quoting is easy to forget, and making the runtime convert string (literal) to number is inefficient compared to having JS do it at compile-time, and making the runtime (even via a call to parseInt) do it also increases bug habitat ever so slightly. Mainly, users don't have to shun octal in non-strict mode, and they do not in Node code I have seen. They won't be adopting strict mode as far as I can tell. Banning octal is just one more reason for those who *might* adopt strict mode to reject it. Agree on parseInt. Old dog, hard to change (runtime-only errors are migration- and user-hostile). Not sure what to do there. /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss -- 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: Blocks: minimal or multiple kinds?
Oh. I feel the barrier of misunderstanding :-(
Give me one more try to get the message through.
(I'd like to have some IM or irc with you, because it would be bad to be
misunderstood again)
I am trying to draw a line not on actual execution semantics (code blocks
and lambda blocks are different in this), but by inherent nature of the
block contents.
The code blocks is sequence of statements, variable declarations, function
declarations, module declarations (maybe something more). Let me call them
imperative elements. If delimited, semicolon is used. The inherent
nature of code block is to represent the linear list of actions (some of
them simple, some of them structured) that specify the control flow of some
code actions. I call this inherent nature imperative.
The lambda block is sequence of imperative elements, too. In fact, except
|args| at the beginning, there is not structural change that makes it
different form code block. Its inherent nature is imperative, too (even if
it is parsed as expression and not run immediately. It is not the matter
here).
A module block is sequence of imperative elements, too. It can contain
export keyword, but otherwise, again, no big difference, structure-wise,
from the code block. And its inherent nature is also imperative. It is
much akin to the body of script in web apps today (though it can be
nested).
So I am saying here - let us define an imperative block structure and
elements (and the structure itself is dictated by its purpose. to represent
list of imperative elements, that is, control-flow). Then let us say the
all above mentioned cases of {...} (include if/then/sub0blocks, function
bodies, and more) are all imperative blocks.
The common structure and elements give common semantics of the block
_contents_, but the blocks themselves are different from use case to use
case. Nevertheless, the elements they are build from would be consistent all
over.
And now, the object literal is sequence of member productions and method
declarations. Let me call then declarative elements. If delimited, colon
is used. The inherent nature of object literal is to represent (unordered)
list of data productions that specify the blueprint of a data structure. I
call this inherent nature declarative.
I claim that class block's inherent nature is also purely declarative. It
declares the structure of the class. In declaring a class, there is nothing
imperative (in constuctor body, yes, but it is a function body, it _is_ of
course, imperative).
I wanted to draw a line, much more abstraction-wise, using the inherent
nature or purpose to define imperative blocks and declarative blocks, and
to postulate that every {...} has only one of such natures. Not mixing them.
The good things it can bring is consistent use of the same metaphor and same
building blocks with same meaning all over (code - list of statements etc.
same in all contexts; data - list of members, having access modifiers,
possibility to declare a method, ... exactly same all over); clarity or
how should I call it - the well-defined intent-separated case of use of
{...} and last but not least, much greater possibility to enhance their
expressive power if there will be less concerns that hybrids will exist.
In no way did I want to propose that { code } be taken as expression. On the
contrary - each use of {...} is well categorized as either code or data, and
its structure is then given by that.
Herby
P.S.: Do not take me by the word - I know the class needs to describe
constructor function's members as well as prototype's member. But it has
static keyword for it. Everything in the class which is not static is the
description of the class' prototype. And if it is declarative, it should be
written as declarative (object-literal way). imnsho. (if class is just a use
case of declarative block group, then it get all the goodies automatically
and they would be guaranteed to work same way as they do for object literal
(I mean access modifiers, method declaration syntax, and there can be more).
No special cases (except static) which is in one place but not in another.
P.P.S.: I am not disclosing that this was created in my mind while I was
working on that other thing (which is in RFC: Empowered data thread) but
a) I see how powerful vistas does this open b) I (by feeling only) think
that overall having such clear imperative / declarative distinction on one
side and consistent use of building elements within each group is a Good
Thing (tm). (as I am writing it, it associated me loose coupling and high
cohesion).
-Pôvodná správa-
From: Brendan Eich
Sent: Thursday, January 12, 2012 8:26 PM
To: Herby Vojčík
Cc: es-discuss@mozilla.org
Subject: Re: Blocks: minimal or multiple kinds?
I wasn't talking about unifying code and data blocks (here).
Ok, I must have misread. I thought you wrote All of: - code block -
module block* - lambda block** could be
Re: Octal literals have their uses (you Unix haters skip this one)
Greg Smith January 12, 2012 12:08 PM To me this seems like an exception rather than a common problem. Most APIs / tools don't use octals for this type of thing. Seems unnecessary to add to the language for this one use case. "Add to the language" is not accurate. Octal is *already* supported by JS engines today, and again, AFAIK, it is required for web compatibility. Banishing octal to the non-normative Annex B, banning it from strict mode -- that does not remove octal from JS in reality. Given this, the shoe is rather on the other foot: strict-mode has one more drawback from the point of view of a non-trivial cohort of users (Node.js hackers who wrangle Unix permissions). Not a Linux hater by any means, just the parseInt thing doesn't bother me for this one situation. That's nice, but Node.js supports JS non-strict and people use it freely, including not quoting octal literals (the API works with string inputs too, so explicit parseInt is not required). The problem for CoffeeScript users can be solved quickly via 0o prefixing. The problem for JS users is also easy: don't use strict mode. Is this really what we want? What good have we done by banning octal in strict mode? Or am I wrong and there are other common uses for octal literals? The only use case I'm citing here is Unix permission modes. That's enough. /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
I'll just add a caveat to brendan's comments below though: JScript doesn't support octal in many (all?) cases, leading to incompatible behaviour when parsing things like 012.I think the problem with octal numbers isn't a philosophical hate of octal, inasmuch as it is a general unhappiness with the existing octal support, namely a simple 0 prefix switching the parse mode. If we had another (unambiguous) prefix that would (I'm sure) be fine.If we were willing to add octal with a clear prefix I would be fine with that, for consistency with hex, I'd lean towards 0o..., but I'm open to any suggestions that people may wish to add. Personally I'd also like a binary form, a la 0b, but I'm unsure how useful regular developers would find that (I don't write "realworld" JS so my needs don't always align with those of regular developers).--OliverOn Jan 12, 2012, at 12:30 PM, Brendan Eich wrote: Greg Smith January 12, 2012 12:08 PM To me this seems like an exception rather than a common problem. Most APIs / tools don't use octals for this type of thing. Seems unnecessary to add to the language for this one use case. "Add to the language" is not accurate. Octal is *already* supported by JS engines today, and again, AFAIK, it is required for web compatibility. Banishing octal to the non-normative Annex B, banning it from strict mode -- that does not remove octal from JS in reality. Given this, the shoe is rather on the other foot: strict-mode has one more drawback from the point of view of a non-trivial cohort of users (Node.js hackers who wrangle Unix permissions). Not a Linux hater by any means, just the parseInt thing doesn't bother me for this one situation. That's nice, but Node.js supports JS non-strict and people use it freely, including not quoting octal literals (the API works with string inputs too, so explicit parseInt is not required). The problem for CoffeeScript users can be solved quickly via 0o prefixing. The problem for JS users is also easy: don't use strict mode. Is this really what we want? What good have we done by banning octal in strict mode? Or am I wrong and there are other common uses for octal literals? The only use case I'm citing here is Unix permission modes. That's enough. /be___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
Can't we just have free competition between 0o644 and 0644? Add the former, and we'll see which wins in real code! If 0o644 wins, and if people like Doug Crockford advocate the drop of 0644, we may then consider including this in a new version of Strict Mode. Furthermore, I'd like to weigh in with Herby Vojčík and ask for 8r644 support. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
No, let's not do everything. That's a bad way to make standards. We should acknowledge that octal is used in JS today and it'll die hard in certain quarters. I don't think this was considered carefully when the decision to ban octal in strict mode was made. If we want to support octal in strict mode, we can certainly ban crazy noctal (08, 09). If we choose to prefix, we should pick one prefix (and it should almost certainly be the same one in Python, Ruby, and CoffeeScript: 0o). Binary is plausible (0b), but after that I see no need for arbitrary-radix literals. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
If we were willing to add octal with a clear prefix I would be fine with that, for consistency with hex, I'd lean towards 0o..., but I'm open to any suggestions that people may wish to add. Personally I'd also like a binary form, a la 0b +1 to both. Then we have three kinds of non-decimal literals, for example: 0b1011, 0o732 and 0x. For long literals, Java has started to make _ as a separator legal, that would be nice to have, too: let aLotOfMoney = 120_327_756_228; -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
Given that octals are likely here to stay, I think they should look as specialized as they are, so a very conspicuous prefix like 0o really makes sense to me. As to which prefix to use, o seems the easiest to remember. On Thu, Jan 12, 2012 at 3:57 PM, Brendan Eich bren...@mozilla.com wrote: No, let's not do everything. That's a bad way to make standards. We should acknowledge that octal is used in JS today and it'll die hard in certain quarters. I don't think this was considered carefully when the decision to ban octal in strict mode was made. If we want to support octal in strict mode, we can certainly ban crazy noctal (08, 09). If we choose to prefix, we should pick one prefix (and it should almost certainly be the same one in Python, Ruby, and CoffeeScript: 0o). Binary is plausible (0b), but after that I see no need for arbitrary-radix literals. /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: Octal literals have their uses (you Unix haters skip this one)
On Thu, Jan 12, 2012 at 9:57 PM, Axel Rauschmayer a...@rauschma.de wrote: If we were willing to add octal with a clear prefix I would be fine with that, for consistency with hex, I'd lean towards 0o..., but I'm open to any suggestions that people may wish to add. Personally I'd also like a binary form, a la 0b +1 to both. Then we have three kinds of non-decimal literals, for example: 0b1011, 0o732 and 0x. For long literals, Java has started to make _ as a separator legal, that would be nice to have, too: let aLotOfMoney = 120_327_756_228; +1 to that, too. It does make things easier to read. Ruby has had that for decades. It is a very specific use-case, but I feel like we shouldn't disregard non-generic use-cases. 0644 (used in node.js in a unix environment) is a non-generic use-case, and as such I feel it shouldn't just die. That is why I would like 0644 and 0o644 to co-exist. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
On Jan 12, 2012, at 1:04 PM, Thaddee Tyl wrote: On Thu, Jan 12, 2012 at 9:57 PM, Axel Rauschmayer a...@rauschma.de wrote: If we were willing to add octal with a clear prefix I would be fine with that, for consistency with hex, I'd lean towards 0o..., but I'm open to any suggestions that people may wish to add. Personally I'd also like a binary form, a la 0b +1 to both. Then we have three kinds of non-decimal literals, for example: 0b1011, 0o732 and 0x. For long literals, Java has started to make _ as a separator legal, that would be nice to have, too: let aLotOfMoney = 120_327_756_228; +1 to that, too. It does make things easier to read. Ruby has had that for decades. It is a very specific use-case, but I feel like we shouldn't disregard non-generic use-cases. 0644 (used in node.js in a unix environment) is a non-generic use-case, and as such I feel it shouldn't just die. That is why I would like 0644 and 0o644 to co-exist. Outside of strict mode 0644, etc will have to continue to exist as I believe both JSC and SpiderMonkey have existing content that depends on that octal notation working. But it would be nice if we could standardise on nicely (unambiguously) prefixed notation that would also work in strict mode. --Oliver ___ 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: Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 4:26 PM, Thaddee Tyl thaddee@gmail.com wrote:
I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.
{ (a, b) a + b }
cannot conflict with any existing program; at least I don't see how it can.
And if people choose to use newlines in their code?
{(a, b)
a + b}
... already has a meaning.
-Jon
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 1:26 PM, Thaddee Tyl wrote:
I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.
{ (a, b) a + b }
cannot conflict with any existing program; at least I don't see how it can.
but it is ambiguous with other currently valid statement blocks such as:
{ (a, b) + b}
or
{ (a,b)
a+b
}
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Octal literals have their uses (you Unix haters skip this one)
Right, as Oliver said, 0644 won't just die in real-world non-strict JS implementations. It's going to stay for web compatibility until someone with enough market share turns it off and survives, and others follow. I don't see anyone rushing to risk market share loss for so little in return. So adding 0o644 support is the way to go. Once again web compatibility and evolutionary dynamics require doing two things, in order to (far off, hard to predict, might never happen) retire the old form. This is not, however "do everything" and so I don't see why we should do 8r644 as well. /be Thaddee Tyl January 12, 2012 1:04 PM +1 to that, too. It does make things easier to read. Ruby has had thatfor decades.It is a very specific use-case, but I feel like we shouldn't disregardnon-generic use-cases. 0644 (used in node.js in a unix environment) isa non-generic use-case, and as such I feel it shouldn't just die. Thatis why I would like 0644 and 0o644 to co-exist.___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss Axel Rauschmayer January 12, 2012 12:57 PM +1 to both. Then we have three kinds of non-decimal literals, for example: 0b1011, 0o732 and 0x.For long literals, Java has started to make "_" as a separator legal, that would be nice to have, too: let aLotOfMoney = 120_327_756_228; -- Dr. Axel Rauschmayera...@rauschma.dehome: rauschma.detwitter: twitter.com/rauschmablog: 2ality.com Oliver Hunt January 12, 2012 12:44 PM I'll just add a caveat to brendan's comments below though: JScript doesn't support octal in many (all?) cases, leading to incompatible behaviour when parsing things like 012.I think the problem with octal numbers isn't a philosophical hate of octal, inasmuch as it is a general unhappiness with the existing octal support, namely a simple 0 prefix switching the parse mode. If we had another (unambiguous) prefix that would (I'm sure) be fine.If we were willing to add octal with a clear prefix I would be fine with that, for consistency with hex, I'd lean towards 0o..., but I'm open to any suggestions that people may wish to add. Personally I'd also like a binary form, a la 0b, but I'm unsure how useful regular developers would find that (I don't write "realworld" JS so my needs don't always align with those of regular developers).--Oliver Brendan Eich January 12, 2012 12:30 PM Greg Smith January 12, 2012 12:08 PM To me this seems like an exception rather than a common problem. Most APIs / tools don't use octals for this type of thing. Seems unnecessary to add to the language for this one use case. "Add to the language" is not accurate. Octal is *already* supported by JS engines today, and again, AFAIK, it is required for web compatibility. Banishing octal to the non-normative Annex B, banning it from strict mode -- that does not remove octal from JS in reality. Given this, the shoe is rather on the other foot: strict-mode has one more drawback from the point of view of a non-trivial cohort of users (Node.js hackers who wrangle Unix permissions). Not a Linux hater by any means, just the parseInt thing doesn't bother me for this one situation. That's nice, but Node.js supports JS non-strict and people use it freely, including not quoting octal literals (the API works with string inputs too, so explicit parseInt is not required). The problem for CoffeeScript users can be solved quickly via 0o prefixing. The problem for JS users is also easy: don't use strict mode. Is this really what we want? What good have we done by banning octal in strict mode? Or am I wrong and there are other common uses for octal literals? The only use case I'm citing here is Unix permission modes. That's enough. /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss Greg Smith January 12, 2012 12:08 PM To me this seems like an exception rather than a common problem. Most APIs / tools don't use octals for this type of thing. Seems unnecessary to add to the language for this one use case.Not a Linux hater by any means, just the parseInt thing doesn't bother me for this one situation. Or am I wrong and there are other common uses for octal literals? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
If not (as it seems to me), it means that a block lambda will not be used as
a statement by itself. If it's the case, it should defined as an Expression
only, where there's no anonymous block to conflict the syntax. That solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic
change for an identical syntax, in regards to strict ES5.
The case where you would like to use a block lambda as a stament can be
resolved by adding parenthesis, like with the current object notation. And
since I still continue to hope we'll ditch the unprefixed anonymous block in
some future revision of ES, that very small edge case could vanish at the
same time.
Does it seems possible/acceptable?
-Message d'origine-
From: Allen Wirfs-Brock
Sent: Thursday, January 12, 2012 10:38 PM
To: Thaddee Tyl
Cc: es-discuss@mozilla.org
Subject: Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 1:26 PM, Thaddee Tyl wrote:
I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.
{ (a, b) a + b }
cannot conflict with any existing program; at least I don't see how it
can.
but it is ambiguous with other currently valid statement blocks such as:
{ (a, b) + b}
or
{ (a,b)
a+b
}
Allen
___
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: Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 11:23 PM, François REMY
fremycompany_...@yahoo.fr wrote:
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
If not (as it seems to me), it means that a block lambda will not be used as
a statement by itself. If it's the case, it should defined as an Expression
only, where there's no anonymous block to conflict the syntax. That solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic
change for an identical syntax, in regards to strict ES5.
The case where you would like to use a block lambda as a stament can be
resolved by adding parenthesis, like with the current object notation. And
since I still continue to hope we'll ditch the unprefixed anonymous block in
some future revision of ES, that very small edge case could vanish at the
same time.
Does it seems possible/acceptable?
Looks like a great idea to me!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
François REMY mailto:fremycompany_...@yahoo.fr
January 12, 2012 2:23 PM
Am I wrong if I say there not a bigger issue with block lambda than
with the current object notation on the matter?
Please continue :-).
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
(You need a name for that function if it is a declaration, and from the
context you show, it is.)
Does this perfectly valid JS mean anything useful?
function f() {
(function (a, b) { return a + b; });
}
Nevertheless, it is legal. JS follows C (not Java) in allowing seemingly
useless expression-statements. This can be a source of bugs. It is also
required in some cases, namely when the function expression (in
parentheses) is the completion value of a Program. In such a case that
value could be the wanted result of eval or an eval-like host API.
If not (as it seems to me), it means that a block lambda will not be
used as a statement by itself. If it's the case, it should defined as
an Expression only,
Expression is already a kind of statement, via ExpressionStatement.
Furthermore, an ExpressionStatement *already* cannot start with a left
curly brace. Please read the grammar:
12.4 Expression Statement
Syntax
ExpressionStatement :
[lookahead ? {{, function}] Expression ;
NOTE An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block. Also, an
ExpressionStatement cannot start with the function keyword because that
might make it ambiguous with a FunctionDeclaration.
where there's no anonymous block to conflict the syntax.
This is the conflict you're looking for.
That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
That is already valid ES1-6.
Others have already replied, but the problem with redefining ( after {
without untenable newline sensitivity is it is a backward-incompatible
change.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I think you're correct. An ExpressionStatment can not begin with a {
so,without changing that rule, there should be no potential for ambiguity
between Block and BlockLambda. The only issue is distinguishing ObjectLiteral
and BlockLambda and from that perspective a {( is as good as a {| as neither
is ambiguous with existing ObjectLiteral syntax,
At that point, it becomes a matter of taste. Which of {|x| x.foo()} or {(x)
x.foo()} looks better to you? I find the | | more pleasant and easer for my
eyes to pick out, but I'm undoubtably influenced by many years of reading and
writing Smalltalk code.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 5:52 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
Am I wrong if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
I think you're correct. An ExpressionStatment can not begin with a {
so,without changing that rule, there should be no potential for ambiguity
between Block and BlockLambda. The only issue is distinguishing
ObjectLiteral and BlockLambda and from that perspective a {( is as good as
a {| as neither is ambiguous with existing ObjectLiteral syntax,
An additional consideration: for a block lambda's completion value to
be another block lambda, the {( syntax would require parenthesis,
while the {| syntax would not:
let succ =
{(x)
{(s)
{(z)
s(x(s)(z))
}}};
With the grammar François is suggesting, this would be a syntax error
(I think), since the body of a block lambda is a StatementList_opt.
The {| syntax, on the other hand, can accommodate block lambdas as
expression statements, though, given another token of lookahead
(again, I think).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 7:11 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 12, 2012, at 3:41 PM, Jon Zeppieri wrote:
...
With the grammar François is suggesting, this would be a syntax error
(I think), since the body of a block lambda is a StatementList_opt.
The {| syntax, on the other hand, can accommodate block lambdas as
expression statements, though, given another token of lookahead
(again, I think).
With two token look-ahead a | BlockLambda could be allowed at the head of a
statement, but it still would not enable unparenthesized object literals at
the head of a statement. It seems like a cognitive burden to allow one but
not the other. A simple { at the start of an expression statement must be
parenthesized rules seems easiest to learn and remember.
Allen
That's a good point, but I think that unparenthesized block lambdas
might be worth this complication. I hadn't considered object literals,
at all, while writing the previous message, and I don't think that was
simply an oversight. Object literals and blocks have a similar syntax
but dissimilar meaning. Block lambdas, on the other hand, are
semantically kinda-sorta like blocks. You don't need to parenthesize
nested blocks in JS code. (In fact, you can't.) That leads me to
expect unparenthesized block lambdas.
I guess it depends, to some extent, whether you think block lambdas
and object literals have more in common with each other (both being
first-class values) than block lambdas and blocks do (both being lists
of statements).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
... continuing with my sent-too-soon message:
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
You're right, this could be done. Allen's right that aesthetics matter,
and so (aesthetic sensibilities in various people were formed by these)
do older languages. Ruby uses || not (). Smalltalk uses | but
differently, and of course does not use {}.
Apart from aesthetics, I argue that || are better because they are
different from the overloaded () pair, which mean expression grouping in
the nearby context of the body of the block-lambda, e.g. a.add()b;
above. () also are used around formal parameter lists. And of course
they are used for control structure heads, e.g. if (foo).
Rather than overloading () yet again, for a different formal parameter
list context (block-lambda parameter list after {), which is immediately
adjacent to an expression-statement contexts (the block-lambda body), I
believe we should use ||.
The Ruby precedent is another reason, and a particular reason to use |
instead of some other candidate. But I'm mainly trying to persuade you
here that () is not the best choice just because it brackets formal
parameter lists for functions.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Block lambda is cool, its syntax isn't
On Thu, Jan 12, 2012 at 4:26 PM, Thaddee Tyl thaddee.tyl at gmail.com wrote:
I have heard many fellow programmers say that, while block lambdas
would be welcome, Ruby's |a, b| syntax is ugly.
I thought I was the only one feeling this way, but since I am not, I
would like to ask why the parentheses cannot be used there.
{ (a, b) a + b }
cannot conflict with any existing program; at least I don't see how it can.
I agree. While Ruby and Smalltalk are useful to continue mining for
ideas, they shouldn't be a source of syntax, as they're not
super-popular. Using || to denote an argument list looks *bizarre* to
my eyes, and I suspect also to the eyes of every single person who's
used a C-like language but not Ruby.
I'm not wedded to {(a,b) a + b} for blocks either, but it's at least
an improvement over {|a,b| a + b}. I wouldn't mind something simple
like block(a,b){a+b} or even do(a,b){a+b}, though those probably
run into ambiguity issues.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be used as
a statement by itself. If it's the case, it should defined as an Expression
only, where there's no anonymous block to conflict the syntax. That solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic
change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course more
consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for uses
of a feature in the wild. Does some enterprising es-discusser wanna take a
big JS program with a bunch of little anonymous functions, swap them out with
block lambdas, and make two gists with the two different syntaxes? That'd be
super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous block
in some future revision of ES, that very small edge case could vanish at the
same time.
I don't understand what you're referring to here -- what do you mean by
unprefixed anonymous block?
Does it seems possible/acceptable?
Lovely.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Block lambda is cool, its syntax isn't
From the perspective of someone who writes JS every day, the parens look
and feel right.
Dave, you asked for some example code, this is actually from task.js:
https://gist.github.com/e4e0e349f9cf35ad3370
On Thu, Jan 12, 2012 at 9:09 PM, David Herman dher...@mozilla.com wrote:
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be
used as a statement by itself. If it's the case, it should defined as an
Expression only, where there's no anonymous block to conflict the syntax.
That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No semantic
change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course
more consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for
uses of a feature in the wild. Does some enterprising es-discusser wanna
take a big JS program with a bunch of little anonymous functions, swap them
out with block lambdas, and make two gists with the two different syntaxes?
That'd be super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous
block in some future revision of ES, that very small edge case could vanish
at the same time.
I don't understand what you're referring to here -- what do you mean by
unprefixed anonymous block?
Does it seems possible/acceptable?
Lovely.
Dave
___
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: Block lambda is cool, its syntax isn't
This one is from https://github.com/ecto/duino/blob/master/lib/board.js and
has more real world uses
https://gist.github.com/d2c8fcbab5a3da4c4dae
Rick
On Thu, Jan 12, 2012 at 9:55 PM, Rick Waldron waldron.r...@gmail.comwrote:
From the perspective of someone who writes JS every day, the parens look
and feel right.
Dave, you asked for some example code, this is actually from task.js:
https://gist.github.com/e4e0e349f9cf35ad3370
On Thu, Jan 12, 2012 at 9:09 PM, David Herman dher...@mozilla.com wrote:
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be
used as a statement by itself. If it's the case, it should defined as an
Expression only, where there's no anonymous block to conflict the syntax.
That solution has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
would be a block lambda as an argument of an async function. No
semantic change for an identical syntax, in regards to strict ES5.
So simple, and so brilliant. I love it!
I must say, the parens look much prettier to me, and they're of course
more consistent with JS precedent.
It does help to write a reasonable chunk of code to compare syntaxes for
uses of a feature in the wild. Does some enterprising es-discusser wanna
take a big JS program with a bunch of little anonymous functions, swap them
out with block lambdas, and make two gists with the two different syntaxes?
That'd be super helpful.
And since I still continue to hope we'll ditch the unprefixed anonymous
block in some future revision of ES, that very small edge case could vanish
at the same time.
I don't understand what you're referring to here -- what do you mean by
unprefixed anonymous block?
Does it seems possible/acceptable?
Lovely.
Dave
___
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: Block lambda is cool, its syntax isn't
Sigh. Never mind, I'm
thinking of statement not _expression_ context -- and you can't start an
_expression_ statement with {. Parade's back on. :-)
/be
Brendan Eich
January 12, 2012
7:21 PM
Sorry, thought about it
more and I'm raining on your (and dherman's) parade :-(.
In an _expression_ but not statement context,
... { (x) e; }
is already a valid JS program if e begins with (, [, +, or - (the last
two intended as unary operators but becoming binary).
Note that | bracketing avoids this problem. In no case can JS of any
extant version have a legal sequence {|.
But because {( is already allowed, what comes after the closing ) can be
the continuation of a parenthesized _expression_.
Even if you don't buy my "better to look different because not function"
argument, this tilts the balance.
/be
___es-discuss
mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss
Brendan Eich
January 12, 2012
4:53 PM
... continuing
with my sent-too-soon message:
function() {
asyncAction(..., { (a, b) a.add(b); } }
}
You're right, this could be done. Allen's right that aesthetics matter,
and so (aesthetic sensibilities in various people were formed by these)
do older languages. Ruby uses || not (). Smalltalk uses | but
differently, and of course does not use {}.
Apart from aesthetics, I argue that || are better because they are
different from the overloaded () pair, which mean _expression_ grouping in
the nearby context of the body of the block-lambda, e.g. a.add()b;
above. () also are used around formal parameter lists. And of course
they are used for control structure heads, e.g. if (foo).
Rather than overloading () yet again, for a different formal parameter
list context (block-lambda parameter list after {), which is immediately
adjacent to an _expression_-statement contexts (the block-lambda body), I
believe we should use ||.
The Ruby precedent is another reason, and a particular reason to use |
instead of some other candidate. But I'm mainly trying to persuade you
here that () is not the best choice just because it brackets formal
parameter lists for functions.
/be
Brendan Eich
January 12, 2012
2:49 PM
Franois REMY
January 12, 2012
2:23 PM
Am I wrong
if I say there not a bigger issue with block lambda than with the
current object notation on the matter?
Please continue :-).
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
(You need a name for that function if it is a declaration, and from the
context you show, it is.)
Does this perfectly valid JS mean anything useful?
function f() {
(function (a, b) { return a + b; });
}
Nevertheless, it is legal. JS follows C (not Java) in allowing seemingly
useless _expression_-statements. This can be a source of bugs. It is also
required in some cases, namely when the function _expression_ (in
parentheses) is the completion value of a Program. In such a case that
value could be the wanted result of eval or an eval-like host API.
If not (as it seems to me), it means that a block lambda will not be
used as
a statement by itself. If it's the case, it should defined as an
_expression_
only,
_expression_ is already a kind of statement, via ExpressionStatement.
Furthermore, an ExpressionStatement *already* cannot start with a left
curly brace. Please read the grammar:
12.4 _expression_ Statement
Syntax
ExpressionStatement :
[lookahead {{, function}] _expression_ ;
NOTE An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block. Also, an
ExpressionStatement cannot start with the function keyword because that
might make it ambiguous with a FunctionDeclaration.
where
there's no anonymous block to conflict the syntax.
This is the conflict you're looking for.
That
solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
That is already valid ES1-6.
Others have already replied, but the problem with redefining ( after {
without untenable newline sensitivity is it is a backward-incompatible
change.
/be
Franois REMY
January 12, 2012
2:23 PM
Am I wrong if I say there not a
bigger issue with block lambda than with the
current object notation on the matter?
I mean, does that code mean anything useful?
function() {
{|a,b| a+b};
}
If not (as it seems to me), it means that a block lambda will not be
used as
a statement by itself. If it's the case, it should defined as an
_expression_
only, where there's no anonymous block to conflict the syntax. That
solution
has been chosen for object notation in the past. That way,
function() {
{
(a, b)
a.add(b)
}
}
would still be an anonymous block where
function() {
asyncAction(..., { (a, b) a.add(b);
