barmar@think.com (Barry Margolin) (02/17/91)
In article <1350036@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight) writes: >PS. My own personal gripes with CL are [1] the type system is far too loose We're tightening it up a bit in the ANSI version. >[3] equality doesn't work the way it does in other lisps & is >a nasty source of problems (e.g. portability) X3J13 has cleaned up EQUAL and EQUALP a little. However, our general feeling is that it's not really worthwhile to spend lots of time on the built-in equality predicates. Equality is generally a domain-specific notion, and simplistic equality predicates are rarely applicable. For instance, should EQUAL recursively descend into defstruct slots? The answer generally depends on the semantics of the structure. >[5] I don't like keyword parameters/optional parameter etc and dislike >paying a cost for a feature I don't use What cost is there for them when you don't use them? There doesn't need to be much cost for the fact that standard functions have keyword arguments, because the compiler can transform calls to them into calls to non-keyword versions. The only exception is when the argument list is not known at compile time (i.e. FUNCALL or APPLY is being used), but these are the situations when the keyword argument list is most useful, so the expense of parsing the keywords is worth it (IMHO). > [6] empty list and false still aren't distinct I don't think this is considered a bug in the CL community. Even Scheme has only very recently changed this. >[10] the >dual name spaces for functions and values (bletch!) (use type hints >to avoid the usual complaints of efficiency (see Pop11)) What efficiency complaints are these? I think most of us who are in favor of multiple namespaces (there are more than two -- there are also namespaces for classes, types, and packages) like the semantics of it. I've never heard an efficiency justification. >[11] type assertions >are unchecked & are effectively promises rather than hints (I'd like >both, thanks) It's easy to write a macro that combines a type declaration and a type check. Something like (defmacro with-type ((variable type) &body body) `(progn (check-type ,variable ,type) (locally (declare (type ,type ,variable)) .,body))) >[12] the lack of a updaters (see Pop11) for an update >model that can support abstraction (SETF is a compile-time thing). ANSI CL will allow you to define a function named (SETF <symbol>). If SETF doesn't recognize the first subform as a macro-style setf method, it turns the SETF call into (FUNCALL #'(SETF <symbol>) ...). By the way, did you ever make your complaints known to HP's representative to X3J13 (sorry, I don't remember who that is)? -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
jeff@aiai.ed.ac.uk (Jeff Dalton) (02/18/91)
In article <1991Feb17.000333.16922@Think.COM> barmar@think.com (Barry Margolin) writes: >>[10] the >>dual name spaces for functions and values (bletch!) (use type hints >>to avoid the usual complaints of efficiency (see Pop11)) > >What efficiency complaints are these? I think most of us who are in favor >of multiple namespaces (there are more than two -- there are also namespaces >for classes, types, and packages) like the semantics of it. I've never >heard an efficiency justification. Maybe you're both right? There is an efficiency argument, but it isn't a justification for two namespaces (or at least not an important one). The basic idea is that in a Lisp-1 a function call might have to check that the value is a function. This is a problem for global variables and for locals where the compiler can't be sure the value will be a function. A solution (for globals?) is to (1) always have a spearate function value that's called, and (2) have assignment of a non-function value change the separate function to one that signals an error. This sort of thing is discussed in (amazingly enough) the first issue of Lisp Pointers in the endpaper "Technical Issues of Separation in Function Cells and Value Cells", page 95. I think you probably have seen this, but since the efficiency issue has been settled (ie, it's not a great problem), it doesn't really count as a justification. -- jd