Some thoughts on the 'reveal' operator

[Mark S. Miller]

At 09:16 PM 9/23/99 , Mark S. Miller wrote:
>to be available in the upcoming 0.8.5, unless I'm talked out
>of it

Sorry I've been so unresponsive & uninformative lately.  I just wanted to 
let y'all know that your messages *have* talked me out of this for 
now.  I'm glad we all agree that the problem solved by "^" needs to be 
solved, but it sounds like we're also in agreement that we should find a 
better solution.

Between now and Oct 7 I'm going to try to stay focused mostly on the FC'00 
paper http://www.erights.org/elib/capability/ode/ , so I'm not going to 
worry about "^" until after that.  As a result, 0.8.5 will be more of a 
maintenance release (hopefully improving the setup/install/icons issues on 
Win* platforms).  The paper as submitted to FC'00 will be changed back to 
the current syntax -- a more conventional expression language -- and will 
footnote that the language may evolve by the time the paper is published.

Of course, this should not at all inhibit the rest of you from arguing 
about it until I can pay attention again.  Dean, you said (verbally to me) 
that E should handle this the way Joule did.  Would you care to explain, 
and to say what that would mean for E?

As long as we're talking syntax design, I'll go ahead and revive an old 
question: Ping especially has long advocated that E adopt Python's use of 
indentation rather than curly brackets for block structure.  My 
counter-argument has been we tried that in Joule, but got killed by tab 
ambiguity.  Most everyone agrees that text files should be considered to 
have a tab stop every N positions, but many passionately insist (as I do) 
that N is 8, while others insist with equal passion that N is 4.  (Note 
that I also believe and advocate that one should indent one's code to 
4-space indentation boundaries, and that editors should interpret the tab 
key on the keyboard to position the cursor to the next indentation 
boundaries.  These issues are not coupled.)  Clearly either solution is 
doomed, as it's incompatible with software built to the other solution.

Except that Python works.  What does it do?

Alternatively, how about if tab was simply not considered as valid 
character to be present in E source code?  A conforming lexer would be 
required to reject such input.  Therefore, if one's editor outputs tab 
characters, one would have to convert these programs before submission.  We 
can trivially supply such conversion programs.  I'm sure we examined and 
rejected such a solution in the Joule days, but I can't remember why.

Again, please feel free to argue this even though I won't be joining such 
an argument until after the 7th.


-----------------------------------------------------------
Due to a bug (possibly at my ISP, but probably in Eudora 4.2.0.58), on 9/15
I lost 18 email messages.  If it's possible for you to check whether you
sent me something on that date, resending it would be great.  Otherwise,
please excuse my non-responsiveness to email you may have sent around that
time.  Sorry for the inconvenience, and thanks.

         Cheers,
         --MarkM