> On Oct 19, 2022, at 2:20 PM, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote: > > On Wed, Oct 19, 2022 at 8:33 AM Marc Feeley - feeley at iro.umontreal.ca (via srfi-discuss list) <xxxxxx@srfi.schemers.org> wrote: > > If github.com/scheme-requests-for-implementation was the only place where libraries can be found then yes this convention would be fine. But there are other libraries than SRFIs and other “consumers” of the sample implementations than humans (e.g. package installers). > > Given the special status of the SRFI web site in setting Scheme standards, I would expect that it follow a standard layout for libraries so that it is easier to remotely access the sample implementations without making a special case for each one, or for SRFIs (vs. other sites where libraries can be found). > > If the goal is to adopt a convention that holds not only in the SRFI repos, but also elsewhere, then we'll need to bring more people into the discussion, i.e. the people who run Akku, Snow, and perhaps the Racket world. But I doubt that we'll be able to get such wide agreement. Establishing a convention that holds for SRFI would at least be a step in the right direction. > > Also the choice of “srfi” as the subdirectory where the sample implementation is stored is obviously very specific to SRFIs. Why impose a layout for SRFIs that will clearly not be followed by other R7RS libraries? > It isn't actually SRFI-specific, in a sense. It's just mapping the import clause (import (srfi N)) to the pathname srfi/N.sld. It just happens to be the case that SRFIs typically use the library name (srfi N), along with perhaps aliases. So if we just say that the convention is that all the components in the library name before the last one map to directories, and that the last one maps to the file N.sld in the deepest directory, then the convention is general. > > I propose that for a library “X” (SRFI or not) the source code file “X.sld” is stored in a subdirectory named “X”. Moreover, for SRFI N the repository would be called “N” rather than “srfi-N”. > > Yikes. I'm reluctant to change the naming convention of all the SRFI subdirectories/repos after twenty-four years. > > Why can't we define a general translation mechanism like I suggested earlier? I didn't give a concrete example, so here's one: > (define-library-mapping (srfi ,n) > (string-append "https://github.com/scheme-requests-for-implementation/srfi-" > (number->string n) > "/srfi/" > (number->string n))) > This would map all the SRFIs all at once. > There are a few issues with what you propose: 1) Currently there is no requirement (or strong suggestion) for a SRFI author to use the srfi-N/srfi/N.sld naming scheme. So a first step would be to standardize this layout (or another) and make it a requirement or strong suggestion for SRFI authors. 2) A programmer (or Scheme system maintainer) has to define such a library mapping for each library provider. In a decentralized library system there could be a very large number of library providers (close to the number of libraries). Think of the 100,000’s of Python modules. That’s why I’m advocating that a library layout be standardized beyond the specific needs of SRFIs, and ideally defined in a SRFI. 3) The define-library-mapping form has phasing issues because it executes arbitrary Scheme code both at compile time and at run time. How is this mapping information provided to the compiler and runtime system? How is it linked with a standalone executable program? This is probably quite system dependent and a big can of worms that could be avoided by having a standardized naming scheme (which is one aspect to address in a standard library layout). 4) The define-library-mapping form above does not say what will be found at https://github.com/scheme-requests-for-implementation/srfi-N/srfi/N . This is exactly the kind of information I expect a standard library layout to specify. Is that URL pointing to a .sld file, a .scm file, a directory, or other, for example is it the file: https://github.com/scheme-requests-for-implementation/srfi-N/srfi/N.sld or is it pointing to a directory where files related to that library are found, i.e.: https://github.com/scheme-requests-for-implementation/srfi-N/srfi/N/N.sld https://github.com/scheme-requests-for-implementation/srfi-N/srfi/N/N-impl.sld https://github.com/scheme-requests-for-implementation/srfi-N/srfi/N/config.ini which would make sense for modularity. The layout should also support sublibraries, such as (srfi N test) which would be the unit tests of (srfi N). It would seem natural to store that sublibrary in a subdirectory of SRFI N: https://github.com/scheme-requests-for-implementation/srfi-N/srfi/N/test/test.sld I’m afraid that not having a standardized library source code layout will hinder the use of libraries across R7RS Scheme implementations. Let’s not miss this opportunity! Marc
