At 12:33 PM 10/20/99 , Ka-Ping Yee wrote:
>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 }
> }
> }
Congratulations Ping! Dropping the "permit" above, this is the approach #3 that I said I would explain in a later message. Thanks for writing that message! The kernel language would then only have
to verb ( patterns ) => { body }
When the "=>" is left out, as in
to setX(newX) {
x := newX
}
this just expands-to-kernel to an appending of "null" on the end of the block:
to setX(newX) => {
x := newX
null
}
The "=>" would be optional on function definitions too, and functions would continue to expand into methods in the usual way.
>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.
Why I'd like to drop the "permit" and make this the entire approach. The disadvantage is that we loose the opportunity to name and type the return result in an easy for the eye to find place, the header, which would argue for more-than-one-way-to-do-it. I don't really care that much about naming the result in header, but I'd really like to provide an optional declaration in the header. I've got some ideas, but I'd like to hear other suggestions first.
>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.
Suggestions again solicited.
Cheers,
--MarkM