Source code of rec from SRFI 31

Questions & Answers
1

Hi,

i searched a moment before asking in racket mailing list.
There is a definition of rec in the official SRFI 31

that i recopy here:

(define-syntax rec
  (syntax-rules ()
    ((rec (NAME . VARIABLES) . BODY)
     (letrec ( (NAME (lambda VARIABLES . BODY)) ) NAME))
    ((rec NAME EXPRESSION)
     (letrec ( (NAME EXPRESSION) ) NAME))))

but i do not understand this part: (lambda VARIABLES . BODY) , this seems to not be valid scheme syntax?!

But i can not think an error could be in an official SRFI too.So i ask advice here.

If try in Racket of course i got errors:

> (lambda VARIABLES . 7)
. lambda: bad syntax in: (lambda VARIABLES . 7)
> rec
. . rec: undefined;
 cannot reference an identifier before its definition
> (define-syntax rec
  (syntax-rules ()
    ((rec (NAME . VARIABLES) . BODY)
     (letrec ( (NAME (lambda VARIABLES . BODY)) ) NAME))
    ((rec NAME EXPRESSION)
     (letrec ( (NAME EXPRESSION) ) NAME))))

> (lambda v . 7)
. lambda: bad syntax in: (lambda v . 7)
> (letrec ( (NAME (lambda VARIABLES . BODY)) ) NAME)
. lambda: bad syntax in: (lambda VARIABLES . BODY)
> (letrec ( (NAME (lambda VARIABLES . 7)) ) NAME)
. lambda: bad syntax in: (lambda VARIABLES . 7)
> rec
. rec: bad syntax in: rec
> (rec (toto . x) . 7)
. lambda: bad syntax in: (lambda x . 7)
>

but rec from racket seems to be ok as i already used it, but i can not find the source code in the github repository.

Guile seems to use another code for rec:

but Gambit seems to use the official SRFI 31 code:

but haven't test it.

Best regards,

2

There is an implicit requirement that BODY be list-structured for the resulting lambda form to be valid. More specifically, a lambda must have one or more body expressions, so a valid BODY must be (a syntax object containing) a non-empty list.

While remaining within the syntax-rules context, an implementation could enforce those requirements like this:

(define-syntax rec
  (syntax-rules ()
    ((rec (NAME . VARIABLES) BODY0 BODY ...)
     (letrec ( (NAME (lambda VARIABLES BODY0 BODY ...)) ) NAME))
    ((rec NAME EXPRESSION)
     (letrec ( (NAME EXPRESSION) ) NAME))))

Apparently at least some Schemers around the SRFI 31 era (before my time) preferred the dot operator to ellipses, on the grounds that it is “more
general-purpose,” or perhaps because ellipses did not exist in Lisps without pattern-based macros, which were controversial. I found that in SRFI 5, also, the use of . when the tail is actually constrained to be a proper list obscured subtleties of the specification.

I think it's also fair to say that Scheme macros from this era rarely were concerned with good error reporting, probably because it was very difficult. Letting the target form (lambda, in this case) report the error seems to have been common. Especially with syntax-parse, specifying requirements instead of leaving them implicit pays off in obviously better error messages.

1 Like
3

The srfi/31 implementation is just the mzlib/etc implementation, which is here: compatibility/compatibility-lib/mzlib/etc.rkt at master · racket/compatibility · GitHub

1 Like
4

It is more clear now then.

> (rec (toto . x) . (7))
#<procedure:toto>

works.

ah ah but i used define-macro (Teach Yourself Scheme in Fixnum Days) in the '90 and it is still in some light scheme implementation.

5

thank you for the path because i was lost in the racket github labyrinth here:

:sob:

6

Note that (lambda VARIABLES . BODY) appears in a template.
The dot is not part of the syntax of lambda, but rather for a dotted pair.
E.g. (1 . (2 . ()) is the same as (1 2).

If BODY from the pattern has matched a list, then (lambda VARIABLES . BODY) becomes a list.

1 Like
7

yes but convention of BODY being a list in not mentioned in the SRFI.

in fact i have concern only with the latter template not the one, i rarely use rec and only the 2nd template i use.

I just asked it because i wanted to inject infix feature in the body of rec to create a rec+ for scheme+

it seems chez scheme use only the latter template according this site but it is not sure, i have not checked the code:

for rec+ i will rely on the guile definition, perheaps like that:

(module rec+ racket/base


	(provide rec+) 

	(require 
		 Scheme+/nfx)

(define-syntax rec+
  (syntax-rules ()
   
    ((_ (name . formals) body ...)                ; procedure
     (letrec ((name (lambda formals ($nfx$-rec body) ...)))
       name))
    ((_ name expr)                                ; arbitrary object
     (letrec ((name ($nfx$-rec expr)))
       name))))
)

or even simplier , i could construct rec+ with lambda+ that i recently added and this give the possibility to return :

(module rec+ racket/base

	(provide rec+) 

	(require  srfi/31
		 Scheme+/lambda+)

(define-syntax rec+
  (syntax-rules ()
   
    ((_ (name . formals) body ...)                ; procedure
     (letrec ((name (lambda+ formals body ...)))
       name))
    ((_ name expr)                                ; arbitrary object
     (letrec ((name ($nfx$-rec expr)))
       name))))
)

but that sound strange because there is a lambda+ in the first pattern and not the other , but the user can use lambda+ in expr.And it would then cause the infix parsing/detection run twice ,one time on the code , another on result,to be tested.....

8

yes but convention of BODY being a list in not mentioned in the SRFI.

Well, you are looking at an implementation, not the specification.

SRFI 31 Specification

Syntax

The following production rules are to be added to those of [KCR1998] (we reuse names of non-terminals).

    <derived expression> --> <rec expression>
    <rec expression> --> (rec <variable> <expression>)
    <rec expression> --> (rec (<variable>+) <body>)

The syntax uses <body> which is defined in R5RS as:

<body>  --> <definition>* <sequence>
1 Like
9

:thinking:

yes but i'm not Champollion
:sweat_smile:

10

Great reference!

Jean-François Champollion (French: [ʒɑ̃ fʁɑ̃swa ʃɑ̃pɔljɔ̃]), also known as Champollion le jeune ('the Younger'; 23 December 1790 – 4 March 1832), was a French philologist and orientalist, known primarily as the decipherer of Egyptian hieroglyphs and a founding figure in the field of Egyptology.

2 Likes