- Haskell - Haskell.org

RE: Strange error in show for datatype
by Jan-Willem Maessen 04 Oct '01

04 Oct '01

"Simon Peyton-Jones" <simonpj(a)microsoft.com> tries his hand at inventing free theorems for qualified types, then concludes: > In which case we could report ambiguity a bit less often. How > useful this would be I don't know. A lot. Any time one is testing the empty case of a bulk type. If you're coding data structures work (and most first and second year CS classes will) that happens all the time. It comes up in situations as simple as making sure your functions return [] when you expect them to. So a clever solution to this problem would make hugs, ghci, etc. far more usable. It would also allow the monomorphism restriction to be relaxed at absolutely no cost in certain cases. Earlier, Simon says: > 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. Strictness alas matters. Here's the witness: class Num a => ZeroList a where consZero :: a -> [a] consZero _ = 0:xs instance ZeroList Int instance ZeroList Double Now: (consZero (error "no type")) :: (ConsNum a) => [a] show (consZero (error "no type")) :: (ConsNum a) => String Do we get "[0]" or "[0.0]"? OK, we have a problem worth addressing, and a non-obvious (or absent) solution. I'd love to hear what our resident type theorists have to say. -Jan-Willem Maessen Eager Haskell Project

2 1

Empty Datatypes
by Ashley Yakeley 04 Oct '01

04 Oct '01

At 2001-10-04 00:36, Simon Peyton-Jones wrote: >It's also useful to be able to introduce >such empty types for phantom-type purposes, so GHC now lets you say > > data T > >and get a type T with no values. Yay! One more thing to cross off my [GHC] Haskell wish-list. Is this working in 5.02? It isn't in 5.00.2. -- Ashley Yakeley, Seattle WA

1 0

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

04 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 02 Oct '01

02 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