CPL

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 20 Feb 87  2255 PST
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    You might wonder why I continue to harp on the CPL....

    Moon argued that
    the New Flavors CPL algorithm did the right thing and was intuitive. He argued
    that some huge number of users depended on it and liked it. So we tried
    to figure out an alternative formulation that was easier to understand.
    The result was that we found an example that showed that the algorithm
    that did the right thing and that programmers loved did the wrong thing.

This is not quite accurate.  The CPL algorithm in New Flavors and the one in
87-002 are very close in their effects.  The example we found where they
differ is one in which the algorithm used in New Flavors fails to produce
the intuitive result.  The programmers never loved the algorithm, nor even
knew in such detail what it did that they could distinguish between the New
Flavors algorithm and the 87-002 algorithm.  What they liked was the result,
not the way it was computed.

What I argued against was other proposed algorithms that produced very
different results.  What you argued against was algorithms whose description
was not very algorithmic.  We both got what we wanted.

    Why aren't we trying to think
    of a simple way for the user to have control of the CPL without making him
    write his own algorithm?

Does this mean that you want me to convert the following, extracted
directly from the Flavors documentation, to 87-002 terminology and
distribute it for comments, either in this working group or at the X3J13
meeting?  If so, I'll be happy to do so.

@Topic[:component-order Option for defflavor]

Enables you to state explicitly the ordering constraints for
the flavor components whose order is important.   You can use it to
relax ordering constraints on component flavors for which order is not
important.   You can also use it to add ordering constraints on flavors
that are not components; this means that if this flavor is later mixed
with another flavor, the ordering of components takes into account the
constraints given by this option.

If :component-order is given, the order of flavor components at
the top of the defflavor form is no longer significant.   The
arguments to :component-order are lists.  The members of
each list are constrained to appear in the order they appear in 
the list.   Any component that does not appear in these lists has no
ordering constraints placed on it. 

For example, the following form imposes many constraints on the ordering
of the seven flavor components:   

(defflavor foo (var1 var2) 
	   (a b c d e f g))

However, your program might not depend on a specific ordering of
components, because the components have no effect on each other.   
For example, your program might depend only these ordering constraints: 

  - Flavor c must precede d. 
    
  - Flavor b must precede g.
    
  - If flavor x is present (it could be a component of one of the
    components, or it could be mixed into flavor foo to create a new 
    flavor), it must follow b and precede g.

You can specify those restrictions by giving the following option to defflavor:

(defflavor foo (var1 var2) 
	   (a b c d e f g)
  (:component-order (c d) (b x g)))

Note that this does not constrain flavors c and d to precede
flavors b, x, and g.    Also, it is not an error to specify
an ordering constraint for a flavor that is not a component of this flavor. 
For example, it is valid to constrain the order of x, although x
might not be a direct or indirect component of this flavor.