Anyone to help with .sls/.sld files? Artyom Bologov (30 Aug 2024 13:29 UTC)
Re: Anyone to help with .sls/.sld files? Amirouche (30 Aug 2024 14:32 UTC)
Re: Anyone to help with .sls/.sld files? Lassi Kortela (30 Aug 2024 15:45 UTC)
Re: Anyone to help with .sls/.sld files? Artyom Bologov (30 Aug 2024 18:27 UTC)
Re: Anyone to help with .sls/.sld files? Lassi Kortela (30 Aug 2024 19:29 UTC)
Re: Anyone to help with .sls/.sld files? Lassi Kortela (30 Aug 2024 20:50 UTC)
Re: Anyone to help with .sls/.sld files? Artyom Bologov (31 Aug 2024 00:03 UTC)
Re: Anyone to help with .sls/.sld files? Retropikzel (31 Aug 2024 14:17 UTC)
Re: Anyone to help with .sls/.sld files? Arthur A. Gleckler (31 Aug 2024 16:02 UTC)

Re: Anyone to help with .sls/.sld files? Lassi Kortela 30 Aug 2024 19:29 UTC

>> Using `export` inside `cond-expand` is an anti-pattern. A library
>> should export the same set of identifiers in all cases.

> Okay. Let it be this way, even if they end up unbound.

>> (cond-expand ... (else)) is probably not appropriate here. It may
>> cause an unsupported implementation to silently import the library
>> until the user attempts to call one of the non-existent procedures. If
>> you leave out the `else` branch, a well-behaved Scheme implementation
>> will raise an error at import time.

> No, the (else) part makes sense here: implementation-specific files are
> extensions over the impl.generic.scm, adding things on top of an
> otherwise self-sufficient base library. So the empty (else) is simply
> sticking with defaults.

Sorry, but there seems to be something fundamentally bogus about how the
code is laid out.

The R7RS library has this:

   (include "impl.generic.scm")
   (cond-expand
    (chicken
     (include "impl.chicken.scm"))
    (gauche
     (include "impl.gauche.scm"))
    (kawa
     (include "impl.kawa.scm"))
    (stklos
     (include "impl.stklos.scm"))
    (else)))

So impl.generic.scm is included unconditionally. But then the
implementation-specific .scm files override some of that stuff.

And different implementation-specific .scm files define different
exported identifiers. Or am I misreading something?

$ grep '^(' srfi/*.scm
srfi/impl.chicken.scm:(import-for-syntax (chicken type))
srfi/impl.chicken.scm:(define-syntax values-checked
srfi/impl.chicken.scm:(define-syntax %declare-checked-var
srfi/impl.chicken.scm:(define-syntax %declare-checked-fn
srfi/impl.chicken.scm:(define-syntax define-checked
srfi/impl.gauche.scm:(define-syntax check-arg
srfi/impl.generic.scm:(cond-expand
srfi/impl.generic.scm:(cond-expand
srfi/impl.generic.scm:(define-syntax check-arg
srfi/impl.generic.scm:(define-syntax values-checked
srfi/impl.generic.scm:(define-syntax let-checked
srfi/impl.generic.scm:(define-syntax %lambda-checked
srfi/impl.generic.scm:(define-syntax lambda-checked
srfi/impl.generic.scm:(cond-expand
srfi/impl.generic.scm:(cond-expand
srfi/impl.generic.scm:(define-syntax define-checked
srfi/impl.kawa.scm:(define-syntax values-checked
srfi/impl.kawa.scm:(define-syntax %lambda-checked
srfi/impl.stklos.scm:(define-syntax check-arg

A Scheme library should not define an identifier and then later redefine
it (in an attempt to override the previous definition). The cond-expands
should arrange things such that there is always:

- Exactly one definition of each identifier.

- Always the same set of identifiers exported from the library.

Additionally, if you want to use cond-expand inside the .scm files, you
should use (include-library-declarations "foo.scm") instead of (include
"foo.scm"). If you use (include "...") then the included code is wrapped
in an implicit (begin ...) which is not portable.