From: Markus Freericks
Subject: cl type problems
Date: 
Message-ID: <MFX.91Apr2124827@dragon.opal>
Dear Newsgroup!

I am relatively new to CL and have stumbled over the following problem:
when testing for an nonexisting type, like in

	(typep 13 'hgsgjs)

my AKCL ("June 3,1987",sun4) gives () and no warning. The same in

	(typecase 13.5 (integer 1)(sguaguy 2)(float 3)(t 4))

which happily returns 3.
No my questions:

- is this an implementation bug ?

- is there any way of testing whether something is a valid type
  specifier? (I've found none)

While this poses no 'real' problem, it can be damn annoying if some
type's name was typoed and dispatching code just ignores it.

Markus
--
Markus Freericks	phone: +49-30-4034110	
Oranienburger Str. 142	email: ···@opal.cs.tu-berlin.de	
1000 Berlin 26 FRG	or ···········@DB0TUI11.BITNET	

From: Barry Margolin
Subject: Re: cl type problems
Date: 
Message-ID: <1991Apr2.183710.4822@Think.COM>
In article <················@dragon.opal> ···@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.

······@think.com
{uunet,harvard}!think!barmar
From: Jeff Dalton
Subject: Re: cl type problems
Date: 
Message-ID: <4474@skye.ed.ac.uk>
In article <····················@Think.COM> ······@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.