Subject: Re: array types From: Erik Naggum <erik@naggum.net> Date: Tue, 17 Jul 2001 20:47:24 GMT Newsgroups: comp.lang.lisp Message-ID: <3204391641332904@naggum.net> * Kalle Olavi Niemitalo <kon@iki.fi> > 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_. #:Erik -- Travel is a meat thing.