Shiro Kawai <xxxxxx@gmail.com> schrieb am So., 2. Juli 2017 um 16:16 Uhr:
What's the intention of disjointness requirement ("Mappings are disjoint from other types of Scheme objects.
")?

Specifically, I wonder if it is prohibited that, when Scheme implementation provides, e.g. tree-map object, to just add mapping APIs to tree-map, instead of creating a wrapper type.

This is probably a general question as we provide more datatypes in srfis; what scope the disjointness requirments cover?  If a future srfi provides another mapping-like APIs, should it be with disjoint types, rather than extending srfi-146 mappings?

You raise an interesting point, indeed. In fact, the wording "disjoint from all other Scheme types", which has been in use for a long time (e.g. in SRFI 111, boxes), is not well-defined (I think, Will Clinger once raised this point as well).

For most purposes, it would be enough to require that there is a type of mappings, which is not necessarily disjoint to other Scheme types (as is the type defined by the predicate ‘promise?’ in the R7RS).

Disjointness, to some extent, however, may be needed for coding polymorphic procedures:

(define (proc x)
  (cond
    ((mapping? x) ...)
    ((tree? x) ...)
    (...)))

If trees were implemented using bare mappings without a wrapper type, the procedure wouldn't do what it is probably expected to do.
 
As a solution I propose to interpret/change the wording "Mappings are disjoint from all other Scheme types" as/into "Mappings are disjoint from all Scheme types that were in existence when the library was loaded for the first time."

(The same shall hold for boxes and all other newly introduced types as well.)

This would allow a, say, tree library building upon SRFI 146 to use bare mappings as trees. The polymorphic function from above, on the other hand, would work, if the tree library specifies as well: "Trees are disjoint from all Scheme types that were in existence when the library was loaded for the first time." This is because loading defines a total order on the set of libraries in (future) existence.

--

Marc


To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=oa8YQq670QJsajDJIblEsMJ9MoezHUAm