Re: Problems with "curry"'s formal specification

[Al Petrofsky <al@xxxxxxxxxxxxx>]

> From: sebastian.egner@xxxxxxxxxxx

> 1. Why are "const"s called "constant"?
> 
> The name was chosen because the values put into the
> filled slots do not depend directly on the arguments
> of the resulting procedure. As this is only true if
> there are no common side effects, the name is not as 
> accurate as it appears at first sight. Unfortunately,
> argument, parameter, and value are all very ambiguous 
> in this context. Do you have a suggestion?

I think "argument" can work.  If the semantics are changed so that
these values are indeed constant in the resulting procedure, then the
name "const" would be more reasonable.

> 3a. When is the procedure expression evaluated?
> 3b. When are the "constants" evaluated?
> 3c. [...], and what do they [the examples above, SE] return? 
> 
> (These questions are also the issue raised by the
> 'cons-stream' example in your other posting with subject 
> line > Re: l, the ultimate curry that is not curry <)

That's a slightly different issue.  If cons-stream is not a procedure,
then it is clearly illegal as the first argument to curry.  No matter
which way you decide to fix the spec, I suggest leaving this
restriction in place.  It happens to make sense for cons-stream, but
it will raise issues with other non-procedures, e.g. what does (curry
quote <>) do?

> OPT3 Yet another option is to define the procedural semantics
> as the only SRFI-compliant semantics. It is easy to modify
> the macro implementation to evaluate the "constants" before
> the specialized procedure is constructed. In this case, it
> might be better to think about the mechanism as some form
> of partial evaluation, without the tricky bit of really 
> doing it.
> 
> Whatever happens to the SRFI, this is certainly an issue
> that has to be addressed. What is your advice?

First, I'm not entirely convinced that this SRFI should proceed at
all, and I agree with those who think that "curry"'s name must be
changed to better reflect its not-curry nature.

That being said, option 3 appeals the most to me.

By the way, even if you decide not to support argument reordering and
duplication (i.e. numbered slots), I see no reason to forbid non-slot
arguments after a rest-slot:

  (curry < 0 <...> 100)  <==>  (lambda args (apply < `(0 ,@args 100)))

This would only require adding one rule to your macro:

    ((curry "loop" (params ...) proc (args ...) <...> . more)
     (lambda (params ... . rest-slot)
       (apply proc args ... (append rest-slot (list . more)))))

-al