When a function expecting n arguments is given n-x arguments, it should return a closure that takes x arguments, like Haskell does. There should also be a partial application function (maybe with optional syntax) for use with functions that have optional arguments.
I think this would be great, but it'll take some work. For example right now Arc compiles s-exps to mzscheme, so it would need to change mzscheme's semantics (not sure if this is even practical or possible). Arc most likely needs to stand on its own a little more before this will be feasible.
Partial application probably isn't as useful in Arc as it is in Haskell since many functions take an arbitrary number of arguments. E.g. you couldn't do (map (+ 10) xs) because (+ 10) just evaluates to 10.
Edit: why is there a gap at the top of my comment?
Probably not, but it's still useful as a generic way to write generator functions. Your par macro isn't working as expected for me. Is this a bug, or am I using it wrong?
I don't know if a call-by-reference par could be implemented using macros. I also don't know that that's a good idea, since it could lead to bugs when mutation is involved.
(= fns nil)
(= x 1)
(push (par + x) fns)
(= x 2)
(push (par + x) fns)
(= x 3)
(push (par + x) fns)
(map [_ 1] fns) => (4 4 4) ; probably not what you want
Edit: I think the issue is that we have slightly different definitions of partial application. You are thinking of it as a sort of syntactic sugar on top of closures, whereas I (being primarily an ML programmer) am used to thinking of partial application as a function call. So that's why we have different intuitions about how it should work.
By the way, why are you bothering with generators? Arc being an exploratory language, the idea seems to be to use lists for everything, at least at first. Iterators/generators are often a premature optimization.
