John Cowan <xxxxxx@mercury.ccil.org> writes:

> Taylan Ulrich Bayırlı/Kammer scripsit:
>
>> I think it would be better if it re-exported string-related procedures
>> in R7RS.  That way, one can import the SRFI without importing the R7RS
>> base and still get a full-fledged string library.  (Maybe one has an
>> alternative to (scheme base), some sort of DSL.)
>
> Running without a base of some sort, whether (scheme r5rs), (rnrs
> base), or (scheme base), is a pretty specialized use case that I think
> could be safely left to local adaptation.  If you have an R6RS or R7RS
> style library system, you can always import just the procedures you
> want.  The only new string-related procedures in R7RS are string-map,
> string-for-each, string->vector, vector->string, and string-copy!, each
> of which is trivial and none of which are required by the portable
> implementation.  In addition, some R7RS string procedures support
> start/end arguments even though their R5RS counterparts do not.
>
> The fact that SRFI 1 theoretically exports primitives like car, cdr, and
> cons, as well as non-primitive but overwhelmingly common procedures like
> length, has never been anything but a theoretical wart and a practical
> nuisance.  SRFI 13 excludes R5RS `string=?` (it has a different procedure
> for string equality), and there was a lot of confusion on the SRFI 13
> mailing list about whether conforming to SRFI 13 required removing or
> hiding `string=?` from one's implementation (this is before library
> systems were commonplace in Schemes).  If (as I assume) SRFI 1 becomes
> the (scheme list) library in R7RS-large, I will add a note saying that
> the R7RS-small procedures are not imported by (import (scheme list)).
>
> At some point someone should write a portable and comprehensive R7RS
> shim that provides every procedure in the R7RS library using only the
> R5RS library, analogous to the various syntax expanders.  At the moment,
> most of my SRFI sample implementations are written in R7RS but come with
> minimal shims that provide what is needed to let them run on Chicken at
> least: adaptation to other R5RS+ systems should be straightforward.

I don't understand what R5RS has to do with this...

What's the problem with re-exporting base bindings?  Importing the same
binding from two libraries is not an error in R7RS.  Maybe SRFI 1 was
too optimistic for its time, but given R7RS library semantics it seems
like the right thing.

Taylan