+ 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 l
out 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 rewr
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 Tennen
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.
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
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
> [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-corr
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,
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 t
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 br
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
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 spag
12 matches
Mail list logo
