This page is part of the web mail archives of SRFI 26 from before July 7th, 2015. The new archives for SRFI 26 contain all messages, not just those from before July 7th, 2015.
Many practical uses of "cut" will pass the
resulting procedure to
another procedure such as "map", "reduce" or "find", where it will be applied repetitively. In such cases the current semantics of evaluating non-slot argument expressions at the time of the call could be expensive and, for the careless, produce unforseen side effects. It will probably be argued that controlling
argument evaluation is
easy to do oneself in code with a few "let"s; my argument is the primary purpose of this SRFI is to reduce clutter and abbreviate some common idioms. I have been using a procedure analog of this macro for some time and find that its automatic argument evaluation is very useful. I do like the macro aspect of this SRFI, since many current compilers will inline "map" and friends and will also inline the generated the procedure; this aspect might be mentioned in the rationale. Changing the semantics is not difficult and does
not result in a
performance loss. Simply adding the following clause between the two in the commented section "loop over <const-or-slot>*" in the reference implementation does the trick: ((cut "loop" (param ...) proc
(arg ...) (f farg ...) .
consts-or-slots)
(let ((temp (f farg ...))) (cut "loop" (param ...) proc (arg ... temp) . consts-or-slots))) It could be argued that side-effects are desirable in cases where an _expression_ is used as a generator; for those uses an alternative version (named "cut!" ? ;)) using the current semantics could be a part of this SRFI, or revert to "lambda". To throw some gasoline on the smoldering fire, I would prefer the
slot
symbols to be "_" and "_.", mainly because they are shorter. One could even expand the definition to take either set. BTW, in light of your comments in the Design Rationale, maybe
"cut"
should be a mnemonic for "curry-uncurry-this". Dale Jordan
|