[ ghc-Bugs-782761 ] Wrong line count in parsec under linux on dos-style files
Bugs item #782761, was opened at 2003-08-04 11:32 Message generated for change (Settings changed) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=782761group_id=8032 Category: hslibs/text Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong line count in parsec under linux on dos-style files Initial Comment: Parsec doubles the line count (reported e.g. in a parse error) when run (at least on a linux box) on DOS-style files (with DOS-style newlines) I have GHC 6.0 My e-mail address is [EMAIL PROTECTED] Bye Vincenzo Ciancia -- Comment By: Simon Peyton Jones (simonpj) Date: 2003-10-06 12:41 Message: Logged In: YES user_id=50165 Daan fixed this. daan2003/09/26 06:42:03 PDT Modified files: libraries/parsec/Text/ParserCombinators/Parsec Pos.hs Log: Fixed line count bug. That is: unix and dos files are correctly handled by unix, and dos. Old mac files are still not correctly handled on unix and dos but we feel that this is less of a problem now with macosx. see bug: http://sourceforge.net/tracker/index.php? func=detailaid=782761group_id=8032atid=108032 Revision ChangesPath 1.2 +0 -1 fptools/libraries/parsec/Text/ParserCombinators/Parsec/Pos.hs -- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-04 18:16 Message: Logged In: NO As a temporary fix, you may comment out the following line in the ParsecPos.hs file. This fix will make correct line numbers being displayed on Unix OS's as well as Microsoft's irrespective of where the text input files are created (this fix will probably result in a bug on Mac's), Comment out the line '\r' - SourcePos name (line+1) 1 in updatePosChar function in ParsecPos.hs Keep a local copy of parsec, and pick up parsec from here, instead of from GHC's text package. A.P. Rao. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=782761group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-814015 ] Old setup procedure for Windows
Bugs item #814015, was opened at 2003-09-28 15:14 Message generated for change (Settings changed) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=814015group_id=8032 Category: Documentation Group: 6.0.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Old setup procedure for Windows Initial Comment: The document user_guide.pdf in the GHC 6.01 for Windows package describes the install procedure for version 5.02, setup.exe instead of ghc-6-0-1.msi. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=814015group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-814864 ] bug ghc --make
Bugs item #814864, was opened at 2003-09-30 02:40 Message generated for change (Settings changed) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=814864group_id=8032 Category: Compiler Group: 6.0 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: bug ghc --make Initial Comment: Using ghc-6.0 with ghc --make mimico.hs gives: ghc: panic! (the 'impossible' happened, GHC 6.0): coreSyn/coreUtils.lhs: 1188: Non-exaustive patterns in function isCrossDllArg I've done some work to help you finding the cause of the bug, by leaving only 4 (stripped down) files (see attachment). A single line --- the definition of function getInput, in ParsecPrim.hs --- is indicated that, if modified (by writing, say, getInput=undefined) causes ghc --make mimco.hs not to 'panic'. (The bug turned out to appear in Parsec files; seems Daan Leijen didn't use ghc --make :-). Hope that helps... Tchau, Carlos -- Comment By: Simon Peyton Jones (simonpj) Date: 2003-10-06 13:08 Message: Logged In: YES user_id=50165 I believe this bug is fixed in 6.0.1 Simon -- Comment By: Nobody/Anonymous (nobody) Date: 2003-10-01 03:23 Message: Logged In: NO Oops, it has nothing to do with --make: ghc -c ParsecPrim.hs causes the same crash... Silly guessing by myself. Tchau, Carlos -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=814864group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-768658 ] bad warning for parallel list comprehension
Bugs item #768658, was opened at 2003-07-09 18:47 Message generated for change (Settings changed) made by simonpj You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=768658group_id=8032 Category: Compiler Group: 6.0 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: bad warning for parallel list comprehension Initial Comment: this piece of code: module ParComp where t :: [(Char,Char)] t = [ (a,b) | a - foo | b - bar ] will generate this warning: ParComp.hs:4: Warning: Defined but not used: b ParComp.hs:4: Warning: Defined but not used: a This is on Linux ghc version 6.0 Brett Letner [EMAIL PROTECTED] -- Comment By: Simon Peyton Jones (simonpj) Date: 2003-10-06 13:15 Message: Logged In: YES user_id=50165 Fixed, thanks to Sigbjorn. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=768658group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Reading Floats
It's a definite bug. It'll be fixed in 6.02. Thanks for reporting it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] | Sent: 03 October 2003 10:08 | To: [EMAIL PROTECTED] | Subject: Reading Floats | | | Hi, | | I recently encountered something I found a bit peculiar when reading | floats from strings. Leading zeroes seem okay, as long as there is no | decimal point. To wit: | | Main (map read [1.0, 0, 01, 01.0]) :: [Float] | [1.0,0.0,1.0,*** Exception: Prelude.read: no parse | | Neither is leading decimal point allowed: | | Main (read .01) :: Float | *** Exception: Prelude.read: no parse | | Is this how it's supposed to be? | | -kzm | -- | If I haven't seen further, it is by standing in the footprints of giants | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Imported instance declarations
This bad error message is improved in subsequent versions of GHC. 6.0.1 says In.hs:5: Duplicate instance declarations: In.hs:5: Functor ((-) i) In module Control.Monad.Reader: Functor ((-) r) Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frieder Kalisch | Sent: 01 October 2003 15:12 | To: [EMAIL PROTECTED] | Subject: Imported instance declarations | | Hello, | | While trying to learn Hakell I came across a weird (to me) error message | concerning imported instance declarations. | | This module | | module XXX() where | | import Control.Monad.Error() | | instance Functor ((-)i) where | fmap = (.) | | gives this error message (compiling with ghc 5.0.4.2): | | Duplicate instance declarations: | XXX.hs:5: Functor ((-) i) | No locn: Functor ((-) r) | | For me this error message is somewhat puzzling: Where is the second | instance declaration given? In this case it happens to be in | Control.Monad.Reader, but how can I find out without looking for it | in the CVS repository? The documentation for Control.Monad.Error does | not mention the imported modules. | | I suppose, that the compiler knows in which module the instance | declaration was given, because it needs to tell duplicate import paths | from duplicate instance declarations. Why is it not given in this example? | | Greetings | | Frieder Kalisch | | | -- | Frieder Kalisch | [EMAIL PROTECTED] | +49-6221-549-432 | | ___ | Haskell mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: IO behaves oddly if used nested
[snip] Neither example is odd behavior, unless you consider Hugs providing a perfectly reasonable instance of Show for IO a odd. True, every program behaves exactly as according to the definition of the run-time behavior of Haskell programs. (Hugs deviates a bit from ghc but ah well) The odd is not in the run-time behavior. The odd is in the conceptual explanation. If I give a description of some f x = y function in Haskell I expect that some program f x is reduced to y and the result is given back (possibly printed). A good story to sell to students. This is almost everywhere the case except for the IO monad. In the former example, the inner putStr is _not_ evaluated but a message is shown (hinting that a IO has some structure we can observe before evaluation). In the latter example, it is shown that we are not interested in a result of a IO program, but only in its (lazily generated) side-effects. The monad behaves oddly with respect to the f x = y behavior. I think I observe the following reactions when I explain IO: 1* Can't the guy in front of me stop poking his nose? (the blank faces and parse errors) 2* Hmm, feels like Java, looks like Java, ahah! is Java! (coders) 3* Hmm, feels like math, looks like math, ahah! is math! (designers and thinkers) Group 1 will mimic, group 2 will produce obfuscuated Java code in Haskell, group 3 has great difficulty with the IO monad (although they are the first group who will write OK haskell programs) because it behaves differently from what they expect. The usual questions of group 3: * Why is an IO a evaluated if I am not interested in it's result? (opposite to the f x = y lazy behavior) * Why is in the putStr hello world example Hello World not shown? (opposite to expected f x = y eval-first-then-show behavior) * Why is in the IO (IO ()) example the inner IO () not evaluated? (somewhat opposite to expected f (f x) behavior - I personally wonder if it is even sound in a category theoretical setting) * ...Lots of other questions... Hmm, have to finish this email now - time constraints. I guess the short story just is: IO monads == sometimes bad conceptual story to sell. Especially so since the best group has the biggest problems and non-trivial examples are only explainable in the end in terms of run-time behavior. What was that remark again about pointy headed people and Haskell? ;-) For that I also gave the Nomad datatype as a possible solution (needs a pretty hefty type checker though). A nice (old) idea would be to represent IO as programs which are interpreted by some _outside_ RTS in a given manner, and leave the Haskell language clean. (It might even be a good idea with respect to the compiler implementation since it removes checking against unsafe IO behavior from the compiler -- just a thought) Bye now, and cheers, l4t3r _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
how is Haskell pronounced?
The subject says it all. I've been using haskell for over a year, but I have no idea how to pronounce it. I tend to oscillate between rhyming with fell and rhyming with full. In the former case the accent goes on the second syllable as in Pascal, while in the latter case it goes on the first, as in rascal or tattle. I feel silly telling people what a great language it is, when I can't even pronounce its name... :) -- David Roundy http://www.abridgegame.org/darcs ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: how is Haskell pronounced?
The subject says it all. I've been using haskell for over a year, but I have no idea how to pronounce it. I tend to oscillate between rhyming with fell and rhyming with full. In the former case the accent goes on the second syllable as in Pascal, while in the latter case it goes on the first, as in rascal or tattle. I feel silly telling people what a great language it is, when I can't even pronounce its name... :) For me it rhymes with tattle - technically, the second vowel is a schwa. Stress is on the first syllable. --KW 8-) -- Keith Wansbrough [EMAIL PROTECTED] http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Read and Write to Same File
On Sun, Oct 05, 2003 at 11:37:16AM +0200, Tomasz Zielonka wrote: On Sun, Oct 05, 2003 at 04:25:41AM -, [EMAIL PROTECTED] wrote: 2. main = do text - readFile test let something = somefunc text writeFile test $! something Are both of these correct (guaranteed to give the behavior I want)? Which is better (and why)? depends on your somefunc try: somefunc = show . f . read where f :: (Show a, Read a, Num a) = [a] - (a,a) f ls = (sum (take 3 ls), mul (take 3 ls)) mul :: (Num a) = [a] - a mul = foldr (*) 1 - if somefunc read all the needed data before returning the result, then the program will either work correctly or give an exception. I think throwing an exception here is wrong. so: --- somefunc = (show . f . read) where f :: (Show a, Read a, Num a) = [a] - (a,a) f ls = seq (ls!!2) (sum (take 3 ls), mul (take 3 ls)) --- must be OK. There is no guarantee that $! will force evaluation of the entire 'something', so you can start writing to file before you finished reading from it. Hopefully it will cause an exception (like in GHC), otherwise you could damage your data (like in Hugs). If test is not a regular file (say, /dev/modem), then it is 100% legal program. So throwing any exception here is not correct (I believe it is done by ghc runtime, since there is nothing exceptional in opening a file for writing already opened for reading, at least in Unix). Anyway such a defence will not work with concurrently running programs. -- Max ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
