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