Hi Brendan, I started to reply, but found it too confusing to talk about
options #1, #2, and #3 and about ASI rules #1, #2, and #3. I'm resending
your text edited with your options relabeled as #A, #B, and #C. I'll then
reply to this edited version. I encourage others to do likewise.
--
First, I agree that we should gather and examine data before making any
decisions. That said, here are my data-free reactions. I may well change my
mind about any of this once we have data to examine.
On Sat, Jul 24, 2010 at 11:16 PM, Mark S. Miller erig...@google.com wrote:
Hi Brendan, I
On 23.07.2010 21:24, Bryan Kyle wrote:
I believe # has the advantage of not being a valid character in an
identifier so there won't be any backwards compatibility problems with
existing code.
Backward compats are good. But is this a good reason to provide ugly
syntax constructs into the
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
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
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
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
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
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
On Jul 24, 2010, at 11:51 AM, Mark S. Miller wrote:
On Fri, Jul 23, 2010 at 10:37 AM, Oliver Hunt oli...@apple.com wrote:
On Jul 23, 2010, at 10:32 AM, Brendan Eich wrote:
On Jul 23, 2010, at 10:27 AM, Oliver Hunt wrote:
[Good point about LL(∞) snipped.]
* To give you an idea of
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
On Sun, Jul 25, 2010 at 4:57 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 24, 2010, at 11:51 AM, Mark S. Miller wrote:
On Fri, Jul 23, 2010 at 10:37 AM, Oliver Hunt oli...@apple.com wrote:
On Jul 23, 2010, at 10:32 AM, Brendan Eich wrote:
On Jul 23, 2010, at 10:27 AM, Oliver Hunt
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
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
On Sun, Jul 25, 2010 at 7:57 PM, Maciej Stachowiak m...@apple.com wrote:
Good point about the escaping hazard. I think # may look funny to people
because it is a noisy symbol and also because it is a comment delimiter in
many languages. Two other characters totally disallowed in the syntax are
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
On Jul 25, 2010, at 4:57 PM, Maciej Stachowiak wrote:
On Jul 24, 2010, at 11:51 AM, Mark S. Miller wrote:
The reason I prefer # to \ is simply that JavaScript source text
[fragments] frequently appear in literal strings. Right now, the only
quoting hazard this introduced is quotes and
On Jul 25, 2010, at 4:57 PM, Maciej Stachowiak wrote:
Perhaps the strawman page for shorter function syntax should list reasons for
rejecting other syntax options. I would be happy to document the reasons
against fn, fun, f and \, but I can't seem to remember my username and
password
18 matches
Mail list logo
