[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another alternative string representation proposal 1.3
From: |
Keisuke Nishida |
Subject: |
Re: Another alternative string representation proposal 1.3 |
Date: |
06 Oct 2000 14:48:50 -0400 |
User-agent: |
T-gnus/6.14.4 (based on Gnus v5.8.6) (revision 02) SEMI/1.13.7 (Awazu) Chao/1.14.0 (Momoyama) Emacs/20.7 (i686-pc-linux-gnu) MULE/4.1 (AOI) |
Dirk Herrmann <address@hidden> writes:
> This third version of the string representation proposal incorporates some
> of the suggested improvements, but also some other things:
>
> * I generalized the idea of a char-field to a memory-field. The idea is,
> that in principle its not only strings and symbols that may share
> memory regions, but one could also think of sharable uniform arrays
> etc. Even if there is currently little use for it, it's something that
> does not seem too far out of scope.
I think this is a good generalization. But why don't you call it
`memory-region'? Isn't it more ordinary?
> A memory-field has the following attributes:
> * base is a void* pointing to the base address of the memory-field.
> * length is a scm_sizet denoting the size of the memory-field.
> * owner_p is a boolean value that indicates whether the memory-field is
> actually the owner of the memory-region, i. e. whether the memory region
> should be freed if the memory-field is garbage collected.
>
> Possible double cell layout:
> <memory-field type tag/owner_p, length, base, <type-dependent-data>>
You always want to include read-only information in attributes, don't you?
If type-dependent-data can be a Scheme object, you need to add a bit for
that. But I think allowing type-dependent-data to be customizable is over
generalization; it creates a confusion. I think a reference count is enough.
Instead, you could allow more sharing patterns, like "shared mutable", by
some encoding:
-2 shared read-only
-1 shared mutable
0 no user
1 one user, mutable
>=2 several users, immutable
This allows shared mutable substrings or subarrays. (Could be useful..)
> String Type
> ===========
>
> Strings in guile are represented by shared copy-on-write memory-fields.
> Thus, a string object in guile is defined by the following attributes:
> * a memory-field object
> * an unsigned integer denoting the offset from the memory-field's base
> address where the characters of the string start
> * an unsigned integer denoting the string's length.
Why don't you use the pointer to the start address rather than the offset?
> Whether or not such situations occur is application dependent. Thus, the
> string implementation provides two functions to generate substrings:
> * scm_shared_substring, shared-substring
> * scm_copied_substring, copied-substring
> The scheme function `substring' can be bound to either one, which allows
> the user to customize the behavior of `substring' for an application or
> even parts of an application. The functions can also be called explicitly
> from user code. Moreover, a compiler can choose between the two variants,
> according to which of them seems more appropriate due to static analysis.
Good design!
-- Kei