Email list hosting service & mailing list manager

Generic interfaces Daphne Preston-Kendal (23 Jul 2021 11:34 UTC)
Re: Generic interfaces Lassi Kortela (23 Jul 2021 11:48 UTC)
Against hierarchy Lassi Kortela (23 Jul 2021 11:56 UTC)
Re: Against hierarchy Marc Nieper-Wißkirchen (23 Jul 2021 12:04 UTC)
Re: Against hierarchy Lassi Kortela (23 Jul 2021 12:08 UTC)
Re: Against hierarchy Marc Nieper-Wißkirchen (23 Jul 2021 12:26 UTC)
R6RS exception hierarchy Lassi Kortela (23 Jul 2021 12:39 UTC)
Re: R6RS exception hierarchy Marc Nieper-Wißkirchen (23 Jul 2021 13:09 UTC)
Re: R6RS exception hierarchy Lassi Kortela (23 Jul 2021 16:05 UTC)
Re: R6RS exception hierarchy Marc Nieper-Wißkirchen (23 Jul 2021 16:24 UTC)
Re: R6RS exception hierarchy Arthur A. Gleckler (23 Jul 2021 17:19 UTC)
Re: R6RS exception hierarchy Marc Nieper-Wißkirchen (23 Jul 2021 17:49 UTC)
Re: R6RS exception hierarchy Arthur A. Gleckler (23 Jul 2021 19:28 UTC)
Re: R6RS exception hierarchy John Cowan (26 Jul 2021 21:32 UTC)
Re: R6RS exception hierarchy Marc Nieper-Wißkirchen (27 Jul 2021 05:46 UTC)
Re: Generic interfaces Daphne Preston-Kendal (23 Jul 2021 17:47 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (23 Jul 2021 18:17 UTC)
Re: Generic interfaces Adam Nelson (23 Jul 2021 18:55 UTC)
Re: Generic interfaces Per Bothner (24 Jul 2021 19:31 UTC)
Re: Generic interfaces John Cowan (24 Jul 2021 04:27 UTC)
Re: Generic interfaces John Cowan (24 Jul 2021 04:26 UTC)
Re: Generic interfaces Daphne Preston-Kendal (25 Jul 2021 09:08 UTC)
Re: Generic interfaces Amirouche (25 Jul 2021 14:36 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (23 Jul 2021 12:18 UTC)
Re: Generic interfaces Daphne Preston-Kendal (23 Jul 2021 17:49 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (23 Jul 2021 17:51 UTC)
Re: Generic interfaces Daphne Preston-Kendal (23 Jul 2021 18:12 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (23 Jul 2021 18:39 UTC)
Re: Generic interfaces John Cowan (24 Jul 2021 03:56 UTC)
Re: Generic interfaces John Cowan (24 Jul 2021 02:22 UTC)
Re: Generic interfaces Jeremy Steward (24 Jul 2021 03:38 UTC)
Re: Generic interfaces Amirouche (25 Jul 2021 06:19 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (25 Jul 2021 08:39 UTC)
Re: Generic interfaces Daphne Preston-Kendal (25 Jul 2021 09:28 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (25 Jul 2021 10:04 UTC)
Re: Generic interfaces Daphne Preston-Kendal (25 Jul 2021 10:47 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (25 Jul 2021 12:16 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (29 Jul 2021 08:18 UTC)
Re: Generic interfaces John Cowan (26 Jul 2021 00:04 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (26 Jul 2021 06:25 UTC)
Re: Generic interfaces John Cowan (26 Jul 2021 12:26 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (26 Jul 2021 13:00 UTC)
Re: Generic interfaces Ray Dillinger (26 Jul 2021 19:28 UTC)
Re: Generic interfaces John Cowan (26 Jul 2021 19:53 UTC)
Re: Generic interfaces Arthur A. Gleckler (26 Jul 2021 22:15 UTC)
Re: Generic interfaces John Cowan (25 Jul 2021 23:37 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (26 Jul 2021 06:10 UTC)
Re: Generic interfaces John Cowan (26 Jul 2021 11:43 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (26 Jul 2021 12:09 UTC)
Re: Generic interfaces John Cowan (26 Jul 2021 13:14 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (26 Jul 2021 13:37 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (16 Nov 2021 18:52 UTC)
Re: Generic interfaces John Cowan (25 Jul 2021 23:00 UTC)
Re: Generic interfaces Marc Nieper-Wißkirchen (26 Jul 2021 05:44 UTC)

Re: Generic interfaces Daphne Preston-Kendal 25 Jul 2021 10:47 UTC

On 25 Jul 2021, at 12:04, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:

> An approach without explicit type descriptors probably works well when you have a linear type hierarchy like the Scheme numeric tower. For use cases like these, such an approach looks like a good one and it would be nice if Scheme supported user-creation of linear type hierarchies like the numeric tower.
>
> Outside of this, however, type descriptors seem to be the much better, not to say the right approach.
>
> So you can read this as a case for proving both approaches parallelly together with clear principles when to use one or the other approach.

Okay, I think this is a fairly decent starting point for deciding when we want to use one approach vs the other.

> Let me add that a lot of syntactic extensions we may have to discuss are unrelated to `syntax-case' vs. `explicit-renaming' as they can be applied to both. That said, ceterum censeo carthaginem esse delendam, `er-macro-transformer' as usually implemented doesn't support (correct) unhygienic macros, so the system as implemented is inferior on technical grounds (not to mention questions of readability of code) and so the question is first and for all whether we want to allow unhygienic macros.

Sir, I quite agree with you, but what are we two against so many?

My hope is likewise that syntax-case will be the system adopted (not least to fulfill WG2’s responsibility, per its charter, to adopt R6RS-compatible solutions where practical), but I no longer think it would be a total disaster to end up with explicit renaming, since SRFI 204 can somewhat reasonably emulate the pattern-matching of syntax-case, and quasirename can provide an analogous form to syntax/quasisyntax, solving the code readability issue. The hygiene issues are regrettable, but the most common use of unhygienic macros is solved correctly by syntax parameters, which can even be used in syntax-rules, avoiding the need to go to the lower level at all in that case. We can provide construct-identifier and bound-identifier=? in extensions, if necessary, as you note in SRFI 211.

Identifier syntax is the other major issue, as far as I’m concerned. As far as I know, there are no explicit renaming systems which provide it, although spec-wise it could trivially be extended to support it; it’s just that the majority of existing explicit renaming macros don’t expect to get anything other than a list as their first argument.

> I promise to get SRFI 211 finalized soon. Can you remind me of the Racket/Gerbil syntax-case extensions you mentioned? Maybe they should be included in SRFI 211 as well.

The ones I wanted to include are listed at <https://gitlab.com/dpk/presrfis/-/blob/master/syntax-case-extensions.md>. Racket’s macro system is quite rich; there may be other extensions there which are handy, but these seem the most generally applicable of the ones which aren’t already on the ballots, like variable-transformers and syntax parameters. (By ‘generally applicable’ I mean that I’ve already had cause to use them myself ;-) albeit, in the case of syntax-e, only to work around bugs in Gerbil’s syntax-case implementation.)

> Marc

Daphne