Is there any theoretical reason why GHC (or Haskell) doesn't permit functions to be inferred from their parameter types? For example, if I write null Data.Set.empty I get a diagnostic saying Ambiguous occurrence `null' It could refer to either `List.null', imported from Data.List at ... or `Map.null', imported from Data.Map at ... or `IntSet.null', imported from Data.IntSet at ... Why doesn't GHC figure it out? More generally it would be nice to be able to define: f :: Type1 -> ResultType1 f :: Type2 -> ResultType2 and expect GHC to select the appropriate f based on the argument and implied result types. Even if the type can't always be determined, why not do it when possible and issue a complaint when it can't? * -- Russ *
On Tue, Dec 7, 2010 at 8:35 AM, Russ Abbott
Is there any theoretical reason why GHC (or Haskell) doesn't permit functions to be inferred from their parameter types? For example, if I write
null Data.Set.empty
I get a diagnostic saying
Ambiguous occurrence `null' It could refer to either `List.null', imported from Data.List at ... or `Map.null', imported from Data.Map at ... or `IntSet.null', imported from Data.IntSet at ...
Why doesn't GHC figure it out? More generally it would be nice to be able to define:
f :: Type1 -> ResultType1 f :: Type2 -> ResultType2
and expect GHC to select the appropriate f based on the argument and implied result types. Even if the type can't always be determined, why not do it when possible and issue a complaint when it can't?
-- Russ
I believe this is covered by the proposal for Type Directed Name Resolution. You may be interested in a recent thread on the cafe[1] discussing its merits and problems. Michael [1] http://www.mail-archive.com/haskell-cafe@haskell.org/msg84144.html
participants (2)
-
Michael Snoyman -
Russ Abbott