Re: voting on GOTO
Chris Bensler wrote:
>
> What could you do with a goto that could not be done otherwise? Optimization
> is not a good enough reason, since I doubt there would be very much
> performance
> gain if any. It may even hinder the language performance in general.
In my opinion, ANY performance gain is worthwhile, as I plan to use BBCMF
far and wide on web hosting, and the faster it is, the more users I can
accommodate.
Also, I have been assured that adding GOTO to the interpreter in no way
negatively affects its speed/performance.
I voted 'yes' on the dev list (and most devs voted yes) for two reasons:
1. I don't care if other people want to use it.
2. It doesn't negatively impact performance of the interpreter.
> Consider if goto even belongs in Eu's repertoire, regardless if it's useful
> or not, as long as we can still achieve the same thing through different
> means.
> Does it actually lend itself to Eu's characteristics? How will it affect the
> language internally?
Good questions, because where do we draw the line between usability and
performance? Right now, on the performance end of the spectrum, assembly
is the language of choice. For usability... I'd have to put Euphoria there
just because I know it and am ignorant of other competing languages. We
have to ask, at times, do we want to sacrifice usability (by which I mean
ease-of-development, ease-of-maintenance, etc.) for performance?
Because Euphoria performs so well as is, my votes will tend to be toward
usability (w/o sacrificing performance), and not toward performance (while
sacrificing usability).
> Rather than a vote, I'd suggest compiling and summarizing all the previous
> discussions
> on goto and put in an official feature request on sourceforge.
Even as a feature request, it has to be discussed and ultimately voted on. I
think you're right that this needs more discussion.
|
Not Categorized, Please Help
|
|
