From: Peter Seibel
Subject: How were the standard types and classes split up?
Date: 
Message-ID: <m3znguf6b3.fsf@javamonkey.com>
Another question about the history of CL's development/design: it
seems that there are some system classes that could have been defined
as types and some types that could have been defined as classes. (For
instance, most of the numeric "types" are system classes (e.g. number,
real, rational, integer) but at the bottom layers things are
partitioned into types (e.g. fixnum and bignum). I'm curious how the
decisions were made about what to make a class and what to make a
type. Were there specific deterministic criteria or was it just a
question of what felt right?

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp

From: Duane Rettig
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <4k77ykqgz.fsf@beta.franz.com>
Peter Seibel <·····@javamonkey.com> writes:

> Another question about the history of CL's development/design: it
> seems that there are some system classes that could have been defined
> as types and some types that could have been defined as classes. (For
> instance, most of the numeric "types" are system classes (e.g. number,
> real, rational, integer) but at the bottom layers things are
> partitioned into types (e.g. fixnum and bignum). I'm curious how the
> decisions were made about what to make a class and what to make a
> type. Were there specific deterministic criteria or was it just a
> question of what felt right?

Historically, CLOS is a latecomer to CL; if you look at CLtL1
("Common Lisp: The Language", Digital Press 1984 ISBM 0-932376-41-X)
you won't find any references at all to classes or to CLOS.  Types,
on the other hand, were there from the beginning and tend to be
divided along implementational lines; for example, the original CL
tried to keep the integer type pure and did not even give a minimum
implementational size to fixnums (I think someone theorized that
fixnums could even be as small as (signed-byte 1), though it would
be stupid to do so), the Ansi spec defined it a little more
precisely, and also defined fixnum/bignum to be an exhaustive
partition of the integer type.  This limited any experimentation on
representations of things like infnities to bignums only.  But it
has always been the practice to partition these types
implementationally, based on efficiency (e.g. fixnums don't cons in
general).  The addition of the hybrid approach in CLOS was a natural
fit, since we always want the best of both worlds of efficiency and
generality.  If you see rough edges between classes and types, it
is largely due to that tension between these two goals.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Wolfhard Buß
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <m31xu6eypj.fsf@buss-14250.user.cis.dfn.de>
Peter Seibel:
| Another question about the history of CL's development/design: it
| seems that there are some system classes that could have been defined
| as types and some types that could have been defined as classes. (For
| instance, most of the numeric "types" are system classes (e.g. number,
| real, rational, integer) but at the bottom layers things are
| partitioned into types (e.g. fixnum and bignum).

Classes are types, but not all types correspond to classes.
Fortunately, implementations are free to provide classes for yet
classless types. (See [CLHS 4.3.7] for details).

CMUCL-18e, for example, provides a built-in-class for type fixnum.

 (type-of 1) => FIXNUM
 (class-of  1) => #<BUILT-IN-CLASS FIXNUM (sealed) {28015145}>


-- 
"Hurry if you still want to see something. Everything is vanishing."
                                       --  Paul C�zanne (1839-1906)
From: Peter Seibel
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <m3oex9gb40.fsf@javamonkey.com>
·····@gmx.net (Wolfhard Bu�) writes:

> Peter Seibel:
> | Another question about the history of CL's development/design: it
> | seems that there are some system classes that could have been defined
> | as types and some types that could have been defined as classes. (For
> | instance, most of the numeric "types" are system classes (e.g. number,
> | real, rational, integer) but at the bottom layers things are
> | partitioned into types (e.g. fixnum and bignum).
> 
> Classes are types, but not all types correspond to classes.
> Fortunately, implementations are free to provide classes for yet
> classless types. (See [CLHS 4.3.7] for details).

Right, that's why I was wondering how the line was drawn: was there
some criteria that caused FIXNUM to get put on the "type" side of the
line when the standard was written? That's a particularly interesting
case since--as you point out--it is often implemented as a class.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Barry Margolin
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <o%ncb.36$pd.16@news.level3.com>
In article <··············@javamonkey.com>,
Peter Seibel  <·····@javamonkey.com> wrote:
>Right, that's why I was wondering how the line was drawn: was there
>some criteria that caused FIXNUM to get put on the "type" side of the
>line when the standard was written?

Maclisp (as well as other Lisp dialects in the 70's) had FIXNUM and BIGNUM
types.  The types already existed when CLOS was added to the language, and
the standard simply adopted that.

-- 
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Peter Seibel
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <m3k77xg6o1.fsf@javamonkey.com>
Barry Margolin <··············@level3.com> writes:

> In article <··············@javamonkey.com>,
> Peter Seibel  <·····@javamonkey.com> wrote:
> >Right, that's why I was wondering how the line was drawn: was there
> >some criteria that caused FIXNUM to get put on the "type" side of the
> >line when the standard was written?
> 
> Maclisp (as well as other Lisp dialects in the 70's) had FIXNUM and
> BIGNUM types. The types already existed when CLOS was added to the
> language, and the standard simply adopted that.

Weren't any of the other things that are now classes in CL types prior
to CLOS. For instance LIST, NUMBER, CONS, etc? Assuming those were
types in Maclisp, et al. why did they get "promoted" to classes in CL
while FIXNUM was "left behind"?

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Barry Margolin
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <Mkpcb.37$pd.33@news.level3.com>
In article <··············@javamonkey.com>,
Peter Seibel  <·····@javamonkey.com> wrote:
>Weren't any of the other things that are now classes in CL types prior
>to CLOS. For instance LIST, NUMBER, CONS, etc? Assuming those were
>types in Maclisp, et al. why did they get "promoted" to classes in CL
>while FIXNUM was "left behind"?

I guess it was a somewhat intuitive notion of which types it would make
sense to dispatch on in method specifications.  Classes generally
correspond to higher-level abstractions, not implementation-specific
distinctions like FIXNUMs.

In the case of FIXNUM vs. BIGNUM, perhaps the feeling was that it's only
necessary to distinguish these when micro-optimizing, and if you're doing
that you'll probably want to avoid most of the overhead of CLOS entirely.

Realistically, the only reason FIXNUM is in the language at all is so that
you can use it in type declarations, which can allow for some compiler
optimizations.  But even this requires very careful coding, since the set
of fixnums is not a group under most arithmetic operations.  For instance,
adding two fixnums can overflow and produce a bignum, so it's not enough to
write:

(declare (fixnum a b))
(+ a b)

you have to write something like:

(declare (fixnum a b))
(the fixnum (+ a b))

-- 
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Peter Seibel
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <m3brt9g314.fsf@javamonkey.com>
Barry Margolin <··············@level3.com> writes:

> In article <··············@javamonkey.com>,
> Peter Seibel  <·····@javamonkey.com> wrote:
> >Weren't any of the other things that are now classes in CL types prior
> >to CLOS. For instance LIST, NUMBER, CONS, etc? Assuming those were
> >types in Maclisp, et al. why did they get "promoted" to classes in CL
> >while FIXNUM was "left behind"?
> 
> I guess it was a somewhat intuitive notion of which types it would make
> sense to dispatch on in method specifications.

Okay, that's pretty much what I figured it was. Thanks.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Steven M. Haflich
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <3F72527F.3060809@alum.mit.edu>
Peter Seibel wrote:

  > Right, that's why I was wondering how the line was drawn:

The line was drawn between the types that are also classes and the
types that are not.  The distinction is more a restriction upon
what portable user code can depend upon, and less a restriction
on how the implementation goes about implementing its
implementation.  You will not find more specific explanation in
the ANS, and therefore, anything further anyone says is either
speculation or unreliable memory.

There is some distinction between semantic and implementational
differences.  Portable code (that has not customized its own
expression by inquiring about types on a specific implementation)
cannot rely on any semantic difference between fixnums and bignum.
For instance, one could imagine an implementaiton in which all
integers were fixnums.  But portable code can rely on semantic
differences between integer and float.
From: Pascal Costanza
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <bktbno$sr3$1@newsreader2.netcologne.de>
Peter Seibel wrote:

> Another question about the history of CL's development/design: it
> seems that there are some system classes that could have been defined
> as types and some types that could have been defined as classes. (For
> instance, most of the numeric "types" are system classes (e.g. number,
> real, rational, integer) but at the bottom layers things are
> partitioned into types (e.g. fixnum and bignum). I'm curious how the
> decisions were made about what to make a class and what to make a
> type. Were there specific deterministic criteria or was it just a
> question of what felt right?

http://doi.acm.org/10.1145/114669.114671 contains a very detailed 
rationale for the relationship between classes and types.


Pascal
From: Peter Seibel
Subject: Re: How were the standard types and classes split up?
Date: 
Message-ID: <m37k3xg085.fsf@javamonkey.com>
Pascal Costanza <········@web.de> writes:

> Peter Seibel wrote:
> 
> > Another question about the history of CL's development/design: it
> > seems that there are some system classes that could have been defined
> > as types and some types that could have been defined as classes. (For
> > instance, most of the numeric "types" are system classes (e.g. number,
> > real, rational, integer) but at the bottom layers things are
> > partitioned into types (e.g. fixnum and bignum). I'm curious how the
> > decisions were made about what to make a class and what to make a
> > type. Were there specific deterministic criteria or was it just a
> > question of what felt right?
> 
> http://doi.acm.org/10.1145/114669.114671 contains a very detailed
> rationale for the relationship between classes and types.

Cool. I'll check it out. Thanks.

-Peter

-- 
Peter Seibel                                      ·····@javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp