Peter Bex scripsit:

Thanks for the enthusiastic and early feedback!

> I'd prefer to let all the "span" operations accept either a span or a
> string, but that would probably slow things down considerably, again,
> which defeats the point of this redesign.

Indeed.  As I keep telling people, Scheme is relentlessly monomorphic
(even though some implementations, like Gauche and Kawa, have their
own private polymorphism).

> conceptually, operating on string internals is a very different operation
> than writing various objects (among which strings) to a port.  It's a little
> ill-defined too, especially the "otherwise, write-string-tree does nothing"
> part.

I'll make that "takes an implementation-specific action".

> > 5) Keep compatibility routines, possibly in a different package?
>
> Which compatibility routines are those?  The remaining SRFI-13 ones?

No, the ones in the section marked "Compatibility" (bad name, I'll
change it).  Basically the case-folding and comparison routines.
The sample implementations of these will have to reify their arguments
as strings and then go through the local string-upcase, string=?,
etc, to ensure compatibility, since R7RS-small allows a fair amount of
implementation-dependence here.  On the other hand, span programming
without them wouldn't really fly.

I think we are stuck with them, and they can be made more efficient by
implementers who can allow access to the internal conversion/comparison
tables.

> > 6) I have made the argument order of string-tabulate compatible with SRFI
> > 1 list-tabulate rather than SRFI 13's string-tabulate; the discrepancy
> > was accidental. Revert to SRFI 13 argument order?
>
> No; this library isn't (fully) compatible anyway.  Let's fix any mistakes.

Agreed; issue closed.

> I'd rather see a brand new well-designed library that's completely
> incompatible with SRFI-13 than a half-baked 70% compatible library.

Well, I think we need some measure of compatibility, but I agree that we
don't need this much.  Arguably it was SRFI 1 that made the mistake (procs
normally come first in argument order), but that's long past fixing.

> > 8) Keep in-char-set?? It creates a dependency on SRFI 14, but is essential
> > for SRFI 13 emulation.
>
> I'd *really* prefer to get rid of the annoying interdependency between
> SRFI-13 and SRFI-14 in this redesign.  Besides, I don't see any point
> in having it: character sets are not mentioned anywhere else.

That is the point of it; instead of making every procedure that accepts
a pred also accept a charset, you can do things like

	(span-every (in-char-set? char-set:ascii) foo)

to verify that the span 'foo' is made entirely of ASCII characters,
without having to write an 'ascii?' predicate.

Arguably this should have been in SRFI 14, but I'm not currently interested
in replacing that SRFI.

> If someone wants to implement just this library without intending to
> implement SRFI-13, this procedure makes no sense.

"Emulation" was a poorly chosen term.  I meant that if you want to do
things like the line above, you need this procedure.  On the other
hand, it's a two-liner.

> It may make more sense to write another "bridge" library between this
> and (the new version of) SRFI-14.  Passing a predicate lambda to search
> for will likely be less efficient than having specialised searching
> functions for characters, character sets etc.

I'll think about such a library.

> On that note: I'd like to see */char variants of the searching functions.
> And perhaps */char-list, which can be implemented efficiently by inlining
> eqv? inside span-find/char-list for example.  This would return a cursor
> to the index of the first occurrance of any character in the list.

I'll think about those too.

> > 9) Bring back -ci variants of the prefix and suffix operations and
> > span-compare from SRFI 13?
>
> These would probably be useful.

But expensive in terms of calling span->string, then string->fold, etc. etc.

--
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
How they ever reached any conclusion at all is starkly unknowable
to the human mind.        --"Backstage Lensman", Randall Garrett

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-wg2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.