Xref: utzoo comp.lang.c:26809 comp.lang.misc:4413
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!cbnewsc!lgm
From: lgm@cbnewsc.ATT.COM (lawrence.g.mayka)
Newsgroups: comp.lang.c,comp.lang.misc
Subject: Re: C strongly typed?
Message-ID: <14318@cbnewsc.ATT.COM>
Date: 12 Mar 90 03:29:34 GMT
References: <90070.034113CMH117@psuvm.psu.edu>
Reply-To: lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,)
Organization: AT&T Bell Laboratories
Lines: 38

In article <90070.034113CMH117@psuvm.psu.edu> CMH117@psuvm.psu.edu (Charles Hannum) writes:
>"void" in C is similar to "nil" in LISP.  It's just a generic type, which can
>hold the place of any other type, WHEN USED IN A POINTER!!  I couldn't assign

Some clarification is called for here.  In C, 'void' (*not* 'void *')
is used in function declarations and definitions to signify the
absence of arguments and/or a return value.  In this role, Common
Lisp's closest analog is the expression

	(VALUES)

which returns zero values.  (The VALUES form is more often used to
return multiple values.)  NIL is quite different.  In Common Lisp,
NIL is a specific object: the only object of type NULL, which is
in turn a subtype of both SYMBOL and LIST.  NIL's existence is
just as tangible as that of the number 0.  NIL does, of course,
fulfil some special roles (e.g., as the default initializer for a
name binding).

C's 'void *', on the other hand, plays the role of a generic
pointer type, as you say.  Its closest Common Lisp analog is the
type T, which is a supertype of every type.  If I were forced at
gunpoint to write type declarations for a Lisp function's
arguments, I would declare each of them to be of type T, which
essentially asserts existence but nothing more.

Despite the syntax, 'void *' has no semantic connection to 'void'
at all as far as I can see.  Indeed, they are almost opposites:
"anything" vs. "nothing." Apparently, C compiler writers simply
decided to apply some new semantics to whatever unused syntax was
lying around.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com

Standard disclaimer.