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

Re: [Scheme-reports] Requesting early review of a character sequence library

Per Bothner scripsit:

> I didn't find any mention of spans over mutable strings.  One can make
> it undefined, or an error; if the latter, is it one that needs to be
> caught?

It's an error, which does not prohibit implementers from allowing it as
an extension.

> Is this proposed as part of a future Scheme specification? I really
> hope not.

That decision is premature.  Here the question is: if we are to have
such a thing, what should it look like?

> I find the duplicate set of procedures a very ugly API, and would be
> strongly against any language standard that has (for example) both
> string-any and span-any, or even both span-ref and string-ref.

I don't usually talk about libraries in the SRFIs I write, but maybe it
makes sense to put the two sets into different libraries.

> What does this API give me that substring/shared doesn't?  Of
> course I know the answer: The span API can be implemented portably
> without modifying the underlying string representation.  But so can
> substring/shared since a valid implementation is string-copy.

Valid but inefficient.  The idea here is to have something both portable
and efficient.

> But I really don't want to encourage people to program in this
> API.  As a language designer and implementor, I'd rather change the
> underlying string representation in my implementation, and tell people
> to use substring/shared.  That makes for a much simpler and elegant
> language.

I agree, but most Schemers aren't in that position.  And if true shared
strings are such a great idea, why are they confined to Guile alone?
(Guile does copy-on-write transparent sharing as well as explicit
sharing.)  Because they are pain to implement?  I suspect so.

John Cowan          http://www.ccil.org/~cowan        cowan@x
If I have seen farther than others, it is because I was standing on
the shoulders of giants.  --Isaac Newton

Scheme-reports mailing list