Brian Kardell <mailto:[email protected]>
August 31, 2013 4:21 PM
On Aug 31, 2013 6:20 PM, "Brendan Eich" <[email protected]
<mailto:[email protected]>> wrote:
>
> Brian Kardell wrote:
>>
>>
>> Fwiw, just bikesheddingly speaking I actually prefer the *.
>>
>
> Let's review. Three reasons for function* syntax:
>
> 1. Opt-in required for backward-incompatible definition of 'yield'
as low-precedence unary prefix operator.
>
> 2. Zero-yield (no yield in body) basis case, useful for delegation
via yield* from another generator.
>
> 3. Decorator to alert the reader that the body contains yield
(ignoring 2 for a moment) reason.
>
> You are "bikesheddingly" supporting 3, I take it. Can you say more
about why you want a decorator for human readers? Again ignoring 2,
which makes the case based on what the JS engine must see, a more
"objective" criterion in this case (and, in a different light, in case 1).
>
> /be
Yes. I know its not especially useful
No, thanks for commenting.
and i debated sitting it out (as i often do on this list) - i think #1
stands on it own, but I felt that there was some debate about the
value of #3 which isn't for compatibility or even function but for
developers, and perhaps it might be useful to say that given the
choice between * and none, I'd prefer the visual queue
("cue" ;-)
that tells me its different with an easy scan because...It's
bikesheddy - i know but I thought it worth saying that as one of those
devs I think it has value. So if we can get 1 and 3 with a single
char... Win.
Mark makes the case for partial program understanding, so it's not just
bikeshedding. I sense people are put off by bikeshedding and sometimes
knee-jerk away from anything resembling it just because syntax is
involved, but there's more to most issues here than the color of the
paint on the bikeshed. And of course, once we have the power plant in
front of the bikeshed operating well, it's fine to argue about the best
color ;-).
/be
Brendan Eich <mailto:[email protected]>
August 31, 2013 3:19 PM
Let's review. Three reasons for function* syntax:
1. Opt-in required for backward-incompatible definition of 'yield' as
low-precedence unary prefix operator.
2. Zero-yield (no yield in body) basis case, useful for delegation via
yield* from another generator.
3. Decorator to alert the reader that the body contains yield
(ignoring 2 for a moment) reason.
You are "bikesheddingly" supporting 3, I take it. Can you say more
about why you want a decorator for human readers? Again ignoring 2,
which makes the case based on what the JS engine must see, a more
"objective" criterion in this case (and, in a different light, in case
1).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Brian Kardell <mailto:[email protected]>
August 31, 2013 3:11 PM
Fwiw, just bikesheddingly speaking I actually prefer the *.
Brendan Eich <mailto:[email protected]>
August 31, 2013 3:07 PM
Generators are a kind of factory function. When you call a generator,
you get an iterator with a bit of extra protocol (.throw as well as
.next).
No big deal, lots of API contracts are implemented by functions, you
say -- why does this one deserve special head syntax. 'return' can be
hard to spot, just as 'yield' could be hidden, in a large body -- and
return of a certain-shaped object as part of an API contract could be
even harder to discern.
In general, you have a point. Languages such as Scheme or Racket
enable their users customize built-in syntax all the time to express
contracts better, even with static syntactic checking using macros.
Even macro-less languages may have decorators (CoffeeScript's syntax
cleverly enables decorators "for free").
You might think of function* as decorator syntax. It's important,
given the 'yield' backward compatibility issue, not to make the syntax
too heavyweight. One character is as minimal as we can get.
But now I'm just shoring up the argument based on compatibility.
You'll have to get Mark or someone else to help you understand their
particular argument that the function head needs decoration to alert
the reader to the possible (not required) presence of yield in the body.
Note also the empty-body basis case -- that's a good argument for
function* independent from the backward-compatibility and
good-for-readers arguments.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Yuichi Nishiwaki <mailto:[email protected]>
August 31, 2013 2:12 PM
I get the point. Indeed. Modes are a kind of magic...
Regarding the secondary reason:
I don't understand the "difference" well, could you explain in detail?
You know, all other languages that are dynamically typed and have
generators, such as python, lua, and even JavaScript 1.8 don't
distinguish two kinds of the functions.
I guess this directly means that there isn't something different as
you said (because they all have more or less made successful).
And in my personal view, yield is something that can be generalized
together with return, like
- return: discards the succeeding partial continuation there
- yield: preserve the succeeding partial continuation there
It is very clear in a sense, I believe. So my guess is that the
strangeness yields have is a mater of getting used to, and that it is
much more natural to treat two of them as a same thing.
_______________________________________________
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
