Scheme conference report

[Bill Rozas <JINX%MIT-OZ@MIT-MC.ARPA>]

	I would like to clarify (hopefully) a few points with respect
to the evaluation of combinations:

	The operator position is a "distinguished" argument.  In my
opinion it is the only position for which the evaluation order might
be relevant.  If reflective procedures are present in an
implementation, then the operator position must be evaluated before
any operand expressions.  Since in the common subset there is no
provision for reflective procedures, there is no need to specify any
particular order with respect to the operator.

	In Will's last message there was a statement to the effect
that normal order evaluation was prohibited.  I find this rather
surprising.  One of Guy Steele's Rabbit compiler main points was that
normal order beta-subtitution could be used very successfully to
optimize Scheme code.  In the absence of side-effects, and if the
programs terminate when using applicative order, there is no way to
determine whether normal or applicative order is used.  A compiler can
use this profitably to postpone evaluation.  A think that a more
appropriate statement is that portable programs should not depend on
the evaluation strategy used, ie. they should work in applicative
order, but different implementations may want to use different
strategies.

	The order of argument evaluation was left unspecified for
various reasons:

	- The order of argument evaluation is only relevant in the
presence of side-effects in some of the argument expressions.  Scheme
is predominantly an applicative language (contrast with Pascal), and
good style requires that arguments to procedures (operands of
combinations) be side-effect free.  By not specifying the order, it
was felt that code with such side-effects would be discouraged since
its effect would not be predictable.

	- An optimizing compiler can do a better job if it has freedom
over the order in which it can execute expressions.  Leaving the order
unspecified potentially allows a clever compiler to choose the optimal
order for each combination.  Note that the meaning of a program can
only be changed by reordering if the argument expressions contain
side-effects.  But this code could not be guaranteed to work in other
implementations with different default order for argument evaluation.

	- Leaving the order of argument evaluation unspecified allows
a parallel implementation to evaluate in parallel.  Note again that
the only programs whose semantics are not clear (and are therefore not
predictable) are those with side-effects in the operands of a
combination.

	A marginally related issue is the issue of macros.  In Scheme
there is not so much of a need to provide a macro facility as in other
dialects of Lisp.  Macros are needed only to provide "nicer", more
readable syntax.  In other dialects they are needed to extend the
langauge since there is no way of encapsulating an expression and an
environment.  Freezing ("thunkifying", wrapping in a lambda
expression) an argument encapsulates a context and an expression in a
procedure which can then be invoked at will by the operator procedure.
While syntactically clumsy, it is conceptually very elegant.  Note
that an optimizing compiler (Rabbit, for example) can eliminate most
or all of the overhead of freezing and thawing.