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 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:30 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:34 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:29 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:06 UTC
Re: Disjoint types in SRFIs Wolfgang Corcoran-Mathe 19 Jun 2021 17:08 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:23 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 20:34 UTC

On 2021-06-19 20:23 +0200, Marc Nieper-Wißkirchen wrote:
> Am Sa., 19. Juni 2021 um 20:09 Uhr schrieb Wolfgang Corcoran-Mathe <
> xxxxxx@sigwinch.xyz>:
>
> > 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.
>
> It is exactly the same here: 'Opaque' means (among other things) that the
> (R6RS) 'record?' predicate won't detect fxmappings as standard records.
> 'Sealed' means that the type cannot be extended through R6RS standard
> means. This does not mean that it is entirely impossible. As R7RS neither
> has record inspection nor opacity, all ways to inherit or inspect record
> types have to non-standard, anyway.

As such, I can't see that there's any standard non-R6RS way to ensure
that a type created (as if) by define-record-type is 'opaque' or
'sealed'.  The sample implementation, e.g., can't ensure that
`(record? some-fxmapping)` is #f in a Scheme implementation providing
such a predicate, or that fxmappings are otherwise disjoint from some
record supertype.

Opaqueness and sealedness are good features that I like and would
use, but I would not want to force them on people.  Hence they are
(implicitly) optional.

That which we do not specify is unspecified.

> BTW, if you allow non-sealedness, the language becomes unusable again
> because you wouldn't guarantee disjointness to other types anymore.

Maybe I've misunderstood, but I think that we have a disconnect between
what R[57]-flavored SRFIs mean by "disjoint" and what is entailed by
the semantics of 'sealed'.

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

"The Algol compiler was so poorly implemented that we dared not rely
on it, and working with assembler code was considered dishonorable.
There remained only Fortran." --Niklaus Wirth