John Cowan <xxxxxx@ccil.org> schrieb am Mo., 3. Juli 2017 um 16:29 Uhr:

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.

I don't want to force implementation to implement mappings as proper record types that have to conform to the full record API (and even to record APIs described in future SRFIs). For example, an implementation may choose to use a native object type to provide mappings that only behaves as a newly created record-type with respect to its type predicate. In particular, inspection would not make sense as would inheritance (in fact, there are no fields defined).

Nevertheless, my wording is rather forbidding. A more lenient/better wording:

"Mappings form a new type as if created by define-record-type. The effect of using record-type inspection or inheritance on the mapping type is unspecified."

This way, implementations can provide a way to create subtypes of mappings or a future SRFI can specify such a means.
 
-- Marc


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