Re: EOF and GOTO and 0th array element
On 0, Juergen Luethje <jluethje at gmx.de> wrote:
>
> Hello Derek,
>
> Derek <ddparnell at bigpond.com> wrote:
>
> <snip>
> > I will argue against the "exit n" idea for a number of reasons.
> >
> > The first reason is that over time, the value of 'n' might change as
> > modifications change the nesting level of the 'exit' statement. This means
> > that one would have to examine, and possibly update, all the 'exit n'
> > statements whenever you add or remove a loop block. Instead of 'exit n', I
> > would suggest that 'exit name' is a safer and less maintenance intensive
> > alternative. The reason being that the name (which can only be attached to
> > the start of a loop block), does not change when one adds and deletes loop
> > blocks. Thus any reference to the name does not have to be examined. Another
> > reason I prefer this is that a descriptive name can aid the reader as to
> > what the code is trying to do, whereas a number doesn't do this.
> >
> > So in summary, I propose that the syntax for 'while' and 'for' loop blocks
> > be changed to ...
>
> > [<NAME>:]while <BOOLEANEXPR> do <STATEMENTS> end while
> > [<NAME>:]for <FORCONTROL> do <STATEMENTS> end for
>
> > and the <STATEMENTS> may include one or more ...
> > exit [<NAME>]
> > where if no name is specified, the loop block that the exit is in is
> > terminated. If a name is specified, the named loop block is terminated. If
> > there is no loop block thus named, an error is generated.
>
> Now, having read your explanations, and having thought about the problem
> more in depth, I'm convinced that your proposal for enhancement of the
> exit statement is really better than "exit n".
>
Goto could be used for the same purpose.
> > I refer to this idea as a controlled GOTO. Firstly, it must be mentioned
> > that the existing 'exit' statement is also a controlled GOTO. It passes
> > control to the end of a loop block. It is controlled in the sense that the
> > target of the exit is not any arbitary line of code. It is ALWAYS the first
> > line after the loop block. My proposal is no different in concept. Control
> > is always passed to the first line of code after the named loop block.
>
> Well, in this sense, even an "if/end if" statement could be called kind
> of "goto". That's not what I meant. My previous remarks about GOTO were
> only meant to refer to the explicit GOTO statement, that is provided by
> BASIC and other languages, and that obviously some people would like to
> see in Euphoria.
>
> <snipped in agreement>
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. 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.
>
> >> <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]
>
> > Hey, if the Master says so, its okay by me too! :) Notice though that the
> > idea of "arbitrarily many levels of control" is not necessarily expressed in
> > terms of Number of Levels.
>
> I wrote this quote as an argument against the GOTO statement (in the
> sense I explained above), not as an argument against your "enhanced exit"
> proposal.
>
If used in a limited fashion, goto works fine with easily-readable
code.
(i.e. used only to exit loops (entering would be too tricky) 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.)
> > ----------------
> > cheers,
> > Derek Parnell
>
> Thank you for your comprehensive reply.
>
> Regards,
> Juergen
>
I think that all features should be implemeted, 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. 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
--
|
Not Categorized, Please Help
|
|
