[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Just add WITH-VALUES and VALUES.
As long as I'm babbling, my problem with ACCEPTS? or
PROCEDURE-ACCEPTS? is that there is no inverse for it -- no general
way to construct a procedure that can advertise how many arguments it
would like to accept. In particular, it makes invalid Scheme's
currently useful eta-expansion rule: if x is a procedure, then x can
be replaced by (lambda args (apply x args)) [modulo EQ?]. We could
recover some kind of eta rule if we had some way to associate an
ACCEPTS? "method" with a procedure, e.g. maybe (ACCEPTING proc1 proc2)
would return a procedure p that behaved the same as proc1 except that
(ACCEPTS? p n) would return the value returned by (proc2 n).
(You can do this kind of thing in T, which has a crude analogue of
ACCEPTS?.) Then we would have x equivalent to
(accepting (lambda args (apply x args)) (lambda (n) (accepts? x n))).
I'm not proposing ACCEPTING, and I'm not saying that I would veto any
proposal that has ACCEPTS? in it.
I've been considering adding a similar procedure to MIT Scheme for a
while, but along slightly different lines:
(restrict-arity proc1 proc2) -> proc3
where proc3 has the same arity signature that proc2 has, yet invokes
proc1 instead. It must also be the case that
"for all n s.t. (accepts? proc2 n) -> #t, (accepts? proc1 n) -> #t"
otherwise restrict-arity should error.
The "eta" rule would be obtained by doing
(restrict-arity (lambda args (apply x args)) x)
Unfortunately, due to the lack of an optional argument mechanism in
the standard, it would be hard to "copy" things like WRITE-CHAR, but
hopefully (perhaps I'm being naive) this will be resolved
independently.
MIT Scheme currently has a restricted form of this in the following
(provided for a different reason)
(coerce-to-compiled proc1 n) -> proc2
proc2 expects exactly n arguments.
The original intent for this would be that map, or for-each, or
similar things would do their arguments checking once by using
coerce-to-compiled, and then invoke the resulting procedure directly
without any further arity checks.