Okay, the weather was bad today so I had unforeseen time to write the SRFI (see the pre-draft in the appendix).
Daphne, would you want to contribute to it with your syntax-rules implementation? Marc Am Di., 24. Aug. 2021 um 11:26 Uhr schrieb Marc Nieper-Wißkirchen < [email protected]>: > > > Am Di., 24. Aug. 2021 um 10:37 Uhr schrieb Daphne Preston-Kendal < > [email protected]>: > >> On 24 Aug 2021, at 09:50, Marc Nieper-Wißkirchen <[email protected]> >> wrote: >> >> > Thanks for sharing this. As for the name: After having rethought it, >> the name "opt-lambda" (or a similar one) is the better name because we >> already have case-lambda (and match-lambda in SRFI 204). >> >> Yeah, I’m not totally fixed on the name. I think a suffix is slightly >> better because there is, to my knowledge, no tradition of forms of ‘define’ >> with prefix names. But I’m happy to bikeshed it later — this is just a >> proof of concept, really. >> > > I don't think that having a define form for each kind of lambda form is > really necessary. In any case, as opt-lambda/lambda-optionals/... is a > conservative extension of lambda, we won't really need a new define keyword > but can just extend the given one (as SRFI 219 already does). > > > Do you think that a version where the values of the previous arguments >> are not bound is that much useful? Of course, it is a nice symmetry with >> let and let*, but does this already warrant this (slight) complication of >> an optionals spec? >> >> One might well ask why we have both let and let* to begin with. (Clojure, >> I believe, has only one let form which is essentially our let*.) >> > > When writing down algorithms, it is certainly helpful to have both because > let lets one specify that the order of evaluation is irrelevant. > > >> The slight efficiency gain from only having one extra procedure call >> internally when possible seems potentially worth it to me. >> >> > As for the surface syntax, the rest argument should be detectable even >> without any optionals specified. For otherwise, the behavior becomes >> irregular. So >> > >> > (opt-lambda (x y (z a) . rest) >> > ...) >> > >> > and not >> > >> > (opt-lambda (x y (z a) rest) >> > ...) >> >> That’s how it’s meant to work, but I think at present the latter will >> match as well, and do something weird, because controlling what patterns >> match what input like that in syntax-rules is moderately tricky. An >> implementation in SRFI 148 or syntax-case would a lot shorter and more >> robust against foibles like this. >> > > Ah, great! Your syntax-rules code is actually very good advertising for > why syntax-case (or a similar system) is a great help even for hygienic > macros that could be written with syntax-rules (if SRFI 148 is not > available). > > [...] > > Marc > PS: As for opt-lambda vs NON-ABBREVIATED-WORD-lambda: If we choose the > latter, it will have to be "optionals-lambda", not "optional-lambda", > because it's not the procedure that is optional. :) > > But "opt-lambda" would be fine as well; Scheme already knows a number of > abbreviations, like "-ref" or "cond" when it is clear what the full form > would be. > > That said, one could even drop the prefix and just provide lambda on > steroids. (This is the SRFI 219 approach.) > >
srfi-227.tgz
Description: application/compressed-tar
