Re: Some thoughts on the 'reveal' operator Mark S. Miller (markm@caplet.com)
Mon, 27 Sep 1999 16:56:18 -0700

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