October 2001 - Haskell

Re: Strange error in show for datatype
by cwitty＠newtonlabs.com 03 Oct '01

03 Oct '01

Bjorn Lisper <lisper(a)it.kth.se> writes: > data LispList t = Atom t | LispList [LispList t] | Str [Char] > > instance Show t => Show (LispList t) where > show (Atom t) = show t > show (LispList t) = show t > show (Str t) = show t > > hugsprompt> (LispList [Atom 1, Str "HEJ"]) ==> [1,"HEJ"] > hugsprompt> (LispList [Str "HEJ",Atom 1]) ==> "Cannot find show function...." > > So there is a problem when the value is of form Str string or where such a > value is first in the list l in a value of the form LispList l. Oddly > enough, such values may appear at other positions without causing any > problems. Are you sure about that? I can't reproduce the above results in hugs (Hugs 98, February 2000) or ghci (5.02). I get a much simpler answer: if the s-expression includes an Atom term, it works; otherwise you get a type error. In particular, for the second example above (LispList [Str "HEJ", Atom 1]) both ghci and hugs produce the expected result, rather than failing. Carl Witty

1 0

RE: Strange error in show for datatype
by Simon Peyton-Jones 03 Oct '01

03 Oct '01

Interesting. The difficulty (which GHCi has too) is this. Consider expr = Str "foo" msg = show expr Hugs wants to print msg. What are the types? expr :: forall a. LispList a msg :: forall a. Show a => String Urk! What "Show" dictionary should Hugs use when evaluating "msg"? You may say "it doesn't matter", but in general that's not the case. In the case of class Num, for example, we might have expr = 3+4 msg = show expr and then the type involved really does matter. In the case of Num there are defaulting rules, but not for arbitrary user types. What is particularly annoying here is that it's intuitively obvious that if we have an expression of type (forall a. LispList a) then it can't have any useful values of type 'a' in it. So we can't need to show any of them. Hmm. I wonder if the following is true. Given the ambiguous type forall a. Show a => T (where a does not appear in T) it's OK to pass the bottom dictionary. Furthermore, I claim that what makes it OK is that Show has no methods that have 'a' in the result that do not also have 'a' in an argument. The Bad Methods are like those in Num and Read: class Num a where fromInteger :: Integer -> a -- Bad guy ... class Read a where read :: String -> a -- Bad guy ... So (my claim) if none of the classes of the ambiguous type have a method that returns an a-value, we can definitely replace the dictionary with bottom. Indeed, if none of the classes have a method that returns an a-value without also consuming one (urk-- strictly, I think, sigh) then the same holds. In which case we could report ambiguity a bit less often. How useful this would be I don't know. Simon | For a change, a teacher asking for help on behalf of a student.... | | I have a student who wants to emulate S-expressions of Lisp | in Haskell. He came up with the following data type: | | data LispList t = Atom t | LispList [LispList t] | Str [Char] | | This works just fine. He then wanted to make it an instance | of Show, in order to print values of this type: | | instance Show t => Show (LispList t) where | show (Atom t) = show t | show (LispList t) = show t | show (Str t) = show t | | Now, this compiles and works for some values of the type, but | not for all! Here is what happens in hugs: | | hugsprompt> (Atom 1) ==> 1 | hugsprompt> (LispList [Atom 1, Str "HEJ"]) ==> [1,"HEJ"] (LispList | hugsprompt> [Atom 1, LispList [Str "HEJ"]]) ==> [1, ["HEJ"]] (Str | hugsprompt> "HEJ") ==> "Cannot find show function...." | (LispList [Str | hugsprompt> "HEJ"]) ==> "Cannot find show function...." | (LispList [Str | hugsprompt> "HEJ",Atom 1]) ==> "Cannot find show function...." | | So there is a problem when the value is of form Str string or | where such a value is first in the list l in a value of the | form LispList l. Oddly enough, such values may appear at | other positions without causing any problems. | | I don't think there is a bug in hugs. Similar problems appear | if the Show instance is derived, and ghc will also complain - | if the definition f = show (LispList [Str "HEJ"]) is | compiled, for instance, the compiler will complain about | ambiguous contexts. Ghc will say | | Enrico.hs:1: Ambiguous context `{Show taKi}' | `Show taKi' arising from use of `show' at | Enrico.hs:17 | | and hugs | | Reading file "Enrico.hs": | Type checking | ERROR "Enrico.hs" (line 17): Unresolved top-level overloading | *** Binding : f | *** Outstanding context : Show b | | So I wonder whether the infamous Monomorphism Restriction is | lurking somewhere here? But I cannot see exactly how right | now. Does anyone else have a clue? | | Björn | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

