on goto
in [General Programming]
|
From: Richard Heathfield on 10 May 2010 12:40 Willem wrote: <snip> > > I'm not seeing any refutations here of the arguments that Seebs presented. Good spot. :-) -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Richard Heathfield on 10 May 2010 12:43 Seebs wrote: > On 2010-05-10, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >> Seebs wrote: >>> On 2010-05-10, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >>>> Yes. But, for me, SESE is idiomatic. > >>> That's not an idiom, that's a policy. > >> Yes, but it's an idiomatic policy. A high-level idiom, if you like. > > Yes. But high-level idioms don't provide the same chunking benefit that > literal idioms do. The reason to use idioms is that they convert a large > number of data into a single datum, allowing the brain to use much less > short-term memory on the idiomatic part while studying the rest. Knowing that the loop has a single exit point gives precisely this advantage. Mucked-up control flow costs computrons. >>> An idiom is a very specific way of writing a loop, > >> That definition of "idiom" is far too restrictive. For example, it >> excludes if((fp = fopen(filename, filemode)) == NULL), which is >> certainly not a very specific way of writing a loop, and yet it is most >> definitely idiomatic. > > I did not say every specific way of writing a loop is an idiom. I didn't think you did. I thought you said "An idiom is a very specific way of writing a loop". An A is a B. > An A is a B does not imply that all B are A. But it does imply that all A are B - to avoid this, it would have to be phrased along the lines of "An A is a B /unless/..." or "An A is a B /except/...". <snip> -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Seebs on 10 May 2010 13:03 On 2010-05-10, Richard Heathfield <rjh(a)see.sig.invalid> wrote: > Seebs wrote: >> Yes. But high-level idioms don't provide the same chunking benefit that >> literal idioms do. The reason to use idioms is that they convert a large >> number of data into a single datum, allowing the brain to use much less >> short-term memory on the idiomatic part while studying the rest. > Knowing that the loop has a single exit point gives precisely this > advantage. No, it doesn't. It's a higher-level cognitive advantage. It certainly provides one, but it doesn't provide pure chunking, because chunking only seems too work for statically-defined things -- you can chunk a loop control that's always the same control, but you can't chunk the general category of exit conditions. At least, most people can't. :) > Mucked-up control flow costs computrons. It does, but "this loops over the array" is simple enough to be a win anyway in most cases. >>>> An idiom is a very specific way of writing a loop, >> >>> That definition of "idiom" is far too restrictive. For example, it >>> excludes if((fp = fopen(filename, filemode)) == NULL), which is >>> certainly not a very specific way of writing a loop, and yet it is most >>> definitely idiomatic. >> >> I did not say every specific way of writing a loop is an idiom. > > I didn't think you did. I thought you said "An idiom is a very specific > way of writing a loop". An A is a B. .... Ahh! Sorry, I missed a 'not', and was very confused. And yes, it was too restrictive; not all idioms are loops. But an idiom is nonetheless a very specific and literal construct, not a general pattern or rule. The cost in computrons of ANY loop condition you have to think about or evaluate in any way is much, much, higher than the cost of "this loops over the contents of A". In general, SESE requires more computrons because it duplicates tests or conditions, or adds additional tests or conditions. Similarly: if (!x) return NULL; /* use x */ is easier than: if (x) { /* use x */ } Any time you add indentation (and thus pending conditionals) or extra tests, you cost computrons. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: James Dow Allen on 10 May 2010 13:36 On May 11, 12:03 am, Seebs <usenet-nos...(a)seebs.net> wrote: > On 2010-05-10, Richard Heathfield <r...(a)see.sig.invalid> wrote: > > Seebs wrote: > >> Yes. But high-level idioms don't provide the same chunking benefit that > >> literal idioms do. > > Knowing that the loop has a single exit point gives precisely this > > advantage. > No, it doesn't. It's a higher-level cognitive advantage. It certainly > provides one, but it doesn't provide pure chunking, because ... > you can't chunk the general category of exit conditions. > . > At least, most people can't. :) > > Mucked-up control flow costs computrons. > It does, but "this loops over the array" is simple enough to be a win > anyway in most cases. > [etc.] Well at least Heathfield and Seebs agree on *something*: We seek human cognitive advantage. The specific code being debated, IIRC, does *not* even involve goto's (*Please change the subject lines, people*), but is rather a trivial search through a 3-D array: for ... for ... for ... if ... return; In fact the code was so straightforward one might wonder why alternatives were even being proposed. I did not search the thread rigorously; I noticed one code by Nathan(?) which seemed obviously inferior. I gather C++ afficionados are proposing a new "access method" for such 3-D arrays (I find for...for...for much too easy to understand, especially since the full package will probably be doing this *many* places needfully, for an a priori unfamiliar method to be useful). Mr. Heathfield, IIRC, hasn't actually deigned to post an alternative. (Contrary to some beliefs I wrote my favorite goto in a smallish fraction of a day; to claim you don't have time to rewrite for for for if return ... well... :-) The thread title is "Goto" but break, inside return, and switch fallthrough suffer, to smaller extent, the same sin as goto. We read On Apr 29, 3:20 pm, Tim Rentsch <t...(a)alumni.caltech.edu> wrote: > Keith H Duggar <dug...(a)alum.mit.edu> writes: > > Subsequently I discussed that flame war with one of the worlds > > genius compiler writers who confirmed the necessity of the inlining > > etc controls explained above. However, he also added that in his > > experience it is pointless to argue with the anti-goto mob because > > it is a religion that ignores all inconvenient empirical evidence. > . > Essentially the same thing could be said of the pro-goto mob. Wrong. The anti-goto mob claims to prefer code that is clearly more complex (is Nathan's the best you have? Did you ever post your solution, Mr. H?) in order to avoid the inside return (or goto). None of us are "pro-goto" per se; we're just asking to *look at all the code and make the best trade-offs*, or select the "least of evils." It's usually better to introduce 1 or 2 boolean variables than to write goto, but what if it's 3 variables and you still need a break? What if by using switch case-fallthrough's you save the need for 5 little functions? There is no "universal demerit system" for code complications, but to assign inside-return a cost of infinity seems much too aggressive. Hope this helps, James Dow Allen
From: Daniel T. on 10 May 2010 13:46
brangdon(a)cix.co.uk (Dave Harris) wrote: > daniel_t(a)earthlink.net (Daniel T.) wrote (abridged): > > > > > Yes. It led to simple code, but that was partly because all the > > > complexity was hidden behind an iterator. > > > [...] > > > > I didn't post anymore than I did because there isn't enough context > > to tell what the best solution is. Even though .size() is checked > > at each level, there may still be an invariant such that all the > > sizes are the same. > > I would be interested in code that solved the same problem that the > original code solved. Or are you agreeing that the original code was the > best, for that problem? Can you only do better if you change the problem > by adding extra invariants? Am I adding extra invariants? I don't know what the invariants are, and I have no reason to believe that the code presented solved any problem at all. That's part of the point I'm trying to make here. We have been handed an incomplete solution to a nonexistent problem and you are asking me if I could write code that "solved the same problem..." Here you go: int main() { } My example above has the benefit of actually being able to compile and run. You can't do that with the original example. |