On Sat, Aug 31, 2013 at 2:12 PM, Yuichi Nishiwaki <
yuichi.nishiwaki at gmail.com> wrote:

> 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?
>


  function f(....) {
    // .... code sequence 1

    // .... balanced code sequence 2

    // .... code sequence 3
  }

Without looking at f's parameters, code sequence 1, or code sequence 3, the
reader knows that code sequence 2 will execute some number of times,
perhaps 0, only during the turn in which f is called and before f returns.
Once f's caller gets control again, code sequence 2 will no longer ever
execute as part of that call to f.  The only contextual knowledge the
reader needs in order to know this is that there are no intermediate
function definitions within f wrapping code sequence 2 -- i.e., that code
sequence 2 is code of the function f itself, as opposed to code of a
function within function a. It suffices to check that there are no
unbalanced function definition starts in code sequence 1. Beyond this "is
it wrapped in a function" question, the reader doesn't even care if code
sequence 1 starts a control structure wrapping code sequence 2, that is
closed in code sequence 3.

If the header says |function*|, then the reader knows that they do not know
all this, and a more careful read is needed to understand when code
sequence 2 might execute as part of a given call to f after f's caller
resumes.

See <http://erights.org/data/irrelevance.html> on the need to do partial
reasoning about code fragments. I find it frustrating that there so little
computer science devoted to the cognitive load required of such partial
program understanding tasks. This properly should be part of the study of
"notation as user interface".



> 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.
>
-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130831/8c0e21ce/attachment.html>

On Sat, Aug 31, 2013 at 2:12 PM, Yuichi Nishiwaki <yuichi.nishiwaki at gmail.com> wrote:

> 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?


```js
function f(....) {
  // .... code sequence 1

  // .... balanced code sequence 2

  // .... code sequence 3
}
```

Without looking at f's parameters, code sequence 1, or code sequence 3, the
reader knows that code sequence 2 will execute some number of times,
perhaps 0, only during the turn in which f is called and before f returns.
Once f's caller gets control again, code sequence 2 will no longer ever
execute as part of that call to f.  The only contextual knowledge the
reader needs in order to know this is that there are no intermediate
function definitions within f wrapping code sequence 2 -- i.e., that code
sequence 2 is code of the function f itself, as opposed to code of a
function within function a. It suffices to check that there are no
unbalanced function definition starts in code sequence 1. Beyond this "is
it wrapped in a function" question, the reader doesn't even care if code
sequence 1 starts a control structure wrapping code sequence 2, that is
closed in code sequence 3.

If the header says `function*`, then the reader knows that they do not know
all this, and a more careful read is needed to understand when code
sequence 2 might execute as part of a given call to f after f's caller
resumes.

See http://erights.org/data/irrelevance.html on the need to do partial reasoning about code fragments. I find it frustrating that there so little computer science devoted to the cognitive load required of such partial
program understanding tasks. This properly should be part of the study of
"notation as user interface".