The named-let incarnation of the let form has two slight inconsistencies with the define form. As defined, the let form makes no accommodation for rest arguments, an issue of functionality and consistency. As defined, the let form does not accommodate signature-style syntax, an issue of aesthetics and consistency. Both issues are addressed here in a manner which is compatible with the traditional let form but for minor extensions.
For more information see: SRFI-5: A compatible let form with signatures and rest arguments
Consider the following two equivalent definitions:
(define fibonacci (lambda (n i f0 f1) (if (= i n) f0 (fibonacci n (+ i 1) f1 (+ f0 f1))))) (define (fibonacci n i f0 f1) (if (= i n) f0 (fibonacci n (+ i 1) f1 (+ f0 f1))))
Although there is a named-let analog for the former form, there is none for the latter. To wit, suppose one wished to compute the 10th element of the Fibonacci sequence using a named let:
(let fibonacci ((n 10) (i 0) (f0 0) (f1 1)) (if (= i n) f0 (fibonacci n (+ i 1) f1 (+ f0 f1))))
As it stands, one cannot equivalently write
(let (fibonacci (n 10) (i 0) (f0 0) (f1 1)) (if (= i n) f0 (fibonacci n (+ i 1) f1 (+ f0 f1))))
which is consistent with define's signature-style form.
Those that favor the signature style may prefer this extension. In any case, it may be more appropriate to include all bound names within the binding section. As presented, this straightforward extension introduces no ambiguity or incompatibility with the existing definition of let.
As it stands, one cannot write a named let with rest arguments, as in
(let (blast (port (current-output-port)) . (x (+ 1 2) 4 5)) (if (null? x) 'just-a-silly-contrived-example (begin (write (car x) port) (apply blast port (cdr x)))))
otherwise equivalent to
(letrec ((blast (lambda (port . x) (if (null? x) 'just-a-silly-contrived-example (begin (write (car x) port) (apply blast port (cdr x))))))) (blast (current-output-port) (+ 1 2) 4 5))
While this example is rather contrived, the functionality is not. There are several times when the author has used this construct in practice. Regardless, there is little reason to deny the let form access to all the features of lambda functionality.
Both the features above rely upon the placement of symbols in let binding lists (this statement is intentially simplistic). The only other apparent use of such symbol placement is to tersely bind variables to unspecified values. For example, one might desire to use (let (foo bar baz) ...) to bind foo, bar, and baz to unspecified values.
This usage is considered less important in light of the rationales presented above, and an alternate syntax is immediately apparent, as in (let ((foo) (bar) (baz)) ...) This may even be preferable, consistently parenthesizing normal binding clauses.
A formal specification of the syntax follows. Below, body, expression, and identifier are free. Each instantiation of binding-name must be unique.
let = "(" "let" let-bindings body ")" expressions = nothing | expression expressions let-bindings = let-name bindings | "(" let-name "." bindings ")" let-name = identifier bindings = "(" ")" | rest-binding | "(" normal-bindings ["." rest-binding] ")" normal-bindings = nothing | normal-binding normal-bindings normal-binding = "(" binding-name expression ")" binding-name = identifier rest-binding = "(" binding-name expressions ")"
For clarity and convenience, an informal specification follows.
(let ((<parameter> <argument>)...) <body>...)
(let <name> ((<parameter> <argument>)...) <body>...)
(let (<name> (<parameter> <argument>)...) <body>...)
(let <name> ((<parameter> <argument>)... . (<rest-parameter> <rest-argument>...)) <body>...)
(let (<name> (<parameter> <argument>)... . (<rest-parameter> <rest-argument>...)) <body>...)
Let $lambda and $letrec be hygienic bindings for the lambda and letrec forms, respectively.
(($lambda (<parameter>...) <body>...) <argument>...)
($letrec ((<name> ($lambda (<parameter>...) <body>...))) (<name> <argument>...))
($letrec ((<name> ($lambda (<parameter>... . <rest-parameter>) <body>...))) (<name> <argument>... <rest-argument>...))
- Andy Gaynor
- Ported to Chicken Scheme 5 by Sergey Goldgaber
Copyright (C) Andy Gaynor (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Scheme Request For Implementation process or editors, except as needed for the purpose of developing SRFIs in which case the procedures for copyrights defined in the SRFI process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the authors or their successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE AUTHOR AND THE SRFI EDITORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
- The source code for this egg can be found: here
- 0.1 - Ported to Chicken Scheme 5