- Hugs-Bugs - Haskell.org

winhugs can't start
by Phat Tran 07 Nov '02

07 Nov '02

Hi! I have a strange problem after a confliction. Well first, I had winhugs in edit-mode then I opened the same file with Jcreator and did some changes and tried to reload the haskell program. At this point there was some thing wrong that it adwised me that it have to turn winhugs off. This was don't automatically by win2000. After this apposal the same precedure kept repeating. I don't know if I have to reinstall my windows or if there is a better way to fix this. I have already try reinstall Hugs98 but have not solve anything. So if you can help me it would be very nice. Sincerely, Phat

2 1

winhugs window disappears
by Mordechai Ben-Ari 07 Nov '02

07 Nov '02

Hello I have used hugs98 with the winhugs gui for a couple of weeks with no problem. Suddenly, every time i try to run it, the window flashes briefly and disappears. Running hugs.exe from a command line still works. I tried uninstalling/rebooting/reinstalling, to no avail. My system is windows xp. Any ideas? Thanks Moti Prof. Moti Ben-Ari Department of Science Teaching, Weizmann Institute of Science and Department of Computer Science University of Joensuu PO Box 111, FIN-80101 Joensuu, Finland Tel: +358-13-251-7951, Fax: -7955 mailto:moti.ben-ari@cs.joensuu.fi http://cs.joensuu.fi/~moti

2 1

Help me!!!!
by Hai 07 Nov '02

07 Nov '02

Please help me,I have just study FP for a while!!!!And I can not execute my file using Hugs!!!Please help me doing this!!!!!!!Thank you very much!!!

2 1

RE: "Could not unambiguously deduce"..
by Simon Peyton-Jones 06 Nov '02

06 Nov '02

| Yes, but isn't that an implementation problem surfacing at the | language level? All the dictionaries needed to delay the decision to | the point of use could also be made available when compiling the | original program, no? After all, that's the reason why there's an | ambiguity in the first place. No, it's not. It's tricky to understand and tricky to explain. I'll have one more go. Consider just this: | > | class C t where | > | expl :: t -> String | > | expl x "default" | > | | > | instance C String where expl s = "String" | > | instance C a => C [a] where expl l = "[a]" Now try this: f :: C a => [a] -> String f xs = expl xs ++ "\n" foo1 = f "wig" foo2 = expl "wig" ++ "\n" baz1 = f [True] baz2 = expl [True] ++ "\n" I think we'll agree that foo2 should return "String\n" and baz2 should return "[a]\n".] But what about foo1 and baz1? Both execute the code for 'f'. What does f do? It needs a dictionary for C[a] to deal with the call (expl xs). BUT it does not know what 'a' is going to be. It can't choose the String instance. So perhaps it should choose the C [a] instance? Well, it could, but then (f xs) would always return "[a]\n". And 'f' must choose one of the two instances right now, because all it's passed is a dictionary for (C a). If, instead, we say f :: C [a] => [a] -> String then f doesn't have to choose which instance... it can just use the C[a] dictionary that is passed. Then in foo1, the compiler knows that it should pass a (C String) dictionary, and in baz1 it should pass a (C [Boo]) dictionary and all is well. In your example things are slightly more complicated because it's the instance decl that gives rise to the problem, but it's just the same issue. Simon | | Not to mention that in the case for which there is an overlap, the | String instance will always be chosen as the more specific one.. | | Claus | | > | data T a ý [a] | > | | > | class C t where | > | expl :: t -> String | > | expl x ÿdefault" | > | | > | instance C String where expl s "String" | > | instance C a ÿC [a] where expl l "[a]" | > | | > | instance (C a {- ,C [a] -} ) ÿC (T a) where | > | expl (D xs) þxpl xs | > | | > | main ÿutStrLn $ expl "hi" | > | | > | ------------ | > | | > | As is, both ghc and hugs reject the program, whereas | > | both accept it with the extra constraint in the C (T a) | > | instance.. Now, I think I can see how the right-hand-side | > | expl could come either from the C String or from the C [a] | > | instance - hence ghc's message: | > | | > | $ ghc --make Tst.hs | > | c:\ghc\ghc-5.04\bin\ghc.exe: chasing modules from: Tst.hs | > | Compiling Main ( Tst.hs, ./Tst.o ) | > | | > | Tst.hs:15: | > | Could not unambiguously deduce (C [a]) | > | from the context (C (T a), C a) | > | The choice of (overlapping) instance declaration | > | depends on the instantiation of `a' | > | Probable fix: | > | Add (C [a]) to the class or instance method `expl' | > | Or add an instance declaration for (C [a]) | > | arising from use of `expl' at Tst.hs:15 | > | In the definition of `expl': expl xs | > | | > | | > | Confused, | > | Claus | > | | > | PS. Perhaps related, but why does Hugs seem to ignore the | > | C a constraint in the context of the original version? | > | | > | $ hugs -98 Tst.hs | > | __ __ __ __ ____ ___ | > | _________________________________________ | > | || || || || || || ||__ Hugs 98: Based on the Haskell 98 | > | standard | > | ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 | > | ||---|| ___|| World Wide Web: | > | http://haskell.org/hugs | > | || || Report bugs to: | > | hugs-bugs(a)haskell.org | > | || || Version: December 2001 | > | _________________________________________ | > | | > | Hugs mode: Restart with command line option +98 for Haskell 98 | > mode | > | | > | Reading file "c:\Program Files\Hugs98\\lib\Prelude.hs": | > | Reading file "Tst.hs": | > | Type checking | > | ERROR "Tst.hs":15 - Cannot justify constraints in instance member | > | binding | > | *** Expression : expl | > | *** Type : C (T a) ÿT a -> String | > | *** Given context : C (T a) | > | *** Constraints : C [a] | > | | > | Prelude> | > | _______________________________________________ | > | Glasgow-haskell-bugs mailing list | > | Glasgow-haskell-bugs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs |

