Am Mi., 23. Sept. 2020 um 19:50 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > On Tue, Sep 22, 2020 at 7:34 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: > >> I would like to hear some opinions on the following questions: >> >> (1) Shall we include another library for sc-macro-transformer? > > > I'm fine either way. For standardization purposes, syntactic closures are rare enough (MIT, Chibi, Picrin) that I don't plan to put them on an R7RS-large ballot, which will leave people with yes/no/abstain ballot entries for syntax-case and explicit renaming. A straw ballot years ago voted for explicit renaming but not syntax-case, but I don't consider that binding. This SRFI is not only for standardization purposes but also to make macro systems usable in a portable way by providing a namespace where they can be advertised. As for the R7RS-large ballot, formulating it may be the hardest task so that depending on the outcomes we don't end up with a system that is hard or impossible to implement efficiently and consistently. Moreover, we have to agree first what the semantics of `er-macro-transformer' actually is. For example, Larceny's `er-transformer' is incompatible to Chibi's `er-macro-transformer'. In any case, I hope that we will be able to reach a consensus before any voting because the results of such votings are often erratic. >> This would include the following exports: >> >> - sc-macro-transformer >> - rsc-macro-transformer >> - make-syntactic-closure >> - capture-syntactic-environment > > > MIT Scheme (see the subpages of <https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref/Syntactic-Closures.html>) provides the convenience procedure (close-syntax form env) === (make-syntactic-closure env '() form). For compatibility with existing macros, this should be provided. The MIT documentation also says that (make-syntactic-closure env '() 'a) provides an alias, though no convenience version is provided. Picrin also provides close-syntax; Chibi does not, but it would be trivial to add. I wanted to add close-syntax but somehow this got lost. Thanks for the catch. >> >> - identifier? >> - identifier=? >> - make-synthetic-identifier >> >> * Both sc-macro-transformer and er-macro-transformer are lacking an >> equivalent of syntax->datum to get at the symbol names of identifiers. > > > Chibi, but not MIT or Picrin, provides identifier->symbol and strip-syntactic-closures. So if we add it, we don't know whether it will be supported by more than one Scheme. >> * Syntactic closures created by sc-macro-transformer cannot be destructured. > > > I think that's why they are called "closures". I have been thinking that the term "closure" refers to the sense of a "closure" of a function in functional programming tracing back to the original LISP's FUNARG. I cannot believe that the non-destructability is meant as a feature because it makes it impossible for a macro to expand into another macro written in that language. >> We can leave it at that, but this would mean that applicability and >> expressiveness of sc-macro-transformer and er-macro-transformer will >> be rather limited compared to the syntax-case system. > > > In my view the point of having them is so that (a) existing macros can be reused, and (b) users of these systems who are accustomed to them can continue to write them. Expressive power beyond what people already expect is more or less irrelevant. I don't think it is entirely irrelevant. With the bare er-macro-transformers, SRFI 99, Clinger's ERR5RS records, for example, cannot be implemented, yet people have been attempting to do so, which leads to macros that work in 99% of the cases, but not in 100%. If we give programmers a tool, especially programmers who are not interested in "esoteric" corners of the language, the tool should be as fool-proof as possible. That's why I would like to see a version of er-macro-transformer (if any) that produces correct code without much thinking. The problem with the minimal interface currently provided by (srfi 211 er-macro-transformer) is that one can only safely write hygienic macros. >> Or we could add a number of further primitives. > > > As far as I know, no other Scheme implements anything but these. Larceny's `er-transformer' has `bound-identifier=?' and `datum<->syntax', for example. Marc
