LetS in Common Lisp

[Joseph.Ginder@CMU-CS-SPICE]

After having read Waters' recently distributed LetS proposal, I have the
following comments.

(1)  Destructuring in general is not supported in Common Lisp; LetS is
proposed as allowing destructuring.  (This is obviouly a minor point.)

(2)  The notions of LetS sequence and generic sequence are bound to be
confused by many users.  If LetS is adopted as part of the Common Lisp
white pages, these notions should be completely integrated so that
there is only one notion of "sequence".  Or at least they should be
clearly differentiated, both in the manual descriptions and in name.
I have no proposal for either of these alternatives.

(3)  Unitary operators generalizing to work for sequences is
inconsistent with the rest of Common Lisp.  
        (Eg.  (+ '(1 2 3) '(4 5 6)) does not work.)

(4)  LetS seems (to me) at least as "experimental" as Flavors.  Don't
get me wrong; I like flavors.  However, I do not believe them to be a
generally accepted method of implementing object-oriented programming
in all its glory (no pun intended); there are questions as to how
inheritance should be done, etc.  Therefore, I believe they should be
in the yellow pages.  I believe LetS to be even less generally
accepted and open for further discussion.  LetS seems a reasonable
candidate for the yellow pages also. 



Now that my position on LetS in Common Lisp is clear, I have a few
comments on it in general.  (Those who have not read Waters' proposal
probably want to ignore the rest of this.)  I'm not prepared to say
that it may not be useful, but I have several problems with it.
Basically, it seems as though it is an attempt to get both functional
composition and efficiency; functional composition for the way it
satisfies Waters' three required properties of looping constructs
(understandability, constructability, and modifiability -- in that
order), efficiency for obvious reasons.  I have two specific quarrels
with the examples he gives in the section of his proposal on
comparison with other loop notations using "sum-positive".

(1)  Tail Recursive Style.  Waters defines a tail-recursive
sum-positive.  I would not do this.  Instead, I would say something
like "(sum (positives vector)).  Then sum and positives could be
defined in the obvious tail-recursive manner.  This clearly separates
the "fragments that the loop is composed of" while retaining the other
advantages of the tail-recursive style which Waters acknowledges.  The
only advantage left for LetS is efficiency.  A smart compiler (or
LetS-type preprocessor even) could perform transformations similar to
those performed by LetS and generate comparably efficient code, could
it not?  Tail recursion clearly defines an execution order, so
correctness preserving should be less of a problem in doing this
conversion.  This is only a first reaction without too much
reflection, so apologies for obvious errors in my reasoning.

(2) Map Style.  In Common Lisp, the mapping functions can express
sum-positive very easily.  First of all, define a type
"positive-number"

   (deftype positive-number () (or (rational (0) *) (float (0.0) *)))

then define a predicate

   (defun PlusP (n) (typep n 'positive-number))

then sum-positive:

   (defun sum-postive (vector) (mapcar #'+ (map 'list #'PlusP vector)))

Efficiency questions are similar to those for tail recursion.

Despite these arguments, I'm willing to concede that LetS may be
useful in other instances and have no quarrel with putting it in the
yellow pages so we can find out.  Perhaps a way of generating
efficient compiled code for functional compositions (and map's) is a
more general solution to this problem.

-Joe Ginder


P.S.  Due to mail problems, this is several days old ...