> I've replaced extras by ports to fix the dependency stuff. I think it's > time we started making a more concrete plan on how to make the core > system use proper modules instead of "units", while still maintaining > separate compilation of course! If we use modules, this kind of bug > will be easily detected because the module refuses to compile. It will > also make the system cleaner in general because names won't "leak out" > unless explicitly imported. Anyway, this is a long-term project that > will probably require fixing #1131 (kill ##sys#alias-global-hook) first.
A few remarks: - Modules are a namespace-specific concept, units are a loading/linking concept. Are you really comparing these here? - The possibility of static linking needs to be preserved. Units provide static entry-points for compilation units, which will be needed for this. Static linking can currently not be simply dropped because of the restrictions that mobile OSs have (android with its fixed table of dynamically loadable libraries, iOS with its complete lack of dynamic loading). - The module system is currently optional - one can just use core procedures in a toplevel program without using modules at all. The machinery to make this work is admittedly ugly, but still I consider it a feature. Forcing pervasive use of modules is noit by itself a bad thing, but need to be thought out thoroughly. - It's possible that I misunderstand your intentions, considering the many meanings of the word "module" used in this context. But another issue that comes to mind is bootstrapping: if you change the imports/exports of a module that represents a core library unit, how can we prevent screw-ups due to mixing up of the import/export-information (import libraries) between the chicken that compiles and the chicken that is compiled? This can get very tricky. felix _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
