TRUE, FALSE

[Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>]

    Date: Tue, 11 Mar 1986  10:19 EST
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

				I'm not sure where the break-even point
    would be in this case, but it's a lot higher than two.

I'd say the key question is whether we anticipate that this function
generator might be used for other things besides these two things, in
the future.  If we think there would be many other things, that would
support the proposal for the function generator.

In turn, this depends partially on how much we think people will be
using functional objects, closures, and function generators.  That's
what GLS's last message was about.  Appropriate design of Common Lisp
can only be done in the presence of a presumed programming style, to
allow us to try to gague how useful certain proposed features will be in
the future.  It's a hard problem because we don't all use the same
programming style, and because programming styles change with time.

In developing Common Lisp, I don't think we were completely consistent
in our treatment of these issues.  (Controversial statement of the
year...)  Some things in Common Lisp, notably the sequence functions,
were a little bit outside of what most of us considered the usual
programming style, for example.  This is presumably because we felt that
the style of the sequence functions was in the direction that we felt
modern Lisp was going.  This is also one of the reasons that lexical
scoping was adopted, although there were certainly others.

I think that GLS's proposed function generator is also in the direction
that model Lisp style is moving towards.  However, we don't all have the
same opinions about style.  Also, it's not clear how far out Common
Lisp, as a broad standard, should reach.  While we don't want to be
mired in the past, we also have a responsibility to be generally
conservative in some ways, because of the large number of
implementations and users.  So I think it's a complex judgement call.