Re: Euphoria features
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Monday, November 15, 1999 2:10 AM
Subject: Re: Euphoria features
> Lucius, Ralf, Kat
>
> When you goto out of a "for" or a "while", you leave the statement in
> an uncertain status if you do not go through some form of termination
> of the for or while structure, including garbage collection.
But when you leave the block that holds that procedure, everything local to
that procedure is reset anyways, and that memory is returned to the pool.
All the local vars are wiped ( or their pointers are set to null, so as to
be garbage collected ), all the global vars don't need any attention. If you
do exit a nested for loop, only to hit the outer next, you are simply
restarting that section of code. Especially if the procedure loop is
separate blocks of code that are arrived at with a gosub opcode and left by
a retsub opcode, a goto within the procedure is not a problem. The only time
it's complicated, imo, is when traversing the subroutine block boundries,,
so don't do that, as i did say before.
>Very little
> in practical reality is saved. Also, in Euphoria, I would like to know
where
> to you would go. The only thing that resembles a label or address in
> Euphoria is a procedure name. If you goto a procedure, where will you
> return to. If you goto a function name to whom will you return the value
> and where will you return to. It appears that Euphoria was designed
> to be goto proof. Now, we need not only goto's, but labels.
You do not goto a function name, you goto a target made just for the goto,
residing in the current procedure or function. In the main code block, you
can jump over function calls, but once in that function, the farthest you
can jump is to the end of that function. That's al that most people need,
it's all that i need, to stop processing when the problem is solved,, and
not at that point to begin processing exit flags in if statements. Here's an
example label--> :eoThisParagraph
> In addition, nobody has addressed my question about the scoping
> effects of gotos. When you goto from the middle of a function or a
> procedure to some other location that would normally have a
> hierarchically built scope, how do you reestablish that scope? How do
> you collapse the scope that you are leaving? Euphoria is a block
> structured language, and I imagine the interpreter is built around
> the initializing and closing of those blocks. If goto out of a block
structure
> does not close that block, what happens to it? If it does, what have
> I gained? If blocks can only be entered at the top, does Euphoria
> entirely depend on the initialization code to clear a block? Things like
> exit argue otherwise.
I answered previously! In compiled languages that don't garbage collect,
once you pop the stack at the end of the procedure to find the address you
came from, all the vars are "forgotten", and that procedure's stack is
forgotten too. I would suppose in an interpreted language, a call to a
function to set all those vars' pointers to null does the "forgetting" part,
and once set to null ( or nil or $nill or whatever ), the garbage collection
handles them normally. Consider that a part of the garbage collection in a
way, because it's done *now* anyways with loop vars when the procedure is
left, i believe, so add the local var list to that function (once we get
procedure/function local vars), since they are declared local, we know what
they are, so adding them to cleanup should not be a problem, i bet Robert
must do this anyways.
> Just a few questions to rock you to sleep with.
Sticks and rocks may,, oh, nevermind 
Kat
|
Not Categorized, Please Help
|
|
