'function *' is not mandatory

Yuichi Nishiwaki yuichi.nishiwaki at gmail.com
Sat Aug 31 18:27:40 PDT 2013


I don't think I miss it, but the example I took was somohow bot clear. I
meant you can get to know if the code will run immediately or after the
habdle back, by reading the code in the same way as you do a normal
function.
On Sep 1, 2013 9:55 AM, "Mark S. Miller" <erights at google.com> wrote:

> 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
> well.
>
>
>
>
> 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
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130901/12e299e0/attachment-0001.html>


More information about the es-discuss mailing list