Subject: Re: array types
From: Erik Naggum <>
Date: Tue, 17 Jul 2001 20:47:24 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* Kalle Olavi Niemitalo <>
> Because LET initializes things without being asked to, [...]

  No, it does not.  This is a confusion in your own mind.  Only you can fix
  it.  Please do not state your conclusions as if they were _observations_
  from a specification.  Binding and initialization are conceptually so far
  apart that I have a hard time figuring out how to respond to you, but you
  have gone astray somewhere, thinking they are the same.  Please backtrack
  to that point and take the right path.  I fear that several other weird
  conclusions come from this strange mistake.  Perhaps you believe that a
  variable is some kind of data storage that is initialized to something in
  a let binding, just like a cons cell is a kind of data storage that is
  explicitly initialized to hold some data when you call the constructor
  cons.  If you think at this C level, maybe it works for you to consider a
  binding as affecting a pointer in a variable and initialization as
  affecting the pointed-to object.  But please, do not think at the C level
  -- the more you succeed in doing so, the harder it will be to get back to
  the truth when you realize that you are stuck.  It _will_ be painful.

> I haven't studied type theory.

  Good for you, but you have absorbed a great deal of trash from it, anyway.
  Sometimes, one has to discard what one think one knows in order to learn
  what is right in both the old and the new context.

> I know C and C++ though, and there you cannot implicitly convert T** to
> const T**.  This seems related to Common Lisp's disjoint (array X) and
> (array Y) types (assuming X and Y are upgraded types).

  No, not at all related.  (array (signed-byte 32)) and (array single-float)
  are disjoint for _exactly_ the same reason that int[] and float[] are.

> CL's OR and SATISFIES type specifiers were quite an astonishment when I
> first read about them, kind of like Scheme's continuations.

  Types in Common Lisp are named partitions of a mathematical value space.
  Types in C are hardware implementations of partitions of the hardware
  value space, plus a little compile-time noise thrown in for good measure.
  The C type concept is easy to understand from a Common Lisp point of
  view, but coming from C, you have to realize that your "type" concept is
  really a very peculiar special case of a much broader, general concept.
  This is why C and the like are horrible languages to expose beginners to.

> Are there any others like them?

  Not that I can recall, but you should not worry about these things now.

> What if I make an array with element-type (cons symbol fixnum); is the
> Lisp required to upgrade that to at least CONS, or can it preserve the
> exact type and let me store only conses pointing to symbols and
> fixnums?  What happens if I mutate the cons after storing it in the
> array -- is that OK as long as I don't use that element of the array?
> With subtypes of COMPLEX, there are no such problems, I think.

  The specialized array is a concession to hardware.  The type is upgraded
  to the most fitting hardware-supported type available.  E.g., you could
  ask for an array of 32-bit integers, or floating point numbers of single
  or double precision (but not both).  If you asked for anything that would
  store any type of Lisp object, as opposed to _some_ types of fast and
  hardware-supported objects, your type would be upgraded to type t with no
  questions asked.

  My advice to you at this stage in our Lisp experience is to drop _all_ of
  your concerns about types.  Do not think about it.  Force yourself _not_
  to think about types.  Think about _values_.

  Travel is a meat thing.