non-frugal supersedes frugal

[kilianmh]

If frugal-uuid/non-frugal is loaded once, then all calls to frugal-uuid symbols are non-frugal. E.g. libraries that depends-on frugal-uuid will still use frugal-uuid/non-frugal.

Is this intended behaviour?

[ak-coram]

Yes, this is the intended behaviour. All non-frugal subsystems should be considered improvements over the base frugal-uuid system (better random, thread-safety, better clock, support for name-based UUIDs). They are not loaded by default so you can avoid loading their dependencies if you don't need to generate UUIDs, only represent and manipulate them. The idea is that you can easily "upgrade" by loading the additional systems. I don't see any reason not to rely on them once they are loaded (except maybe for developing & testing this library).

If you use this library within another library, I would recommend relying on the minimum you need and leaving it up to your end users to load further non-frugal systems. This depends on the use-case of course.

For example my DuckDB client library used to rely on the uuid system, which includes all of ironclad as a dependency by default, which took hours to compile on my emulated aarch64 system with ECL and I didn't even use it (it's only used for hashing). Now I'm able to only rely on the frugal-uuid system which has no external dependencies.

If needed or if you don't want to rely on the defaults, I think it's already possible to force the "frugal" code path by binding a few dynamic variables (such as *unix-timestamp-function*, *v1-generator*, etc.).

[ak-coram]

@kilianmh: is the above answer satisfactory? Do you see room for improvement here?