'function *' is not mandatory

Mark S. Miller erights at google.com
Sat Aug 31 17:55:21 PDT 2013

I think you miss my point, or I miss your's. I am not talking about how
many times the code runs or even whether the code runs at all. I thought I
made that clear. I am talking about whether the code in the callee
activation runs *after* the caller resumes.

Allen clearly and separately makes the same point.

Brendan, your response to Allen & I, citing Yuichi, misses this point as

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

> 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
> _______________________________________________
> 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/20130831/77f7705e/attachment.html>

More information about the es-discuss mailing list