[bitc-dev] Code for bitc_vector_string

Jonathan S. Shapiro shap at eros-os.org
Mon Jul 3 14:28:30 EDT 2006


On Mon, 2006-07-03 at 18:34 +0100, Sam Mason wrote:
> Hi,
> 
> For some reason the compiler didn't seem to be doing good things for
> me today, so I filled out the implementation of bitc_vector_string
> in libbitc/string.c.  It currently makes two passes over the vector,
> one to figure out how big the encoded string will be and another to
> actually do the encoding, but I can't think of a better way to do it.
> 
> It's not very nice code (there are now several places that do remarkably
> similar things with UTF8 encoded strings) and if you have any suggestions
> about what to do with the shared code I'll be happy to restructure things.

Sam:

If you are able to donate the code, we'ld be glad to take it.

Agreed about the UTF8 functions -- these need to move from libbitc into
the runtime library, if I can figure out how to do that cleanly. Then we
will only have one copy.

> I've got a (hopefully) quick question about the vector indexing shorthand
> of using square brackets (e.g. v[i]).  Why isn't this in a typeclass
> like length is with Length?  It would allow array indexing to work with
> the same syntax very easily.

Eventually it will be, as will (nth <expr>). The problem is that
expr[ndx] is a location expression, and we don't have the type system
support for generalized locations. Writing

  (set! a[i] 5)

is NOT the same as

  (set! ((lambda () a[i])) 5)

This means that [] is syntactic -- it isn't an accessor. At some point
we will add location types and this will get relaxed somewhat, but that
is trickier than it sounds.

And it won't help with arrays, because the length of the array is part
of its type and there is no way to do literal class. What's needed here
is a type that is something like like:

  (forall ((Indexable 'a) (Word sz)) (array 'a sz))

Note that 'Word' isn't a type class here -- it's a literal class. BitC
doesn't have those, and probably never will. Arrays are actually the
only motivating case, and they exist solely for legacy reasons.


shap



More information about the bitc-dev mailing list