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

Problems with "curry"'s formal specification

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.



The formal spec of curry is vague in a few respects:

                           Specification

   The formal syntax of a curried expression, in the style of the
   [5]Revised^5 Report on the Algorithmic Language Scheme:

   <curried-expression> -->   (curry <proc> <const-or-slot>*)
                            | (curry <proc> <const-or-slot>* <...>)
   <proc>               -->   <expression>   ; a procedure
   <const-or-slot>      -->   <>	     ; a "slot"
                            | <expression>   ; a constant

   The macro curry transforms a <curried-expression> into a <lambda
   expression> with as many formal variables as there are slots in the
   list <const-or-slot>*. The body of the resulting <lambda
   expression> calls <proc> with the arguments from <const-or-slot>*
   in the order they appear.  In case there is a rest-slot symbol for
   the residual arguments of a variable arity procedure, the resulting
   procedure is also of variable arity and the body calls <proc> with
   all arguments provided to the actual call of the specialized
   procedure.

Why are "const"s called "constant"?  May they be any expressions?
When is the procedure expression evaluated?  When are the "constants"
evaluated?  In other words, which of the following expressions are
legal, and what do they return?

  (let* ((x +) (y (curry x <> 1))) (set! x -)  (y 0))
  (let* ((x 1) (y (curry + <> x))) (set! x -1) (y 0))

The reference implementations give different results.

-al