How to include a part of SLIB which is also a SRFI?

[jpellegrini]

SRFI-95, for example, is part of SLIB, and STklos users do have access to SLIB. But it would be nice to have SRFIs working in a uniform way, no? So the user could just (require "srfi-95")?

In this case, would it be OK to duplicate the code from SLIB?

I see one problem -- if SLIB is updated, then the code in STklos could lag behind. If SLIB was hosted in a git server, STklos could have it as a git submodule, but... SLIB still uses cvs!

[lassik]

The public interface of a SRFI is frozen when the SRFI is finalized, so it can no longer change. I'm not sure whether or not an existing SLIB library's interface can change in the future.

[lassik]

In both cases (SRFI and SLIB), the implementation can of course change to fix bugs and optimize performance.

[jpellegrini]

In both cases (SRFI and SLIB), the implementation can of course change to fix bugs and optimize performance.

Yes -- that's what I meant. If the implementation in SLIB changes, we wouldn't get it automatically. We may not even know about it... But I see there's no other way - maybe it is the case of clearly tagging the STklos included version with a comment in the code.

[lassik]

clearly tagging the STklos included version with a comment in the code.

This is a good idea.

[egallesio]

Hi @jpellegrini and @lassik,

I thought that Aubrey didn't develop anymore SLIB and I was surprised to see that he published a version in 2020. Anyway, by looking at the changelog, the development pace is low and last time that the sort file has been touched is in 2011 (after the publication of this SRFI anyway). Since the portion of code is small and since the probability that this code evolves (for the sample implementation given in the SRFI, as well as for the SLIB one), I think that a duplication is OK in this case. The risk to have a divergence of code is quite low imho.

[jpellegrini]

Okay! :) I suppose this issue can be closed also...

[lassik]

Sounds good.

Chibi-Scheme recently added a "library alias" feature, so that one library name can simply be an alias for another, and either name can be imported. Gauche has a similar (but more comprehensive) feature where a library can extend another library (similar to how an OOP subclass extends its superclass).

If some libraries are in both SRFI and SLIB, an alias feature could come in handy.

[lassik]

Here's an example from Chibi: https://github.com/ashinn/chibi-scheme/blob/master/lib/scheme/comparator.sld

[egallesio]

In fact, we also hav alias on symbols (and by introspecting a module we can find all the symbols of the module)

stklos> (define a 1)
;; a
stklos> (%symbol-alias 'b 'a)
stklos> b
1
stklos> (set! b 100)
stklos> (cons a b)
(100 . 100)

If some libraries are in both SRFI and SLIB, an alias feature could come in handy.

In fact, the problem is that SRFIS are provided with STklos distribution, but the SLIB is not (and is not mandatory). So, we cannot suppose that the SLIB is present for implementing a given SRFI.

[lassik]

In fact, we also hav alias on symbols (and by introspecting a module we can find all the symbols of the module)

The R7RS library system can re-export symbols natively:

(define-library (foo)
  (import (only (bar) a b c))
  (export a b c))

[lassik]

But you have to manually write all the symbols a b c in the export clause. This is arguably a good thing: automatically re-exporting "all symbols defined in bar" will easily have an unexpected effect since it's easy to forget the existence of some internal symbols and accidentally export them.