William D Clinger scripsit:
> Quibble: I think the historical view of strings should be
> continued for backwards compatibility with Scheme tradition.
In that case, you also have to make characters something other than
Unicode scalar values, or else go to very tricky implementations.
I'm trying to break as little of R5.92RS as possible.
> a couple of ambiguities in his specification of string-slice.
Please specify.
> Here is a brief outline of what John could have proposed had
> he been willing to make texts and positions into new types.
I think the only way to make this fly is to introduce a CL-style
distinction between characters (in texts) and basic characters
(in strings), though keeping the name "character". Alternatively,
we could say that strings are sequences of Scheme character objects, but the
atomic unit of texts is a text containing a single (Unicode) character.
However, I'd be pretty unhappy with doubling up like this. There is
little or nothing that strings can do that texts cannot.
> I also think it would be straightforward to implement the
> text and position types portably using the current draft's
> records, bytevectors, and strings. That implementation
> could easily achieve the "should be O(1)" level of
> performance, except make-text would always have to copy its
> argument because there is no portable way to tell whether
> a string is immutable, or whether its immutability would
> be enforced even if it were.
For that matter, you can implement R5RS strings as vectors,
provided you are allowed to redefine "vector?". If strings
are massively more efficient than texts, though, people will
go on using them.
--
John Cowan cowan at ccil.org http://ccil.org/~cowan
Any sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp.
--Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)
Received on Mon Apr 09 2007 - 23:47:57 UTC