On 26 Okt., 06:23, "Matthew D. Swank" <[EMAIL PROTECTED]> wrote:
> I am dubious of the curry proposal, Hi Matt! Could you please be more specific about what makes you dubious? I understand that the #(..) reader macro can’t be used, but this won’t keep us from having some other instead. It could be $(...) or ~(...) or @(...) or *(...) or !(...) or &(...) and so on. > and there are already valid questions about it raised in this thread. What were these questions? wwmorgan mentioned that partial can be used to achieve part of what $ (..) can do. I argue that (partial ...) makes not much sense. Clojure has introduced a good bit of syntax in it’s reader, and it makes totally sense to have it. [1 2 3] instead of (vector 1 2 3). ^form instead of (meta form) and so on. Clojure is still Lisp, and in my opinion probably the best one we ever had. It’s an evolution and brings real progress. Rich mentioned that he finds the idea interesting but sees a technical problem of using the #(...) reader macro. We will probably need something else, as #(..) also works with macros and special forms. So, let’s have $(..) then and make it working for functions only. We have no huge codebase of programs written in Clojure yet, so we can’t do a statistical analysis about uses of #(...). But I guess in most cases it will not be one of the special cases that Rich mentioned, but instead be used as syntactic sugar for (fn [..] ...). So, we could introduce a $(...) and let it do currying. > However, I am also reminded > of the "Design Rationale" section > ofhttp://srfi.schemers.org/srfi-26/srfi-26.html > which argues against an autocurrying mechanism for Scheme. Yes, I am also against autocurrying. That’s why I suggest to make it a macro and introduce a reader macro for it. The code for the currying macro is in this thread. One could rename it from § to curry or something like that. I can’t implement a reader macro for it because the *readtable* is not accessible. So, we would probably need to put it into the Java code and make out of $(f %1 %1 _ 10) ==> (curry f %1 %1 _ 10) which would become ==> (fn [arg1 arg2 & args] (apply f arg1 arg1 arg2 10 args)). The code that I gave was a fast hack which doesn’t work with all cases, but it shows the concept. Given that Clojure is the first modern and only real candidate (at least for me) that can outdate Common Lisp and already provides a rich syntax for the most typical stuff done in functional programming I honestly see no reason why *not* also offering support for explicit currying. Explicit in that it will need a fancy symbol in front of the parens, like $, to make the reader catch and compile it. This also gives the eye something to work with and inform the reader/programmer that currying is happening here. > While not > identical to what's being proposed here, the srfi and attendant > discussion is a good exploration of currying like mechanisms in a > language where primitive function application doesn't support it. It was a nice read, thanks for the link. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
