g-rh@cca.CCA.COM (Richard Harter) (05/09/88)
In article <4627@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes: >In article <27568@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: >>Goto logic says leave and don't come back. >Not true. For example: > FOO: goto FOO; You misapprehend. This is not an example of 'goto' logic -- it is an implementation of a simple loop using goto's. >Goto logic says you can come here anytime you need to and from anywhere you >want to (within limits, of course). Well, this is a matter of terminology -- what precisely does one mean by the phrase 'goto logic', which is actually a neologism. Since I coined the phrase, I will claim priority and say it is my definitions that should be used :-). Seriously, however, your definition is not of much use, because what you say is true of procedure calls also. The difference is: Procedure logic: Record where you are now, transfer to a labelled block (called a procedure) and transfer back to the recorded transfer point upon completion of the block. Goto logic: Do not record where you are now; simply transfer to a labelled block (no standard name). Determine within the block the next block to be executed. The essence of 'goto logic' is that there is no return point to return to. In theory, procedure logic is stronger than simple goto logic, i.e. you can simulate an N statement program which uses gotos but not procedures with an O(N) statement program using procedures but no gotos, said procedure using program running in O(the execution time of the original program). Conversely there are programs using procedures which cannot be replaced by a program only using gotos without paying a penalty either in space or time. [The reason for this is that the return is actually a 'computed goto' which is stronger than the simple goto.] >>The prescription against goto's really means -- don't mix >>the two types of structure. >I think I agree with you (I'll have to ponder this a little while longer). It is worth mentioning that the reason for the stricture is that in 'goto logic' all control is at the same level. In truth, most real examples of goto logic are actually embedded goto logic, where there is a remembered return point that any 'goto block' can exit to. I.e. you put a state machine inside a block and exit the state machine by exiting the block. I have added comp.lang.misc to the group list and have directed followups there, because this is no longer particularly a C topic. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
nevin1@ihlpf.ATT.COM (00704a-Liber) (05/12/88)
In article <27744@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: |Procedure logic: Record where you are now, transfer to a labelled block |(called a procedure) and transfer back to the recorded transfer point upon |completion of the block. |Goto logic: Do not record where you are now; simply transfer to a labelled |block (no standard name). Determine within the block the next block to be |executed. The essence of 'goto logic' is that there is no return point to |return to. Given this I pose a question: which branch of logic, procedure or goto, do things like for loops and while loops fall under? They seem to be a little of both. | In theory, procedure logic is stronger than simple goto logic, i.e. |you can simulate an N statement program which uses gotos but not procedures |with an O(N) statement program using procedures but no gotos, said procedure |using program running in O(the execution time of the original program). Yes, but in practice it takes a little more time to perform procedure logic than goto logic, since some data (the return point) has to be recorded. |Conversely there are programs using procedures which cannot be replaced by |a program only using gotos without paying a penalty either in space or time. Only because in this case you have to explicitly store some data. If you make the assumption that it takes 0 seconds to store a value (this is the assumption that you made when you stated that there is no penalty for simulating goto logic with procedural logic), goto logic will NOT pay a penalty in either space or time. I think that goto logic with storage can be shown to be equivalent to procedure logic. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
g-rh@cca.CCA.COM (Richard Harter) (05/12/88)
In article <4726@ihlpf.ATT.COM> nevin1@ihlpf.UUCP (00704a-Liber,N.J.) writes: >In article <27744@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: ... Defintions deleted ... >Given this I pose a question: which branch of logic, procedure or goto, do >things like for loops and while loops fall under? They seem to be a little >of both. Procedure logic -- the loop considered as a block, has a return point (next statement to be executed after the block) associated with... ... re simulating gotos with procedures, he observes that procedure calls are more expensive. Quite true. However this cost is a fixed cost, i.e. the equivalent program will be slower, at most, by a fixed constant of proportionality. The rate of slowdown is independent of program size or execution time. >|Conversely there are programs using procedures which cannot be replaced by >|a program only using gotos without paying a penalty either in space or time. >Only because in this case you have to explicitly store some data. If you >make the assumption that it takes 0 seconds to store a value (this is >the assumption that you made when you stated that there is no penalty for >simulating goto logic with procedural logic), goto logic will NOT pay a >penalty in either space or time. I think that goto logic with storage can >be shown to be equivalent to procedure logic. Actually you are mixing two different constructs, 'goto to a prespecified address' and 'goto a computed address'. The key point is whether you can change the place that the goto transfers to during execution. The order of strengths is fixed goto procedure call/return computed goto The reason that you can't emulate procedures with fixed gotos with constant cost is that the return can go back to many places. Since any program has a finite number of places that a procedure can return to you can emulate this with a decision tree; however the cost of executing the tree increases with program size (actually number of return points.) On the other hand procedure call/return is not as strong as computed goto (transfer to stored address which may be altered.) The proof is a little tricky; however the fundamental point is that the call part is a transfer to a fixed address. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.