[bitc-dev] Arrays -- request for advice

Jonathan S. Shapiro shap at eros-os.org
Wed Jul 20 12:39:18 EDT 2005


In the course of removing restricted types, I came across a minor
problem.

BitC currently has two sequence types: array and vector. An array is
fixed size and unboxable. A vector is dynamically sized.

The primary reason to have arrays was to deal with certain kinds of
foreign functions that return structures containing C-style arrays,
where we are obliged to honor the representation of the existing API.

We introduced sequence types mainly so that we could do things like
iterators. This arose from a combination of three issues:

  1. We didn't want an extra, "hidden" size variable associated
     with arrays, and

  2. We felt that Pascal's inclusion of array lengths as part of
     the array type was a mistake, and

  3. I didn't understand enough about types and pattern matching
     to realize that we could make this sufficiently polymorphic.

Note that this is really only an issue for argument and return value
passing,

It seems to me that there are three things that we can now do:

1. Augment the array type to include the array size:

   Revise the array type from (array T) to (array T il),
   where "il" is handled as a special case known to the
   compiler and the constructor requires an integer literal
   of type word.

   Define the calling convention to allow polymorphism over
   the array length. When the length component of the type is
   polymorphic, a hidden "length" parameter is passed at the
   calling boundary.

   In the absence of type classes this appears to be the only
   sensible thing, but it is a wart on the type construction
   mechanism.

2. Re-introduce "sequence" as a type class, relying on automatic
   instantiation to generate a specialized dictionary on behalf
   of each array size that is actually instantiated.

Does anyone see other options that would be both feasible and practical?


shap



More information about the bitc-dev mailing list