> > 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.
The compiler and egg-setup stuff need a number of srfi-1/13/14 primitives, and the core tarball should be self-contained, so I see not much chance to eggify more of the base system. > We already support this syntax through the R7RS egg. BTW, what's the status of that egg? The last time I looked it seemed to be basically complete. Or is there still anything missing? (I know there are some rough edges, and obscure warnings, but does it basically work?) > 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). (add1 from me...) > The simple solution would be to stuff everything into a "core" module > which nobody but the core system is supposed to really use. We could > then define r4rs and r5rs/scheme as modules which import the whole of > core and reexport only the relevant procedures. What you mean by "everything" here? All the ##this#.. and ##that#..., or the non-standard chicken procedures that are usually exported from the "chicken" module? > > But there's still the problem of code which replaces primitive > procedures. However much this is frowned upon by "modern" Scheme > standards, this is something that is explicitly allowed by RnRS | n < 6. > AFAIK toplevel code can do that even with identifiers exported by egg > modules, so perhaps this is not an issue. We have to test it though, and > luckily r4rstest.scm already checks this. The module system doesn't prevent this, it just renames identifiers, but doesn't change the semantics of assignment. > 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. Be aware that a platform-independent layer over those syscalls is quite some design work. There is a reason why so many library implementations often fall back to doing exactly this: wrapping each and every syscall (look at ocaml, or the SML basis library). Take windows into the equation and things get even worse. POSIX is not the most ideal API "standard", but at least it is something one can start with, even if Windows support is somewhat painful. > >> I am very interested in this undertaking and want to help you out. > > That would be much appreciated, once we get started. Indeed. felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
