Am Mi., 6. März 2024 um 21:59 Uhr schrieb Sergei Egorov <xxxxxx@acm.org>:
There's no doubt in my mind that R7RS specifies splicing behavior on top/repl level. However, for internal definitions, the 'relaxed' description in (4.2.3.) is later narrowed down in (5.3.2.) to definition-only begins being definitions (no mentioning of splicing there),

5.3.2 is partly inconsistent with 4.2.3, but does not rule it out (IMO).
 
and, finally, in formal syntax section (7.1.6.), where the distinction between top-level splicing begins, definition-only begins, and expression-only begins is made absolutely clear.

Section 7.1.6 is not normative (and ignores macro expansion) but compatible with 5.3.2 and not with 4.2.3.

SRFI 251 can fix this inconsistency, of course.
 
I would also argue that it is (forward-?) compatible with R6RS; with respect to internal definitions, it assigns semantics to a narrower set of programs, but does not force the programs outside of this set to behave in any specific way, so R6RS interpretation of those is not outright banned by R7RS, just moved into 'undefined' territory. This is my intent too -- to specify 'uncontroversial' behavior in a manner that makes clear which programs have the formally described semantics, and which do not, and thus can be subject to further specification when/if a new agreement is reached. If it needs more elaboration in the SRFI text, I am willing to do that.

So you want to make the splicing R6RS begin with both definitions and expressions an error ("undefined territory") when it is followed by a definition (in the sense of SRFI 251)? This makes the set of valid programs a bit weird, I think.

(The root problem of all these proposals, which include SRFI 245, is, of course, that Scheme abandoned the simplicity of earlier Lisps where everything was just an expression. Scheme looks down on other languages because they make a difference between statements and expressions, but, in fact, Scheme also has this wart - in the disguise of definitions and expressions.)

Marc

On Wednesday, March 6, 2024 2:52:48 PM (-05:00), Marc Nieper-Wißkirchen wrote:

Am Mi., 6. März 2024 um 20:11 Uhr schrieb Sergei Egorov <xxxxxx@acm.org>:

I don’t think that this is formally correct. SRFI 251 derives its semantics from R7RS, and no longer relaxes R7RS requirement for body-level ‘begins’ to be either ‘definition begins’ (i.e. contain only definitions) or ‘expression begins’ (i.e. contain only expressions).

This would be incompatible with R6RS, in which body-level begin has splicing semantics and can contain any kind of form. The same seems to be true for R7RS's first form of begin (4.2.3.). Or have I misunderstood you?
 
I believe this puts your second definition of ‘define-number’ into undefined territory: if expanded on body level, it yields a ‘begin’ with 'it is an error' behavior, as in R7RS. To make the second ‘define-number’ work as intended, it should be changed to something like this:
 
(define-syntax define-number
  (syntax-rules ()
    ((_ id val)
     (begin
       (define tmp val)
       (define-values () (begin (unless (number? tmp) (error "boom!")) (values)))
       (define id tmp)))))
 
As we have discussed earlier at some point, perhaps it makes sense to supplement this SRFI with a derived form that makes such code easier to read, e.g.
 
       (define! (unless (number? tmp) (error "boom!")))


On Wednesday, March 6, 2024 10:18:19 AM (-05:00), Marc Nieper-Wißkirchen wrote:

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 <xxxxxx@speechcode.com>:

I've just published draft #3 of 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



-- 
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com