1 0

Re: "Could not unambiguously deduce"..
by C.Reinke 06 Nov '02

06 Nov '02

> | What I don't understand, however, is why adding that extra > | constraint helps in any way? Shouldn't the addition of new > | things in the context only make more options available? Why > | does it make some of the existing, amgibuous options go away? > > With the extra constraint, the instance decl can build a C (T a) > dictionary from a (C a, C [a]) dictionary, by choosing the expl > method from the C [a] dictionary it is passed (ignoring the C a > one). That defers the choice of which of the overlapping instance > decls we are going to use. Perhaps it'll be postponed to a point > at which 'a' is known, in which case the choice is easy. The > point is that we don't want to have to choose between the C String > and C [a] instance decls until we know enough about 'a' to choose > the right one. Yes, but isn't that an implementation problem surfacing at the language level? All the dictionaries needed to delay the decision to the point of use could also be made available when compiling the original program, no? After all, that's the reason why there's an ambiguity in the first place. Not to mention that in the case for which there is an overlap, the String instance will always be chosen as the more specific one.. Claus > | data T a ý [a] > | > | class C t where > | expl :: t -> String > | expl x ÿdefault" > | > | instance C String where expl s ÿString" > | instance C a ÿC [a] where expl l ÿ[a]" > | > | instance (C a {- ,C [a] -} ) ÿC (T a) where > | expl (D xs) þxpl xs > | > | main ÿutStrLn $ expl "hi" > | > | ------------ > | > | As is, both ghc and hugs reject the program, whereas > | both accept it with the extra constraint in the C (T a) > | instance.. Now, I think I can see how the right-hand-side > | expl could come either from the C String or from the C [a] > | instance - hence ghc's message: > | > | $ ghc --make Tst.hs > | c:\ghc\ghc-5.04\bin\ghc.exe: chasing modules from: Tst.hs > | Compiling Main ( Tst.hs, ./Tst.o ) > | > | Tst.hs:15: > | Could not unambiguously deduce (C [a]) > | from the context (C (T a), C a) > | The choice of (overlapping) instance declaration > | depends on the instantiation of `a' > | Probable fix: > | Add (C [a]) to the class or instance method `expl' > | Or add an instance declaration for (C [a]) > | arising from use of `expl' at Tst.hs:15 > | In the definition of `expl': expl xs > | > | > | Confused, > | Claus > | > | PS. Perhaps related, but why does Hugs seem to ignore the > | C a constraint in the context of the original version? > | > | $ hugs -98 Tst.hs > | __ __ __ __ ____ ___ > | _________________________________________ > | || || || || || || ||__ Hugs 98: Based on the Haskell 98 > | standard > | ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 > | ||---|| ___|| World Wide Web: > | http://haskell.org/hugs > | || || Report bugs to: > | hugs-bugs(a)haskell.org > | || || Version: December 2001 > | _________________________________________ > | > | Hugs mode: Restart with command line option +98 for Haskell 98 > mode > | > | Reading file "c:\Program Files\Hugs98\\lib\Prelude.hs": > | Reading file "Tst.hs": > | Type checking > | ERROR "Tst.hs":15 - Cannot justify constraints in instance member > | binding > | *** Expression : expl > | *** Type : C (T a) ÿT a -> String > | *** Given context : C (T a) > | *** Constraints : C [a] > | > | Prelude> > | _______________________________________________ > | Glasgow-haskell-bugs mailing list > | Glasgow-haskell-bugs(a)haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

1 0

RE: "Could not unambiguously deduce"..
by Simon Peyton-Jones 06 Nov '02

06 Nov '02

| What I don't understand, however, is why adding that extra | constraint helps in any way? Shouldn't the addition of new | things in the context only make more options available? Why | does it make some of the existing, amgibuous options go away? With the extra constraint, the instance decl can build a C (T a) dictionary from a (C a, C [a]) dictionary, by choosing the expl method from the C [a] dictionary it is passed (ignoring the C a one). That defers the choice of which of the overlapping instance decls we are going to use. Perhaps it'll be postponed to a point at which 'a' is known, in which case the choice is easy. The point is that we don't want to have to choose between the C String and C [a] instance decls until we know enough about 'a' to choose the right one. Simon | data T a = D [a] | | class C t where | expl :: t -> String | expl x = "default" | | instance C String where expl s = "String" | instance C a => C [a] where expl l = "[a]" | | instance (C a {- ,C [a] -} ) => C (T a) where | expl (D xs) = expl xs | | main = putStrLn $ expl "hi" | | ------------ | | As is, both ghc and hugs reject the program, whereas | both accept it with the extra constraint in the C (T a) | instance.. Now, I think I can see how the right-hand-side | expl could come either from the C String or from the C [a] | instance - hence ghc's message: | | $ ghc --make Tst.hs | c:\ghc\ghc-5.04\bin\ghc.exe: chasing modules from: Tst.hs | Compiling Main ( Tst.hs, ./Tst.o ) | | Tst.hs:15: | Could not unambiguously deduce (C [a]) | from the context (C (T a), C a) | The choice of (overlapping) instance declaration | depends on the instantiation of `a' | Probable fix: | Add (C [a]) to the class or instance method `expl' | Or add an instance declaration for (C [a]) | arising from use of `expl' at Tst.hs:15 | In the definition of `expl': expl xs | | | Confused, | Claus | | PS. Perhaps related, but why does Hugs seem to ignore the | C a constraint in the context of the original version? | | $ hugs -98 Tst.hs | __ __ __ __ ____ ___ | _________________________________________ | || || || || || || ||__ Hugs 98: Based on the Haskell 98 | standard | ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 | ||---|| ___|| World Wide Web: | http://haskell.org/hugs | || || Report bugs to: | hugs-bugs(a)haskell.org | || || Version: December 2001 | _________________________________________ | | Hugs mode: Restart with command line option +98 for Haskell 98 mode | | Reading file "c:\Program Files\Hugs98\\lib\Prelude.hs": | Reading file "Tst.hs": | Type checking | ERROR "Tst.hs":15 - Cannot justify constraints in instance member | binding | *** Expression : expl | *** Type : C (T a) => T a -> String | *** Given context : C (T a) | *** Constraints : C [a] | | Prelude> | _______________________________________________ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

