Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.lisp Subject: Re: cl type problems Message-ID: <1991Apr2.183710.4822@Think.COM> Date: 2 Apr 91 18:37:10 GMT References: Sender: news@Think.COM Distribution: comp Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 39 In article mfx@dragon.opal (Markus Freericks) writes: >I am relatively new to CL and have stumbled over the following problem: >when testing for an nonexisting type, like in ... >my AKCL ("June 3,1987",sun4) gives () and no warning. >- is this an implementation bug ? No, it's a lack of a useful feature. CLtL does not say that the implementation must signal an error if a nonexistent type is specified. It simply says that the second argument must be a type specifier, which implies that "it is an error" (to use CLtL's language) or "the consequences are undefined" (to use the ANSI spec's terminology) if it is not. >- is there any way of testing whether something is a valid type > specifier? (I've found none) Not currently. I think we added TYPE-SPECIFIER-P to the language at the X3J13 meeting two weeks ago. >While this poses no 'real' problem, it can be damn annoying if some >type's name was typoed and dispatching code just ignores it. 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). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar