Am Mo., 29. Aug. 2022 um 22:43 Uhr schrieb Chris Hanson <xxxxxx@chris-hanson.org>:
>
> OK, thanks, that answers my question, I think. I’ll have to look at how
> syntax-rules interacts and where that problem is coming up.
>
> As for syntactic closures, I’m fairly certain that it is possible to write
> robust unhygienic macros in it. However, it’s by no means easy, which is why
> I’ve been thinking for a long time about how to make a better solution.

The R6RS version of `define-record-type' has the following (simplified) syntax:

 (define-record-type record-name
  ...)

Here, `record-name' is an identifier from which the constructor's name
is generated by prepending "make-".  The syntactic context of the
generated identifier will be the same as the syntactic context of the
identifier `record-name'.  With `syntax-case', this is easy to achieve
using `datum->syntax'.  How would you write a macro like
`define-record-type' with syntactic closures?

> I don’t much like syntax-case, or syntax-rules for that matter, because I’d
> prefer to use Scheme as the underlying language rather than inventing a new
> one. I made an attempt at using combinators but I’m not too happy with how it
> turned out.

I understand this for `syntax-rules', where (not necessarily simple)
macros must be written by programming a templating engine and not by
programming in Scheme.  `Syntax-case', on the other hand, uses Scheme
as the underlying language.  A macro transformer is just a procedure
mapping code (syntax objects) to code.

Thanks,

Marc

>
> Thanks,
> Chris
>
> On Monday, August 29, 2022 8:42:08 AM PDT Marc Nieper-Wißkirchen wrote:
> > Am Mo., 29. Aug. 2022 um 10:25 Uhr schrieb Chris Hanson <xxxxxx@chris-
> hanson.org>:
> > > I’m still having trouble understanding exactly what you mean about not
> > > returning raw symbols in their output. Since there’s no code in the SRFI I
> > > can’t read it to figure it out.
> >
> > The comment about returning raw symbols was about ER (without
> > extensions), which doesn't have forms like `close-syntax'.
> >
> > > If I make the following change to foo, it takes care of the problem:
> > >
> > > (define-syntax foo
> > >
> > >   (er-macro-transformer
> > >
> > >    (lambda (x r c)
> > >
> > >      (capture-syntactic-environment
> > >
> > >       (lambda (use-env)
> > >
> > >         `(,(r 'loop) (exit ,(close-syntax (cadr x) use-env))))))))
> > >
> > > This captures the environment in which foo is used, then closes the
> > > argument in that environment, ensuring that it gets the expected binding
> > > of exit. But the raw symbol exit appearing in the output instead gets the
> > > exit bound by loop’s expansion.
> >
> > Yes, this works, of course. But this is outside of what the note
> > discusses as ER doesn't have `close-syntax'.
> >
> > > I’m pretty sure this isn’t what you are suggesting though. But in the
> > > context of using syntactic closures it pretty clearly specifies what’s
> > > supposed to happen.
> >
> > The issue I have is that it doesn't play well with syntax-rules. The
> > `foo' macro should also work as expected when written with
> > syntax-rules (which in turn is implemented with syntactic closures).
> >
> > In any case, this discussion shows that I should weaken the paragraph
> > about syntactic closures added at the last minute to make it clear
> > that I haven't yet found a satisfying way to write SC macros that are
> > also robust in conjunction with syntax-rules. When we write every
> > macro using an unhygienic one with the full power of SC (and not
> > syntax-rules or the ER subset), the problem does not seem to occur, so
> > I shouldn't say in isolation that I find SC broken.
> >
> > (There are still some robust unhygienic macros that can be formulated
> > in syntax-case but not in syntactic closures, but these may not be too
> > interesting.)
> >
> > Thanks,
> >
> > Marc
> >
> > > Thanks,
> > > Chris
> > >
> > > On Sunday, August 21, 2022 11:16:50 PM PDT Marc Nieper-Wißkirchen wrote:
> > > > Am Mo., 22. Aug. 2022 um 00:29 Uhr schrieb Chris Hanson <xxxxxx@chris-
> > >
> > > hanson.org>:
> > > > > I’m not familiar with the term "robust unhygienic macros” and an
> > > > > internet
> > > > > search didn’t reveal any definitions.
> > > >
> > > > The term was coined by myself for the purpose of SRFI 211.
> > > >
> > > > > Is there a definition of this term, or better yet, a paper?
> > > >
> > > > Unfortunately no.
> > > >
> > > > What I mean by a "robust unhygienic macro" is an unhygienic macro that
> > > > even works when the unhygienic macro becomes part of the body of a
> > > > second macro expansion.
> > > >
> > > > Please see "Note 2" under "Explicit-renaming macro" for an example.
> > > >
> > > > > I’m a little confused because the SRFI claims that explicit-renaming
> > > > > macros
> > > > > can produce "robust unhygienic macros” yet syntactic-closure macros
> > > > > cannot.
> > > > > However, explicit-renaming is virtually identical to “reverse”
> > > > > syntactic-
> > > > > closure macros, which are syntactic-closure macros with the definition
> > > > > and
> > > > > use environments flipped.
> > > >
> > > > ER macros implemented with SC (syntactic closures) are indeed not
> > > > "robust" (according to my findings). SRFI 211 describes a variation of
> > > > ER (implemented with marks & substitutions) that can be used to define
> > > > unhygienic macros that are "robust". The variation of ER is not 100%
> > > > compatible with how ER is classically implemented.
> > > >
> > > > You can write down the example in Note 2 for SC as well.
> > > >
> > > > Does this help?
> > > >
> > > > Thanks,
> > > >
> > > > Marc
> > > >
> > > > PS My time this week is limited, so please excuse the rather brief
> > > > reply.
>
>
>
>