Email list hosting service & mailing list manager

Compounds are *not* a generalization of R6RS compound conditions Marc Nieper-Wißkirchen (06 Mar 2021 09:40 UTC)
Re: Compounds are *not* a generalization of R6RS compound conditions Alex Shinn (08 Mar 2021 01:05 UTC)
Re: Compounds are *not* a generalization of R6RS compound conditions Marc Nieper-Wißkirchen (09 Mar 2021 06:49 UTC)
Re: Compounds are *not* a generalization of R6RS compound conditions Marc Nieper-Wißkirchen (09 Mar 2021 07:59 UTC)
Re: Compounds are *not* a generalization of R6RS compound conditions Marc Nieper-Wißkirchen (10 Mar 2021 07:12 UTC)
Re: Compounds are *not* a generalization of R6RS compound conditions Marc Nieper-Wißkirchen (09 Mar 2021 06:59 UTC)
Re: Compounds are *not* a generalization of R6RS compound conditions Marc Nieper-Wißkirchen (08 Mar 2021 17:59 UTC)
Re: Compounds are *not* a generalization of R6RS compound conditions Marc Nieper-Wißkirchen (10 Mar 2021 07:31 UTC)

Re: Compounds are *not* a generalization of R6RS compound conditions Alex Shinn 08 Mar 2021 01:05 UTC

On Sat, Mar 6, 2021 at 6:40 PM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> While I think that it is a good idea to generalize R6RS conditions to general compound objects (possibly all one has to do is to rename "condition" to "compound"), SRFI 222 is a step back (and the reliance on global symbols is particularly unfortunate). It necessarily has to be until there some consensus has been reached on a more powerful record system in R7RS.

I believe that's the key point - if we want something more general, we
should extend records.

It looks like currently there is no docket for SRFI 99 or R6RS or
other record inheritance?
If it's difficult to get agreement or implementation support on this,
I believe the R6RS
condition system is a better approach, as it can be implemented
portably and efficiently.

--
Alex

>
> Unless the latter has happened, I strongly suggest to
>
> - remove the misleading claim from the abstract that SRFI 222 is a generalization (implying that it can act as a substitute) of R6RS conditions and
>
> - add some language on how SRFI 222 is supposed to be implemented on an R6RS system, that is how it is supposed to interoperate with existing R6RS compound types.
>
> While I understand why R7RS (small) cut down R6RS so that a language comparably in size to R5RS was possible, I don't understand the constant re-invention of wheels that are already in R6RS for R7RS (large). Creating unnecessary incompatibilities to R6RS (when there are no prior constraints from R7RS (small)) looks both technically and politically as a bad idea.
>
> Marc
>