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)
|
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