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.
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.