2 1

BOFH's excuse board
by Duncan Coutts 03 Oct '01

03 Oct '01

Hi all, I though you might apreciate this: I've been reading the BOFH (Bastard Operator From Hell) serialisation in The Register (www.theregister.co.uk) far to much recently. He (the bastard) often uses his excuse board to confuse his helpless users. http://bofh.ntk.net/ExcuseBoard.html I have made a Haskell version of this essential tool. I'm sure you'll find it useful. Here's a random output selection and the code: Undiagnosable Framing Condition Extraneous Hardware Crash Temporary Streaming Bug Generic Peripheral Crash Dereferenced Swapfile Override Partial Service Anomoly Delayed Bus Invalidation Virtual Array Reclock Generic Paging Incompatibility Permanent Proxy Timeout Non-Specific Precondition Rejection Redundant Firmware Dereferencing Delayed Reception Reclock Unreportable Operation Corruption Insufficient Parameter Condition Non-Specific Bus Dump Serial Comms Corruption Unvalidated Encryption Underflow Delayed Parity Desynchronisation Major Code Incompatibility Immediate Programming Destabilisation Minor Parity Overflow excuse.hs: -------------------- #!runhugs import Random main :: IO () main = do gen <- getStdGen putStr $ excuse gen excuse :: StdGen -> String excuse gen1 = let (rnd1, gen2) = randomR (0, length part1 - 1) gen1 (rnd2, gen3) = randomR (0, length part2 - 1) gen2 (rnd3, _) = randomR (0, length part3 - 1) gen3 in part1 !! rnd1 ++ " " ++ part2 !! rnd2 ++ " " ++ part3 !! rnd3 ++ "\n" part1 = ["Temporary", "Intermittant", "Partial", "Redundant", "Total", "Multiplexed", "Inherent", "Duplicated", "Dual-Homed", "Synchronous", "Bidirectional", "Serial", "Asynchronous", "Multiple", "Replicated", "Non-Replicated", "Unregistered", "Non-Specific", "Generic", "Migrated", "Localised", "Resignalled", "Dereferenced", "Nullified", "Aborted", "Serious", "Minor", "Major", "Extraneous", "Illegal", "Insufficient", "Viral", "Unsupported", "Outmoded", "Legacy", "Permanent", "Invalid", "Deprecated", "Virtual", "Unreportable", "Undetermined", "Undiagnosable", "Unfiltered", "Static", "Dynamic", "Delayed", "Immediate", "Nonfatal", "Fatal", "Non-Valid", "Unvalidated", "Non-Static", "Unreplicatable", "Non-Serious"] part2 = ["Array", "Systems", "Hardware", "Software", "Firmware", "Backplane", "Logic-Subsystem", "Integrity", "Subsystem", "Memory", "Comms", "Integrity", "Checksum", "Protocol", "Parity", "Bus", "Timing", "Synchronisation", "Topology", "Transmission", "Reception", "Stack", "Framing", "Code", "Programming", "Peripheral", "Environmental", "Loading", "Operation", "Parameter", "Syntax", "Initialisation", "Execution", "Resource", "Encryption", "Decryption", "File", "Precondition", "Authentication", "Paging", "Swapfile", "Service", "Gateway", "Request", "Proxy", "Media", "Registry", "Configuration", "Metadata", "Streaming", "Retrieval", "Installation", "Library", "Handler"] part3 = ["Interruption", "Destabilisation", "Destruction", "Desynchronisation", "Failure", "Dereferencing", "Overflow", "Underflow", "NMI", "Interrupt", "Corruption", "Anomoly", "Seizure", "Override", "Reclock", "Rejection", "Invalidation", "Halt", "Exhaustion", "Infection", "Incompatibility", "Timeout", "Expiry", "Unavailability", "Bug", "Condition", "Crash", "Dump", "Crashdump", "Stackdump", "Problem", "Lockout"] ---------- Actually I was having problems with getStdGen on my hugs instalation. It always returns the same number. So I hacked up an alternative that gets passed $RANDOM on the command line: main = do args <- getArgs let gen = read $ head $ args in putStr $ excuse gen Duncan

1 0

Strange error in show for datatype
by Bjorn Lisper 03 Oct '01

03 Oct '01

