Re: Parameter lists as arguments destructuring sugar
Hi Bob,
This stuff should all be backward compatible. You wouldn't get "1 | 2
| 3" unless you did something
like "show.apply(null, arg)" or "show(...arg)".
I considered object structuring/destructuring of arguments, but
additional syntax would be needed on parameter lists and function
invocations since the shortcut form of object structuring /
destructuring i.e. "{x, y}", would translate to "f(x, y)" and
"function (x, y){}" which are indistinguishable from traditional
forms. Also, if object destructuring of function arguments were
supported (they would be with this proposal, the destructuring page
has an example of it, but it's not fully specified), then you could
just do this...
function ({a, b}){}
//or
function ({a: b, c: d}){}
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
regarding Tennent's "Language Design based on Semantic Principles"
[since I was lucky enough to be near a good university library some 15 years ago, and have a long-standing interest in language design, I'll try to respond to questions from the other thread here; the hope is to turn those principles from an obstacle to a tool in Ecmascript design] As a long-time fan of semantic principles for language design, I've been reading the very odd references to Tennent's design principles in discussions here with some discomfort. In the list archives, 'TCP' sometimes sounds like almost as big a source of problems as 'ASI'. Also, some of the references bear little or no resemblance to the principles I read about! The principles are open to interpretation, and we all have our own misconceptions about them, especially when they seem to support what we wanted to do anyway(*). But they were not taken out of thin air, either: they were collected from early work on language design and language semantics. I've always found them to lead to simpler, more consistent language designs - they point out problems, and show how to remove problems, but they do not make problems. My knowledge of Tennent's principles comes from his paper [1], not from his book, but I doubt that the difference are that great. If you have a university library nearby, the paper and its references are well worth reading for anyone involved in language design - they don't have all the answers, but many of todays problems were already under discussion back then (you'd be surprised at the similarities;-). Let me try to state the two principles from that paper first (try, because I have to collect and paraphrase from the text), followed by interpretations that I've found useful. // principle of abstraction Abstraction facilities may be provided for any semantically meaningful category of syntactic constructs Tennent refers to 'abstraction' in a technical sense, citing motivating examples from set theory, relations and functions, that is from mathematics and theory of computation. Concrete examples from programming languages include abstraction over statements (procedures) and over expressions (functions). Interpretation Note the "semantically meaningful" - Tennent is talking about semantic abstractions, represented in syntax, not about merely syntactic abstractions! I've found that to be the single most important issue when using this principle: what are the semantic objects we need to talk about, and how are they represented in our syntax? We could, of course, decide that our language should also serve as its own meta-language, then syntax phrases would be semantically meaningful, and we would want to support syntactic abstractions/macros (syntax-level functions). But without such a decision, we should not try to apply the principle of abstraction to arbitrary pieces of syntax. The second most interesting issue is that our ideas about which parts of our language are semantically meaningful may evolve - modules are a prime example here: at first, we just have abstractions of statements and expressions, and declarations happen to be a syntactic consequence of that. But as our programs grow larger, we notice that we want to talk about groups of declarations as semantic objects, so now the principle of abstraction applies, and we end up with some form of modules. Something similar applies to break and labels: in current Javascript, neither 'break label' nor 'label' on its own has any meaning, they are part of loops or switch statements. So it simply makes no sense to abstract over break statements independent of their loop/switch - the principle does not apply! We might, however, decide to work out semantics for 'break label' or for 'label' on its own, and then the principle of abstraction would ask us to think about abstractions over these (Tennent discusses sequels as abstractions over the 'break label' form, and mentions label parameters as well). The former very quickly leads towards call/cc, the latter might be easier to implement, but also encourages more complicated uses of labels. Either variant needs semantics before talking about their interactions with lambdas and the like. Similarly for 'this' and 'return'. // principle of correspondence (paraphrasing): The rules governing names in a language should be designed together in order to avoid irregularities in the manner in which the names may be used. In particular, there should be a one-to-one correspondence between declarative and parametric forms of introducing names. This goes back directly to Landin [2], and comes with an example, comparing variable declaration for 'x' with formal function parameter 'x': x*(x+a) where x= b+2*c f(b+2*c) where f(x)= x*(x+a) Interpretation The principle of correspondence interacts with the principle of abstraction: our two most common ways of introducing abstractions in programming languages inv
Re: Removing labels
+ es-discuss
Realized, I didn't include the mailing list.
On Sat, Apr 9, 2011 at 10:48 AM, John Lenz wrote:
> As a point of interest the Closure Compiler uses labelled blocks to enable
> inlining of non-trivial functions. The same can be accomplished with a "do
> {} while (false); " but it is less desirable.
>
> sent from a mobile phone excuse the spelling ...
> On Apr 9, 2011 1:33 AM, "Peter van der Zee" wrote:
> > Can we remove labels from the next version of the spec?
> >
> > Labels are only used for continue and break. I don't think I've ever had
> or
> > seen a need for them (which does not mean they're unused, btw). They can
> be
> > sugar insofar as to breaking a double loop at once. But at the same time
> > they promote spaghetti coding. On top of that there's a decent impact on
> the
> > specification. In fact, I'm a little surprised they were not excluded
> from
> > strict mode.
> >
> > So nothing would really change for label-less `continue` and break.
> >
> > Switch and iterations would not get an empty label (obviously) and the
> whole
> > label stack could be stripped.
> >
> > Furthermore the grammar for continue and break would be as simple as that
> > for debugger. And the label statement would disappear (which is nice
> because
> > at the start of a statement, if the first token is an identifier, you
> need
> > to parse another token before being able to determine whether you're
> parsing
> > a label or an expression).
> >
> > The completion type (8.9) would no longer need to have three parameters,
> > just two.
> >
> > Am I missing anything? Or are there cases where labels allow you do
> > something that's impossible without labels?
> >
> > - peter
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Removing labels
On Apr 9, 2011, at 1:33 AM, Peter van der Zee wrote: > Can we remove labels from the next version of the spec? Ok, this thread has not been a complete waste, but I'm going to suggest, strongly, we not start "let's remove feature X" threads. We are being careful about migration tax. I've written about counting the backward-compatibility breaks on five fingers, and four out of five must break via early (compile-time) errors. (The current exception is typeof null == "null".) Removing labels just taxes well-written code, requiring a pointless rewrite using flag variables or worse. It also would break all the accidental labels of the form javascript:... that have leaped across the URL / script source barrier. As Dave says, we're not going to go on random "I want to remove feature X because some have misused it" snipe hunts. (BTW, that is not why 'with' was removed from ES5 strict mode.) /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removing labels
I don't have Tennent's book handy either. But Neal's post claims: "The principle dictates that an expression or statement, when wrapped in a closure and then immediately invoked, ought to have the same meaning as it did before being wrapped in a closure." And IIRC, when you look it up in Tennent's book, it really doesn't say that. I think if you squint you can sort of see a connection, but it's not obvious. But the particular program equivalence Neal was talking about (which Tennent does not specifically mention in his book) is as old as the lambda calculus (we're talking 1930's here). It's a special case of what's known as beta-equivalence (or often "beta-conversion" or "beta-reduction" or "beta-substitution") in the lambda calculus. For what's known as the call-by-value lambda calculus [1] it can be stated roughly like: (lambda(x1, ..., xn) expr)(v1, ..., vn) = expr[x1 := v1, ..., xn := vn] Using substitution (the "x := v" notation, meaning "substitute v into the expression wherever you see a reference to x") doesn't exactly work for JS, because it doesn't model the heap, but it doesn't much matter for the zero-argument case. More generally, the idea of using program equivalences for reasoning about and designing languages is "bread and butter" for PL researchers. It's weird to see it attributed to a tiny passage of a book from the 80's. Dave [1] If you don't know what call-by-value means here, don't worry about it. It has nothing to do with call-by-reference, just an unfortunate overloading of terminology. Nothing to see here, move along. On Apr 9, 2011, at 10:24 AM, Wes Garland wrote: > On Sat, Apr 9, 2011 at 12:47 PM, David Herman wrote: > When people say "Tennent's correspondence principle" to mean something like > "beta-conversion is semantics-preserving" I believe this post is where they > got the impression that it has to do with Tennent. For better or worse, it > seems to have stuck. > > > I haven't got the faintest clue what beta-conversion is, but Neal's post > seems consistent with what I took away from that (extremely short) discussion > in Tennent's book. I'd look it up now, but it's at my office and this is the > weekend. :) What am I missing? > > Wes > > -- > Wesley W. Garland > Director, Product Development > PageMail, Inc. > +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removing labels
2011/4/9 David Herman : >> [aside: as far as I understand Tennent, this has nothing to do >> with his principles of correspondence or abstraction, which >> are often misquoted and conjured with in the archives] > > AFAICT, this traces back to a blog post by Neal Gafter: > > > http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html > > When people say "Tennent's correspondence principle" to mean something like > "beta-conversion is semantics-preserving" I believe this post is where they > got the impression that it has to do with Tennent. For better or worse, it > seems to have stuck. I was sharing a cube with him then, and from chats with him, it seemed to be a term that the Java guys bandied about a lot but he may have been the one who popularized the usage of it. > 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: Removing labels
On Sat, Apr 9, 2011 at 12:47 PM, David Herman wrote: > When people say "Tennent's correspondence principle" to mean something like > "beta-conversion is semantics-preserving" I believe this post is where they > got the impression that it has to do with Tennent. For better or worse, it > seems to have stuck. > > I haven't got the faintest clue what beta-conversion is, but Neal's post seems consistent with what I took away from that (extremely short) discussion in Tennent's book. I'd look it up now, but it's at my office and this is the weekend. :) What am I missing? Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removing labels
This would be brittle. Take all my arguments against the ^this feature
discussed in an earlier thread and repeat them here. Labels work just fine (and
better than numbers would) for this purpose.
Dave
On Apr 9, 2011, at 7:32 AM, Bradley Meck wrote:
> I think since we can only break/continue to labels in a linear chain
> upwards, break could take a number for how many loops it should break.
> This could still be tested at compile time as well, but would lead to
> somewhat less readable code. It would however be incompatible with
> current label based breaks (easier to find an replace if a compiler
> warns you).
>
> while(true) {
> while(true) {
> break 2;
> }
> }
>
>
> Anywho, I don't personally like number based breaking, just throwing
> around ideas.
>
> Cheers,
> Bradley
>
> On Sat, Apr 9, 2011 at 4:10 AM, Claus Reinke wrote:
>>> Can we remove labels from the next version of the spec?
>>
>> I'm not a fan of labels, at least not as a built-in language
>> construct - I'd much prefer if the language was expressive enough to emulate
>> such functionality when needed (that
>> includes useable syntax), not to mention reducing the
>> need for such features in the first place.
>> However, as long as Javascript has break and continue, ..
>>
>>> Am I missing anything? Or are there cases where labels allow you do
>>> something that's impossible without labels?
>>
>> It seems that language features like lambdas have been shot
>> down because of their interaction with break and continue.
>> In brief, people want to be able to abstract over syntax phrases
>> like the one marked with -| .. |- here, by wrapping it in some
>> form of immediately called function and still have it behave as before:
>>
>> while (..) { .. -| break; |- .. }
>>
>> [aside: as far as I understand Tennent, this has nothing to do
>> with his principles of correspondence or abstraction, which
>> are often misquoted and conjured with in the archives]
>>
>> Now, if we want to wrap that phrase into a function (not a
>> syntax macro), then that function cuts through the while/break
>> construct. Still, we can refactor the code a little to make that
>> wrapping possible:
>>
>> loop: while (..) { ..switch ( -| function() { return 'break'; } ()
>> |- ) {
>> case 'break' : break loop;
>> case 'continue' : continue loop;
>> }
>> ..}
>>
>> With this change, we are able to wrap code involving break
>> or continue into a function (and move that function definition
>> out of the loop body). Since the switch statement has its own
>> break-target, we need the loop label, even though the original
>> break did not have a label.
>>
>> There are other ways to handle this situation, but this seemed
>> to be the most direct way of expressing the intention, given that labels are
>> not first-class values in Javascript.
>>
>> Better alternatives welcome,
>> Claus
>>
>> ___
>> 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: Removing labels
> [aside: as far as I understand Tennent, this has nothing to do > with his principles of correspondence or abstraction, which > are often misquoted and conjured with in the archives] AFAICT, this traces back to a blog post by Neal Gafter: http://gafter.blogspot.com/2006/08/tennents-correspondence-principle-and.html When people say "Tennent's correspondence principle" to mean something like "beta-conversion is semantics-preserving" I believe this post is where they got the impression that it has to do with Tennent. For better or worse, it seems to have stuck. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removing labels
We shouldn't be making backwards-incompatible changes for features just because they can be abused. Every feature can be abused. And simplifying the completion type is not even remotely an important goal. Sometimes labels are just necessary. Sometimes you have a loop that needs an early return, and you're doing a switch inside that loop, and there's no way to break out of the loop without the label. Labels are even more important for code generators, which need to implement non-trivial control flow. The one hand giveth compiler writers tail calls, the other taketh away labels? I sure hope not! But I'll try to resist writing long, impassioned defenses about uncontroversial features of the language. The barrier to making backwards-incompatible changes is high (see Brendan's "five fingers of fate"), and we should only consider removing *extremely* problematic features. Dave On Apr 9, 2011, at 1:33 AM, Peter van der Zee wrote: > Can we remove labels from the next version of the spec? > > Labels are only used for continue and break. I don't think I've ever had or > seen a need for them (which does not mean they're unused, btw). They can be > sugar insofar as to breaking a double loop at once. But at the same time they > promote spaghetti coding. On top of that there's a decent impact on the > specification. In fact, I'm a little surprised they were not excluded from > strict mode. > > So nothing would really change for label-less `continue` and break. > > Switch and iterations would not get an empty label (obviously) and the whole > label stack could be stripped. > > Furthermore the grammar for continue and break would be as simple as that for > debugger. And the label statement would disappear (which is nice because at > the start of a statement, if the first token is an identifier, you need to > parse another token before being able to determine whether you're parsing a > label or an expression). > > The completion type (8.9) would no longer need to have three parameters, just > two. > > Am I missing anything? Or are there cases where labels allow you do something > that's impossible without labels? > > - 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: Removing labels
On 2011-04-09, at 04:33, Peter van der Zee wrote: > Am I missing anything? Or are there cases where labels allow you do > something that's impossible without labels? They let you write more literate code? I agree labels should be eschewed, except where necessary. But sometimes, you just need them. Here's some fairly complex algorithms from the OpenLaszo source that I think would be even more difficult to understand without their judicious use of labels: http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/services/LzCSSStyle.lzs Sure there are plenty of other ways to write this code, but I'm not convinced they are more maintainable. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Removing labels
I think since we can only break/continue to labels in a linear chain
upwards, break could take a number for how many loops it should break.
This could still be tested at compile time as well, but would lead to
somewhat less readable code. It would however be incompatible with
current label based breaks (easier to find an replace if a compiler
warns you).
while(true) {
while(true) {
break 2;
}
}
Anywho, I don't personally like number based breaking, just throwing
around ideas.
Cheers,
Bradley
On Sat, Apr 9, 2011 at 4:10 AM, Claus Reinke wrote:
>> Can we remove labels from the next version of the spec?
>
> I'm not a fan of labels, at least not as a built-in language
> construct - I'd much prefer if the language was expressive enough to emulate
> such functionality when needed (that
> includes useable syntax), not to mention reducing the
> need for such features in the first place.
> However, as long as Javascript has break and continue, ..
>
>> Am I missing anything? Or are there cases where labels allow you do
>> something that's impossible without labels?
>
> It seems that language features like lambdas have been shot
> down because of their interaction with break and continue.
> In brief, people want to be able to abstract over syntax phrases
> like the one marked with -| .. |- here, by wrapping it in some
> form of immediately called function and still have it behave as before:
>
> while (..) { .. -| break; |- .. }
>
> [aside: as far as I understand Tennent, this has nothing to do
> with his principles of correspondence or abstraction, which
> are often misquoted and conjured with in the archives]
>
> Now, if we want to wrap that phrase into a function (not a
> syntax macro), then that function cuts through the while/break
> construct. Still, we can refactor the code a little to make that
> wrapping possible:
>
> loop: while (..) { .. switch ( -| function() { return 'break'; } ()
> |- ) {
> case 'break' : break loop;
> case 'continue' : continue loop;
> }
> .. }
>
> With this change, we are able to wrap code involving break
> or continue into a function (and move that function definition
> out of the loop body). Since the switch statement has its own
> break-target, we need the loop label, even though the original
> break did not have a label.
>
> There are other ways to handle this situation, but this seemed
> to be the most direct way of expressing the intention, given that labels are
> not first-class values in Javascript.
>
> Better alternatives welcome,
> Claus
>
> ___
> 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: Removing labels
Can we remove labels from the next version of the spec?
I'm not a fan of labels, at least not as a built-in language
construct - I'd much prefer if the language was expressive
enough to emulate such functionality when needed (that
includes useable syntax), not to mention reducing the
need for such features in the first place.
However, as long as Javascript has break and continue, ..
Am I missing anything? Or are there cases where labels
allow you do something that's impossible without labels?
It seems that language features like lambdas have been shot
down because of their interaction with break and continue.
In brief, people want to be able to abstract over syntax phrases
like the one marked with -| .. |- here, by wrapping it in some
form of immediately called function and still have it behave
as before:
while (..) { .. -| break; |- .. }
[aside: as far as I understand Tennent, this has nothing to do
with his principles of correspondence or abstraction, which
are often misquoted and conjured with in the archives]
Now, if we want to wrap that phrase into a function (not a
syntax macro), then that function cuts through the while/break
construct. Still, we can refactor the code a little to make that
wrapping possible:
loop: while (..) { ..
switch ( -| function() { return 'break'; } () |- ) {
case 'break' : break loop;
case 'continue' : continue loop;
}
..
}
With this change, we are able to wrap code involving break
or continue into a function (and move that function definition
out of the loop body). Since the switch statement has its own
break-target, we need the loop label, even though the original
break did not have a label.
There are other ways to handle this situation, but this seemed
to be the most direct way of expressing the intention, given
that labels are not first-class values in Javascript.
Better alternatives welcome,
Claus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Removing labels
Can we remove labels from the next version of the spec? Labels are only used for continue and break. I don't think I've ever had or seen a need for them (which does not mean they're unused, btw). They can be sugar insofar as to breaking a double loop at once. But at the same time they promote spaghetti coding. On top of that there's a decent impact on the specification. In fact, I'm a little surprised they were not excluded from strict mode. So nothing would really change for label-less `continue` and break. Switch and iterations would not get an empty label (obviously) and the whole label stack could be stripped. Furthermore the grammar for continue and break would be as simple as that for debugger. And the label statement would disappear (which is nice because at the start of a statement, if the first token is an identifier, you need to parse another token before being able to determine whether you're parsing a label or an expression). The completion type (8.9) would no longer need to have three parameters, just two. Am I missing anything? Or are there cases where labels allow you do something that's impossible without labels? - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
