Re: Euphoria features
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 1:56 PM
Subject: 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.
You don't return from a goto,,, if you did, that would be a gosub, which we
call "calling a function/procedure". A goto limited in scope to the function
it resides in will still return from that function in the manner that
function returns now. If you are coding tracking vars, and you want out of a
routine with your tracking vars intact/updated , then goto :eoThatFunction,
and play with the tracking vars there at the end of the function, before the
actual end.
> >>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.
If you don't need them except for getting out of loops the current messy way
we *must* use occasionally ( a la Ralf ) , then that's all the more vars we
need not code.
>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.
How is how Eu/you store window info related to a goto in the program *flow*
? A goto has nothing to do with the state of events that call the windoze
api for windows. A look into the assy code for a goto in the pascal
debugger shows a straight translation from the script language to a goto
assy language equivalent. And when my code is done processing, and there is
no more to do, i'd really like to stop processing it and goto the end of
that processing section.
> Gee, and that is just what I thought a label was, "a memory pointer...set
> by the interpreter/compiler".
The label is the memory location pointed to by the goto.
>I reiterate. Routine_id() is just a goto in
> sheeps clothing...and just as messy.
But a goto target is not a routine. Routines should not be goto-able.
Whether or not a goto can hit a forward target or not, it should still be
limited in scope to the current function/procedure, and hit no targets
outside that block. A goto in main should not hit a target in a
function/procedure, and vice versa.
Kat,
thinking this topic has been covered pretty well now.
|
Not Categorized, Please Help
|
|
