Re: EOF and GOTO and 0th array element
On 0, Juergen Luethje <jluethje at gmx.de> wrote:
<big snip>
> > Such as I. With goto, exit/continue/exit(n)/next(n) would not be
> > needed.
> > Of course, with goto, for..end for/while..end while/if..end
> > if/select..end select or even procedure..end procedure/function..end
> > function wouldn't be needed either.
>
> Right, but there has been good reasons why Rob nevertheless decided to
> implement while..end while etc. in Euphoria.
> Arguing this way, I also could say Euphoria would not be needed at all,
> because programs can be written in assembler.
Sorry, I meant to add that goto is a bad idea for replacing
for/while/if/select
(select is something else the language could use!)/procedure/function.
goto
does have its uses, but I agree that totally uncontrolled gotos can
destroy
the readability of the code.
<big snip>
>
> The bottom line is, that GOTO is a low level statement, for which there
> is no place in a high level language like Euphoria. High level languages
> should encourage structured programming and structured thinking.
> GOTO doesn't do that. GOTO isn't necessary in a high level language such
> as Euphoria, but GOTO has the potential to produce "logical spaghetti",
> which will lead to less readable and less maintainable code.
> If I want to do low level coding, I'll do it in assembler -- it is much
> fun for me, I don't know a better low level language, and I can do as
> much conditional and unconditional jumps as I like. 
But I like
> Euphoria, because it is a high level language. And I would like it to
> remain a high level language.
>
> > My proposal: implement goto and goto-alternatives, and then let
> > the community decided which style is best by seeing which one is used
> > more often.
>
> "best" and "most often" aren't synonyms, unfortunately things are more
> complicated ...
> There are fairly enough other languages that provide GOTO. Why not keep
> at least one high level language clean?
>
My point is that the programmer should be able to decide whats best,
and not
the program language writter. Not to say I don't understand your
viewpoint
(I have also witnessed the uncontrolled goto spining out of control),
one
compromise would be to create a lgoto which can only be used to jump
out
of loops via labels, but thats exactly what the exit name statement
does.
Personally, I'd like to be able to choose which style I want on a whim,
but thats just my opinion.
> >>>> <quote>
> >>>> Many authors have suggested language features [...]
> >>>> which are expressed in terms of *exit*, *jump-out*,
> >>>> *break*, or *leave* statements. Kosaraju [57] has
> >>>> proved that such statements are sufficient to
> >>>> express all programs without *go to*'s and without
> >>>> any extra computation, but only if an exit from
> >>>> arbitrarily many levels of control is permitted.
> >>>> <unquote>
> >>>> [Knuth, Donald E.: Structured Programming with go to Statements.
> >>>> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
>
> <snip>
>
> > If used in a limited fashion, goto works fine with easily-readable
> > code.
>
> This is often said in this context. The decisive word is *if* ...
> After (not only) my experience, this is just a theoretical consideration.
> In practice, GOTO is *not* used in a limited fashion in (far too) many
> programs. I say this after having read *megabytes* of BASIC source code.
>
> > (i.e. used only to exit loops (entering would be too tricky)
>
> In a high level programming language, *structured* statements should be
> used for that purpose.
>
> <quote>
> What we really want is to conceive of our program in
> such a way that we rarely even /think/ about *go to*
> statements, because the real need for them hardly ever
> arises. The language in which we express our ideas has
> a strong influence on our thought processes. Therefore,
> Dijkstra [23] asks for more new language features --
> structures which encourage clear thinking -- in order
> to avoid the *go to*'s temptations toward complications.
> <unquote>
> [Knuth, Donald E.: Structured Programming with go to Statements.
> Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-301]
>
> This was written in the 70's of the last century. Now we have modern
> languages such as Euphoria.
> And now, in our beloved elegant high level modern programming
> language, which encourages structured programming, you want to
> introduce this unstructured low level statement GOTO.
> I simply cannot understand why. There is no need for it.
> (Well, maybe so long as there is no enhancement of Euphoria's exit
> statement, there will be a little need. But the consequence should be
> to enhance the exit statement, not to introduce GOTO.)
>
> > and not to replace loops or if/switch statements or routines or any of
> > the stuff which should be seperated to be made more readable.)
>
> <snip>
>
> > I think that all features should be implemeted,
>
> I disagree. Anything that is not necessary one the one hand, and has
> the potential to cause harm one the other hand, should *not* be
> implemented.
>
As of version Eu 2.3, goto or some alternative is necessary. And while
goto can create spagetti coding (I op for restricting use to routines
if this
is too big a problem, and this reduces the spagetti to procedures and
functions
only), I doubt very few people on this list would use it to do more
than
jump out of loops or to replace recursive routine calls.
> > and that the programmer
> > should choose one's own style from there. (Of course Rob would never
> > agree to that, and I am better at Euphoria than I am with C, so I continue
> > to write preproc to get around this limitation.
>
> Well, if you consider the lack of GOTO as a limitation, I can understand
> you, of course. For me this is not a limitation. I've been programming
> in PowerBASIC for about 10 years, there is GOTO of course.
> I simply never needed it.
>
I've needed it only on a few occasions, for jumping out of multiple
loops easily, and for speeding up recursive functions (in C mind you,
I've had to do without in Euphoria). But it is those few occasions
where
it does provide usefulness. I'm not trying to completely advocate goto,
but
mere propose it as an alternative.
> > And yes, writing a preproc to implement the goto statement is possible
> > (which I did with rparse, and David Cuny did with ebasic), although the
> > converted code is so messy it is a terrible idea.)
>
> > jbrown
>
> Just my 2 Euro cents.
>
> Best regards,
> Juergen
>
jbrown
--
|
Not Categorized, Please Help
|
|
