On Apr 13, 2011, at 10:46 PM, Kyle Simpson wrote:
>>> I'm not sure I see how this is really introducing an additional ambiguity?
>>
>> It is obviously introducing an ambiguity where none exists today. ?: is
>> indivisible, unlike if vs. if else.
>
> I was referring to no additional visual ambiguity inside the ?: with respect
> to operator precedence and how to interpret a chain of nested ?:, as compared
> to doing the same task if `:` is optional.
>
> a ? b ? c : d ? e ? f : g : h ? i : j : k
> ==>
> a ? (b ? c : (d ? (e ? f : g) : (h ? i : j))) : k
>
> Firstly, that code has no *real* ambiguity, because operator precedence tells
> us how those implied () sets disambiguate it.
In an LR(1) grammar, if vs. if-else or ? vs. ?: is a shift-reduce conflict (to
use yacc terms). It is an ambiguity. It can be disambiguated, but please do not
confuse disambiguation via shifting with "no *real* ambiguity".
> Secondly, in my opinion, the visual "ambiguity" of it is not made any more
> burdensome (and is even perhaps SLIGHTLY *clearer*) by adding () sets to
> disambiguate where you want optional `:`, such as this example (same as
> above, but where `g` and `j` are omitted as placeholders for implied
> `undefined`):
>
> a ? b ? c : d ? (e ? f) : (h ? i) : k
> ==>
> a ? (b ? c : (d ? (e ? f : undefined) : (h ? i : undefined))) : k
This is all akin to bracing "then" and "else" clauses, and there's no need to
belabor it. My point that we should not add more of the same ambiguity stands.
>> In sum, this sounds like an argument against ? as infix operator (implied :
>> undefined).
>
> I'm sorry, I'm lost by this statement. I don't understand on what basis you
> conclude that I just argued against the very thing I'm asking for. Can you
> elaborate at all?
You made an ad-hoc argument for a ? b : undefined but want to write that as a ?
b. The latter is not obviously the same (Dmitry pointed out the potential for
confusion with ??, which has a very different result). It's also not obviously
a good non-hard case to burn into the grammar.
>>> var opts = {
>>> doX: (someX > 0 && someX < 10) ? someX , // leaving off the `: undefined`
>>> (or `: null` if you prefer)
>>> doY: (someY > 0 && someY < 1) ? someY // ditto
>>> };
>>
>> Sorry, I think this is a hazardous pattern. "doX" suggests a boolean value,
>
> How is
>
> doX = (someX > 0 && someX < 10) ? someX
>
> more suggestive of a "boolean" value than is
>
> doX = (someX > 0 && someX < 10) ? someX : undefined
The name "doX" connotes boolean.
>> but you want (number | undefined), a type union.
>
> I'm not sure if you're arguing against:
> a) the pattern of having an `undefined` value in a variable when "unset",
> that otherwise stores numbers when it's "set"; OR
> b) the implied `: undefined`
Both, (b) because of (a). I was explicit about this, there's no confusion.
> If (a), this was a long held pattern long before I ever wrote my first line
> of JavaScript. Moreover, it's far more common today on the greater web than
> any code I've ever written. I'd argue it's pretty close to a de facto pattern
> at this point, so I'm not sure what the point is in using that argument to
> contradict my request for an implied `: undefined`. Moreover, this code
> sample I gave is only one such example. If it irks you that much, I'm sure I
> could find other examples to illustrate. But, I'm not really sure how that
> helps or hinders the process.
No, people do not risk converting undefined to NaN (to 0). It's true that var
hoisting means undefined inhabits the type of all vars, but unless yo use an
uninitialized var, that's not an issue.
>> If any consumer fails to discriminate using typeof, they'll get undefined
>> which coerces to NaN as number (to 0 as integer). Bad times.
>
> First of all, I'm talking about code where I am the consumer, so I take care
> to make sure the proper checks are done.
Why don't you set doX (or just x) to the minimized value you want?
> Secondly, criticizing the pattern as a substitute for criticizing the
> idea/proposal is a non sequitur, or orthogonal at best.
A hazardous pattern is no argument for syntactic sugar. At best you have a
minority use-case. At worst, it's a latent bug. Why should we add amgiguous
sugar for this?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
