On Mon, Dec 03, 2012 at 03:20:41PM +0000, Miguel Negrao wrote:
A 03/12/2012, às 12:53, Brent Yorgey escreveu:
Is there a syntax in Haskell for partial application that would be something like this the following ?
f a b c d = a +b+ c+ d
g = f _ 1 2 3 Yes, a lambda is the only way to do it.
Given how compact haskell’s syntax can be, is there a reason why implementing such placeholders is not a good idea for haskell ?
Yes: it would introduce horrible ambiguity. Consider (f (g _ 1 2)) Does it mean (f (\x -> g x 1 2)) or (\x -> f (g x 1 2)) ? I don't know of any good reason to prefer one over the other. Any rule you come up with is likely to have other weird corner cases you hadn't considered. As I understand it, Scala actually does have this feature, along with lots of confusing, ugly, ad-hoc rules to disambiguate situations like the above.
2. Suppose you make a mistake when implementing a function. If you don't give a type signature, it's possible that GHC will infer some type for it anyway (but not the type you intended!). Now you will not get an error until further down the line when you use that function somewhere else. And what's more, the error will not tell you anything about the real problem. It will just say "X does not match Y on line 297" and you will have to do a lot of work to figure out that the real problem is that you messed up in implementing function foo on line 43. But if you had put a type signature on foo in the first place, you would have gotten an error immediately.
Ok, I see your points. Number 2 does happen to me from time to time, at which point I go back to the a point where the code worked and introduce the type signatures with hlint, so yeah doing the signatures would save me from having to do that. Sometimes I know how to write a function but I don’t know how to write the type signature because they are too complicated for my still reduced knowledge of haskell, for instance, I don’t know when I need to use the forall thing, which hlint sometimes introduces when it produces the type signatures. Perhaps the problem might be that I should be using less top-level functions and defining some of those functions where they are used ? A lot of my top-level functions are used only in one place in the code, I just code them as top-level so that I can test them in ghci if I need to.
No, I don't think using less top-level functions will solve anything. In the case where you don't know how to write a type because it is too complex, or requires features you don't understand, I think it is reasonable to write it, ask GHCI for its type signature, make sure it looks reasonable, and then add it to your file. But I would hope this situation makes up a minority of cases. One could also question the wisdom of writing code that requires type system features you don't understand. -Brent