Some thoughts on the 'reveal' operator

[Marc Stiegler]

2 things, about indentation and revelation.

I think using indentation instead of bracing is a seriously bad idea; after
all the work you have put in to make the language look like a C-syntax
language, this is a leap into darkness. I'd feel differently if the Python
user base was both ten times larger and also as unfamiliar with C-syntax as
C programmers are unfamiliar with Python. As it is, I suspect Python users
can adjust psychologically to braces easily, but not so the other way.

Revelation: I don't remember if this idea came up in the discussion of
reveal alternatives, and it is probably foolish for me to even make
proposals, since I don't have the foggiest idea about the
expansion-to-kernel-language consequences of a proposal, but how about

def multiplier run(a,b) reveals c {
    c := a * b
}

This syntax handles "reveals" sort of like Java handles "throws". And it
seems appropriate, especially since it is not a flow of control construct
like "return" is. And it has a little safety built in too--you always know
with this syntax exactly where to look to see if this method is revealing
anything, which is unlike the current ^ syntax, for which the revealed
object can be specified visually-in-the-middle of the method body--as an
example, the Maker objects typically have the ^ in the middle of the body,
which is where the definition of the made object begins. I have found the ^
syntax in makers error-prone, particularly the self-referencing made objects
which have inner and out declarations all needing to be revealed.
Furthermore, putting "reveal" in the definition line makes it a natural part
of the index extraction for a browsing tool, which is nice both for
programming and for security analysis.

Having said that, in truth, I have adjusted to the ^ syntax, and if you
chose to leave it as is I would consider that just fine. I come from the
FORTRAN branch of language development, I am horrified by IF statements that
return values in the first place :-) I know this puts me 6 sigmas off the
norm for the clientele of this email list, but I wouldn't be surprised if it
puts me a lot closer to the norm for ordinary java programmers :-)

--marcs

-----Original Message-----
From: Mark S. Miller <markm@caplet.com>
To: e-lang@eros-os.org <e-lang@eros-os.org>
Date: Monday, September 27, 1999 3:52 PM
Subject: Re: Some thoughts on the 'reveal' operator


>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
>