meta comments Alex Shinn (24 Sep 2020 21:58 UTC)
Re: meta comments Marc Nieper-Wißkirchen (25 Sep 2020 05:35 UTC)
Re: meta comments Alex Shinn (25 Sep 2020 23:09 UTC)
Re: meta comments Marc Nieper-Wißkirchen (26 Sep 2020 08:15 UTC)
Re: meta comments Marc Nieper-Wißkirchen (26 Sep 2020 17:09 UTC)
Re: meta comments Arthur A. Gleckler (20 Jan 2021 01:45 UTC)
Re: meta comments Marc Nieper-Wißkirchen (20 Jan 2021 06:49 UTC)

Re: meta comments Marc Nieper-Wißkirchen 26 Sep 2020 17:09 UTC

Am Sa., 26. Sept. 2020 um 10:14 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:

> I think I understand the documentation of SC and would say it can
> serve as a specification. What is less clear, though, is how to make
> it work together with other macro systems, say syntax-rules. At least
> that is missing in the documentation.

For example, given the loop macro

(define-syntax loop
  (sc-macro-transformer
   (lambda (exp env)
     (let ((body (cdr exp)))
       `(call-with-current-continuation
         (lambda (exit)
           (let f ()
             ,@(map (lambda (exp)
                      (make-syntactic-closure env '(exit)
                        exp))
                    body)
             (f))))))))

of the MIT/GNU Scheme documentation, the expression

(loop (exit 42))

will evaluate to 42. The following one, however, will exit the Scheme system:

(let-syntax ((wrap
                  (syntax-rules ()
                    ((wrap) (loop exit 42)))))
  (wrap))

So, at least this example should be rewritten. If this is not
possible, the SC system as currently specified is not suitable for
serious macro programming. The problem is that the `loop' transformer
does not know to which identifier the `wrap' transformer renames
`exit'.

The ER version has the same problem, but this can at least be fixed by
adding the requirement that the implementation has to close raw
symbols in the macro output in the use environment.

-- Marc

PS A personal note: The more I discover the deficiencies of these
systems and think about how to provide fixes in this SRFIs, the more I
wonder about the seemingly personal hatred people meet syntax-case
with. From all systems that have been proposed for standardization
beyond syntax-rules, this is the only one that already just works as
intended. (And if one doesn't want syntax-case destructuring for
whatever reason, which is probably incomprehensible to me, one can
restrict oneself to the primitives in the appendix of the R4RS, which
already presented a system that just works 30 years ago.)

That said, I will try hard to write the specifications of the
alternative systems in this SRFI in a way so that they become as
robust as the R4RS low-level system or syntax-case. There was once a
vote between er-macro-transformer and syntax-case. In retrospect, I am
wondering what was going on there when there was no satisfying
specification of er-macro-transformer at hand. It helps if people have
written macro expanders for both systems and have written non-trivial
extended macros for both systems and also macros that touch cases like
the one reported for SC transformer. Otherwise, they have to rely on
what others say, but especially in the case of macro systems, a lot of
FUD has been spread, unfortunately.