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" <[email protected]> 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 < > [email protected]> 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" <[email protected]> wrote: >> >>> On Sat, Aug 31, 2013 at 2:12 PM, Yuichi Nishiwaki < >>> [email protected]> 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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
