Language mavens: Is there a programming with "if then else ENDIF" syntax?

[James Harris]

On 3 Dec, 20:56, Michael Torrie <torr... at gmail.com> wrote:
> Steve Ferg wrote:
> > Is there any particular reason why this might be a *bad* language-
> > design idea?
>
> Syntactically, using braces, begin/end blocks, python white space, and
> your if/elif/then/endif structures, amounts to the same thing; they are
> all equivalent.  Thus from a language pov, there's no compelling reason
> to do one over the other.
>
> One good reason to avoid the if/elif/then/endif syntax and its related
> friends in a language (while/wend, do/loop, for/next) is that they
> require parser support for what amounts to three or four versions of
> precisely the same construct: the block.  Thus from a parser or compiler
> point of view, it's far better and easier to have blocks begin and end
> with something that is consistent and recognizable without a lot of
> look-ahead or context.

I'm not disagreeing with the above paragraph but in the interests of
even handedness an advantage of the other method is ease for a human
to match begins and ends of large blocks. With statement or block
brackets such as "begin" ... "end" (Pascal) and "{" ... "}" (C)
because they are all the same it can be hard to see where each
construct ends. C programmers sometimes write

    } /* for */
  } /* while */

or similar to indicate which construct the terminating brace is
closing.

> I once started to write a parser for the QuickBasic language but found
> very quickly that the grammar required a fair amount of token
> look-ahead.  For example, if I found the token "End", I had to look at
> least one token ahead to find out if this was an "end if" or just an
> "end."  Also "end" could, if I recall, have an optional number parameter
> that would set the exit errorlevel code.  Certainly QuickBasic was not
> context-free and was not LL(1).
>
> I'm not sure, but Python's grammar is LL(1) I think, and probably darn
> close to context-free.

James