Re: Euphoria features
On Mon, 15 Nov 1999 12:16:24 -0600, Kat <KSMiTH at PELL.NET> wrote:
>> >Ralf Nieuwenhuijsen
>>
>Eu currently stores program flow, it can continue to do that, backtracing
>that store as needed.
But, it is not implicit to the flow of the program. When I code a procedure
or a function I know where control will return. When I goto, that is lost.
>>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.
The need for status or state variables cannot be obviated by goto's. In
fact, the lack of current state information causes more program error
in interactive situations than almost any other cause. The same window
create routine may function in a variety of situations, but when it comes
time to delete or alter that window, I'd better have current state information
on it and any windows that it is related to or touches. Trying to manage
"state" or status by carefully crafted goto's that take me out of the
logical dead-ends that I have programmed, is about as error prone as
anything that I can think of. Status information "flattens out" the code
model and allows state or status switching by allowing the storing of one
set of status information and the fetching of another.
>>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
Gee, and that is just what I thought a label was, "a memory pointer...set
by the interpreter/compiler". I reiterate. Routine_id() is just a goto in
sheeps clothing...and just as messy.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
