🚀 go-pugleaf

> Jeff Dalton (jeff@aiai.edinburgh.ac.uk) writes:
> 
>   ...  For instance, why should I write code for vectors with as many
>   as, say, 1000 elements when I can write instead for "vectors as big
>   as this Lisp can handle"?  Why should I have to pick a number?
> 
> Well, this probably only works for that particular example, but you
> can always build implementation constants into your own type
> definitions:

Sure, but what should I have to do this?

Indeed, there's a huge range of object indexing applications where
fixnums are virtually guaranteed to work.  Why?  Because in most
implementations the number of bits in a fixnum is at least as great
as the number in a pointer.  Maybe you lose on the sign bit, but
then objects are almost never (un)aligned so that all pointer bits
are needed.

If you want to worry, you can check.  Often people don't check.
Does this mean their code isn't portable?  Probably.  But so is
code that assumes it can make arrays with more than 1024 elements.
Does that mean code that calls MAKE-ARRAY without checking is
completely beyond the pale?  That it might as well be written as
a random sequence of characters?  I think not.  (But some people
claim something very close to this when it comes to standards.
I think they are wrong.)

> Then again, by type inference, the compiler SHOULD be able to figure
> out the range of I anyway.

Certaily in some cases.

-- jd