I don't think that having modules is too big for small scheme. It's also probably desirable to have the module system made by the a given scheme implementation. That leaves them with the freedom to implement modules in whatever way is best suited for their internal implementation of environments. As long as there is a standard public/behavior provided by the working group of small scheme, the module system itself would not make small scheme big.
I'm all for having standard module system in small scheme. I'm also all for keeping that module system with small and simple public interface. Pavel On Mon, Aug 24, 2009 at 12:44 PM, Thomas Lord<[email protected]> wrote: > On Mon, 2009-08-24 at 14:51 -0400, John Cowan wrote: >> Thomas Lord scripsit: >> >> > Why not just stick to the much simpler REQUIRE and use naming >> > conventions to distinguish exported from internal definitions in >> > a library? >> >> Naming conventions collide: some day there may be more than one Tom Lord >> writing Scheme code. Name prefixing puts the library *user* in control >> of the conventions rather than the library author. (The other import >> specifications, "only", "except", and "rename", support trivial special >> cases: I wouldn't die to see them go.) > > Ah. I just stupidly skimmed too quickly over the chicken > docs you pointed me at and missed that it does import > renaming/aliasing (with "prefix"). Sorry for the noise. > > So, yeah, the Chicken module system has the advantages > you describe over just require/provide. > > I still say it's too big for small scheme (and too > small for big scheme). In small scheme without it, > you could implement something very close to it in a > library, as syntax. You'd wind up with something that's > more flexible (e.g., permitting open-ended ways to have > multiple instantiations of a given "module"). > > >> > There's nothing "of the essence" about the chicken module system. >> > I presume it works very nicely in the context of Chicken but it seems >> > kind of redundant and ad hoc and it adds implementation complexity - >> > all of which I think disrecommends it for small Scheme. >> >> There's nothing "of the essence" about map and for-each either, but we >> don't want to give them up. > > Oh, I wouldn't mind seeing map and for-each pushed > off to libraries. Not at all. Now that you mention it > it sounds like a good idea. I'm not sentimental. > > You (separately) asked what characters from ASCII I > would omit requiring: any that aren't part of the > lexical language, is the answer. > > I'd (personal preference) like small scheme to be > something that can run on a 1-watt, low-memory > system in, say, a light switch. I'd like to be able > to use it in situations where I'm never going to > load it up with more than a few lines of code (and > couldn't, even if I wanted to). But the small scheme > standard tells me what those few lines of code mean. > > By "of the essence" I mean that I just want the > definition of small scheme to capture some basic > properties of lambda and some invariants for basic > data types and a some minimal form of syntactic > extensiblity (hygiene not being high on the priority > list but flexibility is). > > Heck, let's push AND/OR/IF/COND etc. off to a > library. Most every implementation will likely > have them built in, and that's just fine, but... > > Something like the core language to which Rabbit > reduced all syntax... > > -t > > > > > _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
