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 18:09 UTC

On 2021-06-19 19:18 +0200, Marc Nieper-Wißkirchen wrote:
> Am Sa., 19. Juni 2021 um 19:09 Uhr schrieb Wolfgang Corcoran-Mathe <
> xxxxxx@sigwinch.xyz>:
>
> > On 2021-06-19 12:02 +0200, Marc Nieper-Wißkirchen wrote:
> > > "Fxmappings (pronounced "fix-mappings") form a new type, as if created by
> > > define-record-type (see R7RS § 5.5). In systems supporting R6RS
> > record-type
> > > semantics, fxmappings are instances of a sealed, opaque, nongenerative
> > > record type with uid fxmapping-7a1f4d5b-a540-462b-82b1-47283c935b85. The
> > > effects of using record-type inspection or inheritance for the fxmapping
> > > type are unspecified."
> > >
> > > The first sentence remains meaningless, the semantic implications of the
> > > second should also hold for R7RS schemes, and the final sentence sounds
> > > superfluous at best as the sentence before that talks about a sealed and
> > > opaque record type.
> >
> > I agree that this is a little confusing.  Since the new draft hasn't
> > been pulled yet, I'll split out the R6RS-specific semantics as a
> > separate paragraph.  Re: Marc Feeley's comments, I'm also not
> > convinced that 'sealed' is the right choice here.
> >
>
> Can you give some compelling use case for a non-sealed type that would
> promote good coding practices?

I think that "good coding practices" here is a bit of a weasel-phrase.
Many Schemes provide record-type inheritance, of course, and it's not
my intention to forbid extending fxmappings or any other type.
Similarly for inspection, which is completely orthogonal to SRFI 224's
goals and thus should not be disallowed.

> Note that we are not requiring R6RS semantics here. We are requiring
> exactly the semantics we want using the language of R6RS (because there no
> better is existing at the moment).

Yes, I appreciate the rigor of R6RS in this area, and it does give us
a useful vocabulary.  Using this vocabulary, I'm just not in favor of
requiring that fxmappings be sealed or opaque.

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

"Conquering the galaxy is what bacteria with spaceships would
do--knowing no better, having no choice." --Greg Egan, _Disapora_