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