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

Re: 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.

> 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)))))