Arc Forumnew | comments | leaders | submitlogin
3 points by shiro 6159 days ago | link | parent

One of my friend is a Haskell programmer and he and I once have tried to put implicit currying into Scheme.

The biggest problem is Scheme's variable arity. You might think you can do currying only based on the required arguments, but that doesn't work in practice. Suppose this simple "complement" procedure:

    (def complement (f) (fn args (no (apply f args))))
This loses arity information of original function f. It is extremely annoying that you get it curried for two-arg function f by

    (f 1)
and not curried for its complement:

    (~f 1)
Another example that breaks implicit currying is a simple debugging aid procedure that wraps the given function to trace its invocation. Just redefining f with the wrapped f (which, many simple 'trace' macro does), and implicit currying on f break. It's very fragile.

If you have access to the internal of the implementation, you may be able to extract arity information from the original function and transplant it to the new function. But automating it generally is difficult, and relying programmers to do that manually is cumbersome.

Our conclusion was that implicit currying and variable arity (without type information) didn't mix. You have to choose either one.



1 point by binx 6158 days ago | link

The same statement can be used for multiple inheritance. Some people may call it a trouble maker, while some people call it a feature...

-----

3 points by shiro 6158 days ago | link

I don't quite get the parallel. I'm talking about introduction of a new feature X breaking a model implied by an existing feature Y, even if there's nothing wrong with either X or Y individually. Can you elaborate your remark?

-----