On 06/26/14 16:33, Peter Bex wrote: > On Mon, Jun 23, 2014 at 04:02:59AM +0400, Oleg Kolosov wrote: >> On 06/19/14 23:27, Peter Bex wrote: >> Units are also used for separate compilation of large code bases. It is >> not always make sense to separate everything into modules. This is >> useful, but should be build only matter. AFAIK, current system does not >> allow to transparently switch between module and unit mode for the given >> source file. We can try to add an option for chicken to mostly ignore >> module declarations and just issue some useful warnings but compile as a >> unit. This approach will enable incremental migration. > > That's an interesting idea. It might work, but I'm also unsure of the > added benefit; if the code is always compiled separately in the "ignore > modules" mode, it won't add the intended benefits of additional checking > of dependencies and exports.
I mean an option to compile like: internally convert (module <name> <exports>) to (declare <name>), hook import somehow into this for rename and such, issue warnings for names still unresolved but just continue and generate a unit. This will allow having something working during conversion to modules and not require to declare and resolve everything at once. This is all hand wavy, I have not investigated technical details too much, but it seemed not so hard to do at first sight. >> ...cific details, maybe it is already improved. An ability to split up >> the Chicken runtime might will be helpful, currently it is too big and >> contains many unnecessary things (can be moved into eggs). Windows ... > > I'm unsure how much further we can strip down the core. Perhaps we can > drop SRFI-1, SRFI-13 and SRFI-14, which would be just fine as eggs. But > currently core is using some procedures from these. I think that this is > a separate issue, though. Refactoring stuff as modules is a shitload of > work which is not yet certain to be feasible, and we should not drag more > work into this project. Eggs was not the right word. I meant to just split it up more and make most components optional. I was under an impression somehow that this was the point of "call to arms". The motivation here is that we found out that Chicken works surprisingly well on embedded devices and want to integrate it even deeper (like initramfs, firmware updater and such). An experiments show it is possible to reduce runtime size to at least half of it's current size and still have something usable. But it is too troublesome to do manually, modularization will definitely help here and looks like good thing in general. >> What do you think about Chibi Scheme approach >> (http://synthcode.com/scheme/chibi/#h2_ModuleSystem)? >> Also, having compatible (and standard compliant) >> module system is a huge selling point IMO. > > We already support this syntax through the R7RS egg. We can't just > switch to the R7RS module system in core because it would break 100% of > the user code out there, for no technical gain whatsoever. CHICKEN core > is an R5RS system, and adding an R7RS module system to it adds no > benefit if everything else from R7RS is only available as an extension. > > We have already too many people asking about the difference between use, > require, require-extension, uses etc. Adding a second module system to > core would only add to the confusion (and *replacing* it would break the > world). The idea is: require and friends are not necessary at all (and confusing). The user should just use import and let the runtime system figure it out. Like John mentioned earlier. The only real use case for detailed control over library loading I can imagine is the support for module hot reload. >>> Indeed, bootstrapping is an ever-present pitfall. And there's also >>> library.scm which does not really correspond to a particular module. >>> Perhaps to "scheme", but not exactly. > > Yeah. Especially the stuff from posix should be cleaned up. There are > plenty of things unrelated things in there at varying abstraction levels, > which is only stuffed in there because it's somehow related to an > underlying syscall that's defined by POSIX. This is a little too > system-specific for me; it would make more sense to group those things > together into things like files, process-control, user-management etc, > and define modules in that way. > That got me thinking: maybe we could implement module versioning? Not just put everything into lib/chicken/<API_VERSION> but proper module.so.1.2.3 like other shared libraries? And somehow add this to imported namespace (##module#1.2.3#procedure or so). In theory this should allow to move stuff around, but can open a whole can of worms, but still, what do you think? -- Regards, Oleg _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