1 0

"Could not unambiguously deduce"..
by C.Reinke 06 Nov '02

06 Nov '02

I'm not actually sure whether this is a bug, but if it isn't, could someone please enlighten me about what is going on?-) [the following is a simplified version of a problem with instances generated by Drift, for Strafunksi, where T would be the Drift target, C would be Term, and expl(ode) would return TermRep] ------------ {-# OPTIONS -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances #-} module Main where data T a = D [a] class C t where expl :: t -> String expl x = "default" instance C String where expl s = "String" instance C a => C [a] where expl l = "[a]" instance (C a {- ,C [a] -} ) => C (T a) where expl (D xs) = expl xs main = putStrLn $ expl "hi" ------------ As is, both ghc and hugs reject the program, whereas both accept it with the extra constraint in the C (T a) instance.. Now, I think I can see how the right-hand-side expl could come either from the C String or from the C [a] instance - hence ghc's message: $ ghc --make Tst.hs c:\ghc\ghc-5.04\bin\ghc.exe: chasing modules from: Tst.hs Compiling Main ( Tst.hs, ./Tst.o ) Tst.hs:15: Could not unambiguously deduce (C [a]) from the context (C (T a), C a) The choice of (overlapping) instance declaration depends on the instantiation of `a' Probable fix: Add (C [a]) to the class or instance method `expl' Or add an instance declaration for (C [a]) arising from use of `expl' at Tst.hs:15 In the definition of `expl': expl xs What I don't understand, however, is why adding that extra constraint helps in any way? Shouldn't the addition of new things in the context only make more options available? Why does it make some of the existing, amgibuous options go away? Confused, Claus PS. Perhaps related, but why does Hugs seem to ignore the C a constraint in the context of the original version? $ hugs -98 Tst.hs __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2001 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: December 2001 _________________________________________ Hugs mode: Restart with command line option +98 for Haskell 98 mode Reading file "c:\Program Files\Hugs98\\lib\Prelude.hs": Reading file "Tst.hs": Type checking ERROR "Tst.hs":15 - Cannot justify constraints in instance member binding *** Expression : expl *** Type : C (T a) => T a -> String *** Given context : C (T a) *** Constraints : C [a] Prelude>

1 0

Does SOE run on Unix?
by Warren Burton 05 Nov '02

05 Nov '02

Several of the programs in Paul Hudak's Haskell text will run under Windows, but fail with Solaris or Linux because Win32Misc isn't available. It looks like only timeGetTime is imported from Win32Mics. Is this an oversight with a simple fix? Has anybody done the fix? Or is this just the tip of the iceberg with a hopeless mess just out of sight? Thanks for any help, Warren

2 1

ambiguous occurrences (in RC1)
by Ross Paterson 05 Nov '02

05 Nov '02

Hugs accepts the following: module A where x = 1 module B where import A x = 'a' y = x but the reference to x in B is ambiguous.

1 0

REMINDER - HC&A Report (November edition)
by C.Reinke 04 Nov '02

04 Nov '02

As you may have noticed, the deadline for the next edition of our report passed last Thursday. Yet I still don't have received an update for the Hugs section. Given your ongoing efforts, and the recent activity around preparing a new release, I consider this as a serious bug! Unless fixed urgently, it would leave a disappointing gap in the report.. I'm currently in the process of editing the parts of the report together, so if one of our Hugs Heros (tm) could send me an update as soon as possible, it could still go in. Thanks, Claus

1 0