guile-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]