The proceed adbmal* seems like an interesting alternative to values for some situations.

But the syntactic versions don't add anything except disadvantages -- they delay evaluation (possibly to a different dynamic extent), and they do not memoize their results, so multiple calls could produce different values and could produce multiple side effects. Consider the following to remove these issues.

(adbmal expr ...) ==> (let ((tmp expr) ...) (lambda (f) (f tmp ...)))

(where (tmp ...) are generated temporary ids).

The advantage this has over adbmal* is that it avoids cons'ing up arguments into a list and needing to call apply on f.

alet is interesting -- I see it having potential to be CL's destructuring-bind with added support for multi-valued expressions. Did you consider arbitrary recursion to the bindings?

(alet (((a (values b ((adbmal c . d) . e))) expr)) ...)

How about destructuring vector expressions too?

Semantic consistency issues I have with alet:

Rules 1 and 2-1 mean that:

(foo 'bar) ==> simple binding

(foo bar '(1 2)) ==> de-structuring ???

3-1/5-1:

((foo bar) (iota 2)) ==> destructuring

((foo bar) (iota 3)) ==> destructuring, runtime error -- too many values

((foo) (iota 2)) ==> single-variable binding, no destructuring, not an error! ???

4-1/5-2:

((foo . bar) (iota 2)) ==> destructuring

((foo . bar) (iota 2) "hello") ==> foo bound to (0 1) , bar bound to ("hello") ???

These examples are non-intuitive. The 2-1 rule should just go away, in my opinion. The second two can be easily remedied by changing 5-1/5-2 to instead be specializations on 3-1/4-1:

5-1. ((<var1> <var2> ...) (list <expr1> <expr2> ...))

((lambda (<var1> <var2> ...) body) <expr1> <expr2> ...)

5-2. ((<var1> <var2> ... . <varn>) (list <expr1> <expr2> <expr3> ...))

==> ((lambda (<var1> <var2> ... <varn>) body) <expr1> <expr2> ... (list <exprn> ...))

So, we require the caller to use the list keyword on the right hand size, but lose no performance with an unnecessary call to list. 3-1 needs to be changed to permit as few as one variable also.

For completeness, rule 3-1 could be changed to permit zero variables. That may seem useless by a user, but if alet calls are generated by other macros, it may be convenient to permit the most general situations.

On Sat, Feb 22, 2020 at 7:16 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:

Scheme Request for Implementation 182,
"ADBMAL, ALET, and ALET*,"
by Joo ChurlSoo,
is now available for discussion.

Its draft and an archive of the ongoing discussion are available at https://srfi.schemers.org/srfi-182/.

You can join the discussion of the draft by filling out the subscription form on that page.

You can contribute a message to the discussion by sending it to xxxxxx@srfi.schemers.org.

Here's the abstract:

Unlike the VALUES and CALL-WITH-VALUES mechanism of R5RS, this one uses an explicit representation for multiple return values as a single value, namely a procedure. Decomposition of multiple values is done by simple application. The macro, ADBMAL, evaluates to a procedure that takes one procedure argument. The ADBMAL macro can be compared with LAMBDA. While a LAMBDA expression that consists of <formals> and <body> requires some actual arguments later when the evaluated LAMBDA expression is called, an ADBMAL expression that consists of <expression>s corresponding to actual arguments of LAMBDA requires <formals> and <body>, that is, an evaluated LAMBDA expression, later when the evaluated ADBMAL expression is called.

This SRFI also introduces the new LET-syntax ALET and ALET*, which depend on ADBMAL to manipulate multiple values, and which are compatible with LET and LET* of R5RS in single-value bindings. They also have a binding form making use of VALUES and CALL-WITH-VALUES to handle multiple values, and new binding forms for list, cons, and other multiple values. In addition, they have several new binding forms for useful functions such as escape, iteration, optional arguments, etc.

Regards,

SRFI Editor