On Wed, Dec 17, 2014 at 08:49:02PM -0500, John Cowan wrote:
> I'd appreciate getting feedback on the pre-SRFI version of a library I
> have designed for immutable shared character sequences called "spans".

This is great!  A more efficient redesign of SRFI-13 was long overdue.
Here's my initial reply after a quick scan of the library.

> It's available at <http://trac.sacrideo.us/wg/wiki/StringSlicesCowan>
> (the term "string slice" is no longer used).  Here are the current issues:

I'm a little worried about the duplication of -span and -string operations.
This seems confusing and causes the API surface to be pretty large.
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.

> 1) Is "character span" a satisfactory name?

Seems fine to me.

> 2) Allow negative indices in make-span and subspan? Convenient, but
> irregular.

Ugly and unSchemely.

> 3) Titlecase doesn't really fit; keep it?

Too complicated and special-purpose and like you said, it doesn't fit;
drop it.

> 4) Keep string trees?

I'm not sure the name is good, but the operation is potentially useful.
On the other hand, it doesn't fit so well with the design of the library;
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.  What about user-defined records?  What about records with an associated
record printer?  And so on.  It's probably best to drop it.

> 5) Keep compatibility routines, possibly in a different package?

Which compatibility routines are those?  The remaining SRFI-13 ones?
That doesn't make much sense to me, unless you propose re-adding all the
variable argument versions as well.  That's pretty ugly and defeats the
point of this library, IMHO.

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

> 7) Currently string-mismatch returns a cursor into its second
> argument. Should it return a cursor into the first argument, or into
> both arguments? (In Chibi it makes no difference.)

Unsure.  Maybe someone else has an idea about this.

> 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.

If someone wants to implement just this library without intending to
implement SRFI-13, this procedure makes no sense.  On the other hand,
if someone wants to implement SRFI-13, they can do it in terms of the
primitives in their Scheme implementation.  This *would* cause some
unportability, but we still have cond-expand, and most current Schemes
ship SRFI-13 already anyway.

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.

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.

> 9) Bring back -ci variants of the prefix and suffix operations and
> span-compare from SRFI 13?

These would probably be useful.

Cheers,
Peter
--
http://www.more-magic.net

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports