OpenEuphoria

Re: EOF and GOTO and 0th array element

• Posted by Derek Parnell <ddparnell at bigpond.com> Aug 23, 2002
• 481 views

----- Original Message -----
From: "Juergen Luethje" <jluethje at gmx.de>
To: "EUforum" <EUforum at topica.com>
Subject: Re: EOF and GOTO and 0th array element


>
> For handling such situations more elegant, I'd like to have an enhanced
> exit-statement in Euphoria, where the numbers of levels to exit can be
> given. Then this code snippet would be as simple as:
>
> ----------------------------------------
> while 1 do
> .
> .
> --    test values; if fail, exit loop
>       for y=1 to 10 do
>            if test y fails then
>               exit 2    -- exits both the for loop and the while loop
>            end if
>       end for
> .
> .
> end while
> ----------------------------------------
>
> For instance, PowerBASIC has a similar feature (One has to write
> "exit,exit" instead of "exit 2".) With this very simple and powerful
> feature, the last argument for GOTO will disappear! 

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.

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.

Another reason for preferring this style is based on clarity of expression.
If fairly sure that if a programmer codes 'exit 2' it is NOT because she
wishes to exit the loop block that just happens to enclose the current one.
I suspect the the coder actually wishes to exit a specific loop block. If
that is the case, naming the loop block that is of interest helps clarify
the code.

This proposal would not break any existing Euphoria code.

Example:

  TextLine = gets(theFile)
  ProcessFile: while not atom(TextLine) do
      epos = find('=', TextLine)
      if epos != 0 then
          theKey = trim(TextLine[1..epos-1])
          theValue = trim(TextLine[epos+1..length(TextLine)]
          for i = 1 to length(theValue) do
            if theValue[i] = ',' then
               if i = length(theValue) or
                  theValue[i+1] = ' ' then
                    ErrMsg("Subvalue is invalid")
                    exit ProcessFile
               end if
            end if
          end for
          ProcessCmd(theKey, theValue)
      end if
      TextLne = gets(theFile)
  end while
  close(theFile)


> <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.

----------------
cheers,
Derek Parnell