'function *' is not mandatory

Yuichi Nishiwaki yuichi.nishiwaki at gmail.com
Sat Aug 31 16:27:35 PDT 2013

You say the things get worse because introducing yields causes a probem
that another parameter -- when to call a certain code block -- might be
added at the time when readung the code, but I don't agree. There is
already a parameter for code reading: how many times the code will be
executed (or in short, whether the code is run, 0 or 1).

Whenever you read the code you have to read until you come across the
first, assumed to be executed when passed the arguments you want do at the
time, return statement to know what will happen when you invoke the
function, and this is the same case to yields.  You need to take care of
the timing only after that.
On Sep 1, 2013 7:48 AM, "Mark S. Miller" <erights at google.com> wrote:

> 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/20130901/b05e4d14/attachment.html>

More information about the es-discuss mailing list