This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.
Alan Watson <a.watson@xxxxxxxxxxxxxxxx> writes:
> (a) For my Scheme, I looked at the errors I wanted to signal and
> decided that I only needed to deal with pairs, symbols, and nulls[*].
> 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).
> (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.
In my toy Scheme implementation I already had a dynamically typed host
language, so it would introduce a need of wrappers for some types like
numbers, while they weren't needed before.
> [**] 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
--
__("< Marcin Kowalczyk
\__/ qrczak@xxxxxxxxxx
^^ http://qrnik.knm.org.pl/~qrczak/