Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!edcastle!aiai!jeff From: jeff@aiai.ed.ac.uk (Jeff Dalton) Newsgroups: comp.lang.lisp Subject: Re: cl type problems Message-ID: <4474@skye.ed.ac.uk> Date: 11 Apr 91 17:52:15 GMT References: <1991Apr2.183710.4822@Think.COM> Reply-To: jeff@aiai.UUCP (Jeff Dalton) Distribution: comp Organization: AIAI, University of Edinburgh, Scotland Lines: 26 In article <1991Apr2.183710.4822@Think.COM> barmar@think.com (Barry Margolin) writes: >This is considered a "quality of implementation" issue. Both Symbolics and >Lucid signal an error when TYPEP is given a nonexistent type name, and >Symbolics gives a warning at compile time. So vote with your wallet. If >you use AKCL because of its price rather than quality, then this is the >kind of tradeoff you can expect (disclaimer: I've never actually used AKCL, >so I don't know whether this is an isolated misfeature or indicative of the >general quality, I'm just making a general point about the hazard of basing >choices primarily on price). I use AKCL because (1) it is free, (2) it is small enough to run on my 8 meg Sparcatation at work and my 386 machine at home, (3) it comes with complete sources, (4) it is very portable so I can run it on new machines that don't have a CL, (5) it has reasonable performance, and (5) it is a reasonably good, though not perfect, implementation of CLtL (I). The defects in KCL are not due so much to quality as to size. Yes it would be better if it made some checks that it doesn't. It would also be bigger and perhaps slower. It might also not have been finished. Another factor is that X3J13 keeps making changes and it's easier for commercial organizations with 10s or more of employees to keep up than it is for one or two people working in their spare time at the University of Texas.