l...@gnu.org (Ludovic Courtès) writes: > Hello, > > Andreas Rottmann <a.rottm...@gmx.at> writes: > >> l...@gnu.org (Ludovic Courtès) writes: > >> However, even if I think based on your criteria nothing speaks against >> including fmt in Guile, there is still the argument of code duplication: >> if some external library (e.g., conjure) makes use of wak-fmt and >> another chooses the version included in Guile, a third program/library >> can't make use of both of these without ending up with two copies of the >> `fmt' code loaded, incurring a load-time and memory usage overhead. >> Obviously, there's also duplicated work involved in maintaining the >> different adaptions of the `fmt' code. > > I agree. > > I think there’s a tension between the interest of Guile, which is to > provide a convenient way to access useful features, and the interests of > implementation-neutral “platforms” like Wak. For instance I find it > important to have SXML, LALR, etc. usable out-of-the-box; it lowers the > barrier to entry. > I certainly understand that. Hopefully the CPAN effort for Guile will bear some fruits and make it very easy to get additional libraries installed.
> Besides it’s still unclear (to me) what the future of Wak and similar > projects is. I hope that it will take off, but I haven’t forgotten > Snow, ScmPkg, etc. either. > Well, there's a (IMHO) important difference in that Wak packages are based on R6RS, which specifies a module system. This way, you don't really need a package manager to install the code from Wak -- you can reasonably install by copying or symlinking files. >> I think the ideal solution > > I think there’s no ideal solution, not yet. :-) > Indeed, that's why I used the subjunctive and even said that the (hypothetical) ideal solution is not realistic yet :-p. Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
