2.15.5 Rationale design

Why not real currying/uncurrying?

It is possible in Scheme to implement a macro turning a multi–argument procedure into a nesting of single–argument procedures and back. These operations are usually called “curry” and “uncurry” in other programming languages.

Yet, Scheme remains an inherently uncurried language and is not prepared to deal with curried procedures in a convenient way. Hence, a “by the book” implementation of currying would only be useful if you apply it in the sequence “curry, specialize some arguments, and uncurry again”, which is exactly the purpose of the macro cut specified in this document. The primary relevance of currying/uncurrying in Scheme is to teach concepts of combinatory logic.

Why not a more general mechanism, also allowing permutation omission and duplication of arguments?

The reason is that I, the author of this SRFI, consider more general mechanisms too dangerous to mix them with the mechanism proposed here. In particular, as soon as parameters are being rearranged it is usually necessary to be aware of the meaning of the parameters; unnamed variables can be quite harmful then. The mechanism proposed here is designed to prevent this.

Please refer to the discussion threads “OK, how about...,” (Alan Bawden), “is that useful?” (Walter C. Pelissero), and “l, the ultimate curry that is not curry” (Al Petrofsky).

Why are the macro called cut/cute and not [enter your favourite here]?

Well, the original name proposed for this SRFI was curry which immediately stirred some emotions as it does not what is commonly known as currying. Some alternatives have been discussed, such as:

section         specialise      specialize,
partial-apply   partial-call    partial-lambda,
_j              _i              $
&               srfi-26         foobar
xyz             schoenfinkelize curry-which-isnt-curry
tandoori

and it has also been suggested to pick a five letter symbol uniformly at random and fix this as a name. To be fair, not all of these name have been put forward as serious proposals, some of them were merely to illustrate a point in the discussion. In addition, I have played with the game of the name quite a bit and considered other candidates not listed here.

Despite the fact that the discussion list only represents a highly biased random sample of people’s opinion (motivation to post a message is higher if you disagree, for example) it told me that the SRFI could potentially benefit from a different name; however impractical it may be to go for unanimous popularity.

The name cut refers to “operator section”, as the concept is often called in other programming languages, but I tend to remember it as the acronym for “Curry Upon This”. ;-) The names for the evaluating version of cut that have been proposed were cut!, cutlet, cut*, and cute.

Is it possible to implement the SRFI without macros?

Not really. As Stephan Houben has pointed out during the discussion (refer to “Implementing it as a procedure”) it is possible to implement the cute–mechanism as a procedure. Refer also to Al Petrofsky’s posting “Problems with curry’s formal specification” for details.

However, the procedural implementation comes with a slight performance penalty and it is not possible the implement the cut–mechanism as a procedure, too.

As both are needed, we rely on macros to implement the SRFI. Why is there another symbol for the rest–slot when lambda–expressions use the dotted notation for variable length argument lists? There are two reasons. The first one is the existence of a procedural implementation of a related mechanism (refer to the previous paragraph). For a procedure, however, it is not possible to have dotted notation. The second reason is the way the hygienic macro mechanism in R5RS is defined to deal with dotted notation, as Felix Winkelmann has pointed out. Refer to the discussion threads “Improper lists in macros [WAS: none]”.

Why is it impossible to specify when a non–slot is evaluate individually per non–slot?

cut evaluates all non–slots at the time the specialized procedure is called and cute evaluates all non–slots at the time the procedure is being specialized. These are only the two extremes and it is possible to define a syntax that allows to choose per non–slot. However, I am convinced that the benefit of the greater flexibility is not worth the risk of confusion. If a piece of code really depends on the distinction, it might be better to make this explicit through let and lambda.

Why is (cut if <> 0 1) etc. illegal?

It is specified that a <slot-or-expr> must be either the slot symbol or an <expression> in the sense of R5RS, Section 7.1.3. As if is no <expression>, the above case is illegal. The reason why cut and cute are restricted in this sense is the difficulty of defining the meaning of such generalized expressions. Please refer to the discussion archive for details.