Hello, Andreas Rottmann <a.rottm...@gmx.at> writes:
> l...@gnu.org (Ludovic Courtès) writes: [...] >> 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. OK. > 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. 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. > I think the ideal solution I think there’s no ideal solution, not yet. :-) Thanks, Ludo’.
