[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: loss of abstraction
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
- 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