Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-27 Thread Garrett Smith
On 7/25/10, Mark S. Miller erig...@google.com wrote: On Sun, Jul 25, 2010 at 11:36 AM, Brendan Eich bren...@mozilla.com wrote: On Jul 25, 2010, at 10:52 AM, Mark S. Miller wrote: The problem is that as long as ASI exists, one will often see working code such as this, since it does usually

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-26 Thread Dmitry A. Soshnikov
On 26.07.2010 4:11, Maciej Stachowiak wrote: On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote: On Jul 25, 2010, at 4:59 PM, Maciej Stachowiak wrote: On Jul 25, 2010, at 11:36 AM, Brendan Eich wrote: Let's not go in circles. I claim: * The horses are long gone from the

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-26 Thread Waldemar Horwat
Maciej Stachowiak wrote: On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote: Mark's restricted production idea is on target, if we think it's worth doing. At least in C or C++, I've seen code like this: veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-26 Thread Mark S. Miller
I'm proposing that the same opt-in that makes function call a restricted production also turns off semicolon insertion, making that code into a static syntax error. For those cases where the language can't reliably tell what I mean, I don't want it to guess. On Mon, Jul 26, 2010 at 2:02 PM,

Fwd: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Mark S. Miller
. -- Forwarded message -- From: Brendan Eich bren...@mozilla.com Date: Sat, Jul 24, 2010 at 10:28 PM Subject: Re: Rationalizing ASI (was: simple shorter function syntax) To: Maciej Stachowiak m...@apple.com, Mark S. Miller erig...@google.com Cc: es-discuss es-discuss@mozilla.org On Jul 24, 2010

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Mark S. Miller
message -- From: Brendan Eich bren...@mozilla.com Date: Sat, Jul 24, 2010 at 10:28 PM Subject: Re: Rationalizing ASI (was: simple shorter function syntax) To: Maciej Stachowiak m...@apple.com, Mark S. Miller erig...@google.com Cc: es-discuss es-discuss@mozilla.org On Jul 24, 2010, at 3

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Mark S. Miller
On Sat, Jul 24, 2010 at 11:46 PM, Brendan Eich bren...@mozilla.com wrote: On Jul 24, 2010, at 11:30 PM, Mark S. Miller wrote: From: Brendan Eich bren...@mozilla.com I see three tenable alternatives: A. Remove ASI in some opt-in version, in full -- no error correction, no restricted

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Mark S. Miller
On Sun, Jul 25, 2010 at 11:36 AM, Brendan Eich bren...@mozilla.com wrote: On Jul 25, 2010, at 10:52 AM, Mark S. Miller wrote: The problem is that as long as ASI exists, one will often see working code such as this, since it does usually work. This training of the eye is a kind of

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Brendan Eich
On Jul 25, 2010, at 11:56 AM, David Herman wrote: In order to reliably remove this hazard, we would need to ban statements from starting with '('. Perhaps we should consider doing so. That's a REPL-killer: as is, you have to do unnatural paren-wrapping for object-literal expressions at

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread David Herman
Mark's restricted production for CallExpression attacks the hazard even more directly, but apart from our aversion to restricted productions, what might it break? I don't see offhand what it might break. This question seems easy to investigate empirically-- crawl the web looking for

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Brendan Eich
On Jul 25, 2010, at 2:02 PM, David Herman wrote: Mark's restricted production for CallExpression attacks the hazard even more directly, but apart from our aversion to restricted productions, what might it break? I don't see offhand what it might break. This question seems easy to

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Brendan Eich
On Jul 25, 2010, at 2:17 PM, Brendan Eich wrote: Also, not another restricted production! But hats off to Mark for proposing it, since it zeroes in on the hard case. A good es-discuss thread (it's not like we have too many going at once) can clarify what may seem murky or overcomplicated

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Brendan Eich
On Jul 25, 2010, at 4:59 PM, Maciej Stachowiak wrote: On Jul 25, 2010, at 11:36 AM, Brendan Eich wrote: Let's not go in circles. I claim: * The horses are long gone from the barn. * The mistake is easy to overlook even for JS coders who do use semicolons. * The trade-off of banning ASI

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Maciej Stachowiak
On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote: On Jul 25, 2010, at 4:59 PM, Maciej Stachowiak wrote: On Jul 25, 2010, at 11:36 AM, Brendan Eich wrote: Let's not go in circles. I claim: * The horses are long gone from the barn. * The mistake is easy to overlook even for JS coders

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Mark S. Miller
On Sun, Jul 25, 2010 at 5:11 PM, Maciej Stachowiak m...@apple.com wrote: On Jul 25, 2010, at 5:06 PM, Brendan Eich wrote: On Jul 25, 2010, at 4:59 PM, Maciej Stachowiak wrote: On Jul 25, 2010, at 11:36 AM, Brendan Eich wrote: Let's not go in circles. I claim: * The horses are

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-25 Thread Mike Shaver
On Sun, Jul 25, 2010 at 8:15 PM, Mark S. Miller erig...@google.com wrote: veryLongObjectName.someOtherVeryVeryLongObjectName.ridiculouslyLongFunctionName    (longArgument1, longArgument2, longArgument3, longArgument4, longArgument5); Yes. Even in the absence of ASI issues, my inclination

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-24 Thread Maciej Stachowiak
On Jul 24, 2010, at 12:40 PM, Brendan Eich wrote: On Jul 24, 2010, at 11:58 AM, Mark S. Miller wrote: On Sat, Jul 24, 2010 at 9:21 AM, Kevin Curtis kevinc1...@gmail.com wrote: [...] Also, is anything proposed for rationalizing ASI in Harmony. I would welcome ideas. I was sad when we

Re: Rationalizing ASI (was: simple shorter function syntax)

2010-07-24 Thread Brendan Eich
On Jul 24, 2010, at 3:38 PM, Maciej Stachowiak wrote: ASI has two parts: syntax error correction + restricted productions. The pain users feel from ASI in my experience is mostly not from the well-specified error correction part. It's mainly due to those infernal restricted productions,