White space vs. text for program structuring

[Mark S. Miller]

 From these messages, I am satisfied with my sense of the consensus: don't 
change to indentation-based block structure.  In other words, I'm going to 
leave this aspect of the language alone.

At 03:09 PM 9/28/99 , Ka-Ping Yee wrote:
>On Tue, 28 Sep 1999, Bill Frantz wrote:
> >
> > Since people use the two dimensional appearance and (most) languages use
> > one dimensional token parsing to determine program structure, there is more
> > than enough room for error to creep in.  I have always thought that warning
> > diagnostics for situations where the two methods give different structures
> > would be useful.
>
>Yes, this is one of the strongest arguments for indentation-based block
>structure: the braces are redundant, because people will indent their
>code and visually interpret their code by indentation anyway.  Problems
>happen when the two are inconsistent.

In documenting the grammar, I will encourage such warnings to be given.  I 
hope eventually to modify our lexer to follow this recommendation.  I think 
I'll also have it warn when it sees tab characters.  These warnings should 
be suppressable.

>For me the controversy over tab sizes isn't really relevant; it's just
>the command language issue that's the sticking point.
>
>I suppose we can revisit the command language issue.  Mark, is it still
>an essential part of your E plan that people be able to use E as their
>shell?

Essential.  Lisp & Smalltalk both show the power of using the same language 
as your programming language and your shell language.  I am aware of only 
two capability-oriented shell languages: E & Rees's secure 
W7/Scheme48.  Except for these, there are no shells that could be used for, 
for example, EROS, without hiding the unique power of EROS.  Because of 
syntax, sadly, I expect E would be able to gather much wider acceptance as 
a capability-shell language.


         Cheers,
         --MarkM