On Wed, May 30, 2012 at 12:46 PM, Allen Wirfs-Brock
<[email protected]>wrote:
> On May 29, 2012, at 11:59 PM, Mark S. Miller wrote:
>
> ...
> I appreciate this reason ;), but I like semicolon for another reason --
> the parens suggest "factoring out" the "o.", as if
>
> o.(stuff1; stuff2)
>
> means the same thing as
>
> o.stuff1; o.stuff2
>
> where stuff1 and stuff2 are not identifiers, but (to take an extreme
> stance) anything that can appear within an expression statement between an
> initial "o." and a terminal ";".
>
> Although it does not fall out of the factoring interpretation, I think it
> is still natural for the expression as a whole to have o as its value,
> since expression statements are not normally thought of as having a value.
>
> However, I think it is just too much syntax to have both this and
> mustache. We should choose at most one. I would prefer neither to both.
>
>
> I think that
>
> o.{
> p1: expr0,
> p2() {return this.p1},
> get p3 () {someSideEffect(); return this.p1}
> };
>
> and
>
> o.(
> p1 = expr1;
> p2());
> p3 //I didn't include this case in the bnf I wrote up
> }
>
> are syntacticly distinctive enough that there would be no reason to trade
> them off against each other. They should each be consider based upon their
> unique utility. An advantage of my recent strawman (and what we discussed
> at the TC39 meeting) is that it leveraged one construct for a larger
> number of use cases. That is generally a good think, if it doesn't create
> confusion. Unfortunately may strawman may not meet that mark.
>
> If you are concerned about the overall syntactic complexity budget of the
> language, then we aren't limited to only trading the above two constructs
> off against each other. There are other new and relatively complex
> syntactic embellishments that we have adopted that IMO may not have as much
> general utility as either of the above. If we are concerned about the
> syntactic complexity budget, we should be looking globally at all the
> proposals. But, that is another conversation.
>
My concern is indeed the overall complexity budget. And I agree. I'm happy
to have both of these if we can make some real complexity cuts elsewhere. I
look forward to that other conversation ;).
>
> Allen
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
