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