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