Felix Winkelmann scripsit: > All eggs that use queues, mmap, binary-search and eviction will break. > This is manageable, as salmonella will point them out to us, but I'd > also like to eggify srfi-18, srfi-69, srfi-1/13/14 and perhaps srfi-4 > as well and all that (including the /really/ massive changes related > to core unit restructuring) will require us constantly running after > broken eggs.
A couple of simple things come to mind. 1) Deprecate all mechanisms for creating units. Provide a compiler switch used when building Chicken to shut off this warning. 2) Deprecate all mechanisms for loading units except `use` (and presumably `require-extension`, which is equivalent to it). `Use` is safe because it will load either a unit or a module without problem. (Which eggs, if any, are not modules at this point?) 3) Set up the meta language so that if it attempts to require an egg that is present as a unit, it just uses the unit. > I wonder whether it isn't better to postpone releasing these changes, > by creating development branches and switch in one step to CHICKEN 5, > which would have a number of advantages over doing all that in a > piecewise fashion: I'm agnostic about this. There will be a lot of eggs that will have to be maintained in two versions, no matter what. I think we should continue to think about ways to ameliorate that. -- John Cowan http://www.ccil.org/~cowan co...@ccil.org In computer science, we stand on each other's feet. --Brian K. Reid _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers