this is the OP. is there is no such thing as functional automatic currying in any kind of lisp? is it possible with macros? (read: careful macros)
Name:
Anonymous2008-11-26 0:18
>>11
There's probably a Lisp that includes partial application, which is what I assume you meant to say. If not, make one, faggot.
Name:
Anonymous2008-11-26 0:33
>>12 no, not specifically partial application, though i'm sure it would need to exist to have a truly curryed lisp. really, im just too busy and i want you to do it for me.
i suppose that would really be some kind of laziness...
Name:
Anonymous2008-11-26 4:06
SRFI-26: Notation for Specializing Parameters without Currying
[b]Why not real currying/uncurrying?[/b]
It is possible in Scheme to implement a macro turning a multi-argument
procedure into a nesting of single-argument procedures and back. These
operations are usually called "curry" and "uncurry" in other
programming languages. Yet, Scheme remains an inherently uncurried
language and is not prepared to deal with curried procedures in a
convenient way. Hence, a "by the book" implementation of currying
would only be useful if you apply it in the sequence "curry,
specialize some arguments, and uncurry again"---which is exactly the
purpose of the macro cut specified in this document. The primary
relevance of currying/uncurrying in Scheme is to teach concepts of
combinatory logic.
>>20 ((((+) 1 2) 3) 4) is the value 10, in a lazy lisp like >>15 suggested. get your head out of your ass
Name:
Anonymous2008-11-26 16:11
>>23
That has nothing to do with laziness. It's partial application.
Name:
Anonymous2008-11-26 16:14
The pleasure of being cummed inside
Name:
Anonymous2008-11-26 16:17
>>24
the entire Haskell programing language is automatically curried, is that also partial application?
Name:
Anonymous2008-11-26 17:06
>>26
Yes. Partial application is when you apply a function taking n arguments to only one argument, and get a function taking n-1 arguments rather than a syntax error. Automatic currying is an ungainly way of saying it. But it has nothing to do with laziness.
>>15,18,27
(define (plus . args)
(lambda x
(if (null? x)
(apply + args)
(apply plus (append args x))))))
(((plus 1) 2) 3)
(((plus) 1 2) 3)
(((plus) 1) 2 3)
The plus function returns a thunk that must be applied to 0 arguments to get the expression's value, else it will continuously bind the its arguments to the return thunk.
Methinks, only the evaluator would need to be modified to provide for a lazy LISP interpreter.