On Mon, Jul 3, 2017 at 5:37 AM, Shiro Kawai <xxxxxx@gmail.com> wrote:

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

"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."

This looks good to me. It prohibits overly ambiguous implementation (e.g. using alists), while allows an implementation to choose to use pre-existing native object as mapping.

I agree that this achieves the same result as saying the type is disjoint. I would drop the reference to SRFI 99, however, as I don't think it adds anything. In particular, I do not see that it should be an error to create new subtypes of mapping, which is what "sealed" means.

A further issue is that SRFI 146 really introduces two types. With prefixing or renaming, you can load both (srfi 146) and (srfi 146 hash) into the same process, and then you have both mappings and hash mappings, and there is no guarantee whether they are interchangeable or not. In the (srfi 146 hash) implementation I am writing (which is almost code complete), they are disjoint, but they could be made non-disjoint by modifying the <mapping> record type to have a hash table field. The SRFI needs to take this possibility into account.

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

This great college [Trinity], of this ancient university [Cambridge],

has seen some strange sights. It has seen Wordsworth drunk and Porson

sober. And here am I, a better poet than Porson, and a better scholar

than Wordsworth, somewhere betwixt and between. --A.E. Housman