Short Comparing proposal

Wed Feb 1 19:18:19 UTC 2017

This is an interesting concept, but reuse of ()'s and : will make it
difficult to pin down, scale to other operators and communicate.  Really
the "inclusion" operator needs to be something that stands out, doesn't
break existing spec, and won't kill new specs.  Excuse my poor concept
below, as it probably breaks existing spec.

if(x == ${(A || B) && C})

Reusing the template string format RHS to specify the basics is bad, but my
brain won't give me another valid option.  This allows you to also do
complex logic in RHS and LHS comparison.

On Wed, Feb 1, 2017 at 1:06 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> Interesting. Would it play well nested too?
>
> ```js
> if (x === 2 || (x === 3 && y === 1));
>
> // as
>
> if (x === (|| 2, (&& 3, y === 1)))
> ```
>
> ?
>
>
> On Wed, Feb 1, 2017 at 6:22 PM, T.J. Crowder <tj.crowder at farsightsoftware.
> com> wrote:
>
>> The chief advantage I see to doing this with syntax is
>> short-circuiting. Otherwise, you could use a helper function to
>> achieve `if (valueIn(object.property.secondProp, 'a', 'b'))` quite
>> readily. Short-circuiting makes this interesting, though I worry about
>> it pulling its syntactic weight.
>>
>> If the mechanism did short-circuiting (lazy evaluation), then this
>> (using your syntax for now)...
>>
>> ```js
>> if (object.property.secondProp === (foo() : bar())) {
>>     // do something
>> }
>> ```
>>
>> ...wouldn't call `bar` if the if the property's value matches the
>> return value of `foo` (just like `x === foo() || x === bar()`
>> wouldn't).
>>
>> That being the case, the syntax would have to be visually distinct
>> from an array (as yours is) to avoid confusion, while still supporting
>> arbitrary expressions and, ideally, spread syntax.
>>
>> I notice that you've used a relational operator (strict equality, in
>> this case) and then special syntax following it, rather than (say) `if
>> (x anyof ('a', 'b'))`. Is it your intention that other operators would
>> work with it too? `if (x > (a : b : c))`? (Rather than `if (x > a || x
>> > b || x > c)` or `if (x > Math.min.call(Math, a, b, c))`.)
>>
>> Also, you've used `||` in your example. What about `&&`? Suppose I
>> want to make sure that `x` is greater than all three values in `a`,
>> `b`, and `c`? I wonder if we could keep the syntax general enough to
>> handle both cases.
>>
>> On syntax: I'm with Ryan about not being keen on the `(x : y : z)`
>> syntax. Also, given that the values could be arbitrary expressions
>> nested arbitrarily deep, it seems like the `:` after the first value
>> is a bit late to be telling the parser what's going on. I wonder if we
>> could do it earlier. (Also, `:` isn't a natural list delimiter to my
>> mind...)
>>
>> Hmmm, taking the `||` vs. `&&` into it, one idea would be to put the
>> logical operator immediately (other than whitespace) following the
>> opening paren:
>>
>> ```js
>> if (x === (|| 'a', 'b')) {
>> ```
>>
>> Equivalent to (but x is only evaluated once):
>>
>> ```js
>> if (x === 'a' || x === 'b')
>> ```
>>
>> and
>>
>> ```js
>> if (x > (&& foo(), bar())) {
>> ```
>>
>> Equivalent to (but x is only evaluated once):
>>
>> ```js
>> if (x > foo() && x > bar())
>> ```
>>
>> (Starts feeling a bit like Lisp.)
>>
>> I can't help but think: At a high level, operators are just functions
>> with special syntax, multiple dispatch, and lazy operand evaluation.
>> Setting aside the multi-dispatch aspect, what if we...had a way to
>> lazily evaluate function arguments? It sounds simple, but it gets
>> complicated *fast* for situations like this where the argument list
>> varies in length. But potentially quite powerful, and plays into
>> [operator overloading](https://esdiscuss.org/topic/operator-overloadin
>> g-proposal)
>> should that happen...
>>
>> -- T.J.
>>
>> On Wed, Feb 1, 2017 at 5:50 PM, kdex <kdex at kdex.de> wrote:
>> > I actually don't think this is worth pursuing, as it can easily be
>> > implemented
>> > by libraries once we solve operator overloading, without adding new
>> syntax:
>> >
>> > ``
>> >   if (1 < [2, 3])
>> > ``
>> >
>> > Am 01.02.2017 um 18:12 schrieb Ryan Birmingham:
>> >
>> > I have a handfull of questions on this proposal as well:
>> > How would your proposal look with three or four things to check against?
>> > Would the collection of things to check against be a variable?
>> > Would this be syntactic sugar to the array includes method, or would
>> this be
>> > something entirely new?
>> >
>> > -Ryan Birmingham
>> >
>> > On 1 February 2017 at 12:03, Felipe Nascimento de Moura
>> > <felipenmoura at gmail.com> wrote:
>> >>
>> >> I see...
>> >> we could perhaps think on some other approach.
>> >>
>> >> What about:
>> >> if (obj.prop.prop ?== 'a' : 'b')
>> >>
>> >> This way, we have "?==", which is not too chocking once we already got
>> >> "!==", and this kinda prepares the engine to deal with the next values
>> as
>> >> part of the comparison.
>> >> Also, feels familiar due to " something ? 'a' : 'b' "
>> >>
>> >> Personally, I don't feel that comfortable with this syntax.
>> >> We could think on different a token as well
>> >>
>> >> if (obj.prop.prop === (? 'a' : 'b')) // feels like a ternary, but
>> without
>> >> the first statement
>> >> if (obj.prop.prop === ('a'  | 'b'))) // could break the web once it is
>> >> already valid syntax (although not very used)
>> >> if (obj.prop.prop === ('a' :: 'b')) // perhaps a double colon
>> >>
>> >> Anyways, open for suggestions :)
>> >>
>> >>
>> >>
>> >>
>> >> On Wed, Feb 1, 2017 at 2:48 PM Ryan Birmingham <rainventions at gmail.com
>> >
>> >> wrote:
>> >>>
>> >>> I like the idea, and I generally agree that your proposal would
>> increase
>> >>> readability, but I'm not a fan of the colon in parenthesis.
>> >>> In this context, the colon looks like it should represent a member
>> >>> assignment of 'b' to 'a'.
>> >>>
>> >>>
>> >>> -Ryan Birmingham
>> >>>
>> >>> On 1 February 2017 at 11:27, Felipe Nascimento de Moura
>> >>> <felipenmoura at gmail.com> wrote:
>> >>>>
>> >>>> Hi.
>> >>>>
>> >>>> I wonder if there is already a proposal for such thing or if it
>> would be
>> >>>> something interesting to be proposal:
>> >>>>
>> >>>> The motivation:
>> >>>> Let's say you have an object whose property you want to compare to
>> 'a'
>> >>>> or 'b':
>> >>>>
>> >>>> ```
>> >>>> if (object.property.secondProp === 'a' || object.property.secondProp
>> ===
>> >>>> 'b') {
>> >>>>   // do something
>> >>>> }
>> >>>> ```
>> >>>>
>> >>>> The proposal:
>> >>>> Now, with this syntax you would be able to perform such comparisons
>> in a
>> >>>> much simpler, better to read approach:
>> >>>>
>> >>>> ```
>> >>>> if (object.property.secondProp === ('a' : 'b')) {
>> >>>>     // do Something
>> >>>> }
>> >>>> ```
>> >>>>
>> >>>> And with the advance of the Optional Chaining Operator proposal, it
>> >>>> would get even better, like so:
>> >>>>
>> >>>> ```
>> >>>> // this:
>> >>>> if (object &&
>> >>>>     object.property &&
>> >>>>     (object.property.secondProp === 'a' ||
>> >>>>     object.property.secondProp === 'b')) {
>> >>>>   // ...
>> >>>> }
>> >>>>
>> >>>> // becomes this:
>> >>>> if (object?.property?.secondProp === ('a' : 'b')) { ... }
>> >>>> ```
>> >>>>
>> >>>> Alternatives:
>> >>>> I do know that we could accomplish that with other techniques, like:
>> >>>>
>> >>>> ```
>> >>>> ['a', 'b'].includes(object.property.secondProp)
>> >>>> ```
>> >>>>
>> >>>> I just think it might be counterintuitive and having a syntax for a
>> >>>> "short comparing" would be better for reading and understanding.
>> >>>>
>> >>>> Would make ternary comparison even shorter, too:
>> >>>>
>> >>>> ```
>> >>>> let currentState = object.property.status === ('fail' : 'ok') ?
>> 'done' :
>> >>>> 'doing'
>> >>>> ```
>> >>>>
>> >>>> Please let me hear your thoughts on that :)
>> >>>>
>> >>>> Regards.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> es-discuss mailing list
>> >>>> es-discuss at mozilla.org
>> >>>> https://mail.mozilla.org/listinfo/es-discuss
>> >>>>
>> >>>
>> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170201/21b057ab/attachment.html>