
Regarding syntax templates that require all ids to be bound, is that something that could be implemented now as a library? If so, would it require a lot of work?

@kellysmith12.21 it’s possible, but a lot of the work would be in making it as convenient as the built in syntax templates. for example define-simple-macro
woudn’t work with the new template form so you’d have to provide your own version of define-simple-macro

similarly for define-syntax-rule

Then it may be something worth considering for my lang, since I want to give it a macro system and I was planning for a slightly different API than Racket’s. I’d be tempted to implement it with syntax-parse
and compile it to the built-in syntax templates. Not sure if that’s the best way to do it, though.

How do you plan to support binding creation?
Currently, we can do something like:
(define-syntax (foo stx)
(with-syntax ([x #'x])
#'(let ([x 1]) x)))
But #'x
would be considered an error in your system.

From https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/:
> Unlike developer signing and notarization, this isn’t intended to prevent any modifications being made to executable code. Malicious software could always re-sign modified code using another signature, although in doing so it would lose access to resources which were tied to the original signing identity, of course. But it’s intended to significantly reduce the surface area of attacks.

Might need to make a separate form just for marking identifiers which you know won’t be bound until later

Let’s suppose we somehow managed to do that. So now we can write:
(define-syntax (foo stx)
(with-syntax ([x (magic-form x)])
#'(let ([x 1]) x)))
and it’s expected to be OK.
But what about:
(define-syntax (foo stx)
(with-syntax ([x (magic-form x)])
#'(values ([x 1]) x)))
Do we expect it to error without expansion of foo
?

Thanks for the link — that certainly discusses this in more breadth and depth!

Probably not; I think it would take a drastic reimagining of the macro system for templates to be able to tell the difference between how let
and values
treat their subforms. (In general, Racket macros don’t currently reveal information like that until they’re expanded.)

Treating that example in a way that lets foo
macroexpand into erroneous code seems a lot easier. This variant of #'
would just look up the syntax template variable binding of every identifier in its body, and it wouldn’t silently accept unbound variables as literals.

magic-form
may as well be generate-temporary
there

I’ll probably have a form called something like with-fresh-vars
that can be used like (define-syntax (foo stx)
(with-fresh-vars (x y z)
#'(let ([x 1] [y 2] [z 3])
(list x y z))))
This form would probably be a simple wrapper for generate-temporaries
.
Once added to Racket, the API in <https://dl.acm.org/doi/10.1145/3428297|Macros for domain-specific languages>, will make it easier to use local expansion to check which forms bind variables. I could try using it in my syntax templates to track which what gets bound and where.
Regarding the case of a template producing (values ([x 1]) x)
, I’d expect that to be a valid template containing bad code. I could have templates statically ensure syntactic correctness, but that seems like a feature better suited to a static language, where the compiler is expected to do a lot of verification.
In the case of my lang, I intend for macros to be provided with contracts which verify the syntax of the expansion

(Please forgive me, I may have missed something.)

Because we always need new platform compatibility problems, apparently DrRacket is very slow on Wayland. https://www.reddit.com/r/Racket/comments/k5l5ih/racket_79_sluggish_on_fedora_33/\|https://www.reddit.com/r/Racket/comments/k5l5ih/racket_79_sluggish_on_fedora_33/
