> Yes, in Chibi this is the meta-level module language. I can see how > this would be less elegant in implementations without a meta-level. Good point. >> This can also >> be interpreted as "import the named library and >> re-export all exported identifiers" (the name is >> debatable), and if so, you can add more definitions >> there to enhance the original library. Pros are that >> (1) it is clear that it's define-library level >> meta-syntax and not an ordinary macro, and (2) in the >> latter form, you can put additional definitions. Cons: >> it might be too flexible---too easy to write many >> libraries that adds little something to existing >> libraries, like what happened in the inheritance of OOP, A further problem with extensible libraries is, what happens if the original library is re-defined (reloaded) and adds or removes exports compared to the old one? There's another virtue to a simple define-library-alias: documentation tools can directly tell the user that a library is an alias of another. This is potentially very helpful for newcomers to Scheme. With an aliased library, the whole library can be a simple indirection to another library. There's no need to do extra work to walk the exports and keep them in sync. > Another option is to extend define-library syntax, e.g. > (define-library (alias <library-name>)). With this specific syntax, you could no longer create libraries whose first library name part is `alias`. >> (define-library (scheme bitwise) (alias-for (srfi 151))) > In terms of personal preference, I like alias-for and prohibit any other > library declaration. This is my favorite proposal so far (in addition to `define-library-alias`). > Gauche has also export-all, but I started feeling ambivalent on it, when > used in place of export. It's good at the start of a new library when > you don't know how the public API will be, but eventually you got sloppy > to replace it with proper export, and exporting things that should be > kept internal. Exactly. Python had `from foo import *` all over the place and people got sloppy. They eventually had to add a feature where each library can specify which of its identifiers belong to the `*` set :) I love the fact that Scheme doesn't have an export-all. You can then see the public API at a glance by looking at the export forms in a `define-library`, and it's reliable. Also makes it easy to write code walkers to explore the public APIs. > There are several interpretations of export-all. [...] Probably > the most intuitive implementation if the set of > top-level definitions plus all imported bindings. Since most libraries do (import (scheme base)), re-exporting all imported bindings would add to the kind of namespace pollution that Shiro warned about. > A variant which avoids this ambiguity is export from: > > (define-library (scheme bitwise) > (import (srfi 151)) > (export (from (srfi 151)))) This is reasonable and interesting. But is it overkill - is there a need for a library to be a union of two or more libraries? I'd still prefer an explicit list of exported symbols for each library that is not strictly a simple alias of another. > However, the cons you mention swayed me. I didn't want the > added flexibility or > discussions about resulting semantics. What if you alias > multiple libraries? What > if you alias and then add some definitions? +1 > > Also, this is more lightweight - there is only one library > object, which can be referred > to by either name in the library registry. +1
