> I would think that support for Chicken 2 & 3 should be dropped after a > Chicken 5 branch is made.
Yes, that sounds reasonable. > 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. > Is this not the case? What are the goals for a Chicken 5 release? Mostly cleaning up. Shrinking the core system will make maintenance easier, and reduces the need to follow our usual patch-review process. It also allows to use alternatives to cast-in-concrete APIs (like srfi-18) in an easier way. A smaller core system makes it also easier to use it on embedded systems, in particular on systems that don't need loads of external libraries. Restructuring the libraries is required to make things easier for users, especially newcomers. The current library structure is mostly arbitrary. This is not a problem for long-time users, but where what procedure can be found is currently very unintuitive - one just has to know about it, or use tools like chicken-doc all the time. 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... felix _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
