Re: The Declaration Approach (was: Some thoughts on the 'reveal' Ka-Ping Yee (ping@lfw.org)
Wed, 20 Oct 1999 12:33:33 -0700 (PDT)

On Wed, 20 Oct 1999, Mark S. Miller wrote:
> On other code examples, the declaration approach leads to an explosion of
> names and less readable programs. Contrast current E's
>
> define PointMaker(x, y) {
> define Point {
> to getX {x}
> to getY {y}
> }
> }
>
> with the declaration approach's
>
> define PointMaker(x, y) => p {
> p := define Point {
> to getX => result { result := x }
> to getY => result { result := y }
> }
> }
>
> If I'm missing a way to rescue this approach, please let me know!

For simple expressions you could permit the omission of the named result variable, as in:

define PointMaker(x, y) => {

        define Point {
            to getX => { x }
            to getY => { y }
        }

}

This reduces verbosity in particular for easy things like getX and getY, while still flagging "revealed" values with a distinctive operator, though it does introduce some potential arbitrariness -- whether the author uses a result variable or not becomes a style issue, and it may put us in danger of more-than-one-way-to-do-it.

By the way, i would argue for a distinct operator rather than just => for "reveal", to aid text searches and syntax highlighting. This is one you really want to stand out fairly easily.

"Old code doesn't die -- it just smells that way."