Hi, For a change, a teacher asking for help on behalf of a student.... I have a student who wants to emulate S-expressions of Lisp in Haskell. He came up with the following data type: data LispList t = Atom t | LispList [LispList t] | Str [Char] This works just fine. He then wanted to make it an instance of Show, in order to print values of this type: instance Show t => Show (LispList t) where show (Atom t) = show t show (LispList t) = show t show (Str t) = show t Now, this compiles and works for some values of the type, but not for all! Here is what happens in hugs: hugsprompt> (Atom 1) ==> 1 hugsprompt> (LispList [Atom 1, Str "HEJ"]) ==> [1,"HEJ"] hugsprompt> (LispList [Atom 1, LispList [Str "HEJ"]]) ==> [1, ["HEJ"]] hugsprompt> (Str "HEJ") ==> "Cannot find show function...." hugsprompt> (LispList [Str "HEJ"]) ==> "Cannot find show function...." hugsprompt> (LispList [Str "HEJ",Atom 1]) ==> "Cannot find show function...." So there is a problem when the value is of form Str string or where such a value is first in the list l in a value of the form LispList l. Oddly enough, such values may appear at other positions without causing any problems. I don't think there is a bug in hugs. Similar problems appear if the Show instance is derived, and ghc will also complain - if the definition f = show (LispList [Str "HEJ"]) is compiled, for instance, the compiler will complain about ambiguous contexts. Ghc will say Enrico.hs:1: Ambiguous context `{Show taKi}' `Show taKi' arising from use of `show' at Enrico.hs:17 and hugs Reading file "Enrico.hs": Type checking ERROR "Enrico.hs" (line 17): Unresolved top-level overloading *** Binding : f *** Outstanding context : Show b So I wonder whether the infamous Monomorphism Restriction is lurking somewhere here? But I cannot see exactly how right now. Does anyone else have a clue? Björn

2 1

RE: GHC doesn't compile Happy example
by Simon Marlow 02 Oct '01

02 Oct '01

Carlos Scheidegger writes: > First, the Happy example uses some functions that exist in > Hugs but not in GHC, like isAlpha, isDigit and isSpace (I think so, > at least, because i type ':t isAlpha' in GHCi and get > 'variable not in > scope'), so I created a module called CharClasses with these > functions. This is a long-standing known bug in Hugs. These functions are available from the Char module. > So, I ran happy and generated calc.hs without any problems. > > When I try to compile calc.hs, by doing > > ghc -o calc.exe calc.hs CharClasses.hs > > I get: > > c:/ghc/ghc- > 5.02/libHSstd.a(PrelMain__1.o)(.text+0x16)://c/tmp/ghc1756.hc: > undefined reference to `__stginit_Main' > c:/ghc/ghc- > 5.02/libHSstd.a(PrelMain__2.o)(.text+0x4)://c/tmp/ghc1756.hc: > undefined reference to `Main_main_closure' > c:/ghc/ghc- > 5.02/libHSstd.a(PrelMain__2.o)(.text+0x33)://c/tmp/ghc1756.hc: > undefined reference to `Main_main_closure' It looks like perhaps the calc.hs module isn't declared as module Main. > Another strange behavior is that I can only call the main function > once. Any other call I get: > > Happy> main > *** Exception: illegal operation > Action: hGetContents > Handle: {loc=<stdin>,type=semi-closed,binary=False,buffering=line} > Reason: handle is closed > File: <stdin> This is the defined behaviour of getContents: it puts the stdin Handle in a state known as "semi-closed", wherein any further I/O operations on it are forbidden. Because I/O state is retained between computations, the semi-closed state persists until the next :load or :reload command. You can make these handles reset themselves after every evaluation by giving GHCi the command ':set +r'. This works because stdin, stdout and stderr are just top-level expressions that can be reverted to their unevaluated state in the same way as any other top-level expression (CAF). Cheers, Simon

1 0

Haskell tutorial
by Simon Marlow 02 Oct '01

02 Oct '01

Just spotted this Haskell tutorial at IBM developerWorks (free registration required): http://www-105.ibm.com/developerworks/education.nsf/linux-onlinecourse-b ytitle/9A31A3C4A0CE683E86256AD400822942?open&t=grl,l=805,t=haskell (hope that URL doesn't get mangled by Exchange...). Looks like it's aimed at non-functional-programmers. Cheers, Simon

1 0

WICS'2002: Extended Deadline
by Dr. Muhammad Sarfraz 02 Oct '01

02 Oct '01

