Re: Euphoria features
- Posted by Kat <KSMiTH at PELL.NET> Nov 15, 1999
- 609 views
----- Original Message ----- From: Everett Williams <rett at GVTC.COM> To: <EUPHORIA at LISTSERV.MUOHIO.EDU> Sent: Monday, November 15, 1999 11:34 AM Subject: Re: Euphoria features > On Mon, 15 Nov 1999 08:59:35 +0000, nieuwen at XS4ALL.NL wrote: > > >Lucius, goto's _are_ effective .. > >One out of 10, maybe 15 algorithms I use, depends on flag variables to jump out of multiple > >levels of a loop. Now that's messy. > > > > >Ralf Nieuwenhuijsen > > Ralf, > > Those flag variables, if named something explanatory provide status > information that is most valuable, specifically in debugging or influencing > the code to be performed at the target of the goto. My favorite is a > depth variable for recursive code. A var you coded yourself, or the for/while vars? I addressed the for/while vars earlier. You can do the tracing vars you write now, if you do, as you do now. >The other problem with goto, is that it > is a tailless kite. It provides no pointer to it's source once it gets where > it is going. Eu currently stores program flow, it can continue to do that, backtracing that store as needed. >I suspect that because of the violence done to block structures > and the loss of state information(currently, in Euphoria, you are always > in the main line, or in a procedure or function stack that leads back to > the main line), the overhead alone will prevent the use of goto's if > Robert is foolish enough to resurrect this long-dead canard for those > who haven't learned how to structure their logic yet. I know how to build up a huge pile of procedures, calling them as needed with if statements, using global vars to pass back flags about whether to call the next procedure, etc., and i consider that worse than any block-scope-limited goto could ever be. It's more code, more overhead, and harder to debug. I agree with Ralf on this one. Gimme a goto. >By the way, > routine_id() with call...call_back is a goto with many of the same effects. Routine_id() should be only setting a memory pointer before it is normally set by the interpreter/compiler. No harm in that. In fact, if it's not done, how can you have two functions call each other? Kat