[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
   \__/       qrczak@xxxxxxxxxx
    ^^     http://qrnik.knm.org.pl/~qrczak/