l...@gnu.org (Ludovic Courtès) writes: > Hello, > > Andreas Rottmann <a.rottm...@gmx.at> writes: > >> Not that I have any say in that, but IMHO, it would be preferable to >> keep external libraries maintained separatly from the Guile core; >> however in this case, including it in the core might be justified by its >> proposed use in the JIT compiler. > > When we do include external libs, we should strive to leave upstream > files unmodified, as is done for (sxml ssax), (system base lalr), > (ice-9 match), and others. > As I already mentioned, the Wak adaption of `fmt' does not modify upstream files (except for the test suite); it is just adding library definition files that include the upstream files. As wak-fmt seems to work nicely on Guile, I see no problem here.
> I think it would make sense to include ‘fmt’ in core Guile only if the > API is reasonably stable and there are infrequent upstream releases, so > we don’t quickly end up shipping an old incompatible version. > I think `fmt' qualifies these criteria. 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 think the ideal solution would be to move the R6RS library definitions upstream, but I don't think that's realistic just yet, as (a) there's no built-in `include' in R6RS (I think R7RS will fix that), so an `include' implementation would either have to be shipped, again resulting in code duplication with other libraries (as `include' is portably implementable in R6RS), and (b) there's not yet a real, entrenched standard for naming of R6RS library files (which again might be fixed by R7RS, and could in the meantime be mitigated by a package manager such as dorodango, although implementation-specific library<->file name mapping is not yet implemented). Even given all that, if some core component of Guile itself (e.g., a VM code generator) wants to make use of `fmt', there's probably no way around shipping a copy in core Guile itself. Just my 0.02€ -- Andreas Rottmann -- <http://rotty.yi.org/>
