[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with "curry"'s formal specification
> 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)))))