Shiro Kawai <xxxxxx@gmail.com> schrieb am Mo., 3. Juli 2017 um 10:22 Uhr:
On Sun, Jul 2, 2017 at 9:31 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

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.


Ok, I was thinking of Gauche's case where tree-map is built-in and srfi-146 is loaded at runtime, but certainly, when you check tree-map? works on a mapping object (or mapping? works on a tree-map object), mapping library has already been loaded and the user don't know (or care) when it has been loaded.  So, from user-observablity standpoint, either implementation may be permitted.  Am I following it correctly?

Yes.
 
If so, however, does disjointness clause have any effect?  Would it prohibit an implementation that use (list 'mapping <comparator> . <alist>) to implement a mapping?

It depends whether it is guaranteed that (scheme base) is loaded before any other library. I have been assuming this.

However, see my enhanced proposal using the semantics of define-record-type, which exactly does not have this problem as the R7RS explicitely mentions record types in section 3.2.
  
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]"?

The difference is that the basic tenets of Tree and Mapping are the same.  On the other hand, when one use alist to implement Mapping, or use one-element vector to implement Box, an alist or a one-element vector can represent one of two very functionally different data structures, yet the clue to distinguish them is only in the programmer's mind.   Probably the type analogy was misleading---what I should've said is that two data structures that differ greatly in their functionalities should be distinguishable programatically.

Thanks for the explanation. In fact, concepts of "interfaces" and automatic "coercion" could help here.