Re: goto: it's conceded
On Sunday 01 June 2008 4:21:05 am Derek Parnell wrote:
> its so nice to hear from you again. Hope things have been going well for
> you.
Yes, I've been busy!
> Your right about that. The reason we haven't got GOTO as I write this is
> because everything takes time and nothing happens just by saying "I want".
OK. I've been following a number of threads, and perhaps what I've inferred
from responses isn't the case. My apologies.
I have great respect for the constraints you're under.
> It baffles me as to where this idea comes from, because if one actually
> follows both the conversations AND the actual work being done, it can lead
> to a much better understanding of where things are really going with v4.0.
I apologize. I've not had time to play with Euphoria recently.
> Firstly, this looks like a handy thing to have. I don't remember having
> seen this construct before. I assume the index value is still in scope for
> the 'else' block to use.
To my understanding, no. You've exhausted the loop and fallen through, so the
index value is out of scope.
> And if they do exist, they are exceptionally ineffectual
> because there are quite a few neat syntax sugarary bits coming our way.
Groovy.
> I believe GOTO, by necessity, adds to the maintenance overhead of any
> program it is used in. The amount of increase varies but it is always an
> increase. Therefore, if I am ever being asked to work on maintaining such
> code, I will need to have the use of GOTO justified to me before I could be
> comfortable with it. The most obvious justification would be in the area of
> performance, such that by using GOTO the improved performance is practical,
> necessary and can only be achieved via GOTO usage.
Well, sometimes you're nested deep, and you need to get out. Implementing it
without GOTO is messy and error prone. With GOTO, it's clear what's happening
and it executes as expected.
> Ok, there are limitations to that concept but in general, I agree. For
> example, having built-in matrix operations ala FORTRAN would be useful to
> quite a few people, but that might have to wait awhile before getting in
> Euphoria. In the meantime, a library solution will be used.
Fair enough.
> I'd rather you didn't. You skills are needed in helping improve Euphoria.
> Why don't you join us in working on the beast.
I'd love to, but at the moment I'm neglecting to work on my own programming
language so I can work on a 3d Reyes-style renderer. And yet again, the sky
is starting to brighten outside, and I still haven't gotten any sleep.
If only there were more hours in the day!
-- David Cuny
|
Not Categorized, Please Help
|
|
