[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cut should evaluate its arguments



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