help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Style Issues in Lisp and Scheme programming, setq versus let ... and


From: Pascal J. Bourguignon
Subject: Re: Style Issues in Lisp and Scheme programming, setq versus let ... and onion structure with multiple cores or eyes or kernels Re: string to list or string to array
Date: Wed, 21 Nov 2012 22:56:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

gnuist007@hotmail.com writes:

> On Oct 24, 8:03 am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
>> > btw, Lisp's prefix notation, (f x y z) is more expressive and
>> > convenient for expressing currying (((f x) y) z) than f(x y z).
>>
>> With all due respect to Lisp, that's not true.  Curried calls in the
>> non-Lisp syntax are simply "f(x)(y)(z)" or even better "f x y z".
>>
>>         Stefan
>
> As an aside you show the notation. well and good. But I realize that
> there is no executable substitute or ability to return a curried
> function
> in emacs. Consider these forms.
>
> (+ 2 3 4) ;; executable
> (((+ 2) 3) 4)  ;; not executable
> (cons '+ (cons 2 (cons 3 (cons 4 nil))))  ;; ditto
> (eval  '(+ (cons 2 (cons 3 (cons 4 nil)))))  ;; ditto
>
> Can anyone suggest an executable version of first in terms of curried
> addition?
>
> Since Pascal is busy, and David Kastrup is not seen for quite some
> time, I hope someone can give a reply to the question of the thread.


Well, if you want to keep the variadicity of the operation, it's hardly
possible, because you can only return either a number or a function.  In
lisp, numbers are not applicable functions.

Otherwise the following should work, in emacs-24:

;; in emacs-24:
(setq lexical-binding t)
(defun plus/2 (arg) (lambda (x) (+ arg x)))
(defun plus/3 (arg) (lambda (y) (plus/2 (funcall (plus/2 arg) y))))

(funcall (plus/2  2) 3)                --> 5
(funcall (plus/3  2) 3)                --> #<some closure>
(funcall (funcall (plus/3  2) 3) 4)    --> 9


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]