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
