I've just published draft #3 of SRFI 187.  It was submitted by Joo ChurlSoo, author of the SRFI.

https://srfi.schemers.org/srfi-187/

Here are Joo's comments on the draft:

I [have changed] the delimiter from the ampersand to the empty list that is a special object of its own type, for the following reasons.
1. In case optional variables are unpredictable, when there are no optional variables, the delimiter becomes a required variable and the function does not work properly.
   - (define-syntax ... (syntax-rules) ... (alambda r ... & o ...) ...)
2. When an identifier is used as a delimiter, the situation is unnecessarily complicated by the fact that the identifier is sometimes used as a variable.
   - This ampersand is a good example.
3. So, what should be used as a delimiter? In situations where keywords are not unified for each implementation, I think the empty list is probably the best.  Even if not, the best would be the empty list.
(alambda <extended formals> <body>)
<extended formals> --> <variable>
               | (<required spec>* <delimiter> <optional spec>* <rest spec>)
<delimeter> --> ()                      ;The default is #f.    
              | (default)              

There are two types of delimiter, which separate variables into required and optional variables. One is an empty list and the other is a list with one element. The former has #f as the default value and the latter has its element.
Examples:
((alambda (req () num cha str)            ;same as (#f)
   (list req num cha str))
 10)                            => (10 #f #f #f)
((alambda (req ('undefined) num cha str)
   (list req num cha str))
 10)                            => (10 undefined undefined undefined)
((alambda (req () (num req) (cha #\a) (str "opt"))
   (list req num cha str))
 10 30 #\o)                     => (10 30 #\o "opt")
I've attached new srfi-187.html, alambda-rules.scm, and alambda-macro.scm.
PS
1. Upon the change of the alambda's spec, the optional spec of srfi-182 was changed.  So, I've attached new srfi-182.html, adbmal-rules.scm, and adbmal-macro.scm.
2. Upon the change of the optional spec of srfi-182, the fox.scm of srfi-183 was changed.  So, I've attached a new fox.scm.
3. Following the alambda's change of spec, I was able to make a code of define-record-lambda(srfi-184) using alambda.  So, I've attached record-alambda-rules.scm and record-alambda-macro.scm.
The fox.scm, record-alambda-rules.scm, and record-alambda-macro.scm are just for records, not necessarily.

No further changes will be made if no particular defects are found.
 
Here's the diff:

https://github.com/scheme-requests-for-implementation/srfi-187/compare/draft-2..draft-3

Regards,


SRFI Editor