[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Emgergency release of tla-1.2.1pre1

From: Tom Lord
Subject: Re: [Gnu-arch-users] Emgergency release of tla-1.2.1pre1
Date: Mon, 19 Apr 2004 06:29:58 -0700 (PDT)

    > From: Miles Bader <address@hidden>

    >> That's one reason why higher-level string types are being added
    >> to hackerlab.

    > That's of course a good thing.  I have noticed in what hacking
    > I've done on tla that string handling is usually pretty painless
    > -- is this interface you mean, or is there an even newer one?


tla simply uses the allocating varients of str_ functions (plus, of
course, the relational-string-table and associative-string-table
types).  In other words, str_alloc_cat (allocate space for and make
the concatenation of two strings) rather than str_cat (concatenate
into a supplied buffer).  It treats strings as "values" (just like
numbers or characters) except that strings must be explicitly
deallocated.   It's the almost complete avoidance of modifying strings
and have having to compute buffer sizes that makes strings easy in
tla.   This comes at the cost of many, many calls to str_length plus
plenty of allocation and freeing of strings.

The hackerlab plan is to have 6 string-like types eventually:

               length?    mutations?    layout?     encoding?   mem mgt?

  str_*        implicit   regions       contiguous  iso8859-1   explicit
  dstr_*       explicit   regions       contiguous  iso8859-1   ref count
  ustr_*       implicit   regions       contiguous  mixed       explicit
  udstr_*      explicit   regions       contiguous  mixed       ref count
  spstr_*[2]   explicit   value         scattered   mixed       ref count
  buffer_*     explicit   edit-buffer   scattered   mixed       ref count

  [2] "splay string"

str_ is what you see in tla.

dstr_ is a string of the str_ variety (a "region"), wrapped in a
handle that records the length of the string and keeps a reference

ustr_ is like str_ except that it works on Unicode in a variety of
mixable/matchable encoding forms.

udstr_ is to dstr_ as ustr_ is to str_.

spstr_ is a "constructive string type".   I.e., the concatentation
of two strings is usually represented as a tree whose root node
is a "+" node (concatentation) and whose two leaf nodes are the 
strings that were concatenated.

buffer_ is just what it sounds like: an emacs-ish edittable buffer.
In essense, a buffer_ is a handle object for a (variable) spstr_ 

dstr_, ustr_, udstr_ are being actively developed these days and, if
you want to learn more about those or help write tests for them, you 
should ask on the pika-dev mailing list.  See:


reply via email to

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