Re: Spec vs code, user-driven vs designer-driven
Amirouche 05 May 2021 21:37 UTC
On 2021-05-05 22:26, Marc Nieper-Wißkirchen wrote:
> Am Mi., 5. Mai 2021 um 22:13 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>> On Wed, May 5, 2021 at 2:52 PM Marc Nieper-Wißkirchen
>> <xxxxxx@nieper-wisskirchen.de> wrote
>>
>>> You can only do `(import (foo bar))' if you have your library
>>> installed where your Scheme implementation can find it. So you
>>> need to have knowledge about your Scheme outside of the
>>> cond-expand.
>>
>> I think all Schemes will look in the current directory as well,
>> which is what I depend on. But you are right that knowing where to
>> put the library file has to be external to Scheme.
>>
>>> Of course, with cond-expand built into define-library, for most
>>> Schemes, you just need 'cp' or 'mv' to install or adapt your code
>>> to a particular Scheme.
>>
>> Many R[67]RS systems have copied Vicare and Chibi respectively, yes:
>> they check the library search path for foo/bar.sld. But Chicken
>> looks for foo.bar.sld instead, Guile for foo/bar.scm, etc. These
>> rules are normally not configurable for any one Scheme. Furthermore,
>> as I pointed out, the interpretation of relative paths in `include`
>> is also not always the same as Chibi's.
I do not understand, at the moment it is already possible to write
portable libraries. It could be easier, but I do not see it as
necessary.
> So unless we want to standardize more about library locations, etc. in
I was under the impression that the library locations was left out
on purpose.
> R7RS-large (which wouldn't cover non-R7RS-large systems), having a
> well-accepted package and installer spec sounds like a good idea IMO.
That work was started with snowfort, but no Scheme implement the
existing spec but chibi?
> Such a packager could even do some source code transformation (to
> support non-standard lexical syntax).
I understand better that idea of supporting non-standard lexical
syntax. I am not sure how a package manager will help to avoid
cond-expand.
> Speaking of `include', the analogous Racket procedures may be worth
> standardizing as they cover both the question of file system vicinity
> and syntactic environment:
> https://docs.racket-lang.org/reference/include.html.
Thanks for the link.