Am So., 25. Juli 2021 um 11:28 Uhr schrieb Daphne Preston-Kendal <xxxxxx@nonceword.org>:

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

> A general comment: Just as with the question of how to handle keyword and optional parameters in future Scheme standards (including R7RS-large), I would postpone finalizing any general generic method approach until after it has become clear what macro facilities R7RS-large will provide.

I strongly agree, but the question of how a general generic method approach integrates with the specific case of dictionaries means we have to consider at least some aspects of it now, imo.

Indeed. That's why I wrote "finalizing" on purpose. Thinking about it earlier actually makes a lot of sense to get an impression of what macro facilities would be helpful to have.

Though perhaps the issues with e.g. alists and plists mean a SRFI 225-like approach with custom descriptors is better anyway in that specific case.

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.

John: Given the increasing number of issues hanging on it, perhaps we should vote on the formerly-Amber docket (whose central issue is syntax-case vs explicit renaming) next?

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.

That is notwithstanding that the formerly-Orange docket with portable numeric operations and various other portable proposals is now nearly fully SRFI’d up and ready to vote, and that a further delay may lead to more SRFIs with procedures accepting only one kind of dictionary instead of any dictionary type (which, again, we can fix later if so). The non-portable syntax docket is also nearly completely SRFI’d — we don’t have formal specifications for explicit renaming macros (cough, SRFI 211?), nor of the Racket/Gerbil syntax-case extensions I proposed (but they can be kicked down into a subsequent ballot if necessary), nor of Guile’s with-ellipsis which is necessary to support R7RS's extended form of syntax-rules in a syntax-case-based implementation (again, SRFI 211).

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.

I think it would be helpful to have an answer to these questions sooner rather than later.

Marc