Apologies if you receive multiple copies **************************************************************************** * Due to a number of requests and some other reasons, the Deadline is extended. **************************************************************************** * WICS'2002 The Fourth Workshop on Information & Computer Science March 17-18, 2002 King Fahd University of Petroleum & Minerals, Dhahran, Saudi Arabia Information & Computer Science Department (KFUPM) in collaboration with IEEE Computer Society Saudi Arabia Chapter Theme: Internet Computing Best papers will be published in A Special Issue Of Information Sciences Journal Important Dates: November 05, 2001 Papers due (about 15 pages). December 20, 2001 Notification of acceptance. January 20, 2002 Camera-ready papers. March 17 - 18, 2002 Workshop. For detailed information, please visit: http://www.ccse.kfupm.edu.sa/wics/ Contact Address : Chairman, Organizing Committee, WICS'2002 Department of Information & Computer Science KFUPM # 5066 King Fahd University of Petroleum and Minerals Dhahran 31261, Saudi Arabia Tel.: +966-3-860-2175 Fax: +966-3-860-2174 Email: wics(a)ccse.kfupm.edu.sa WWW: www.ccse.kfupm.edu.sa/wics/

1 0

WinHugs crashes reversing infinite lists
by carlos.scheidegger＠via-rs.net 01 Oct '01

01 Oct '01

Hello all. I think I found a bug on Hugs for Windows 32 (both on the GUI version and the console). If you try to reverse an infinite list, for example: reverse (repeat 0) reverse [1..] This will make Hugs segfault. Of course, reversing an infinite list is not something you should do, but so isn't segfaulting :) GHC for W2K just freezes (as would be expected). Hope I helped, Carlos

1 0

GHC doesn't compile Happy example
by carlos.scheidegger＠via-rs.net 01 Oct '01

01 Oct '01

Hello all. I'm trying to use GHC to compile the example parser in Happy, but with no success. I'm using GHC 5.02 for W2K, and I'm not quite sure what to do to make it work. I successfully compiled some small test cases, to see if I had installation problems, and they compiled just fine. First, the Happy example uses some functions that exist in Hugs but not in GHC, like isAlpha, isDigit and isSpace (I think so, at least, because i type ':t isAlpha' in GHCi and get 'variable not in scope'), so I created a module called CharClasses with these functions. So, I ran happy and generated calc.hs without any problems. When I try to compile calc.hs, by doing ghc -o calc.exe calc.hs CharClasses.hs I get: c:/ghc/ghc- 5.02/libHSstd.a(PrelMain__1.o)(.text+0x16)://c/tmp/ghc1756.hc: undefined reference to `__stginit_Main' c:/ghc/ghc- 5.02/libHSstd.a(PrelMain__2.o)(.text+0x4)://c/tmp/ghc1756.hc: undefined reference to `Main_main_closure' c:/ghc/ghc- 5.02/libHSstd.a(PrelMain__2.o)(.text+0x33)://c/tmp/ghc1756.hc: undefined reference to `Main_main_closure' I tried to compile each .o file separately, but I got the exact same errors. I don't know much about the structure of ghc and the interactions with gcc, but this does look like a linker error, and I'm guessing it's trying to tell me that I don't have a main function. But I do have one, as I checked the calc.hs and the main = getContents >> print . calc . lexer is there. GHCi seems to load the module just fine, and the parser and lexer seem to be working correctly. One strange thing that happens is that if I run an example from the interactive mode, it works, but if I call the main function, I get *** Exception: calc.hs:285: Non-exhaustive patterns in function lexer Another strange behavior is that I can only call the main function once. Any other call I get: Happy> main *** Exception: illegal operation Action: hGetContents Handle: {loc=<stdin>,type=semi-closed,binary=False,buffering=line} Reason: handle is closed File: <stdin> If I reload all modules with ':s' I can run it again, but also only once. I really don't know what I'm doing wrong. Can anyone help me? Thank you in advance, Carlos

1 0

RE: GHC 5.02 is released
by Julian Seward (Intl Vendor) 01 Oct '01

01 Oct '01

Yes. There is now a ... -src-2.tar.bz2 file there; unfortunately I forgot to remove the message when I put it there. Download and compile away. J | -----Original Message----- | From: Frank Seaton Taylor [mailto:fstaylo@alpha.ncsc.mil] | Sent: Friday, September 28, 2001 8:36 PM | To: haskell(a)haskell.org | Subject: Re: GHC 5.02 is released | | | Has the problem with | | http://haskell.cs.yale.edu/ghc/dist/5.02/ghc-5.02-src-1.tar.bz2 | | described as | | Note: as posted on Friday 21 Sept, has a known minor | build-system bug. | It will | build a perfectly correct in-place compiler, but is not | quite suitable | for | building binaries for widespread distribution (package | builders please | note). | We will endeavour to post here a fixed version of the source on | Monday, once | we've had a chance to test the fix." | | been fixed yet? | | Just wondering before I download it... | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0