More brace conventions are bad if they can be avoided -- there have been some studies on this. I think non-leakage warrants a keyword. In addition, the compiler should be able to determine which things leak and tell me.
I have no specific proposal.
Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595
"Mark S. Miller" <markm@caplet.com> on 10/22/99 11:32:56 AM
To: "Douglas Crockford" <crockford@earthlink.net>
cc: e-lang@eros-os.org
Subject: Re: The Declaration Approach (was: Some thoughts on the 'reveal'
operator)
At 06:43 AM 10/22/99 , Douglas Crockford wrote:
>Perhaps
>
> to foo(x) < booga(x) >
>
> produces { booga(x) }
>
>and
>
> to foo(x) { booga(x) }
>
> produces { booga(x) null }
>
>The idea here is that the leakability of an outer block is determined by the
>delimiters of the block. The <> delimiters are probably a bad choice here
>because of confusion with GREATERTHAN, but the idea is that <> blocks are
>productive and {} blocks are not.
Good, I like the bracketing approach. I also agree that angle brackets are bad, but if suitable brackets could be found, this might be the best thing. However, just to clarify, E must expand to Kernel E, and Kernel E must be a subset of E. Therefore, I think you wanted to say
to foo(x) < booga(x) >
expands to
to foo(x) < booga(x) >
and
to foo(x) { booga(x) }
expands to
to foo(x) <
booga(x)
null
>
However, since we're agreed that angle brackets are bad, "reveal" remains the best concrete proposal.
Cheers,
--MarkM