Surely it would lead to all sorts of problems if you didn't use distinctive syntax. When you passed too few arguments to a fn, instead of generating an error, it would just yield a curried version.
Or is this one of those things (like defmacro in a Lisp1) that sounds like it would lead to problems, but doesn't in practice?
According to your essays, a major paradigm of arc is to let hackers do as much as possible, without giving errors when the compiler is worried things are "too dangerous". Partial application/function currying is my #1 request for arc right now... I would love it if any arc function given too few non-optional parameters would perform an implicit curry.
Incidentally, [...] syntax helps amortize the problem of non-existent curry: curried (map fn) == [map fn _]
Adding curry support will also require us to define flipped parameters, i.e.
(def flip (f x y)
(f y x))
Or better:
(mac flip ( (f x . ys) )
(if
(no ys)
(w/uniq p
`(fn (,p) (,f ,p ,x)))
(is 1 (len ys))
`(,f ,(car ys) ,x)
(ero "flip: more than two parameters in call")))
In haskell and all ML children, when you pass too few arguments to a fn, it would just yield a curried version. Of course, they have static type systems to reduce errors caused by passing too few arguments. but I guess Arc's goal is to be good for quick prototyping, not good at elimating run-time errors...
That is one of the features of Haskell I really like. I'm not sure of all the implications for attempting it with Arc, but if it's possible to do it well, I think it's worth the research.
Implicit currying is another "new possibility".
In CL, applying a number to a list causes an error, but it's valid in Arc.
And in CL, passinging less or more arguments to a fixed-number-parameter-function causes an error, but with implicit currying, it's not an error any more.
