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

*To*: jar*Subject*: Just add WITH-VALUES and VALUES.*From*: Guillermo J. Rozas <jinx@hpesogg.hp.com>*Date*: Wed, 23 Aug 89 12:11:50 pdt*Cc*: ramsdell@linus.mitre.org, rrrs-authors@life.ai.mit.edu*In-Reply-To*: Jonathan Rees's message of Wed, 23 Aug 89 13:51:53 edt <8908231751.AA00815@zurich.ai.mit.edu>*Reply-To*: jinx%hpesogg@sde.hp.com

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.

**References**:**Just add WITH-VALUES and VALUES.***From:*jar (Jonathan Rees)

- Prev by Date:
**Numbers** - Next by Date:
**theology; MAX and MIN** - Prev by thread:
**Just add WITH-VALUES and VALUES.** - Next by thread:
**Just add WITH-VALUES and VALUES.** - Index(es):