Re: correction on mlet & mlabels

[masinter.PA@Xerox.ARPA]

We tried to keep the "kernel" described in Section I simple and
straightforward, and keep all of the options that were possibly
controversial in Section II. The subsections of II are ordered very
roughly from benign to more controversial.

I'm a poor choice for defending or motivating mlet, but the other
author's of the paper are already on their way to IJCAI.

I agree that more examples and motivation are needed throughout the
paper, especially in some of the options section. In the interest of
brevity (and getting the paper out before IJCAI!) we kept it short.

Originally, we were using DEFUN to define methods, i.e., DEFUN changed
to say "if any of the required arguments are type-specified, then this
defun specializes rather than replaces the current definition."

Given that, the meaning of "mlet" is that it changes the specified
method lexically, rather than the discriminator.

At the risk of putting my foot in my mouth once more, I'll offer that
you're right about what mlet was intended to mean:

mlet can expand into a flet, not a let;
the result is not something that overrides more specific methods; in the
example, it doesn't override storm-window.

MLET was intended to be lexical, by analogy with FLET. In general, I
think dynamic binding of function cells is something to be avoided. 

If you have more areas that you'd like motivation or explaination for,
please let us know.. I expect that there are some parts that need to be
hashed out further as they are looked over by the rest of you.

Larry