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 <email@example.com>: > >> On Wed, May 5, 2021 at 2:52 PM Marc Nieper-Wißkirchen >> <firstname.lastname@example.org> 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 RRS 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.