On 11/15/2013 06:18 PM, Claude Pache wrote:
>
> Le 15 nov. 2013 à 17:59, Rick Waldron <waldron.rick at gmail.com
> <mailto:waldron.rick at gmail.com>> a écrit :
>
>>
>> On Fri, Nov 15, 2013 at 11:34 AM, Axel Rauschmayer <axel at rauschma.de
>> <mailto:axel at rauschma.de>> wrote:
>>
>>     (...)
>>
>>     That would make the async programming code more compact, too (I’m
>>     assuming a nullary paren-free arrow variant and I prefer the
>>     asterisk after the arrow):
>>
>>
>> To be clear, this preference is inconsistent with all other generator
>> forms where the asterisk is before the params, per Brandon's original
>> examples.
>
> The other point of view is that this preference is consistent with
> other generator forms where the asterisk is after the token that
> defines the general role of the construct as a procedure (either the
> `function` keyword, or the `=>` token). Personally, I tend to read
> `function*`as a unit meaning "generator function", and so would I for
> `=>*`.
>
There is one reason (that is beyond bikeshedding) why I think the star
should be together with the arrow. (I have no opinion whether it should
be before or after the arrow though)

Its harder to scan whether this is a generator arrow function or a
normal arrow function because the star is too far away:

    someFunction(*(someArgument, anotherArgument) => {
        ... code ... 
    });

compared to this form, where its immediately obvious that this is not a
regular function, just by looking at the composed symbol (arrow-star)

    someFunction((someArgument, anotherArgument) =>* {
        ... code ... 
    });


The arbitrary length of arguments, as well as the ability to split them
to multiple lines makes it potentially even harder to reliably locate
the star:

    someFunction(*(argument,
                              anotherArgument,
                              somethingThird) => {
                                  ... code ...
    });

vs

    someFunction((argument,
                             anotherArgument,
                             somethingThird) =>* {
                                  ... code ...
    });

Here is the single-argument example, for completeness:

    someFunction(*singleArgument => yield asyncOp(singleArgument));

versus

    someFunction(singleArgument =>* yield asyncOp(singleArgument));

in which it looks like the star is somehow related to the argument.

If you're not convinced, you can try to find all the arrow-stars in the
above code, then try to find all the arrows and determine whether
they're generator arrows or regular arrows :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131118/6b1f7a31/attachment-0001.html>

On 11/15/2013 06:18 PM, Claude Pache wrote:
> The other point of view is that this preference is consistent with
> other generator forms where the asterisk is after the token that
> defines the general role of the construct as a procedure (either the
> `function` keyword, or the `=>` token). Personally, I tend to read
> `function*` as a unit meaning "generator function", and so would I for
> `=>*`.

There is one reason (that is beyond bikeshedding) why I think the star
should be together with the arrow. (I have no opinion whether it should
be before or after the arrow though)

Its harder to scan whether this is a generator arrow function or a
normal arrow function because the star is too far away:

    someFunction(*(someArgument, anotherArgument) => {
        ... code ... 
    });

compared to this form, where its immediately obvious that this is not a
regular function, just by looking at the composed symbol (arrow-star)

    someFunction((someArgument, anotherArgument) =>* {
        ... code ... 
    });


The arbitrary length of arguments, as well as the ability to split them
to multiple lines makes it potentially even harder to reliably locate
the star:

    someFunction(*(argument,
                              anotherArgument,
                              somethingThird) => {
                                  ... code ...
    });

vs

    someFunction((argument,
                             anotherArgument,
                             somethingThird) =>* {
                                  ... code ...
    });

Here is the single-argument example, for completeness:

    someFunction(*singleArgument => yield asyncOp(singleArgument));

versus

    someFunction(singleArgument =>* yield asyncOp(singleArgument));

in which it looks like the star is somehow related to the argument.

If you're not convinced, you can try to find all the arrow-stars in the
above code, then try to find all the arrows and determine whether
they're generator arrows or regular arrows :)