On Wed, May 30, 2012 at 3: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.
>
Yes, I think the newer o.( foo = "thing"; bar = "other" ) is nice and will
satisfy the need just the same.
I'm also 100% in agreement with Allen here. The paren form lacks the
possibility of extending this syntax to existing forms, which IIRC we were
all in agreement was one of the better and more convincing "wins" of the
curly form - which lead to the agreeing that it was indeed worthy of it's
own proposal.
This should not be read as opposition to the paren form, merely a circling
of the cart.
Rick
>
> 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.
>
> Allen
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
