Shiro Kawai <xxxxxx@gmail.com> schrieb am Mo., 3. Juli 2017 um 00:58 Uhr:Ok, I agree with John that we leave it to future discussion; this issue is much broader than just this srfi.My immediate motivation is that I like to implement mapping as the same object as Gauche's built-in tree-map to avoid overhead of extra layer in every API. Marc's suggestion of requring disjoint from objects existing in the process wouldn't allow it anyway.Actually, it would (and this, by intent). It is up to the actual implementation whether ‘tree-map’ loads ‘mapping’ or ‘mapping’ loads ‘tree-map’ or neither loads the other library. Thus there is no guarantee that the ‘tree-map’ type is disjoint from the ‘mapping’ type as long as the specification of ‘tree-map’ does not also state that the ‘tree-map’ type is disjoint from all other types in existence at the point ‘tree-map’ is loaded for the first time.So if a program observes that ’tree-map?’ yields ‘#t’ on a mapping, the program can assume that the loading of the ‘mapping’ library took place before the loading of the ‘tree-map’ library. Whether the implementation actually did load ‘mapping’ before doesn't matter as long as it is not observable.
This is subtle indeed; e.g. for srfi-111 Boxes, I see the case that one wants a box to be disjoint from existing containers, for the box effectively works as a higher-order type: Using Haskell-ish notation, for any given type a, we want to distinguish 'a' and 'Box a', hence it excludes possibility of using existing container type as Box.Mapping, on the other hand, looks more like an abstract interface (except that it has constructors). So it looks natural that Tree implements Mapping. We do want Mapping disjoint from List, but that's because we want to distinguish 'Mapping' and '[Mapping]' in the same reason as of Box; it's because of lists rather than of mappings.But then, what about "Tree of Mapping"? Is it much different to "[Mapping]"?