Re: Disjoint types in SRFIs Lassi Kortela 13 Jun 2021 10:40 UTC
> Show me any attempt and I claim that I will be able to show you its > particular flaw. OK, so there is more than one separate flaw. > No; they are not shown to people. That's why the underlying record type > is assumed to be opaque. The wording doesn't force the implementation to > actually define a record type. If it wants so, it could use the > following definition (assuming R6RS): > > (define-record-type fxmapping > (sealed #t) (opaque #t) > (nongenerative fxmapping-2bf340e5-304e-436e-8478-926c7040f3f) > (fields ...) > ...) OK, in that case a UUID seems fine. > Another alternative is to allocate human-readable IDs and track them in > a table in <https://registry.scheme.org/ > > This solution has two obvious disadvantages: > > (1) It needs a central registry outside the SRFI process. > (2) It doesn't treat every SRFI fairly. Once a human-readable ID like > "mapping" is registered, it can hardly be reused by a later SRFI. See > the rationale of SRFI 97 why it is, say, (srfi :41 streams) and not > (srfi streams). Any reason not to simply use things like "srfi-146-mapping" and "srfi-224-mapping" as the unique names? If the same type is used in more than one SRFI, it could be numbered after the first SRFI it appeared in.