Re: The Declaration Approach (was: Some thoughts on the Mark S. Miller (markm@caplet.com)
Wed, 20 Oct 1999 15:36:13 -0700

At 11:22 AM 10/20/99 , Douglas Crockford 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 }
> > }
> > }
>
>I prefer the declaration approach, actually. It looks less magical.

What about readability? In using a language, you pass your eyeballs over a lot of code, trying to quickly semi-parse and pick out what's significant. I simply find the latter example above unacceptably verbose, given that something like the first is possible.

>There is much to admire in a notation in which things just fall into place,
>but it can be confusing, particularly to people with a procedural
>upbringing. "Get that and put it there" is comforting in its directness and
>simplicity, even if it requires you to name where there is.

E is still an expression language. "if" still functions as both the traditional "if" and as the traditional "?:". Given that they have to absorb this anyway, there may be answers that aren't confusing, and that have the pleasing directness of current E.

>If I were writing the report for submission to PoPL, I would rather describe
>the functional example. But if I were writing "E for Dummies", I would
>insist on the declaration approach.
>
>This is more a marketing issue than a technical issue. Who is your audience
>for this language?

My audience is more towards the dummies that PoPL, but it's sorta both. I'm trying to design a language that can be understood and used by typical lightweight scripting programmers. I am also trying to design a technically beautiful language in which programs have clear hard and fast formal properties, analyzable and respectable to the theorist. Back in the Vulcan days (ancestor to Joule) we had a slogan: "Clean But Real!". I still believe in that.

However, regarding surface syntax issues, the marketing issue dominates. But my audience is as unfamiliar with the declaration approach as they are with the expression language approach. A pure marketing answer, which would not disrupt the theorist too much, is to just introduce a C-like "return". But lexically nested definitions are fundamental to E, and this would introduce an ambiguity: which level are we returning from? Also, to me, it's pretty horrible to force control flow where it isn't needed. I confess I have a similar reaction to forcing assignments where they aren't needed.

In any case, none of this is a fatal argument one way or another. My previous message, though, does mention a fatal problem with the declaration approach -- the initial value problem. This would need to be solved in order for the declaration approach to remain in the running. I haven't been able to solve it myself, but maybe y'all will come up with something.

         Cheers,
         --MarkM