A problem with SRFI 251's approach is that macros can gain unwanted spooky
actions at a distance.
Consider the following expression E:
(let ((x 1))
(define (f) x)
(define-number y 42)
(define x 2)
(f))
Here, define-number is defined through
(define-syntax define-number
(syntax-rules ()
((_ id val) (define id val))))
Evaluating E gives 2.
Now the author of define-number decides to change its definition to
(define-syntax define-number
(syntax-rules ()
((_ id val)
(begin
(define tmp val)
(unless (number? tmp) (error "boom!"))
(define id tmp)))))
This is possible with SRFI 251. However, suddenly evaluating E gives 1.
R6RS and R7RS solve this problem by making E together with the second
version of define-number an error.
SRFI 245 doesn't have this problem.
Am Mi., 6. März 2024 um 02:55 Uhr schrieb Arthur A. Gleckler <
s...@speechcode.com>:
> I've just published draft #3 of SRFI 251
> <https://srfi.schemers.org/srfi-251/>. It was submitted by Sergei Egorov,
> author of the SRFI.
>
> Here are Sergei's comments on the draft:
>
> Here is a third draft with an extra example (and test), demonstrating the
> 'staged' nature of define-syntax in stfi-251: macros defined in a
> definition group can be used in downstream expressions and definition
> groups.
>
> Here is the commit summary:
>
> - "Staged" define-syntax example added
> - Drop trailing whitespace.
> - Publish third draft.
>
> Here's the diff:
>
>
> https://github.com/scheme-requests-for-implementation/srfi-251/compare/draft-2..draft-3
>
> Regards,
>
> SRFI Editor
>
