Re: variata

[andy@aids-unix (Andy Cromarty)]

The difficulty with expressions like (COND) and (BEGIN) is not
that it is difficult to define a semantics for them, but rather
that it is difficult to *intuit* a semantics for them.  We can
generate any of several arcane rules to cover such special cases.
It would be much nicer if no special rules were necessary, and if
instead we could apply some very small number of general principles
in figuring out what such aberrant constructs mean when we run across
them.

At the very least, if they must be included, perhaps we could come
up with one rule, uniformly applied, to define their semantics --
preferably one consistent with (what most Scheme programmers would
take to be) the "reasonable principles" of Scheme programming. 
(An informal example of such a rule -- not that I necessarily endorse
it -- would be, "Any special-form control construct (LET, COND, LAMBDA,
CASE, IF, BEGIN, LETREC, DO, etc.) that normally contains combinations-to-
evaluate in its main body may contain a null body, in which case its return
value is undefined.")

If the principal argument in favor of such vacuous constructs is that
some programs might generate them automatically -- and that strikes me
as a prima facie legitimate concern -- then we should consider what is
involved in making such programs generate only "intuitive" code instead.
Quite frankly, this doesn't seem to me to be a case where the author of
a program-writing program would be significantly constrained if uses of
BEGIN and COND are restricted to non-vacuous applications.  There are lots
of cases that are much worse about which no one has yet expressed concern,
such as the RRRS permitting special forms to be "syntax" objects instead
of making them shadowable first-class bindings.

					asc