Marcin 'Qrczak' Kowalczyk wrote:
 >>I would be interested to hear why you might want to associate source
 >>location with other types of object.
 >
 > For example to report that it obviously has a wrong type, in an
 > implementation which tries to infer some types statically.
 > E.g. (apply f 5).

I would associate this error with location of the call to apply.

 >>(b) You can distinguish small integers by having interned small
 >>integers be unboxed[**] and uninterned small integers be boxed.
 >
 > This complicates the implementation. It's silly to introduce
 > non-canonical representation of integers just for this reason.

I think you are exagerating. If you support boxed bignums, then this
approach does not significantly complicate the implementation.

 >>[**] Boxed small integers are not necessarily a serious performance
 >>problem if you use a cache of very small integers.
 >
 > It's still some performance hit:
 > - The cache is much smaller than the range of unboxed numbers
 > - Reading the value has to dereference a pointer and use processor
 >   cache
 > - There is no single representation used in various places where
 >   values are known to fit in a machine word, e.g. vector indices

I benchmarked my Scheme with first boxed numbers with a cache and then
with unboxed numbers. I found there was no significant difference. Of
course, it depends on how often you hit the cache. I was using tak,
which can stay completely in the cache.

Regards,

Alan
--
Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México