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
