Re: Is there an index of symbols defined by the various SRFI's? Ciprian Dorin Craciun 27 Mar 2018 17:06 UTC
On Tue, Mar 27, 2018 at 7:53 PM, Arthur A. Gleckler <email@example.com> wrote: >> In any case I think the best "key" for a particular definition should >> be as simple as `srfi-x--<identifier>` (note the double `-` separating >> the SRFI identifier and the definition identifier. >> >> Or any other key that can be automatically derived given the library >> and definition identifiers. (This process also has to be reversible, >> i.e. having the key, deriving the library and definition identifier >> without any additional lookup.) > > > How about an s-expression-based key, like ((srfi x) identifier)? Indeed my `srfi-x--identifier` is directly derived from your proposed s-expression syntax: (string-concatenate (string-join "-" (map symbol->string (first key))) "--" (symbol->string (second key))) The reverse involves splitting strings, first on the double hiphen, then the first part on hiphens. BTW would the following library identifier s-expression be acceptable: * for actual SRFI's `(srfi n)`, or `(srfi n submodule ...)` in case a SRFI has multiple "submodules"; (I think some SRFI's, like the ones exposing both procedural and syntactic layers, have something similar); * for RxRS `(scheme n)` or `(scheme n submodule ...)` for partial implementations like `(scheme n lazy)`; (the R7RS uses such a notation, except that I introduced an `n` between `scheme` and `lazy`, to be able to note different versions of the standard;) Or perhaps for submodules we could use a third component in the key like `((srfi n) (submodule ...) identifier)` and `((rrs 7) (scheme base) cons)`, thus allowing the "module" part to be any valid object as specified by that particular SRFI or standard. (I think I'm in favour of this third component, as it decouples the first component which we can standardise upon, and the second component which is up to the author of the specification.) Ciprian.