bug (?) - unboxed tuples
Hello, I recently read the following: [EMAIL PROTECTED]:~/Documents/pi3/diverses/Mascheroni ghci Exponent.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Skipping TheLog ( ./TheLog.hs, ./TheLog.o ) Compiling Exponent ( Exponent.hs, interpreted ) ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): Bytecode generator can't handle unboxed tuples. Possibly due to foreign import/export decls in source. Workaround: compile this module to a .o file, then restart session. The complete code of both modules is attached, as well as system information (I know not much about such things, so I can only hope that is helpful for you). Compiling Exponent to a .o file did work, so there is no real problem. However, ghci said 'Please report it as a compiler bug', so I am doing it. Besides, there are no tuples at all in module Exponent, module TheLog, where there are a couple of tuples (are they unboxed though?) was compiled earlier, so I don't understand the message. If you could spare the time to explain (or give a source for an explanation), I would be even more grateful than I am anyway (such a wonderful thing as ghc FOR FREE!!). All the best to you, Daniel Fischer [EMAIL PROTECTED]:~/Documents/pi3/diverses/Mascheroni ghci Exponent.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Skipping TheLog ( ./TheLog.hs, ./TheLog.o ) Compiling Exponent ( Exponent.hs, interpreted ) ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): Bytecode generator can't handle unboxed tuples. Possibly due to foreign import/export decls in source. Workaround: compile this module to a .o file, then restart session. Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org, or http://sourceforge.net/projects/ghc/. -- module Exponent where import TheLog (theLog) expoN :: Int - Rational - Rational expoN k x = expoNHelp k x 0 expoNHelp :: Int - Rational - Rational - Rational expoNHelp k x val | k = 0 = 1 + val | otherwise = expoNHelp (k-1) x nval where nval = x*(1+val)/(fromIntegral k) exSteps :: Rational - Rational - Int exSteps x eps | eps = 0 = error exSteps: eps = 0 | otherwise = exStepHelp x eps 1 0 exStepHelp :: Rational - Rational - Rational - Int - Int exStepHelp x eps yet k | now*m (m-x)*eps = k | otherwise = exStepHelp x eps now (k+1) where m = fromIntegral k + 1 now = yet*x/m expoEps :: Rational - Rational - Rational expoEps x eps = expoN k x where k = exSteps (abs x) eps expoStell :: Int - Rational - Rational expoStell n x = expoEps x (4/10^(n+1)) checkExLog :: Int - Rational - Bool checkExLog k x = abs (expoStell k (theLog k x) - x) 1/10^k checkLogEx :: Int - Rational - Bool checkLogEx k x = abs (theLog k (expoStell k x) - x) 1/10^k --- module TheLog where import Data.Ratio theSteps :: Rational - Rational - Int theSteps x eps | eps = 0 = error theSteps: eps = 0 | x0 = error theSteps: x 0 | x = 1 = error theSteps: x = 1 | otherwise = stepsHelp x ((1-x)*eps) 1 1 stepsHelp :: Rational - Rational - Int - Rational - Int stepsHelp x eps n val | val (fromIntegral (2*n-1))*eps = n | otherwise = stepsHelp x eps (n+1) (val*x) theSum :: Rational - Int - Rational theSum x k = sum [x^i/(fromIntegral i * 2 + 1) | i - [0 .. k]] logSum :: Rational - Rational - Rational logSum s eps = theSum x k where x = s^2 k = theSteps x eps applog :: Rational - Rational - Rational applog s eps = logSum s eps * 2* s smallLog :: Int - Rational - Rational smallLog n x = applog ((x-1)/(1+x)) (1/10^(n+1)) splitTen :: Rational - (Rational, Rational) splitTen x | x^2 10 = (s, k+1) | x^2 1%10 = (t, l-1) | otherwise = (x, 0) where (s, k) = splitTen (x/10) (t, l) = splitTen (10*x) log10 :: Int - Rational log10 k = log2 (k+1) * 3 + (smallLog (k+1) (5%4)) log2 :: Int - Rational log2 k = smallLog (k+1) (5%4) * 3 + (smallLog (k+1) (128%125)) fineLog :: Int - Rational - Rational fineLog k x | x = 0 = error fineLog: x = 0 | k 2 = error fineLog: k
RE: bug (?) - unboxed tuples
On 14 January 2005 20:57, Daniel Fischer wrote: Hello, I recently read the following: [EMAIL PROTECTED]:~/Documents/pi3/diverses/Mascheroni ghci Exponent.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Skipping TheLog ( ./TheLog.hs, ./TheLog.o ) Compiling Exponent ( Exponent.hs, interpreted ) ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): Bytecode generator can't handle unboxed tuples. Possibly due to foreign import/export decls in source. Workaround: compile this module to a .o file, then restart session. The complete code of both modules is attached, as well as system information (I know not much about such things, so I can only hope that is helpful for you). Compiling Exponent to a .o file did work, so there is no real problem. However, ghci said 'Please report it as a compiler bug', so I am doing it. Besides, there are no tuples at all in module Exponent, module TheLog, where there are a couple of tuples (are they unboxed though?) was compiled earlier, so I don't understand the message. If you could spare the time to explain (or give a source for an explanation), I would be even more grateful than I am anyway (such a wonderful thing as ghc FOR FREE!!). Could you send us the source? Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1065291 ] Bad error message for missing module in --make
Bugs item #1065291, was opened at 2004-11-12 16:37 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1065291group_id=8032 Category: Compiler Group: 6.2.2 Status: Open Resolution: None Priority: 3 Submitted By: Simon Peyton Jones (simonpj) Assigned to: Simon Marlow (simonmar) Summary: Bad error message for missing module in --make Initial Comment: GHC --make uses getImports to find the imports of a module. It has two bad flaws a) it's a total hack, parsing the file character by character, which is really slow. We though it stopped after the import statements but it doesn't; it chunters through the entire file b) It does not record line numbers, so if the imported module does not exist, there is no decent error message We have a plan; this bug report makes sure we don't forget. -- Comment By: Simon Marlow (simonmar) Date: 2005-01-17 15:12 Message: Logged In: YES user_id=48280 Partially fixed, (b) still to do. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1065291group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1064881 ] internal error: stg_ap_pp_ret
Bugs item #1064881, was opened at 2004-11-12 00:25 Message generated for change (Settings changed) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1064881group_id=8032 Category: Runtime System Group: 6.2.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: internal error: stg_ap_pp_ret Initial Comment: From: Tom Pledger [EMAIL PROTECTED] The RTS asked me to log this. -- xterm excerpt -- [EMAIL PROTECTED] Clean]$ GHCRTS='-M64M -hc' sh go.sh + Cleaner -- refpath /home/datamine/Cleaner/data/1000:/home/datam ine/Cleaner/data:data --fields reference:street:street:street:suburb:city,region:postco de --noheader --infile data/100-input.txt --one -- markup data/100-markup.txt --nzpost data/100- nzpost.txt Fri Nov 12 13:09:46 NZDT 2004 Cleaner: internal error: stg_ap_pp_ret Please report this as a bug to glasgow-haskell- [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ + exit 254 -- end of excerpt -- Without the -hc , I get a segmentation fault instead. Without the -M64M , the program completes successfully. -- Comment By: Simon Marlow (simonmar) Date: 2005-01-17 15:13 Message: Logged In: YES user_id=48280 No response from submitter, and we have strong evidence to suggest this bug has already been fixed (lots of people are using darcs...) -- Comment By: Simon Marlow (simonmar) Date: 2004-12-13 10:47 Message: Logged In: YES user_id=48280 I believe this bug was fixed in GHC 6.2.2. Could you please retry your test with that version? -- Comment By: Nobody/Anonymous (nobody) Date: 2004-12-10 19:29 Message: Logged In: NO I received a similar message runing darcs compiled with GHC under Cygwin on Windows 2k. [EMAIL PROTECTED] /cygdrive/c/projects/voyager/crypto_poc $ darcs +RTS -K10M -M512M -RTS whatsnew -ls darcs.exe: internal error: stg_ap_v_ret Please report this as a bug to glasgow-haskell-bugs@haskell.org, or http://www.sourceforge.net/projects/ghc/ Without the -K -M options the program dies with a Windows Application Error: The instruction at 0x0060edb2 referenced memory at 0x1118e000. The memory could not be read. Thanks for all your work on this great project! Matt Van Gundy matthew ~dot~ vangundy ~at~ yardi ~dot~ com -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1064881group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1096068 ] Problems with binary linux distribution
Bugs item #1096068, was opened at 2005-01-04 22:05 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1096068group_id=8032 Category: Documentation Group: 6.2.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with binary linux distribution Initial Comment: Problems with documentation when installing from binary linux distribution of GHC 6.2.2, for glibc 2.2: ghc-6.2.2-i386-linux-glibc2.2.tar.bz2 Missing directories: ghc-6.2.2/share/ps/ ghc-6.2.2/share/html/users_guide/ ghc-6.2.2/share/html/hslibs/ ./configure worked fine. Make install worked for some time but bailed out when attempting to copy .ps files from ghc-6.2.2/share/ps/. The installed GHC seems to work, though (at least some simple tests with ghci). But I suppose some documentation is not in place. I suggest you recreate the tar file as to include the full distribution. Björn Lisper [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2005-01-17 16:15 Message: Logged In: YES user_id=48280 Fixed, thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1096068group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: recursive group context bug?
You cannot sequence two operations from different monads...
p has type: m (IO ())
id has type, IO () (in this case because this is what p returns)...
You can do:
p :: (Monad m) = m (IO ())
p = q = (\a - return a)
Or
p :: (Monad m) = m (IO ())
p = run q = id -- provided an overloaded definition of run is
provided for 'm'
Keean.
Ashley Yakeley wrote:
I suspect someone's come across this before, so maybe there's an
explanation for it.
This does not compile:
module Bug where
{
p :: IO ();
p = q = id;
q :: (Monad m) = m (IO ());
q = return p;
}
Bug.hs:3:
Mismatched contexts
When matching the contexts of the signatures for
p :: IO ()
q :: forall m. (Monad m) = m (IO ())
The signature contexts in a mutually recursive group should all be
identical
When generalising the type(s) for p, q
The code looks correct to me. Why must the signature contexts be
identical in this case?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recursive group context bug?
Got the wrong type sig there... p :: IO () p = run q = id Keean. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recursive group context bug?
On Mon, Jan 17, 2005 at 09:52:18AM +, Keean Schupke wrote:
You cannot sequence two operations from different monads...
Note that this compiles:
module Bug where
{
p :: IO ();
p = q = id;
q :: (Monad m) = m (IO ());
q = return (return ()); -- the only change is in this line
}
Best regards,
Tomasz
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Unicode in GHC: need more advice
On 14 January 2005 12:58, Dimitry Golubovsky wrote: Now I need more advice on which flavor of Unicode support to implement. In Haskell-cafe, there were 3 flavors summarized: I am reposting the table here (its latest version). |Sebastien's| Marcin's | Hugs ---+---+--+-- alnum | L* N* | L* N*| L*, M*, N* 1 alpha | L*| L* | L* 1 cntrl | Cc| Cc Zl Zp | Cc digit | N*| Nd | '0'..'9' lower | Ll| Ll | Ll 1 punct | P*| P* | P* upper | Lu| Lt Lu| Lu Lt 1 blank | Z* \t\n\r | Z*(except| ' ' \t\n\r\f\v U+00A0 U+00A0 U+2007 U+202F) \t\n\v\f\r U+0085 1: for characters outside Latin1 range. For Latin1 characters (0 to 255), there is a lookup table defined as unsigned char charTable[NUM_LAT1_CHARS]; I did not post the contents of the table Hugs uses for the Latin1 part. However, with that table completely removed, Hugs did not work properly. So its contents somehow differs from what Unicode defines for that character range. If needed, I may decode that table and post its mapping of character categories (keeping in mind that those are Haskell-recognized character categories, not Unicode) I don't know enough to comment on which of the above flavours is best. However, I'd prefer not to use a separate table for Latin-1 characters if possible. We should probably stick to the Report definitions for isDigit and isSpace, but we could add a separate isUniDigit/isUniSpace for the full Unicode classes. One more question that I had when experimenting with Hugs: if a character (like those extra blank chars) is forced into some category for the purposes of Haskell language compilation (per the Report), does this mean that any other Haskell application should recognize Haskell-defined category of that character rather than Unicode-defined? For Hugs, there were no choice but say Yes, because both compiler and interpreter used the same code to decide on character category. In GHC this may be different. To be specific: the Report requires that the Haskell lexical class of space characters includes Unicode spaces, but that the implementation of isSpace only recognises Latin-1 spaces. That means we need two separate classes of space characters (or just use the report definition of isSpace). GHC's parser doesn't currently use the Data.Char character class predicates, but at some point we will want to parse Unicode so we'll need appropriate class predicates then. Since Hugs got there first, does it make sense just follow what was done here, or will a different decision be adopted for GHC: say, for the Parser, extra characters are forced to be blank, but for the rest of the programs compiled by GHC, Unicode definitions are adhered to. Does what I said above help answer this question? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: How expensive are MVars ?
On 13 January 2005 23:36, Nick Main wrote: I'm planning to implement a small OO language on top of GHC (think JavaScript) and need to decide on how to implement the mutable object graph that is required. The two approaches I'm considering are: - something on top of Data.Graph - using MVars as the object references. The MVar approach is the most appealing, since it would also allow the OO language to contain threads. How expensive is an MVar access (in GHC), compared to the graph navigation that would be required to resolve a reference using Data.Graph ? I know this is a fairly nebulous question, but any comments or suggestions are appreciated. So here's a nebulous answer: I don't know, measure it :-) Each MVar operation involves a function call right now, so you might class it as expensive. Personally for your application, I think I'd use a mutable array to represent the heap. That amounts to almost the same as using Data.Graph, but I imagine you'll need the mutability for speed. Perhaps providing a mutable Graph data structure implemented using an array would be a nice abstraction. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recursive group context bug?
I suspect its becuse q needs to get the dictionary for 'm' from somewhere... as it is recursive, p calls q calls p, so p must have the dictionary for 'm' in its context... So this works: module Main where p :: Monad m = m () p = q = id q :: Monad m = m (m ()) q = return p Keean. Tomasz Zielonka wrote: On Mon, Jan 17, 2005 at 09:52:18AM +, Keean Schupke wrote: You cannot sequence two operations from different monads... Note that this compiles: module Bug where p :: IO (); p = q = id; q :: (Monad m) = m (IO ()); q = return (return ()); -- the only change is in this line } Best regards, Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recursive group context bug?
This must be a bug then, because the following works! y :: Num a = a y = fromIntegral (y::Int) A simpler example might be: x :: Int x = y y :: Num a = a y = fromIntegral x I have not studied the report to see if this should be legal. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Timing Functions
I'm putting together a script togather run-time statsfor some functions I'm working with, and I'm having a terrible time. My strategy is to evaluate a function a number of times and compute the difference between the elapsed CPU time before and after the repeated calls. timeNReps :: (a - b) - a - Int - FilePath - IO () timeNReps func arg reps fileName = do t0 - System.CPUTime.getCPUTime runNReps func arg reps t1 - System.CPUTime.getCPUTime appendFile fileName ((showMS (t1 - t0)) ++ "\n") where showMS n = show (n `quot` 10)showMS just converts the pico-second result into milli-seconds and stringifies it.runNReps isan IO program (do sequence) that is intended to call the function and tail-call itself a given number of times: runNReps :: (Int - a) - Int - Int - IO () runNReps fx todo | todo 0 = do let junk = (f x)runNReps f x (todo - 1)| otherwise = return (())Apparently runNReps doesn't apply f to x at all! I've called my test function with a suitable argument from top level (within ghci) and it takes ~20 sec. wall time to return; when I evaluate "runNReps test arg 1" it returns immediately. When I use this within my timing script I get timing output that indicates that calls for all args between 1 and 50 take about the same (very small) amount of time, but I know, both from theory and experiments in Scheme versions, thatmy test function's complexity is exponential in its arg. I'm using GHC 6.0.1 under Mandrake 9.1 on a 1.8 GHz Pentium box with 256MB RAM. Any idea where I'm going wrong? -- Bill Wood [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Timing Functions
On Mon, 17 Jan 2005 10:48:18 -0600, jekwtw [EMAIL PROTECTED] wrote: I'm putting together a script to gather run-time stats for some functions I'm working with, and I'm having a terrible time. My strategy is to evaluate a function a number of times and compute the difference between the elapsed CPU time before and after the repeated calls. timeNReps :: (a - b) - a - Int - FilePath - IO () timeNReps func arg reps fileName = do t0 - System.CPUTime.getCPUTime runNReps func arg reps t1 - System.CPUTime.getCPUTime appendFile fileName ((showMS (t1 - t0)) ++ \n) where showMS n = show (n `quot` 10) showMS just converts the pico-second result into milli-seconds and stringifies it. runNReps is an IO program (do sequence) that is intended to call the function and tail-call itself a given number of times: runNReps :: (Int - a) - Int - Int - IO () runNReps f x todo | todo 0 = do let junk = (f x) runNReps f x (todo - 1) | otherwise = return (()) Haskell is a non-strict language which means that 'junk' wont be evaluated since it's not necessary for the function to terminate. Check 'replicateM_' from Control.Monad. runNReps :: Int - IO a - IO () runNReps = replicateM_ -- Friendly, Lemmih ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Timing Functions
Hi Bill, You know, Haskell is so smart that it realised that you want to measure it and therefore it performs very good -- NO, I am just kidding! Welcome to lazy programming! The thing is, that you don't force the evaluation of the result of you function f. Therefore you program doesn't bother to do anything. The way around is not easy in any case. You have basically two choices: a) force the evaluation inside runNReps, b) or collect the results and force the evaluation in timeNReps. The forcing can be done via seq or maybe print or whatever seems appropriate. Please note that seq is just force Weak Head Normal Form, which means basically that just the top-most contructor is evaluated (to be not _|_). Btw: runNReps doesn't need to be in the IO Monad I came up with the following version: timeNReps :: (Show b) = (a - b) - a - Int - FilePath - IO () timeNReps func arg reps fileName = do t0 - getCPUTime let results = map (func) $ take reps $ repeat arg putStrLn $ Produced String of length ++ (show $ length $ show results) t1 - getCPUTime appendFile fileName ((showMS (t1 - t0)) ++ \n) where showMS n = show (n `quot` 10) I hope it helped. Cheers, Georg On Mon, 17 Jan 2005 10:48:18 -0600, jekwtw [EMAIL PROTECTED] wrote: I'm putting together a script to gather run-time stats for some functions I'm working with, and I'm having a terrible time. My strategy is to evaluate a function a number of times and compute the difference between the elapsed CPU time before and after the repeated calls. timeNReps :: (a - b) - a - Int - FilePath - IO () timeNReps func arg reps fileName = do t0 - System.CPUTime.getCPUTime runNReps func arg reps t1 - System.CPUTime.getCPUTime appendFile fileName ((showMS (t1 - t0)) ++ \n) where showMS n = show (n `quot` 10) showMS just converts the pico-second result into milli-seconds and stringifies it. runNReps is an IO program (do sequence) that is intended to call the function and tail-call itself a given number of times: runNReps :: (Int - a) - Int - Int - IO () runNReps f x todo | todo 0 = do let junk = (f x) runNReps f x (todo - 1) | otherwise = return (()) Apparently runNReps doesn't apply f to x at all! I've called my test function with a suitable argument from top level (within ghci) and it takes ~20 sec. wall time to return; when I evaluate runNReps test arg 1 it returns immediately. When I use this within my timing script I get timing output that indicates that calls for all args between 1 and 50 take about the same (very small) amount of time, but I know, both from theory and experiments in Scheme versions, that my test function's complexity is exponential in its arg. I'm using GHC 6.0.1 under Mandrake 9.1 on a 1.8 GHz Pentium box with 256MB RAM. Any idea where I'm going wrong? -- Bill Wood [EMAIL PROTECTED] -- Georg Martius, Tel: (+49 34297) 89434 --- http://www.flexman.homeip.net - ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Timing Functions
Many thanks to both Georg and Lemmih. Actually, I had considered laziness, but I didn't pursue it enough. I tried one version of runNReps in which I passed (f x) as an additional arg; when that didn't work, a little thought convinced me that laziness was doing me in. I also tried another approach, which was to use the function evaluation, but that didn't work either (note: I know (f x) can not be the empty list for values of x I'm interested in, but I don't think Haskell does, unless it's *really* smart :-) : runNReps :: (Int - [a]) - Int - Int - IO () runNReps f x todo | todo 0 = do let junk = (f x) if null junk then return (()) else runNReps f x (todo - 1) | otherwise = return (()) Ideas? Again, many thanks, -- Bill Wood [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Rebindable syntax for monads and arrows
On 07 jan 2005, at 17:53, Amr A Sabry wrote: Greetings all, This message is a sort of a poll to find out how much interest the community has in an implementation of rebindable syntax for monads and arrows. You can send your answers directly to me (sabry ... indiana edu) and I will summarize to the list if appropriate. An example using monads --- The type Vec below is almost a monad: - the operations vreturn and @= are almost of the right type (they have an additional constraint FinSet a =) - the operations vreturn and @= satisfy the monad laws class Eq a = FinSet a where enumerate :: [a] newtype Vec a = Vec (a - Float) unV (Vec f) = f vreturn :: FinSet a = a - Vec a vreturn a = Vec (\ b - if a==b then 1 else 0) (@=) :: FinSet a = Vec a - (a - Vec b) - Vec b (Vec va) @= f = Vec (\ b - sum [ (va a) * (unV (f a) b) | a - enumerate]) Because of the additional type constraint (FinSet a =) we cannot make the type Vec an instance of the class Monad, and hence we cannot use the do-notation to express our computations. --- -- Question I --- -- Do you have other examples, where you wished you could define instances of the class Monad with operations whose types are more constrained than required? Or more generally do you feel that allowing such a behavior is worthwhile? A resounding yes to that one. Both of them. The example I have is one of trying to put numerical values under the identity monad and then record expressions on those values within the monad itself. This was somewhat hampered by the impossibility of putting additional type constraints on instances of Monad. --- -- Question II --- -- Arguably the do-notation for monadic computations is nice but the overhead of writing using explicit combinators is not that bad. The situation for arrows is quite different: the syntactic sugar for arrows is almost essential and it often expands into something you _do_not_want_to_write_ So, do you have examples, where you wished you could define instances of the class Arrow with operations whose types are more constrained than required? Unfortunately not, but I must admit to not having played with Arrows. Might be a nicer idiom for what I'm doing though... Doei, Arthur. -- [EMAIL PROTECTED] | Work like you don't need the money A friend is someone with whom | Love like you have never been hurt you can dare to be yourself | Dance like there's nobody watching ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] New PhD Positions Department of Computing Science, Chalmers University
Please pass on to interested students. Apologies for multiple copies. - New PhD Positions (DEADLINE 15 February 2005! See How to apply below) Department of Computing Science, Chalmers University of Technology Göteborg University Gothenburg, Sweden http://www.cs.chalmers.se/Cs/ The Department has about 80 researchers, half being faculty members and half PhD students. Our focus is on algorithms, bioinformatics, distributed systems and computing, functional programming, formal methods, interaction design, language technology, parallel and high performance computing, programming logic and type theory, but research is not restricted to these topics. For more information, see http://www.cs.chalmers.se/Cs/Research. PhD positions are for 5 years. There is no tuition fee. A PhD position is a regular job with social benefits; the salary amounts currently to about 20600 SEK per month in the first year (the exact amount depends on teaching duties, usually 20% of your time). Knowledge of Swedish is not a prerequisite for application. English is our working language for research. Both Swedish and English are used in undergraduate courses. Half of our researchers and PhD students are native Swedes; the rest come from more than 20 different countries. Applicants must have a very good undergraduate degree in Computing Science or in a related subject with a strong Computing Science component. They must also have a strong, documented interest in doing research. You may even apply if you have not yet completed your degree, but expect to do so by 1 September 2005. You are also invited to apply for our new International Master's Programme in Dependable Computer Systems, which can help you to obtain the necessary qualification, if you do not yet have it (see http://www.cs.chalmers.se/Cs/Education/dcs/). Applicants in the area of language-based and logic-based security are encouraged to apply to specially allocated positions. The School especially welcomes female applicants. How to apply (http://www.cs.chalmers.se/~tsigas/PhD/phd-05-en.thtml) To apply send us a letter containing the following documentation: 1. A letter of application, listing specific research interests 2. A curriculum vitae 3. Attested copies of undergraduate degrees and other certificates 4. Copies of relevant work, for example dissertations or articles, that you have authored i or co-authored 5. A description of: * Previous teaching experience, documented, if any * Previous PhD studies, also in other subjects * State financial support for these, if any * Previous work experience 6. Letters of recommendation from your teachers or employers *** You MUST include Letters of Recommendation: we typically get over 100 apps, and it is simply not feasible for us to request individual letters *** The job refrence number is: 6/2005. The last date for your full application to arrive is February 15, 2005 to: Registrator, Chalmers University of Technology, Se-412 96 Göteborg, Sweden. Phone: +4631 772 1000, fax: +4631 772 4922, email: [EMAIL PROTECTED] If you have financial support of your own (industry job, grant, etc.), please state this fact clearly. It will increase your chances to be accepted considerably, because you need not compete for the limited number of fully financed positions. A decision about the PhD positions will be taken before May 15, 2005. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ICLP 2005: Call for Papers
Apologies if you receive multiple copies Call for Papers Twenty first International Conference on Logic Programming ICLP'05 2-5 October, 2004 Sitges (Barcelona) Spain Co-located with the International Conference on Principles and Practice of Constraint Programming (CP'05) http://www.iiia.csic.es/iclp2005/ The Conference -- The 21st International Conference on Logic Programming will be held near Barcelona (Spain) from October 2nd to October 5th, 2005. ICLP'05 will be colocated with the International Conference on Principles and Practice of Constraint Programming (CP'05). Conference scope Since the first conference held in Marseilles in 1982, ICLP has been the premier international conference for presenting research in logic programming. Contributions (papers and posters) are sought in all areas of logic programming including but not restricted to: Theory Implementation Semantic Foundations Compilation FormalismsMemory Management Nonmonotonic ReasoningVirtual Machines Knowledge Representation Parallelism Environments Alternative Paradigms Program Analysis Constraint Logic Programming Program TransformationAbductive Logic Programming Validation and Verification Inductive Logic Programming Debugging, Profiling Answer Set Programming Language IssuesApplications Concurrency Semantic Web Objects Software Engineering Coordination Web Tools Mobility Internet Agents Higher Order Artificial Intelligence Types Deductive Databases Modes Natural Language Programming Techniques Specific attention will be given to work providing novel integrations of these different areas, and to new applications of logic programming in general. Contributions on applications will be assessed with an emphasis on their impact and synergy with other areas, as opposed to technical maturity. Applications of logic programming to the Semantic Web are especially encouraged. The technical program will include several invited talks and advanced tutorials, in addition to the presentations of the accepted papers and posters. A special session on industrial applications of logic programming is also planned and several workshops will be held in parallel with the conference. For the first time, a doctoral student consortium will be organized as part of ICLP. Papers --- Papers must describe original, previously unpublished research, and must not be simultaneously submitted for publication elsewhere. They must be written in English and not exceed 15 pages in Springer LNCS format. The authors are encouraged, although not obliged, to submit their papers already in Springer LNCS format. General information about the Springer LNCS series and the LNCS authors' instructions are available at the Springer LNCS/LNAI home page (http://www.springer.de/comp/lncs/index.html). Papers should express their contribution clearly, both in general and technical terms. It is essential to identify what was accomplished, describe its significance, and explain how the paper compares with and advances previous work. Authors should make every effort to make the technical content understandable to a broad audience. The primary means of submission will be electronic, in pdf format. If electronic submission is not possible, five hard copies should be sent to one of the program co-chairs. More information on the submission procedure will be available at http://www.utdallas.edu/ICLP05 Industrial Papers - A special session on industrial applications of logic programming is also planned during the conference. Papers accepted in this session will describe innovative applications of logic programming to industrial problems. The application's innovativeness and industrial impact will be the main criteria used for judging the paper. Papers accepted for this session will be published in the proceedings as shorter, (up to) 10 pages papers. Posters --- Posters provide a forum for presenting work in an informal and interactive setting. They are ideal for discussing current work not yet ready for publication, for PhD thesis summaries and research project overviews. Accepted posters will also get a 10 minute
[Haskell] ANN: Cabal 0.4
The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal IMPORTANT INFORMATION: See both the README file and the changelog for important interface changes. DOWNLOAD: The Haskell Cabal has reached pre-release stage, with a 0.4 version The community should use this release to evaluate the interfaces and explore the concepts of these tools. Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items to [EMAIL PROTECTED] and Isaac Jones: [EMAIL PROTECTED] ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: You cannot currently execute the setup scripts with ./Setup.lhs since Cabal Hugs support isn't ready-for-prime-time. You can compile it with ghc thusly: ghc -package Cabal Setup.lhs -o setup and then use the setup executable after that. This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/ -*-change-log-*- 0.4 Isaac Jones [EMAIL PROTECTED] Sun Jan 16 2005 * Much thanks to all the awesome fptools hackers who have been working hard to build the Haskell Cabal! * Interface Changes: ** WARNING: this is a pre-release and the interfaces are still likely to change until we reach a 1.0 release. ** Instead of Package.description, you should name your description files something.cabal. In particular, we suggest that you name it packagename.cabal, but this is not enforced (yet). Multiple .cabal files in the same directory is an error, at least for now. ** ./setup install --install-prefix is gone. Use ./setup copy --copy-prefix instead. ** The Modules field is gone. Use hidden-modules, exposed-modules, and executable-modules. ** Build-depends is now a package-only field, and can't go into executable stanzas. Build-depends is a package-to-package relationship. ** Some new fields. Use the Source. * New Features ** Cabal is now included as a package in the CVS version of fptools. That means it'll be released as -package Cabal in future versions of the compilers, and if you are a bleeding-edge user, you can grab it from the CVS repository with the compilers. ** Hugs compatibility and NHC98 compatibility should both be improved. ** Hooks Interface / Autoconf compatibility: Most of the hooks interface is hidden for now, because it's not finalized. I have exposed only defaultMainWithHooks and defaultUserHooks. This allows you to use a ./configure script to preprocess foo.buildinfo, which gets merged with foo.cabal. In future releases, we'll expose UserHooks, but we're definitely going to change the interface to those. The interface to the two functions I've exposed should stay the same, though. ** ./setup haddock is a baby feature which pre-processes the source code with hscpp and runs haddock on it. This is brand new and hardly tested, so you get to knock it around and see what you think. ** Some commands now actually implement verbosity. ** The preprocessors have been tested a bit more, and seem to work OK. Please give feedback if you use these. 0.3 Isaac Jones [EMAIL PROTECTED] Sun Jan 16 2005 * Unstable snapshot release * From now on, stable releases are even. 0.2 Isaac Jones [EMAIL PROTECTED] * Adds more HUGS support
[Haskell] Why is getArgs in the IO monad?
See subject. It seems that it would be constant through execution, and so could be just [String]. Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Why is getArgs in the IO monad?
It's not a constant; see, for example, System.Environment.withArgs (http://www.haskell.org/ghc/docs/latest/html/libraries/base/System.Environment.html#v%3AwithArgs). Abe On Mon, 17 Jan 2005 16:23:17 -0500, Jim Apple [EMAIL PROTECTED] wrote: See subject. It seems that it would be constant through execution, and so could be just [String]. Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Why is getArgs in the IO monad?
On Mon, Jan 17, 2005 at 04:23:17PM -0500, Jim Apple wrote: See subject. It seems that it would be constant through execution, and so could be just [String]. I like to think that pure functions don't change between executions. getArgs :: [String] would certainly break that. Best regards, Tomasz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] signature of when, unless
Frederik Eaton [EMAIL PROTECTED] writes: Wouldn't it be more useful if the type was when :: Monad m = Bool - m a - m () not when :: Monad m = Bool - m () - m () Seconded. peace, isaac ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Why is getArgs in the IO monad?
How about a semantic answer instead of an operational one? If getArgs had type [String], then its denotation must be a (lazy) list of (lazy) sequences of characters (extended by bottom). For instance, the expression (words hello world) denotes the list [hello,world]. What list would getArgs denote? - Conal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Abraham Egnor Sent: Monday, January 17, 2005 1:31 PM To: Jim Apple Cc: haskell@haskell.org Subject: Re: [Haskell] Why is getArgs in the IO monad? It's not a constant; see, for example, System.Environment.withArgs (http://www.haskell.org/ghc/docs/latest/html/libraries/base/System.Envir onment.html#v%3AwithArgs). Abe On Mon, 17 Jan 2005 16:23:17 -0500, Jim Apple [EMAIL PROTECTED] wrote: See subject. It seems that it would be constant through execution, and so could be just [String]. Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Why is getArgs in the IO monad?
Conal Elliott wrote: If getArgs had type [String], then its denotation must be a (lazy) list of (lazy) sequences of characters (extended by bottom). For instance, the expression (words hello world) denotes the list [hello,world]. What list would getArgs denote? I don't think I understand your (rhetorical) question. It seems that, looking out at the world from main, the args passed to main and the compilation happen at the same time (before, long long ago). What motivation would we have for treating them differently? Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Why is getArgs in the IO monad?
Abraham Egnor wrote: It's not a constant; see, for example, System.Environment.withArgs That seems unnecessarily hack-ish. When would one use it when taking a [String] parameter would be inferior? Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Why is getArgs in the IO monad?
Tomasz Zielonka wrote: I like to think that pure functions don't change between executions. I'd like to think they wouldn't change within executions. Is there a pure haskell way to check the value of a function between exections? Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Re: Why is getArgs in the IO monad?
Hi Jim. If I understand you, you're asking for an operational answer to your original why -- this time bringing in the operational issues of compile and run times. I'm suggesting you might better understand the why of Haskell if you think denotationally (here about the meaning of the [String] type), rather than operationally. As a simpler example (type-wise), if getArgs were to have type [String], then length getArgs would have type Int. The meaning of length getArgs would then have to be a value whose type is the meaning of Haskell's Int, i.e. either bottom or a 32-bit integer. I'm guessing that none of those 2^32+1 values is what you'd mean by length getArgs. On the other hand, the IO monad is a much roomier type. HTH, - Conal -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jim Apple Sent: Monday, January 17, 2005 10:28 PM To: haskell@haskell.org Subject: [Haskell] Re: Why is getArgs in the IO monad? Conal Elliott wrote: If getArgs had type [String], then its denotation must be a (lazy) list of (lazy) sequences of characters (extended by bottom). For instance, the expression (words hello world) denotes the list [hello,world]. What list would getArgs denote? I don't think I understand your (rhetorical) question. It seems that, looking out at the world from main, the args passed to main and the compilation happen at the same time (before, long long ago). What motivation would we have for treating them differently? Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Books on Haskell
Hello! I've completed reading of Yet another Haskell tutorial and now want to learn Haskell more thoroughly. I'm searching for a book, in which the features of Haskell are explained in the form of examples and exercises (like in the book Clause and Effect on PROLOG). My purpose in exploring Haskell is to determine whether I can program much more productively by using Haskell instead of Java/C#. In order to do that, I have to learn Haskell quite thoroughly. What book can you recommend? TIA Dmitri Pissarenko -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] performance question
Hello all, A question on that most elusive of subjects performance in haskell (GHC 6.2) Using the GHC profiler, I obtained the following analysis results (i hope the code doesn't come out too ugly by mail): total time =0.92 secs (46 ticks @ 20 ms) total alloc = 83,373,032 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc isIn Main 50.0 22.8 getCon Main 13.0 16.7 o' Main 8.76.6 satisfiesMain 6.50.0 powerList Main 6.5 46.9 CAF Main 6.50.1 showCon Main 4.30.3 MAIN MAIN 4.30.0 a' Main 0.06.7 The problem child, that isIn function, has got about 78000 entries in the profile log. I should probably mention that this is an incredibly dumbed down version of the program, the dimensions of the data it is supposed to handle are such that, on a trial run I killed the process after about 15 minutes, when I found out it hadn't even completed 3% of its task. sad stuff, really. Anyways, 'isIn' is a predicate that checks whether a given Double lies within an interval, where intervals are defined as ... define an interval bound, either inclusive (I) or exclusive (E) data Bound = I Double | E Double deriving (Eq, Show, Ord) data Interval = Il Bound Bound | Nil Bound Bound deriving (Eq,Ord) where Nil acts as the complement of an interval, this is reflected in the isIn function. isIn :: Double - Interval - Bool isIn r (Nil x y) = not (isIn r (Il x y)) isIn r (Il (I x) (I y)) = r = x r = y isIn r (Il (I x) (E y)) = r = x r y isIn r (Il (E x) (I y)) = r x r = y isIn r (Il (E x) (E y)) = r x r y I tried rewriting it to something that intuitively 'feels' like it should be faster, but i have no real idea about the cost of the respective haskell expressions: ... version 2 isIn :: Double - Interval - Bool isIn r (Nil x y) = not (isIn r (Il x y)) isIn r (Il x y) = case x of (I x') - if r = x' then case y of (I y') - r = y' (E y') - r y' else False (E x') - if r x' then case y of (I y') - r = y' (E y') - r y' else False ... which indeed turns out to be a tad bit faster, according to the new profile log. total time =0.80 secs (40 ticks @ 20 ms) total alloc = 64,404,104 bytes (excludes profiling overheads) COST CENTREMODULE %time %alloc isIn Main 30.00.0 getCon Main 25.0 21.6 powerList Main 15.0 60.7 showConMain 7.50.3 o' Main 7.58.6 CAF Main 7.50.1 MAIN MAIN 5.00.0 a' Main 2.58.6 But it can hardly be called impressive. Can anyone see another obvious optimization, or have I just hit the ceiling because of the sheer number of function calls to isIn? I am still pretty new to haskell, and I find it hard to wrap my head around the way the compiler deals with my code. If someone has a few leads on general performance heuristics in haskell/GHC, I would be happy to read them too... thanks for your time. stijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Books on Haskell
If you really want to find out if Haskell is for you, you need to try and do things you already know how to do in the other languages. For this reason I found that Algorithms: A Functional Programming Approach was great for showing me where Haskell excelled and why it was the language for me. I also have The Haskell School of Expression (the book I first learnt haskell from) and The craft of functional programming. They are both great books. As far as learning about Haskell, I have learnt the most from doing the Implementing a functional language tutorial. However, if you are not interested in compilers, this would not be a good option. Matt. On 17/01/2005, at 8:00 PM, Dmitri Pissarenko wrote: Hello! I've completed reading of Yet another Haskell tutorial and now want to learn Haskell more thoroughly. I'm searching for a book, in which the features of Haskell are explained in the form of examples and exercises (like in the book Clause and Effect on PROLOG). My purpose in exploring Haskell is to determine whether I can program much more productively by using Haskell instead of Java/C#. In order to do that, I have to learn Haskell quite thoroughly. What book can you recommend? TIA Dmitri Pissarenko -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Books on Haskell
Thanks for your suggestions! As far as learning about Haskell, I have learnt the most from doing the Implementing a functional language tutorial. However, if you are not interested in compilers, this would not be a good option. I am primarily interested in using Haskell for everyday work, which in my case amounts to applications with a) (often) non-trivial algorithmic part and a b) user interface part. I want to use Haskell in order to increase my productivity in both of these parts. Compilers are, at least at the moment, not my topic of interest. Best regards Dmitri Pissarenko -- Dmitri Pissarenko Software Engineer http://dapissarenko.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Matroids in Haskell
On Fri, 14 Jan 2005, Michael Matsko wrote: Dimitri Matriods are generalization of vector spaces. Basically, they are defined by a set of linear dependence axioms and basis exchange properties. Oxley's Matriod Theory is the standard reference. There are a multitude of equivalent formulations. ... and the most spectacular result is, that a greedy algorithm for a problem is optimal if and only if the problem has Matroid structure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs vs GHC (again)was: Re: Somerandomnewbiequestions
John Meacham wrote: Actually, If I were writing new haskell libraries, I would use mmap whenever I could for accessing files. not only does it make the file pointer problem go away, but it can be drastically more efficient. I'm not sure this is a good idea, because GHC really needs non-blocking I/O to support its thread model, and memory-mapped I/O always blocks. In fact this is a problem even if we only memory-map files at the programmer's request. -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs vs GHC (again)was: Re: Somerandomnewbiequestions
can't GHC do this using the threaded RTS? Keean. John Meacham wrote: Actually, If I were writing new haskell libraries, I would use mmap whenever I could for accessing files. not only does it make the file pointer problem go away, but it can be drastically more efficient. I'm not sure this is a good idea, because GHC really needs non-blocking I/O to support its thread model, and memory-mapped I/O always blocks. In fact this is a problem even if we only memory-map files at the programmer's request. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs vs GHC (again)was: Re: Somerandomnewbiequestions
On Mon, 2005-01-17 at 13:44 -0800, Ben Rudiak-Gould wrote: John Meacham wrote: Actually, If I were writing new haskell libraries, I would use mmap whenever I could for accessing files. not only does it make the file pointer problem go away, but it can be drastically more efficient. I'm not sure this is a good idea, because GHC really needs non-blocking I/O to support its thread model, and memory-mapped I/O always blocks. In fact this is a problem even if we only memory-map files at the programmer's request. Indeed, a new IO system that could transparently take advantage of the system's native asynchronous IO features might be a good fit to GHC's thread model. Note that just using lots of system threads and blocking IO is usually not as efficient as single(/few) threaded multiplexed IO like GHC uses currently. Some OSs that do not have kernel native async IO implement the POSIX async IO API using OS threads and tend to get poor performance and few users. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I/O interface
Marcin 'Qrczak' Kowalczyk wrote:
Convenience. I'm worried that it uses separate types for various
kinds of streams: files, pipes, arrays (private memory), and sockets.
Haskell is statically typed and lacks subsumption. This means that
even though streams are unified by using a class, code which uses
a stream of an unknown kind must be either polymorphic or use
existential quantification.
Yes, this is a problem. In my original proposal InputStream and
OutputStream were types, but I enthusiastically embraced Simon M's idea
of turning them into classes. As you say, it's not without its
disadvantages.
I see several possibilities here.
* We could adopt Avery Lee's suggestion (from the discussion in
2003) to use field labels instead of methods. Advantages: InputStream
and OutputStream behave more like their OOP equivalents, with no loss of
extensibility. Disadvantages: potentially less efficient (no
specialization possible); loses some static type information.
* We could use a single type for all input and output streams in the
standard library, but retain the type classes also.
* We could provide existential wrappers:
data IStream = (InputStream a) = MkIStream !a
instance InputStream IStream where ...
A nice thing about the last approach is that it supports dynamic
downcasting:
case (x :: IStream) of
MkIStream x -
case (Data.Dynamic.cast x :: UArrayInputStream) of
Just x - (getUArray x, getCurrentIndex x)
Nothing - ...
Completeness. Unless File{Input,Output}Stream uses {read,write}()
rather than file{Read,Write}, openFile provides only a subset of
the functionality of open(): it works only with seekable files,
e.g. not with /dev/tty.
What is the type of stdin/stdout? They may be devices or pipes
(not seekable), regular files (seekable), sockets...
Simon M's current interface is incomplete, but the concept is fine.
Again, to try to avoid confusion, what you call a seekable file the
library calls a file, and what you call a file I would call a Posix
filehandle. Roughly. It's hard to be precise because file is such a
heavily overloaded term. (For example, is /dev/tty a file? Is the
(major,minor) device number it might correspond to on a particular
filesystem at a particular moment a file? Is the integer that's returned
from open(/dev/tty, ...) a file? Is the tty device itself a file? I
think you've used file in all four senses.)
When I talk about a stream, I mean one end of a unidirectional pneumatic
tube. If it's the ingoing end, you stick some data in the tube and it's
carried away. If it's the outgoing end, you wait for some data to arrive
and then take it. Tubes all look the same. No pneumatic tube is a
storage device, but you may happen to know that it leads to a Frobozz
Magic Storage Device at the other end.
By the same token, stdin is never a file, but the data which appears
through stdin may ultimately be coming from a file, and it's sometimes
useful, in that case, to bypass stdin and access the file directly. The
way to handle this is to have a separate stdinFile :: Maybe File.
As for openFile: in the context of a certain filesystem at a certain
time, a certain pathname may refer to
* Nothing
* A directory
* A file (in the library sense); this might include things like
/dev/hda and /dev/kmem
* Both ends of a (named) pipe
* A data source and a data sink which are related in some qualitative
way (for example, keyboard and screen, or stdin and stdout)
* A data source only
* A data sink only
* ...
How to provide an interface to this zoo?
The dynamic-typing approach is to return some sort of Thing with a
complicated interface which is approximately the union of the interfaces
for each thing in the above list. Unsupported methods fail when called.
This is roughly what Posix does, except that directories are a special
case, and Nothing is very special (as perhaps it should be, but I'm not
sure).
The Haskell approach is, I guess, to use an algebraic datatype, e.g.
data FilesystemObject
= Directory Directory
| File File
| InputOutput PosixInputStream PosixOutputStream
| Input PosixInputStream
| Output PosixOutputStream
Here I'm using Posix*Stream for all streams backed by Posix
filehandles. I'm unsure whether NoSuchPath should be in there too.
You might say that this is annoyingly complicated. My first reaction is
tough--it's exactly as complicated as the reality it models. But there
should presumably be helper functions of types FilesystemObject-IStream
and FilesystemObject-OStream.
The other complication is that Posix makes you specify access rights
when you look up a path in the filesystem. This makes no sense, but it's
something we have to live with.
So I'd argue for replacing openFile with something like
data FilesystemObject = ...
openPath :: FilePath - IOMode - IO FilesystemObject
filesystemInputStream :: FilesystemObject - (IO?) IStream
data
Re: [Haskell-cafe] I/O interface
On Mon, 2005-01-17 at 16:27 -0800, Ben Rudiak-Gould wrote:
Marcin 'Qrczak' Kowalczyk wrote:
Convenience. I'm worried that it uses separate types for various
kinds of streams: files, pipes, arrays (private memory), and sockets.
Haskell is statically typed and lacks subsumption. This means that
even though streams are unified by using a class, code which uses
a stream of an unknown kind must be either polymorphic or use
existential quantification.
Yes, this is a problem. In my original proposal InputStream and
OutputStream were types, but I enthusiastically embraced Simon M's idea
of turning them into classes. As you say, it's not without its
disadvantages.
I see several possibilities here.
* We could adopt Avery Lee's suggestion (from the discussion in
2003) to use field labels instead of methods. Advantages: InputStream
and OutputStream behave more like their OOP equivalents, with no loss of
extensibility. Disadvantages: potentially less efficient (no
specialization possible); loses some static type information.
I've often thought it would be nice to have a class and it's most
general instance, a record with the same fields as the class has
methods. It would be even better if they could share the same name, eg:
class IStream s where
read :: s - ...
data IStream = IStream {
read :: ...
}
instance IStream IStream where
read s = read s --the field selector not the class method
Obviously each instance of the IStream class can be converted to an
IStream record (loosing type information) which is useful for
heterogeneous collections of streams, and other interface programming
techniques.
This technique is perhaps a middle ground, it's a tad more complex that
just having a single type for streams but it allows code which does not
want to know to use a single type while allowing for static typing in
other cases where it is desired for safety or for better performance by
specialising.
A downside (apart from naming issues) is that while there is an
automatic conversion IStream data type - IStream class instance, there
is no automatic conversion the other way round. Compare this with Java
interfaces for example, a Java IStream interface is like our IStream
data type, but there is automatic conversion from the types implementing
the interface to the interface type itself. In Haskell we normally go
for the more strongly typed interfaces (Haskell classes) rather than the
more dynamic interfaces (record of functions) so the language supports
the former more naturally than the latter (eg automatic 'conversion'
when accessing an object through a class interface).
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Books on Haskell
Hi, I have 3 Haskell books, The Craft of Functional Programming (Thompson), Introduction to Functional Programming Using Haskell (Bird) and The Haskell School of Expression (Hudak). I recommend Thompson's book because it contains good explanations and lots of exercises, although the book is quite big and takes some time to work through. Bird's book is a bit shorter and is good for explanations too but it isn't quite so hands on as it contains fewer exercises. Hudak's I feel is a bit too advanced for a first read, it focusses on using the Hugs graphics library and I think that the graphics examples can sometimes cloud the simple ideas that are trying to be explained. I'll probably try reading it again in the future. All the best Dave O ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Books on Haskell
David Owen ([EMAIL PROTECTED]) wrote: I recommend Thompson's book because it contains good explanations and lots of exercises, although the book is quite big and takes some time to work through. Do you know if there are solutions to exersises avaialable somewhere? Have you gone through the whole book, i.e. all the exercises? Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] performance question
Stijn De Saeger wrote: data Bound = I Double | E Double deriving (Eq, Show, Ord) data Interval = Il Bound Bound | Nil Bound Bound deriving (Eq,Ord) isIn :: Double - Interval - Bool isIn r (Nil x y) = not (isIn r (Il x y)) isIn r (Il (I x) (I y)) = r = x r = y isIn r (Il (I x) (E y)) = r = x r y isIn r (Il (E x) (I y)) = r x r = y isIn r (Il (E x) (E y)) = r x r y If performance is the main concern, I would flatten the data structure: data Interval = IlII Double Double | IlIE Double Double | IlEI Double Double | IlEE Double Double | NilII Double Double | NilIE Double Double | NilEI Double Double | NilEE Double Double isIn :: Double - Interval - Bool isIn r (IlII x y) = r = x r = y isIn r (IlIE x y) = r = x r y isIn r (IlEI x y) = r x r = y isIn r (IlEE x y) = r x r y isIn r (NilII x y) = r x || r y isIn r (NilIE x y) = r x || r = y isIn r (NilEI x y) = r = x || r y isIn r (NilEE x y) = r = x || r = y Depending on your application you might not need all of those cases. Another neat trick you can pull is to take advantage of the fact that Double is actually a discrete type, like Int, and you can therefore get away with closed intervals only: data Interval = Il Double Double | Nil Double Double isIn :: Double - Interval - Bool isIn r (Il x y) = r = x r = y isIn r (Nil x y) = r x || r y But this requires nextLargestDouble and nextSmallestDouble functions. I don't know if Haskell provides them. Also, you could run into trouble with wider-than-Double intermediate values. Finally, if you never do anything with intervals except pass them to isIn, you can do this: type Interval = Double - Bool isIn r i = i r -- Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Books on Haskell
Dmitri Pissarenko [EMAIL PROTECTED] writes: What book can you recommend? shamelessPlugI reviewed The Haskell School of Expression on Slashdot a few months ago./shamelessPlug: http://books.slashdot.org/article.pl?sid=04/03/12/221232 peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
