From: John Boozer
Subject: Common Lisp Hyperspec, Functions & Typechecking
Date: 
Message-ID: <544451c3.0211071052.22bcf9ff@posting.google.com>
I've been digging through the Common Lisp Hyperspec and "Common Lisp,
the Language, 2nd Edition" and I was wondering if someone could
clarify something for me.  I'm trying to figure out what type-checking
is required in the standard Lisp functions.  + and * say "might signal
type-error if some argument is not a number".  Functions like read
give no clarification on type-checking the arguments.  What is
required of a conforming implementation if read is passed an object
that isn't a stream as its first parameter?  In general, what is
required of a conforming implementation if a function seems to be
expecting a particular type, but the specification doesn't mention
signaling a type-error?
 
If that information is somewhere in the Hyperspec, please point me to
it.
 
John Boozer

From: Nils Goesche
Subject: Re: Common Lisp Hyperspec, Functions & Typechecking
Date: 
Message-ID: <lkheet19ck.fsf@cartan.de>
·······@mindspring.com (John Boozer) writes:

> I'm trying to figure out what type-checking is required in the
> standard Lisp functions.  + and * say "might signal type-error if
> some argument is not a number".  Functions like read give no
> clarification on type-checking the arguments.  What is required of a
> conforming implementation if read is passed an object that isn't a
> stream as its first parameter?

You surely mean ``an input stream designator��.  NIL is fine, for
instance.

> In general, what is required of a conforming implementation if a
> function seems to be expecting a particular type, but the
> specification doesn't mention signaling a type-error?

It can do anything it likes, including crashing the system or making
demons fly out of your nose.

> If that information is somewhere in the Hyperspec, please point me
> to it.

Read 1.4.4.3 The ``Arguments and Values'' Section of a Dictionary
             Entry.

In general, the behavior of an implementation will depend on the
speed, safety and debug settings you use in your declarations.

You might also be interested in

1.4.2 Error Terminology

Regards,
-- 
Nils G�sche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x0655CFA0
From: John Boozer
Subject: Re: Common Lisp Hyperspec, Functions & Typechecking
Date: 
Message-ID: <aqete6$22a$1@slb4.atl.mindspring.net>
> You surely mean ``an input stream designator��.  NIL is fine, for
> instance.

Hmm, really?  What do you get when you pass NIL to read?


> Read 1.4.4.3 The ``Arguments and Values'' Section of a Dictionary
>              Entry.

Oh yippee, that's just what I was looking for. Thanks!
From: John Boozer
Subject: Re: Common Lisp Hyperspec, Functions & Typechecking
Date: 
Message-ID: <aqetsb$72s$1@slb6.atl.mindspring.net>
> Hmm, really?  What do you get when you pass NIL to read?

Oh, never mind.  Found it.
From: Jeremy Yallop
Subject: Re: Common Lisp Hyperspec, Functions & Typechecking
Date: 
Message-ID: <aqeu0f$9dscr$1@ID-114079.news.dfncis.de>
John Boozer wrote:
> Hmm, really?  What do you get when you pass NIL to read?

*standard-input*.  Read the hyperspec.

Jeremy.
From: JP Massar
Subject: Re: Common Lisp Hyperspec, Functions & Typechecking
Date: 
Message-ID: <3dcc82f5.86527441@netnews.attbi.com>
On Thu, 7 Nov 2002 18:39:08 -0500, "John Boozer"
<·······@mindspring.com> wrote:

>> You surely mean ``an input stream designator��.  NIL is fine, for
>> instance.
>
>Hmm, really?  What do you get when you pass NIL to read?
>

;;; Using Allegro
 
> (read nil)
6
6
> 

;;; Using Corman

(read nil)
;;; An error occurred in function READ-EXPRESSION:
;;; Error: Expected an input character stream, got NIL



(Which is, presumably, a bug)