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
