Anyone know how to fix the following type error is translated code? Hat/MySet.hs:636:60: Couldn't match `Hat.Hat.R (Hat.Hat.List a)' against `Hat.Hat.RefExp' Expected type: Hat.Hat.R (Hat.Hat.Fun a b2) -> Hat.Hat.RefExp -> Hat.Hat.R (Hat.Hat.Fun b1 (Hat.Hat.List b)) Inferred type: Hat.Hat.R (Hat.Hat.Fun a b2) -> Hat.Hat.R (Hat.Hat.List a) -> Hat.Hat.RefExp -> Hat.Hat.R (Hat.Hat.List b2) In the fifth argument of `Hat.Hat.app1', namely `Hat.PreludeBasic.hmap' In the fourth argument of `Hat.Hat.ap2', namely `(Hat.Hat.app1 p391v20v391v29 p391v20v391v27 p Hat.PreludeBasic.amap Hat.PreludeBasic.hmap ff)' The original code looks like this (and does not cause type errors when compiled normally). map :: (Ord a, Ord b) => (a->b) -> Set a -> Set b map f = fromList . List.map f . toList The translated code looks like this: gmap :: (Ord a,Ord b) => T.RefSrcPos -> T.RefExp -> T.R (T.Fun (T.Fun a b) (T.Fun (Set a) (Set b))) hmap :: (Ord a,Ord b) => (T.R (T.Fun a b)) -> T.RefExp -> T.R (T.Fun (Set a) (Set b)) gmap pmap p = T.fun1 amap pmap p hmap hmap ff p = T.ap2 p391v9v391v38 p (p391v18v391v18 !. p) (gfromList p391v9v391v16 p) (T.ap2 p391v20v391v38 p (p391v31v391v31 !. p) 636 > (T.app1 p391v20v391v29 p391v20v391v27 p Hat.List.amap Hat.List.hmap ff) (gtoList p391v33v391v38 p)) I have not a clue what I'm up to when it gets this fun. Bob
Thomas Davie
Hat/MySet.hs:636:60: Couldn't match `Hat.Hat.R (Hat.Hat.List a)' against `Hat.Hat.RefExp' Expected type: Hat.Hat.R (Hat.Hat.Fun a b2) -> Hat.Hat.RefExp -> Hat.Hat.R (Hat.Hat.Fun b1 (Hat.Hat.List b)) Inferred type: Hat.Hat.R (Hat.Hat.Fun a b2) -> Hat.Hat.R (Hat.Hat.List a) -> Hat.Hat.RefExp -> Hat.Hat.R (Hat.Hat.List b2) In the fifth argument of `Hat.Hat.app1', namely `Hat.PreludeBasic.hmap' In the fourth argument of `Hat.Hat.ap2', namely `(Hat.Hat.app1 p391v20v391v29 p391v20v391v27 p Hat.PreludeBasic.amap Hat.PreludeBasic.hmap ff)'
Simplifying, this means it was expecting to be given a function R (a->b) -> R (c->[d]) but was actually supplied with hmap of type R (a->b) -> R [a] -> R [b] Now clearly the latter looks more or less correct for map, whilst the former does not. For one thing, it has too few arguments. Judging by the name, 'hmap' is the worker part of the worker/wrapper split in the traced map. So the fault would appear to be that hat-trans is doing an optimisation incorrectly. It has called the worker function directly, believing the call to be saturated, when in fact it is only partially applied, and it should have called the wrapper instead. Hence the differing arities in the error message. Olaf is the person who will be able to confirm whether this is a correct diagnosis, and if so, to provide the solution. Regards, Malcolm
Malcolm Wallace wrote:
Olaf is the person who will be able to confirm whether this is a correct diagnosis, and if so, to provide the solution.
No, the problem is not within the optimisation for saturated applications. The problem is that qualified names are not handled correctly and sometimes are confused with unqualified names. The following examples demonstrate this. The program import qualified List map :: (a->b) -> a -> b map f = List.map f is wrongly transformed, because the transformation believes that List.map has arity 1, like the just defined function map. If you just change function names, e.g. import qualified List tmap :: (a->b) -> a -> b tmap f = List.map f then the transformation works fine. The transformation knows that List.map has arity 2 and hence won't apply the optimisation. So the problem is in the auxLabelSyntaxTree part. So I'd like to pass the problem back to Malcolm. Or I'll have to see tomorrow how this part works. Ciao, Olaf
Olaf Chitil
The problem is that qualified names are not handled correctly and sometimes are confused with unqualified names.
So the problem is in the auxLabelSyntaxTree part. So I'd like to pass the problem back to Malcolm. Or I'll have to see tomorrow how this part works.
Ah, I must accept responsibility. The comment in this piece of code particularly sums up the situation:
lookEnv :: Environment -> TokenId -> TraceId lookEnv env id = case useEnvironment env id of Just info -> id `plus` info _ -> case id of -- this is a horrible hack to by-pass qualified names. Qualified _ x -> case useEnvironment env (Visible x) of ....
Thus, at lookup-time, if the qualified name does not resolve, we pretend it is an unqualified name. In fact, the problem lies further back than the AST-relabelling phase. It is during import resolution (in AuxFile) that we are failing to store the qualified variable names into the environment in the first place. I have attempted a solution, to store both qualified/unqualified variants of names into the environment (as appropriate, given the import decls). So far, it doesn't work, but I am too tired to investigate further tonight. I can send you the diffs if you want to look at it yourself...? Regards, Malcolm
participants (3)
-
Malcolm Wallace -
Olaf Chitil -
Thomas Davie