Re: Another alternative string representation proposal 1.3

[Keisuke Nishida]

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