Email list hosting service & mailing list manager

Disjoint types in SRFIs Marc Nieper-Wißkirchen (13 Jun 2021 09:06 UTC)
Re: Disjoint types in SRFIs Lassi Kortela (13 Jun 2021 10:16 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (13 Jun 2021 10:29 UTC)
Re: Disjoint types in SRFIs Lassi Kortela (13 Jun 2021 10:40 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (13 Jun 2021 11:50 UTC)
Re: Disjoint types in SRFIs Lassi Kortela (13 Jun 2021 11:55 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (13 Jun 2021 13:11 UTC)
Re: Disjoint types in SRFIs Daphne Preston-Kendal (08 Dec 2021 11:06 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (08 Dec 2021 12:40 UTC)
Re: Disjoint types in SRFIs John Cowan (08 Dec 2021 18:21 UTC)
Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe (13 Jun 2021 18:58 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (13 Jun 2021 19:18 UTC)
Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe (15 Jun 2021 19:31 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (15 Jun 2021 20:52 UTC)
Re: Disjoint types in SRFIs John Cowan (15 Jun 2021 21:55 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (16 Jun 2021 07:35 UTC)
Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe (18 Jun 2021 20:33 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (18 Jun 2021 20:43 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (19 Jun 2021 10:02 UTC)
Re: Disjoint types in SRFIs Marc Feeley (19 Jun 2021 12:30 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (19 Jun 2021 12:46 UTC)
Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe (19 Jun 2021 17:49 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (19 Jun 2021 18:07 UTC)
Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe (19 Jun 2021 17:09 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (19 Jun 2021 17:18 UTC)
Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe (19 Jun 2021 18:09 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (19 Jun 2021 18:24 UTC)
Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe (19 Jun 2021 20:34 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (19 Jun 2021 21:03 UTC)
Re: Disjoint types in SRFIs John Cowan (13 Jun 2021 20:52 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (13 Jun 2021 21:17 UTC)
Re: Disjoint types in SRFIs John Cowan (13 Jun 2021 21:38 UTC)
Re: Disjoint types in SRFIs Marc Nieper-Wißkirchen (14 Jun 2021 07:04 UTC)

Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe 19 Jun 2021 17:49 UTC

On 2021-06-19 14:46 +0200, Marc Nieper-Wißkirchen wrote:
> Am Sa., 19. Juni 2021 um 14:30 Uhr schrieb Marc Feeley <
> xxxxxx@iro.umontreal.ca>:
>
> > > On Jun 19, 2021, at 6:02 AM, Marc Nieper-Wißkirchen <
> > xxxxxx@nieper-wisskirchen.de> wrote:
> > >
> > > I have been thinking of a formulation as the following one:
> > >
> > > "Fxmappings are instances of a sealed, opaque, nongenerative record
> > type with uid fxmapping-7a1f4d5b-a540-462b-82b1-47283c935b85 where the
> > semantics shall be as specified by R6RS, Library Chapter 6. In particular,
> > this means that the type defined by the record type predicate `fxmapping?'
> > is disjoint from the base types defined in R6RS and R7RS and from any
> > generative record type and any non-generative record type with a different
> > uid."
> > >
> >
> > This wording does not work for Schemes with single inheritance record
> > types, which are a fairly simple (and very useful) extension of record
> > types.  For example in Gambit you can define the record type bar as a
> > subtype of the foo type like this:
> >
> > [snip]
>
> It is really the question of what one wants (and we don't even have to look
> at a specific implementation like Gambit because your example works mutatis
> mutandis in R6RS).
>
> The usual wording in similar SRFIs has been something along the lines of
> "... belong to a new type disjoint from all other types ...". When we try
> to make sense of it, we can interpret this as that we don't want to allow
> inheritance here because this would create non-disjoint types. This is why
> the attribute "sealed" appears in my proposed wording, meaning that it is
> an error to create subtypes through inheritance.

This convinces me that neither 'sealed' nor 'opaque' should appear in
the 224 spec.  Extension and inspection are unspecified, not forbidden.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"A picture is worth 10k words--but only those to describe the picture.
Hardly any sets of 10k words can be adequately described with pictures."
--Alan J. Perlis