"Mappings form a new type as if created by define-record-type. It is an error to use record-type inspection or inheritance on the mapping type; i.e. the mapping type is sealed and opaque in the language of SRFI 99."

(The intended semantics are very much those I proposed before, but leaves the exact semantic definition to the report where it belongs, and so "kicking the can down the road" as John put it.)

--

Marc

Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> schrieb am Mo., 3. Juli 2017 um 09:31 Uhr:

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]"?

 

--

Marc

However, probably talking about interface is too early; we already have an issue that, even this srfi suggests hash-based mappings being provided with the same API, this srfi alone doesn't allow one to write a generic algorithm using mapping interface that works for both comparison-based and hash-based mappings without writing manual dispatch for every call of mapping API. 

I reckon that this issue would be addressed with some comprehensive srfi that deal with polymorphism.  With that, we'll be able to apply generic mapping procedures on srfi-146 mapping objects or native tree-map objects.  So I now support to leave the disjointness clause as it is now.

On Sun, Jul 2, 2017 at 11:07 AM, John Cowan <xxxxxx@ccil.org> wrote:

On Sun, Jul 2, 2017 at 4:36 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

So, mapping? would return #f on all existing objects and on all possible return values of existing procedures, where "existing" means "existing in the Scheme process before the mapping library was loaded".

Well, that's clear enough, but I don't think it's *strong* enough.  It excludes the possibility that `mapping?` returns #t on a pair, but not the possibility that `pair?` returns #t on a mapping, in case someone were dumb enough to implement a mapping as a raw alist.

Disjointness is complicated.  For example, I've been wondering if SRFI 14 character sets really must be disjoint from SRFI 103 general sets.  They are both linear-update, so that's not a problem, and covariance/contravariance is not an issue either, because there is no overloading in (standard) Scheme.  So loosening the disjointness constraint would just mean that in some implementations, general set operations would work on character sets, and in some implementations they would not, which is in the scope of "it is an error".  The same issue will come up again fairly soon with the forthcoming integer-set SRFI. 

I am still inclined to kick the can down the road for future resolution.

-- 

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org

Statistics don't help a great deal in making important decisions.

Most people have more than the average number of feet, but I'm not about

to start a company selling shoes in threes. --Ross Gardler

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