Yes, it is. the reason is, as I think, the following from application h t we can derive t :: a h :: t1 -> t2 after unification t :: a h :: a -> t2 now (h:t) t :: [e] h :: e merging t:: a ~ [e] -> a == [e] and it follows h :: [e] -> t2 h :: e which would give infinite type for unification. Nevertheless, from the example it is obvious, that for particular case, it is fine. We can explicitly type: h :: [a] -> a t :: [[a] -> a] for (h:t) it is OK h :: e ~ [a]->a and t :: [e] ~ [[a]->a] e.g. e == [a]->a and h :: e and t ::[e], which is fine Now, h t h :: [a] -> a t :: [[b] -> b] and it is fine, as type a == [b] -> b of course, monomorphism restriction would lead to infinite type again. So, the question is, how for the particular case force the inference this way, to break the restriction... Dušan On 03/07/2014 09:33 AM, Vincent Beffara wrote:
We have and error of infinite type for Prelude> :t ((\(h:t) -> h t) [head, last, head, last, head, last])
Of course, head and tail are incompatible on type level...
It seems like you need heterogenous collections[0] Well the error pops up much earlier than that, see:
Prelude> :t (\(h:t) -> h t)
Regards, Henk-Jan van Tuyl
[0] http://www.haskell.org/haskellwiki/Heterogenous_collections
-- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/
http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --