Thomas Lord scripsit:

> Strings are like vectors and unlike bignus in that "-ref" and
> "-set!" have a natural meaning for them (although I acknowledge
> that you and I don't agree on exactly what a character ought to be).
> Strings are unlike vectors in that they are homogeneous arrays.

You say these things as if they were eternal verities.  I suggest that
they are engineering tradeoffs from a time that has long since passed.

> Perhaps the easiest-to-see examples come from systems programming
> where, for example, a string is a natural representation for a buffer
> of characters that is displayed directly on a terminal;

I think a bytevector is much more appropriate in this connection (besides
which, modern terminals are represented by pixel arrays, not character
sequences or arrays).

> or, another example, a device driver wants to accumulate characters
> in a string-like buffer before passing them to a client program.

A vector (or even a list) seems better there, but again, device drivers
don't deal in characters, but in bytes.

> In situations like those examples you very much want a stable,
> string-like object (representing a fixed region of memory) with
> mutations on the content of the string.

It isn't very string-like, though.

> If I were to build what we could call a "large implementation of small
> scheme" the type system would probably include, at its lowest levels,
> fixnums, floats, 8, 16, and 32-bit code points,

Code units, I suppose you mean.

> cons-pairs, vectors, a
> facility for deriving a new disjoint type from any earlier constructed
> type,

A Good Thing.

> a facility for creating mutable, homogeneous arrays of any
> earlier constructed type,

Not clear that this means anything for boxed types.

> a facility for constructing a disjoint immutable type from any mutable
> type, procedures, environments, locatives, symbols, low-level macros,
> disjoint booleans, and nil.

I'm not in favor of first-class environments, locatives, or low-level
macros.

> Additionally, some programs "want" to make a distinction between
> element types and sequence types.

The whole point of my efforts is to deny that strings are a sequence type.

> To go the other way we shall have
> to wrap either or both characters and strings in some disjoint type,
> leading to a needlessly inefficient representation.

Unless strings are unboxed, I don't see it.

-- 
Using RELAX NG compact syntax to        John Cowan <[email protected]>
develop schemas is one of the simple    http://www.ccil.org/~cowan
pleasures in life....
        --Jeni Tennison                 <[email protected]>

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to