On Tue, Aug 19, 2014 at 05:21:06PM +0200, Felix Winkelmann wrote: > > I would think that support for Chicken 2 & 3 should be dropped after a > > Chicken 5 branch is made. > > Yes, that sounds reasonable.
I didn't know we still supported CHICKEN 2 and 3. In what way is that done? AFAIK the server-side component for "chicken-setup" is no longer active. Is it? > > I had also implicitly assumed that the modularisation changes would help > > bring full R7RS support to core. > > I think it is R7RS support will be in an egg for the time being. Once > we figure out the remaining issues, this should be usable in a rather > seamless way. Works for me. I do think, however, that we should take a good look at the r7rs library names, and probably adopt them wholesale, for the parts that we implement. This would make CHICKEN easier to use for people using multiple Schemes, and for newbies coming from other Schemes. It would also ease our burden at figuring out good names: half of the stuff will suddenly *have* a good name. Note that this does _not_ imply we should implement things that we don't already have, just move the things we do have under the names defined by R7RS. If we have something that's close to R7RS but not identical, we may decide to tweak it to match R7RS. Except for R7RS-style parameters ;) > Finally, using more modules in core catches many errors related to > wrong naming, or unintended cross-references between library units. > > Oh, and should we ever want to have a fully "transparent" import that > always does The Right Thing, then a cleaned up and more modularized > core will be essential to that. > > We really need to address the cruft that has accumulated over more > than a decade... "proper cleanups" are very dangerous. However, if done right, they can make life better. Cheers, Peter -- http://www.more-magic.net _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
