[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
virtualizing vectors and strings
From: |
Dirk Herrmann |
Subject: |
virtualizing vectors and strings |
Date: |
Tue, 25 Sep 2001 01:00:12 +0200 (MEST) |
Hello together.
What about...
* virtualizing the string interface? That is, using the 'smob' trick of
subtyping for strings? We've had a lot of discussions what kind of
string representation would be most appropriate. However, we did not
come to an agreement, although many favor the utf-8 representation since
it is used in a lot of other projects. Since, IMO, we have to live with
some performance drawbacks anyway when working with utf-8 strings, it
would not hurt a lot if in addition we would have a virtual function
dispatch. That is, in the type cell of a string object there are some
bits which encode the string's subtype, i. e. the string's
representation. Like with smobs, there exists an array of function
tables, where for each subtype/representation the corresponding handler
functions are stored.
Using a similar approach as with smobs will allow to load optimized
implementations for certain string representations on demand, like in my
case for the isolatin-1 representation. Users can then, depending on
their location, choose for themselves which representations they will
use internally.
* virtualizing the vector interface? Integrating homogenuous
numeric vector types together with ordinary vectors is currently
problematic, since for example the SCM_VECTORP macro and some other
stuff will not work for additional vector types. Like with smobs,
this will allow to provide additional specialized vector types, while
still making sure that everywhere around guile and its extensions, these
new types will be treated as vectors.
A nice side effect of this change is, that we could free a couple of tc7
codes. (Which may not be a big problem any more anyway...)
Best regards
Dirk Herrmann
- virtualizing vectors and strings,
Dirk Herrmann <=