Subject: Re: Types (in arrays)
From: Erik Naggum <>
Date: 2000/03/06
Newsgroups: comp.lang.lisp
Message-ID: <>

* Andrew Cooke <>
| I have a program that needs to store many arrays of words (16 bits).

  the available types are then (unsigned-byte 16), (signed-byte 16), (mod
  65536), (integer 0 65535), (integer -32768 +32767), etc, which all should
  mean the same thing: 16 bits of allocated data per element of the array.
  if they don't behave the same, you probably have a broken Common Lisp

| My questions are really:
| - How do I know which type specifiers are simple enough for a compiler
| to understand the implications (1 clearly wasn't - although I may be
| wrong in thinking it is a valid type specifier)?

  the function upgraded-array-element-type will return the internal type it
  has deemed most optimal for the array element type you have requested.

| - Why does case (3) fail silently?

  probably because the implementation only checks for types it knows, and
  consider it risky to comment on stuff it doesn't know about.

| - How are types used?  There seem to be several different things going
| on at once - memory size allocation, testing when new values are stored,
| initial value allocation (I get zeroes rather than nill if the type is
| numeric, for example).

  this is a very big question.  the simple answer is that the vendor has
  made a number of decisions that are believed to give optimal performance,
  both in time and space, given the type information you have provided.
  now, this is not quite the useless answer it looks like, because it means
  that each vendor will make "personal" decisions about what constitutes
  "optimal performance" -- and these decisions will naturally differ quite
  a bit from person to person.  one rule of thumb prevails, however: useful
  optimizations always reflect the capabilities of the aunderlying hardware,
  so you have to have a fairly good grasp of how the implementation uses
  machine resources to make the decisions.  I'll leave it at that for now,
  since this is issue that very quickly becomes suiteable for comp.arch.