This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.
Marc writes: > So I send a plea to everyone: if you have a view on this subject now > is the time to voice it. A summary of my view: * Neither the original or alternate SRFI 0 proposal addresses the real problem. * The real problem is modularity. * Although it sounds hard, maybe we can solve the modularity problem --- in the restricted context of SRFIs -- by pursuing a simple, external configuration language (similar to Kelsey's refinement of the alternate proposal). To elaborate, I'll start at the beginning... What are SRFIs for? I see two reasonable answers (both within the scope of the existing documents that try to answer this question): 1. To allow an individual programmer to produce code that executes in many different Scheme implementations. 2. To allow many programmers (using many Scheme implementations) to share code that relies on more than the minimal language specified in RnRS. There's a significant difference in focus between these two goals. The first might be a useful goal, but I think that the second is a far more important one (and one that SRFIs can achieve). What is SRFI 0 for? If SRFI 0 is meant as a foundation for using SRFIs, I see two answers, in parallel to the above: 1. To define a how programmer writes source code that can adapt to different programming languages (i.e., languages with different built-in features). 2. To define how a programmer writes source code in a well-specified language (bigger than RnRS) so that other programmers can use the code. The original SRFI 0 addresses #1. The alternate SRFI 0 proposal (and Kelsey's extralinguistic refinement) comes closer to addressing #2. But, as Donovan has pointed out, even the alternate proposal provides no mechanism that allows parts of a program to use different SRFIs. If reuse is the ultimate goal, we must address the fact that code from multiple programmers will likely depend on different, possibly conflicting, SRFIs. This line of reasoning brings us to modules, of course. Mike writes: > - Module system: > Unfortunately, a general module system is far away. Are we sure? I'd like to test this hypothesis. Perhaps it's just a question of how general is "general". I wonder whether we can pin down a configuration language (outside of Scheme) that will enable modular SRFIs and sharable code. If we can, then I believe that we should push a module foundation in SRFI 0, rather than an #if-like construct. At the very least, I'd like to explore the possibility. Below is a sketch for a simple configation language. It closely resembles Ada or Modula-3. It is less than the module language I want to program with, but it is enough to write useful programs and to support modular SRFIs. It is easy mapped to existing module languages in various Scheme implementations (I think). ----------------------------------------------------------------------- The configuration language provides three first-order constructs: * Interfaces - An interface is a set of variable names (and an implied contract for the variables' use). <interface-decl> = (define-interface <i-name> (<identifier> ...)) * Modules - A module is a set of definitions and expressions, closed with respect to some basis language (e.g. R4RS or R4RS + SRFI-3) and a set of imported variables (imported from specific other modules). Some of the defined variables are exported. A module exports and imports run-time variables, not values or macros. The body of a module is in a separate file, to avoid messy reader issues, such as case-sensitivity. <module-decl> = (define-module <m-name> <module-body>) <module-body> = (body <file>) (syntax <language> ...) (export <i-name> ...) (import <m-name> ...) <language> = r4rs | r5rs | srfi-<n> | ... * Generic modules - A generic module is a module that is parameterized over (some of) the modules that provide its imports. Combining a generic module with specific imported modules defines a new module. <gen-decl> = (define-generic (<g-name> <m-name> ...) <module-body>) | (define-module (<g-name> <m-name> ...)) A program is a sequence of <config-decl>s <program> = <config-decl> ... where a <config-decl> is an interface, module, or generic module declaration, or an include declaration for textually substituting a file: <config-decl> = <interface-decl> | <module-decl> | <gen-decl> | (include <file>) A program must define a set of modules that are closed over the import relation. Running the program evaluates each definition and expression of the program's modules, sequentially within each module and sequentially across modules in the order of the module declarations. ----------------------------------------------------------------------- I've omitted some details above (because it's just a sketch), but certain aspects of the sketch are important: * Support for components - Linking among modules is hardwired into each module, which makes modules good for expressing an individual program, but unsuitable as units for sharing code. Generic modules are units for sharing code (and they are intended as compilation units). * First-order and extralinguistic configuration - If necessary, a particular configuration can be implemented by renaming variables within modules, then concatenating all modules expressions to form a sequence of top-level expressions (although this strategy prohibits separate compilation of generics). Certain aspects are unimportant: * Terminology - I chose "module", "interface", and "generic" because they seem to be the most commonly used terms. * Keywords and placement of parentheses (obviously). Certain issues are not addressed: * <file> specification - The language should define <file> so that a configuration can refer to standard library files (such as a component implementing SRFI 1) as well as files relative to the configuraiton file. * How to get SRFI N (perhaps based on SRFI M) into implementation X - I don't beleive that this is the interesting problem for SRFI 0. * Hierarchical components - I'd like to have hierarchical components, but I couldn't make them simple enough to fit into the sketch, so they're probably too complicated to be worthwhile for now. With the above sketch, I'm hoping to learn how "far away" we are from a SRFI-friendly module system. More concretely, I ask the following question of each of you: how far is the above sketch from an acceptable module system? Matthew