Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.oz.au (Richard O'keefe)
Newsgroups: comp.lang.eiffel
Subject: Re: Comments on proposed Eiffel language changes
Message-ID: <2900@goanna.oz.au>
Date: 22 Feb 90 05:34:43 GMT
References: <48a55876.12c9a@digital.sps.mot.com> <2888@goanna.oz.au> <3476@tukki.jyu.fi>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 75

In article <3476@tukki.jyu.fi>, sakkinen@tukki.jyu.fi (Markku Sakkinen) writes:
> In article <2888@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes:
> >Computers have no trouble whatsoever with
> >layout inside names.  Consider Fortran, Algol 68, and IMP for starters.
> 
> Fortran's stupid lexical conventions certainly cause trouble both to
> computers (compilers: separate lexical analysis is impossible)
> and more importantly, to programmers. Everybody knows some classic
> example like
>       DO 100 I = 1.10

No, Fortran's conventions don't cause any trouble to computers at all.
I have written two Fortran preprocessors; the hacks for lexical
analysis require nothing deeper than counting parens and looking out
for '=' and ','.  It wasn't at all hard.

The DO statement is not a problem with Fortran's *lexical* rules.
If the syntax were
	DO <variable> FROM(<expr>) TO(<expr>) [BY(<expr>)]
	...
	END DO [<variable>]
-- which would fit very nicely indeed with Fortran lexical style --
that kind of mistake couldn't happen.  No way am I going to defend
the Fortran "DO" statement.

There is an interesting reason why Fortran, Algol 60, and Algol 68
allow and ignore embedded spaces in tokens.  They were all intended
for "scientific" programming.  When you enter a 40 digit number from
a set of tables such as Abramowitz & Stegun or from some other source,
it is very easy to make typing mistakes.  It is _much_ easier to check
	3.14159 26535 89793 23846
than it is to check
	3.14159265358979323846
Ada compromises and allows embedded and ignored underscores in numbers,
which is nearly as good.  I do _not_ advocate allowing spaces in Eiffel
tokens, but I _do_ think that allowing underscores in numbers would be
useful.  The syntax of "Reals" is very much downplayed in "Eiffel: the
language", "Real" is used but not defined in the syntax appendices and
the change wouldn't invalidate existing programs (to keep it under
control one could rule that an underscore in a number must be preceded
and followed by a digit).

> >Another is to use a form of stropping; there were four official
> >methods of stropping for Algol 68 and IMP used another, e.g.
> >	%require latest x = %old y;
> 
> Please give a more enlightening example. In the above, the '%'
> characters appear only at places where they contribute nothing
> to separating the identifiers. Also, what is/was IMP?

IMP is the IMPlementation language of the EMAS operating system.
Sorry about the example; the point here was simply that it had yet
another stropping convention.

> Some old Algol-60 compiler(s) required the language keywords
> to be within apostrophes:
>    'begin' 'integer' n, m ... 'end'
> Is that called 'stropping' also?

I think it's called "quote stropping" or "prime stropping",
another one is "point stropping" (leading "." and optional following "."),
then there are Case, UPPER, and "reserved" stropping.  The Algol 68C
compiler supports most of them.

I think this has gone on long enough; anyone who wants to talk about
spaces in tokens can do it in comp.lang.misc.  The relevance to Eiffel
is that

 -- Eiffel uses reserved words and prohibits embedded spaces,
    not because computers can't handle anything else (PL/I has no
    reserved words!) but because Eiffel's designers thought that
    was the right choice.

 -- Some method of clumping digits in numeric literals _would_
    make some kinds of Eiffel programs easier to desk check.