Re: [Haskell-cafe] I can't install hs-plugins beceause of Linker.h
I believe that hs-plugins has fallen out of use, on #haskell, I was directed to hint[1]. IIRC, I had to disable some packages because of cross installation. /Joe [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hint Yuri Kashnikoff wrote: Hi! I was trying to install hs-plugins both from sources $./Setup.lhs ... and with $cabal fetchcabal install and both failed. It always reports that Linker.h is missing. I have tried to use --extra-include-dirs with path to ghc-6.10.1 dir and ghc-6.10.1/include dir. Nothing changed. Here is a report from Setup.lhs: Setup.lhs:2:2: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks Warning: defaultUserHooks in Setup script is deprecated. Configuring plugins-1.4.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package ghc-6.10.1 requires Cabal-1.6.0.1 package plugins-1.4.0 requires Cabal-1.6.0.2 checking build system type... i386-apple-darwin9.6.0 checking for ghc... ghc checking for value of __GLASGOW_HASKELL__... 610 checking for ghc library directory... /opt/local/lib/ghc-6.10.1/. checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for arc4random... yes checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating config.mk config.status: creating testsuite/makewith/io/TestIO.conf config.status: creating testsuite/makewith/unsafeio/Unsafe.conf config.status: creating config.h config.status: config.h is unchanged Setup.lhs: Missing dependency on a foreign library: * Missing header file: Linker.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. begin:vcard fn:Joseph Fredette n:Fredette;Joseph adr:Apartment #3;;6 Dean Street;Worcester;Massachusetts;01609;United States of America email;internet:jfred...@gmail.com tel;home:1-508-966-9889 tel;cell:1-508-254-9901 x-mozilla-html:FALSE url:lowlymath.net, humbuggery.net version:2.1 end:vcard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I can't install hs-plugins beceause of Linker.h
It depends on if you need 'eval' or object loading capability. For true plugins, hs-plugins is still the only binding to the GHC rts object loader, for eval-like mechanisms, we've a number of bindings to the ghc-api bytecode interpreter, such as hint. That said, hs-plugins is kinda sorta patches-applied maintained. jfredett: I believe that hs-plugins has fallen out of use, on #haskell, I was directed to hint[1]. IIRC, I had to disable some packages because of cross installation. /Joe [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hint Yuri Kashnikoff wrote: Hi! I was trying to install hs-plugins both from sources $./Setup.lhs ... and with $cabal fetchcabal install and both failed. It always reports that Linker.h is missing. I have tried to use --extra-include-dirs with path to ghc-6.10.1 dir and ghc-6.10.1/include dir. Nothing changed. Here is a report from Setup.lhs: Setup.lhs:2:2: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks Warning: defaultUserHooks in Setup script is deprecated. Configuring plugins-1.4.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package ghc-6.10.1 requires Cabal-1.6.0.1 package plugins-1.4.0 requires Cabal-1.6.0.2 checking build system type... i386-apple-darwin9.6.0 checking for ghc... ghc checking for value of __GLASGOW_HASKELL__... 610 checking for ghc library directory... /opt/local/lib/ghc-6.10.1/. checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for arc4random... yes checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating config.mk config.status: creating testsuite/makewith/io/TestIO.conf config.status: creating testsuite/makewith/unsafeio/Unsafe.conf config.status: creating config.h config.status: config.h is unchanged Setup.lhs: Missing dependency on a foreign library: * Missing header file: Linker.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. begin:vcard fn:Joseph Fredette n:Fredette;Joseph adr:Apartment #3;;6 Dean Street;Worcester;Massachusetts;01609;United States of America email;internet:jfred...@gmail.com tel;home:1-508-966-9889 tel;cell:1-508-254-9901 x-mozilla-html:FALSE url:lowlymath.net, humbuggery.net version:2.1 end:vcard ___ 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] I can't install hs-plugins beceause of Linker.h
Originally I was trying to install turbinado which depends on plugins=1.4. Actually I don't know how turbinado uses plugins. But still I can't build it because of plugins. I wonder how turbinado guys builds hs-plugins with ghc-6.10.1. On Sun, Mar 15, 2009 at 12:04 PM, Don Stewart d...@galois.com wrote: It depends on if you need 'eval' or object loading capability. For true plugins, hs-plugins is still the only binding to the GHC rts object loader, for eval-like mechanisms, we've a number of bindings to the ghc-api bytecode interpreter, such as hint. That said, hs-plugins is kinda sorta patches-applied maintained. jfredett: I believe that hs-plugins has fallen out of use, on #haskell, I was directed to hint[1]. IIRC, I had to disable some packages because of cross installation. /Joe [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hint Yuri Kashnikoff wrote: Hi! I was trying to install hs-plugins both from sources $./Setup.lhs ... and with $cabal fetchcabal install and both failed. It always reports that Linker.h is missing. I have tried to use --extra-include-dirs with path to ghc-6.10.1 dir and ghc-6.10.1/include dir. Nothing changed. Here is a report from Setup.lhs: Setup.lhs:2:2: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks Warning: defaultUserHooks in Setup script is deprecated. Configuring plugins-1.4.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package ghc-6.10.1 requires Cabal-1.6.0.1 package plugins-1.4.0 requires Cabal-1.6.0.2 checking build system type... i386-apple-darwin9.6.0 checking for ghc... ghc checking for value of __GLASGOW_HASKELL__... 610 checking for ghc library directory... /opt/local/lib/ghc-6.10.1/. checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for arc4random... yes checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating config.mk config.status: creating testsuite/makewith/io/TestIO.conf config.status: creating testsuite/makewith/unsafeio/Unsafe.conf config.status: creating config.h config.status: config.h is unchanged Setup.lhs: Missing dependency on a foreign library: * Missing header file: Linker.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. begin:vcard fn:Joseph Fredette n:Fredette;Joseph adr:Apartment #3;;6 Dean Street;Worcester;Massachusetts;01609;United States of America email;internet:jfred...@gmail.com tel;home:1-508-966-9889 tel;cell:1-508-254-9901 x-mozilla-html:FALSE url:lowlymath.net, humbuggery.net version:2.1 end:vcard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Yuri S. Kashnikov Novosibirsk State University, Russia 2 Pirogova street 630090, Novosibirsk-90 yuri.kashnik...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to catch error in array index when debugging
Claus == Claus Reinke claus.rei...@talk21.com writes: Claus None of which is satisfactory. You might also want to add Claus yourself to this ticket: Claus index out of range error message regression Claus http://hackage.haskell.org/trac/ghc/ticket/2669 How do I do that? Claus Ghc Trac's idea of voting is by adding yourself to the cc, Claus so that tickets can be sorted by length of cc list: I was asking specifically how I add myself to the CC list. There is no button to do so. There is a CC text field, but last time I typed my name there, it ERASED the previous member of the CC list. Rather than a wrapper, I coded an assert, and added it in all the places where I used (!). That was no fun. It did identify the calling function, but that doesn't tell me anything very interesting. I now have to repeat the process for all the callers of that function, which is no joke. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Default Tuple Orderings
Hi, Does anyone know how Haskell’s tuple ordering works? Presumably for some tuple T1 (x1,x2,...xn) and another tuple T2 (y1,y2,...yn) Haskell would compare T1 and T2 as follows: T1 T2 if: x1 y1 OR otherwise if x1 == y1 then if x2 y2 OR otherwise if x2 == y2 then if x3 y3 OR otherwise etc xn yn OR otherwise both tuple are equal In other words my best guess is that the ordering of tuples is by comparing the first tuple elements and then the seconds, thirds etc, until there’s an element less than another. Is this reasoning correct? So minimum xs would yield the “smallest” tuple (according to the above rules and if xs is a list of tuples)? Cheers, Mark Spezzano No virus found in this outgoing message. Checked by AVG. Version: 7.5.557 / Virus Database: 270.11.13/2001 - Release Date: 14/03/2009 6:54 AM ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] is there a version of hsffig that builds on a recent versin of haskell?
is there a version of hsffig that builds on a recent versin of haskell? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Default Tuple Orderings
Mark Spezzano wrote: In other words my best guess is that the ordering of tuples is by comparing the first tuple elements and then the seconds, thirds etc, until there’s an element less than another. ...until there's an element not equal to the other, yes. It finds the first position at which the two elements in the tuples are unequal and returns the result of comparing those two elements (LT or GT). If there's no such position, then the tuples are equal. See also: http://en.wikipedia.org/wiki/Lexicographical_order HTH, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How to catch error in array index when debugging
Peter == Peter Hercek pher...@gmail.com writes: Peter Colin Paul Adams wrote: Adrian == Adrian Neumann aneum...@inf.fu-berlin.de writes: Adrian You can use the ghci debugger http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci- Adrian debugger.html Adrian it can set breakpoints on exceptions. So i tried adding the -fbreak-on-error flag. It made no difference - it still exited: interactive: Error in array index interactive: interrupted interactive: warning: too many hs_exit()s Peter IIRC, this is because you are catching exceptions at some Peter higher level where you actually find out that this kind of Peter an exception is not handled and give up. If your Peter application is Gtk2Hs then this library will do the Peter catching you do not like in this case. Try to use That is the case. Peter -fbreak-on-exception instead of -fbreak-on-error. If you Peter try this you may need to set break-on-exception late enough Peter in the execution (use some breakpoint) so that you are not Peter stopping at places which are ok (are correctly handled in Peter an exception handler). This works - in conhunction with :trace and :history. Thanks. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A non-inductive Haskell proof?
The following theorem is obviously true, but how is it proved (most cleanly and simply) in Haskell? Theorem: (nondecreasing xs) = nondecreasing (insert x xs), where: nondecreasing :: (Ord a) = [a] - Bool nondecreasing []= True nondecreasing xxs@(x : xs) = and [a = b | (a, b) - zip xxs xs] insert :: (Ord a) = a - [a] - [a] insert x xs = takeWhile (= x) xs ++ [x] ++ dropWhile (= x) xs Thanks. _ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Most elegant funciton for removing adjacent duplicates from a list using foldl and foldr
I need to write an implementation using foldl, and a separate implementation using foldr, of a function, remdups xs, that removes adjacent duplicate items from the list xs. For example, remdups [1,2,2,3,3,3,1,1]= [1,2,3,1]. My approach is first to write a direct recursion, as follows: remdups :: (Eq a) = [a] - [a] remdups []= [] remdups (x : []) = [x] remdups (x : xx : xs) = if x == xx then remdups (x : xs) else x : remdups (xx : xs) This code works, but it has three cases, not usual two, namely [] and (x : xs). What, if any, is the implementation using only two cases? Also, if three cases are required, then how can it be implemented using foldr, and how using foldl? Thanks. _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I can't install hs-plugins beceause of Linker.h
On Sun, 2009-03-15 at 11:38 +0600, Yuri Kashnikoff wrote: Hi! I was trying to install hs-plugins both from sources $./Setup.lhs ... and with $cabal fetchcabal install and both failed. It always reports that Linker.h is missing. Setup.lhs: Missing dependency on a foreign library: * Missing header file: Linker.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. It's a bug in the package that was exposed when Cabal-1.6.0.2 started checking for header files and C libs. I reported the bug to the package maintainer at the time of the release of Cabal-1.6.0.2. Until the maintainer updates it, the fix is to edit the .cabal file and simply remove the mention of Linker.h. You can use the new cabal unpack command: cabal unpack plugins cd plugins-1.4.0 vi plugins.cabal cabal install Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most elegant funciton for removing adjacent duplicates from a list using foldl and foldr
2009/3/15 R J rj248...@hotmail.com I need to write an implementation using foldl, and a separate implementation using foldr, of a function, remdups xs, that removes adjacent duplicate items from the list xs. For example, remdups [1,2,2,3,3,3,1,1]= [1,2,3,1]. My approach is first to write a direct recursion, as follows: remdups :: (Eq a) = [a] - [a] remdups []= [] remdups (x : []) = [x] remdups (x : xx : xs) = if x == xx then remdups (x : xs) else x : remdups (xx : xs) This code works, but it has three cases, not usual two, namely [] and (x : xs). What, if any, is the implementation using only two cases? Also, if three cases are required, then how can it be implemented using foldr, and how using foldl? Thanks. Perhaps it would be helpful to define a helper function with this signature: prepend :: (Eq a) = a - [a] - [a] Which for prepend x xs will put x at the front of the list, so long as the first element of the list xs is different from x. Once you have this function, take a look at the type signature for foldr. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most elegant funciton for removing adjacent duplicates from a list using foldl and foldr
2009/3/15 R J rj248...@hotmail.com: What, if any, is the implementation using only two cases? This version considers 2 cases 2 times :-) But only the 'go' function is recursive, so it could probably be written using some kind of fold. The value being build by the fold should probably be some kind of tuple so you can keep track of some state. remdups2 :: (Eq a) = [a] - [a] remdups2 [] = [] remdups2 (x:xs) = go x xs where go x [] = [x] go x (y:ys) = if x == y then go x ys else x : go y ys I almost managed to write one using foldr, but it always put the first group last :-( Perhaps someone else manages to get it right. -- Warning: doesn't work correctly! Last group is last... remdups3 :: (Eq a) = [a] - [a] remdups3 [] = [] remdups3 (x:xs) = snd $ foldr f (x, []) xs where f y (x, xs') = if y == x then (x, xs') else (y, x : xs') ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad is missing Applicative instance
ouch, I was confusing the mtl and transformers package... so basically transformers is a better replacement for mtl? or does mtl offer things transformers does not? On Sun, Mar 15, 2009 at 12:04 AM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sat, 14 Mar 2009, Peter Verswyvelen wrote: I was using the transformers but still had to implement the Applicative instance of State This package contains an applicative instance for StateT but not for State In 'transformers' State is a type synonym for StateT Identity and thus does not need an own instance declaration. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most elegant funciton for removing adjacent duplicates from a list using foldl and foldr
Why don't you just swap the pattern match order? remdups :: (Eq a) = [a] - [a] remdups (x : xx : xs) = if x == xx then remdups (x : xs) else x : remdups (xx : xs) remdups xs= xs This should cover all cases no? Also I prefer guards, but I guess that is personal remdups (x1:x2:xs) | x1 == x2 = remdups (x2 : xs) | otherwise = x1 : remdups (x2 : xs) remdups xs = xs 2009/3/15 R J rj248...@hotmail.com I need to write an implementation using foldl, and a separate implementation using foldr, of a function, remdups xs, that removes adjacent duplicate items from the list xs. For example, remdups [1,2,2,3,3,3,1,1]= [1,2,3,1]. My approach is first to write a direct recursion, as follows: remdups :: (Eq a) = [a] - [a] remdups []= [] remdups (x : []) = [x] remdups (x : xx : xs) = if x == xx then remdups (x : xs) else x : remdups (xx : xs) This code works, but it has three cases, not usual two, namely [] and (x : xs). What, if any, is the implementation using only two cases? Also, if three cases are required, then how can it be implemented using foldr, and how using foldl? Thanks. -- Express your personality in color! Preview and select themes for Hotmail®. See how.http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=TXT_MSGTX_WL_HM_express_032009#colortheme ___ 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
[Haskell-cafe] ANNOUNCE: dzen-utils 0.1
Hello! I'm please to announce dzen-utils 0.1. I don't feel like it is ready to be released, but let's see how everything goes. :) == WHAT == dzen-utils contains various utilities for creating dzen input strings in a type-safe way using some combinators, including the ability to apply colors locally (instead of applying for everything beyond some point). It can also emulate dbar and gdbar, do automatic padding, and more. == WHY == I don't like to write bash scripts for dzen, and I don't like the way xmobar treats its configuration and its inability to show anything other than text. This package is a short-term solution for my problems. Maybe I'll write xmozen in the future. ;) == WHERE, HOW, etc. == It is in Hackage already, go get it[1]. Please see the documentation of System.Dzen for some small examples. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dzen-utils Thanks for your time, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Link errors
Hi, If I include import Text.Regex.Posix ((=~)) into a Haskell code, I get the following link error: FindBBUsage.o:fake:(.text+0x44d): undefined reference to `__stginit_regexzmposixzm0zi72zi0zi3_TextziRegexziPosix_' collect2: ld returned 1 exit status Any ideas on how to fix this? I am using GHC version 6.10.1 on Windows XP. Thanks, Logo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Link errors
Lingappan, Loganathan wrote: If I include import Text.Regex.Posix ((=~)) into a Haskell code, I get the following link error: FindBBUsage.o:fake:(.text+0x44d): undefined reference to `__stginit_regexzmposixzm0zi72zi0zi3_TextziRegexziPosix_' collect2: ld returned 1 exit status Any ideas on how to fix this? I am using GHC version 6.10.1 on Windows XP. Did you use --make ? Regards, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I can't install hs-plugins beceause of Linker.h
Thanks. Problem solved now! On Sun, Mar 15, 2009 at 7:20 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Sun, 2009-03-15 at 11:38 +0600, Yuri Kashnikoff wrote: Hi! I was trying to install hs-plugins both from sources $./Setup.lhs ... and with $cabal fetchcabal install and both failed. It always reports that Linker.h is missing. Setup.lhs: Missing dependency on a foreign library: * Missing header file: Linker.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. It's a bug in the package that was exposed when Cabal-1.6.0.2 started checking for header files and C libs. I reported the bug to the package maintainer at the time of the release of Cabal-1.6.0.2. Until the maintainer updates it, the fix is to edit the .cabal file and simply remove the mention of Linker.h. You can use the new cabal unpack command: cabal unpack plugins cd plugins-1.4.0 vi plugins.cabal cabal install Duncan -- Yuri S. Kashnikov Novosibirsk State University, Russia 2 Pirogova street 630090, Novosibirsk-90 yuri.kashnik...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: is there a version of hsffig that builds on a recent versin of haskell?
On Mar 15, 4:03 am, Anatoly Yakovenko aeyakove...@gmail.com wrote: is there a version of hsffig that builds on a recent versin of haskell? ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe Unfortunately no. There have been too many changes in GCC and GHC since, and too low interest to the project from other developers, so I did not maintain it. Dmitry. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What unsafeInterleaveIO is unsafe
Hello, I was studying about what unsafeInterleaveIO is.I understood unsafeInterleaveIO takes an IO action, and delays it. But I couldn't find any reason why unsafeInterleaveIO is unsafe. I have already read an example in http://www.haskell.org/pipermail/haskell-cafe/2009-March/057101.html says lazy IO may break purity, but I think real matter in this example are wrong use of seq. did I misread? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
unsafeInterleaveIO allows embedding side effects into a pure computation. This means you can potentially observe if some pure value has been evaluated or not; the result of your code could change depending how lazy/strict it is, which is very hard to predict! For example: -- given f :: Integer - Integer main = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 x - case f v of 0 - return 0 n - return (n - 1) y - readIORef r print y -- a couple of examples: f x = 0 -- program prints 0 -- f x = x -- program prints 1 f is pure. But if f is nonstrict, this program prints 0, and if it's strict, it prints 1. The strictness of a pure function can change the observable behavior of your program! Furthermore, due to the monad laws, if f is total, then reordering the (x - ...) and (y - ...) parts of the program should have no effect. But if you switch them, the program will *always* print 0. Also, the compiller might notice that x is never used, and that f is total. So it could just optimize out the evaluation of f v completely, at which point the program always prints 0 again; changing optimization settings modifies the result of the program. This is why unsafeInterleaveIO is unsafe. -- ryan On Sun, Mar 15, 2009 at 11:31 AM, Yusaku Hashimoto nonow...@gmail.com wrote: Hello, I was studying about what unsafeInterleaveIO is.I understood unsafeInterleaveIO takes an IO action, and delays it. But I couldn't find any reason why unsafeInterleaveIO is unsafe. I have already read an example in http://www.haskell.org/pipermail/haskell-cafe/2009-March/057101.html says lazy IO may break purity, but I think real matter in this example are wrong use of seq. did I misread? ___ 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
[Haskell-cafe] Help with Bird problem 4.5.6: sequence of successive maxima
This Bird problem vexes me, in the first instance because it doesn't seem to specify a unique solution: Given a list xs = [x_1, x_2, . . . , x_n], the sequence of successive maxima ssm xs is the longest subsequence [x_j1, x_j2, x_j3..x_jk] such that j_1 = 1 and j_m j_n = x_jm x_jn. For example, xs = [3, 1, 3, 4, 9, 2, 10, 7] = ssm xs = [3, 4, 9, 10]. Define ssm in terms of foldl. From this specification, I infer: ssm [] = [] ssm [1] = [1] ssm [1, 2, 3]= [1, 2, 3] ssm [1, 0, 3, 2] = [1, 3] However, what is ssm [1,0,100,2,3,4,5]? Is it [1, 100] or [1, 2, 3, 4, 5]? I think the latter, but am not certain. Whichever it is, what's the solution? Thanks. _ Windows Live™ Groups: Create an online spot for your favorite groups to meet. http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I can't install hs-plugins beceause of Linker.h
Fixed on hackage. $ cabal update $ cabal install plugins-1.4.1 Or via the web: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/plugins-1.4.1 -- Don yuri.kashnikoff: Thanks. Problem solved now! On Sun, Mar 15, 2009 at 7:20 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Sun, 2009-03-15 at 11:38 +0600, Yuri Kashnikoff wrote: Hi! I was trying to install hs-plugins both from sources $./Setup.lhs ... and with $cabal fetchcabal install and both failed. It always reports that Linker.h is missing. Setup.lhs: Missing dependency on a foreign library: * Missing header file: Linker.h This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. It's a bug in the package that was exposed when Cabal-1.6.0.2 started checking for header files and C libs. I reported the bug to the package maintainer at the time of the release of Cabal-1.6.0.2. Until the maintainer updates it, the fix is to edit the .cabal file and simply remove the mention of Linker.h. You can use the new cabal unpack command: cabal unpack plugins cd plugins-1.4.0 vi plugins.cabal cabal install Duncan -- Yuri S. Kashnikov Novosibirsk State University, Russia 2 Pirogova street 630090, Novosibirsk-90 yuri.kashnik...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
On Sun, 2009-03-15 at 13:02 -0700, Ryan Ingram wrote: unsafeInterleaveIO allows embedding side effects into a pure computation. This means you can potentially observe if some pure value has been evaluated or not; the result of your code could change depending how lazy/strict it is, which is very hard to predict! For example: -- given f :: Integer - Integer main = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 x - case f v of 0 - return 0 n - return (n - 1) y - readIORef r print y -- a couple of examples: f x = 0 -- program prints 0 -- f x = x -- program prints 1 f is pure. But if f is nonstrict, this program prints 0, and if it's strict, it prints 1. The strictness of a pure function can change the observable behavior of your program! Right. If the compiler feels like changing the way it implements your program based on that factor. But `semantics' that the compiler doesn't preserve are kind of useless... Furthermore, due to the monad laws, if f is total, then reordering the (x - ...) and (y - ...) parts of the program should have no effect. But if you switch them, the program will *always* print 0. I'm confused. I though if f was strict, then my program *always* printed 1? Also, the compiller might notice that x is never used, and that f is total. So it could just optimize out the evaluation of f v completely, at which point the program always prints 0 again; changing optimization settings modifies the result of the program. This is why unsafeInterleaveIO is unsafe. Well, unsafeInterleaveIO or reasoning based on overly specific assumptions about how things must be implemented, anyway. I'm not sure you've narrowed it down to usafeInterleaveIO, though. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
Am Sonntag, 15. März 2009 21:25 schrieb Jonathan Cast: On Sun, 2009-03-15 at 13:02 -0700, Ryan Ingram wrote: Furthermore, due to the monad laws, if f is total, then reordering the (x - ...) and (y - ...) parts of the program should have no effect. But if you switch them, the program will *always* print 0. I'm confused. I though if f was strict, then my program *always* printed 1? But not if you switch the (x - ...) and (y - ...) parts: main = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 y - readIORef r x - case f v of 0 - return 0 n - return (n - 1) print y Now the IORef is read before the case has a chance to trigger the writing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help with Bird problem 4.5.6: sequence of successive maxima
Am Sonntag, 15. März 2009 21:09 schrieb R J: This Bird problem vexes me, in the first instance because it doesn't seem to specify a unique solution: Given a list xs = [x_1, x_2, . . . , x_n], the sequence of successive maxima ssm xs is the longest subsequence [x_j1, x_j2, x_j3..x_jk] such that j_1 = 1 and j_m j_n = x_jm x_jn. For example, xs = [3, 1, 3, 4, 9, 2, 10, 7] = ssm xs = [3, 4, 9, 10]. Define ssm in terms of foldl. From this specification, I infer: ssm [] = [] ssm [1] = [1] ssm [1, 2, 3]= [1, 2, 3] ssm [1, 0, 3, 2] = [1, 3] However, what is ssm [1,0,100,2,3,4,5]? Is it [1, 100] or [1, 2, 3, 4, 5]? I think the latter, but am not certain. Since [1,2,3,4,5] is longer than [1,100], it's the former. But if we consider the example [1,0,3,2], the two lists [1,3] and [1,2] are equally long, both are valid answers given the above spec. So if you want one list as the answer, you have to add a criterium to choose. Whichever it is, what's the solution? Is the above all that Bird gives as specification or was there more? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
On Sun, 2009-03-15 at 21:43 +0100, Daniel Fischer wrote: Am Sonntag, 15. März 2009 21:25 schrieb Jonathan Cast: On Sun, 2009-03-15 at 13:02 -0700, Ryan Ingram wrote: Furthermore, due to the monad laws, if f is total, then reordering the (x - ...) and (y - ...) parts of the program should have no effect. But if you switch them, the program will *always* print 0. I'm confused. I though if f was strict, then my program *always* printed 1? But not if you switch the (x - ...) and (y - ...) parts: main = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 y - readIORef r x - case f v of 0 - return 0 n - return (n - 1) print y Now the IORef is read before the case has a chance to trigger the writing. But if the compiler is free to do this itself, what guarantee do I have that it won't? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
Am Sonntag, 15. März 2009 21:56 schrieb Jonathan Cast: On Sun, 2009-03-15 at 21:43 +0100, Daniel Fischer wrote: Am Sonntag, 15. März 2009 21:25 schrieb Jonathan Cast: On Sun, 2009-03-15 at 13:02 -0700, Ryan Ingram wrote: Furthermore, due to the monad laws, if f is total, then reordering the (x - ...) and (y - ...) parts of the program should have no effect. But if you switch them, the program will *always* print 0. I'm confused. I though if f was strict, then my program *always* printed 1? But not if you switch the (x - ...) and (y - ...) parts: main = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 y - readIORef r x - case f v of 0 - return 0 n - return (n - 1) print y Now the IORef is read before the case has a chance to trigger the writing. But if the compiler is free to do this itself, what guarantee do I have that it won't? None? Wasn't that Ryan's point, that without the unsafeInterleaveIO, that reordering wouldn't matter, but with it, it does? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
On Sun, 2009-03-15 at 22:09 +0100, Daniel Fischer wrote: Am Sonntag, 15. März 2009 21:56 schrieb Jonathan Cast: On Sun, 2009-03-15 at 21:43 +0100, Daniel Fischer wrote: Am Sonntag, 15. März 2009 21:25 schrieb Jonathan Cast: On Sun, 2009-03-15 at 13:02 -0700, Ryan Ingram wrote: Furthermore, due to the monad laws, if f is total, then reordering the (x - ...) and (y - ...) parts of the program should have no effect. But if you switch them, the program will *always* print 0. I'm confused. I though if f was strict, then my program *always* printed 1? But not if you switch the (x - ...) and (y - ...) parts: main = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 y - readIORef r x - case f v of 0 - return 0 n - return (n - 1) print y Now the IORef is read before the case has a chance to trigger the writing. But if the compiler is free to do this itself, what guarantee do I have that it won't? None? Wasn't that Ryan's point, that without the unsafeInterleaveIO, that reordering wouldn't matter, but with it, it does? Sure. But *that point is wrong*. Given the two programs main0 = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 y - readIORef r x - case f v of 0 - return 0 n - return (n - 1) print y main1 = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 x - case f v of 0 - return 0 n - return (n - 1) y - readIORef r print y There is *no* guarantee that main0 prints 0, while main1 prints 1, as claimed. The compiler is in fact free to produce either output given either program, at its option. Since the two programs do in fact have exactly the same set of possible implementations, they *are* equivalent. So the ordering in fact *doesn't* matter. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] big discussion about Haskell on Reddit
I noticed that on Programming Reddit, where I lurk, there is a big discussion about the disconnect between how much Haskell is advocated there and the number of applications written in it. http://www.reddit.com/r/programming/comments/84sqt/dear_reddit_i_am_seeing_12_articles_in/ The difficulty of reasoning about memory and CPU-efficiency in nontrivial programs was suggested as an explanation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] big discussion about Haskell on Reddit
fft1976: I noticed that on Programming Reddit, where I lurk, there is a big discussion about the disconnect between how much Haskell is advocated there and the number of applications written in it. http://www.reddit.com/r/programming/comments/84sqt/dear_reddit_i_am_seeing_12_articles_in/ The difficulty of reasoning about memory and CPU-efficiency in nontrivial programs was suggested as an explanation. As well as a million other crazy things, sadly. Reminds me of: http://xkcd.com/386/ Just to cheer people up, there are now 1124 packages on hackage.haskell.org, and on average ~10 releases of Haskell apps and libs are happening each day: http://galois.com/~dons/images/hackage-daily-graph.png -- Don (goes back to writing some code) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
Am Sonntag, 15. März 2009 22:20 schrieb Jonathan Cast: There is *no* guarantee that main0 prints 0, while main1 prints 1, as claimed. The compiler is in fact free to produce either output given either program, at its option. Since the two programs do in fact have exactly the same set of possible implementations, they *are* equivalent. So the ordering in fact *doesn't* matter. Hum. Whether the programme prints 0 or 1 depends on whether writeIORef r 1 is done before readIORef r. That depends of course on the semantics of IO and unsafeInterleaveIO. In so far as the compiler is free to choose there, it can indeed produce either result with either programme. But I think Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. (report, section 7) restricts the freedom considerably. However, I understand unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded. as explicitly allowing the programmer to say do it if and when the result is needed, not before. So I think main0 *must* print 0, because the ordering of the statements puts the reading of the IORef before the result of the unsafeInterleaveIOed action may be needed, so an implementation is obliged to read it before writing to it. In main1 however, v may be needed to decide what action's result x is bound to, before the reading of the IORef in the written order, so if f is strict, the unsafeInterleaveIOed action must be performed before the IORef is read and the programme must print 1, but if f is lazy, v is not needed for that decision, so by the documentation, the unsafeInterleaveIOed action will not be performed, and the programme prints 0. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
On Sun, 2009-03-15 at 23:18 +0100, Daniel Fischer wrote: Am Sonntag, 15. März 2009 22:20 schrieb Jonathan Cast: There is *no* guarantee that main0 prints 0, while main1 prints 1, as claimed. The compiler is in fact free to produce either output given either program, at its option. Since the two programs do in fact have exactly the same set of possible implementations, they *are* equivalent. So the ordering in fact *doesn't* matter. Hum. Whether the programme prints 0 or 1 depends on whether writeIORef r 1 is done before readIORef r. That depends of course on the semantics of IO and unsafeInterleaveIO. In so far as the compiler is free to choose there, it can indeed produce either result with either programme. But I think Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. (report, section 7) restricts the freedom considerably. Why not read that line as prohibiting concurrency (forkIO) as well? However, I understand unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded. Where is this taken from? If GHC's library docs try to imply that the programmer can predict when an unsafeInterleaveIO'd operation takes place --- well, then they shouldn't. I'm starting to suspect that not starting from a proper denotational theory of IO was a major mistake for GHC's IO system (which Haskell 1.3 in part adopted). as explicitly allowing the programmer to say do it if and when the result is needed, not before. Haskell's order of evaluation is undefined, so this doesn't really allow the programmer to constrain when the effects are performed much. So I think main0 *must* print 0, because the ordering of the statements puts the reading of the IORef before the result of the unsafeInterleaveIOed action may be needed, so an implementation is obliged to read it before writing to it. In main1 however, v may be needed to decide what action's result x is bound to, before the reading of the IORef in the written order, so if f is strict, the unsafeInterleaveIOed action must be performed before the IORef is read and the programme must print 1, Although as Ryan pointed out, the compiler may decide to omit the case statement entirely, if it can statically prove that f v is undefined. but if f is lazy, v is not needed for that decision, so by the documentation, the unsafeInterleaveIOed action will not be performed, and the programme prints 0. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
Am Sonntag, 15. März 2009 23:30 schrieb Jonathan Cast: On Sun, 2009-03-15 at 23:18 +0100, Daniel Fischer wrote: Am Sonntag, 15. März 2009 22:20 schrieb Jonathan Cast: There is *no* guarantee that main0 prints 0, while main1 prints 1, as claimed. The compiler is in fact free to produce either output given either program, at its option. Since the two programs do in fact have exactly the same set of possible implementations, they *are* equivalent. So the ordering in fact *doesn't* matter. Hum. Whether the programme prints 0 or 1 depends on whether writeIORef r 1 is done before readIORef r. That depends of course on the semantics of IO and unsafeInterleaveIO. In so far as the compiler is free to choose there, it can indeed produce either result with either programme. But I think Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. (report, section 7) restricts the freedom considerably. Why not read that line as prohibiting concurrency (forkIO) as well? Good question. Because forkIO is a way to explicitly say one doesn't want the one thing necessarily done before the other, I'd say. However, I understand unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded. Where is this taken from? If GHC's library docs try to imply that the From the documentation of System.IO.Unsafe. programmer can predict when an unsafeInterleaveIO'd operation takes place --- well, then they shouldn't. I'm starting to suspect that not starting from a proper denotational theory of IO was a major mistake for GHC's IO system (which Haskell 1.3 in part adopted). Maybe. as explicitly allowing the programmer to say do it if and when the result is needed, not before. Haskell's order of evaluation is undefined, so this doesn't really allow the programmer to constrain when the effects are performed much. The full paragraph from the report: The I/O monad used by Haskell mediates between the values natural to a functional language and the actions that characterize I/O operations and imperative programming in general. The order of evaluation of expressions in Haskell is constrained only by data dependencies; an implementation has a great deal of freedom in choosing this order. Actions, however, must be ordered in a well-defined manner for program execution -- and I/O in particular -- to be meaningful. Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. I read it as saying that IO *does* allow the programmer to control when the effects are performed. So I think main0 *must* print 0, because the ordering of the statements puts the reading of the IORef before the result of the unsafeInterleaveIOed action may be needed, so an implementation is obliged to read it before writing to it. In main1 however, v may be needed to decide what action's result x is bound to, before the reading of the IORef in the written order, so if f is strict, the unsafeInterleaveIOed action must be performed before the IORef is read and the programme must print 1, Although as Ryan pointed out, the compiler may decide to omit the case statement entirely, if it can statically prove that f v is undefined. I suppose that's a typo and should be unneeded. But can it prove that f v is unneeded? After all, it may influence whether 0 or 1 is printed. but if f is lazy, v is not needed for that decision, so by the documentation, the unsafeInterleaveIOed action will not be performed, and the programme prints 0. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
main = do
r - newIORef 0
v - unsafeInterleaveIO $ do
writeIORef r 1
return 1
x - case f v of
0 - return 0
n - return (n - 1)
y - readIORef r
print y
-- a couple of examples:
f x = 0 -- program prints 0
-- f x = x -- program prints 1
f is pure. But if f is nonstrict, this program prints 0, and if
it's strict, it prints 1. The strictness of a pure function can
change the observable behavior of your program!
Strictness is an effect, even if it isn't recorded in Haskell's types.
Replacing 'v - ..' by 'let v = undefined' provides similar choices.
'unsafeInterleaveIO' explicitly uses the implicit effects of
strictness to drive the explicit effects of IO, which is why it
is unsafe (moving IO effects from explicit to implicit). But even
if 'unsafeInterleaveIO' where eliminated, strictness/evaluation
would still remain as an implicit effect in Haskell. Here's a
variation without 'unsafeInterleaveIO':
import Data.IORef
import Control.Exception
main = do
r - newIORef 0
let v = undefined
handle (\(ErrorCall _)-print hireturn 42) $ case f v of
0 - return 0
n - return (n - 1)
y - readIORef r
print y
-- a couple of examples:
f x = 0 -- program prints '0'
f x = x -- program prints 'hi0'
(sideline: I often interpret '_|_::t' not so much as an element of 't'
but as failure to produce information at type 't'; the type tells us
what information we can have, evaluation not only provides the
details, but also decides whether or not we have any of that info,
and how much of it)
Furthermore, due to the monad laws, if f is total, then reordering the
(x - ...) and (y - ...) parts of the program should have no effect.
case f v of { 0 - return 0; n - return (n - 1) }
=
return $! case f v of { 0 - 0; n - (n - 1) }
=/=
return $ case f v of { 0 - 0; n - (n - 1) }
Monad laws apply to the latter, so how is reordering justified?
It doesn't matter if 'f' is total, the context requires to know whether
'f v' is '0' or not. Since the only thing used from the result is its
successful evaluation, the case could be eliminated, but that still
leaves
return $! f v
=/=
return $ f v
But if you switch them, the program will *always* print 0.
In my copy of the docs, the only things known about 'unsafeInterleaveIO'
are its module, its type, and that is is unsafe. If we assume, from the name,
that evaluation of its parameter will be interleaved unsafely with the main IO
thread, there is no knowing when or if that evaluation will happen. Unless
there is a dependency on the result of that evaluation, in which case we have
an upper bound on when the evaluation must happen, but still no lower
bound. From the comments in the source code, it appears that lower
and upper bound are intended to be identical, ie. evaluation is supposed
to happen at the latest possible point permitted by dependencies.
Changing dependencies changes the program.
Also, the compiller might notice that x is never used, and that f is
total. So it could just optimize out the evaluation of f v
completely, at which point the program always prints 0 again; changing
optimization settings modifies the result of the program.
It doesn't matter whether or not 'x' is used. It matters whether 'f v'
needs to be evaluated to get at the 'return' action. Even if 'f' is total,
that evaluation cannot be skipped. Eta-expansion changes strictness,
which changes the program (eg, '\p-(fst p,snd p)' =/= 'id::(a,b)-(a,b)',
even though these functions only apply to pairs, so we know that
whatever 'p' is, it ought to be a pair - only we don't; and neither do
we know that 'f v' is a number, even if 'f' itself is total).
None of this means that lazy IO and monadic IO ought to be mixed
freely. If a program depends on strictness/non-strictness, that needs
to be taken into account, which can be troublesome, which is why
lazy IO hasn't been the default IO mechanism in Haskell for many
years. It is still available because when it is applicable, it can be
quite elegant and simple. But we need to decide whether or not
that is the case for each use case, even without the explicit 'unsafe'.
Hth?
Claus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
On Mon, 2009-03-16 at 00:14 +0100, Daniel Fischer wrote: Am Sonntag, 15. März 2009 23:30 schrieb Jonathan Cast: On Sun, 2009-03-15 at 23:18 +0100, Daniel Fischer wrote: Am Sonntag, 15. März 2009 22:20 schrieb Jonathan Cast: There is *no* guarantee that main0 prints 0, while main1 prints 1, as claimed. The compiler is in fact free to produce either output given either program, at its option. Since the two programs do in fact have exactly the same set of possible implementations, they *are* equivalent. So the ordering in fact *doesn't* matter. Hum. Whether the programme prints 0 or 1 depends on whether writeIORef r 1 is done before readIORef r. That depends of course on the semantics of IO and unsafeInterleaveIO. In so far as the compiler is free to choose there, it can indeed produce either result with either programme. But I think Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. (report, section 7) restricts the freedom considerably. Why not read that line as prohibiting concurrency (forkIO) as well? Good question. Because forkIO is a way to explicitly say one doesn't want the one thing necessarily done before the other, I'd say. As is unsafeInterleaveIO. (And as is unsafePerformIO, as per the docs: If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. ) However, I understand unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded. Where is this taken from? If GHC's library docs try to imply that the From the documentation of System.IO.Unsafe. This version of those docs: http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.html leaves unsafeInterleaveIO completely un-documented. So I'm still not sure what you're quoting from. programmer can predict when an unsafeInterleaveIO'd operation takes place --- well, then they shouldn't. I'm starting to suspect that not starting from a proper denotational theory of IO was a major mistake for GHC's IO system (which Haskell 1.3 in part adopted). Maybe. as explicitly allowing the programmer to say do it if and when the result is needed, not before. Haskell's order of evaluation is undefined, so this doesn't really allow the programmer to constrain when the effects are performed much. The full paragraph from the report: The I/O monad used by Haskell mediates between the values natural to a functional language and the actions that characterize I/O operations and imperative programming in general. The order of evaluation of expressions in Haskell is constrained only by data dependencies; an implementation has a great deal of freedom in choosing this order. Actions, however, must be ordered in a well-defined manner for program execution -- and I/O in particular -- to be meaningful. Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. I read it as saying that IO *does* allow the programmer to control when the effects are performed. Right. But by using forkIO or unsafeInterleaveIO you waive that ability. So I think main0 *must* print 0, because the ordering of the statements puts the reading of the IORef before the result of the unsafeInterleaveIOed action may be needed, so an implementation is obliged to read it before writing to it. In main1 however, v may be needed to decide what action's result x is bound to, before the reading of the IORef in the written order, so if f is strict, the unsafeInterleaveIOed action must be performed before the IORef is read and the programme must print 1, Although as Ryan pointed out, the compiler may decide to omit the case statement entirely, if it can statically prove that f v is undefined. I suppose that's a typo and should be unneeded. But can it prove that f v is unneeded? After all, it may influence whether 0 or 1 is printed. [Ignored: begging the question] jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] State monad is missing Applicative instance
Peter Verswyvelen schrieb: ouch, I was confusing the mtl and transformers package... so basically transformers is a better replacement for mtl? or does mtl offer things transformers does not? transformers and monad-fd are cleanly separated, transformers is Haskell 98 and monad-fd uses functional dependencies. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help with Bird problem 4.5.6: sequence of successive maxima
Am Sonntag, 15. März 2009 21:09 schrieb R J: This Bird problem vexes me, in the first instance because it doesn't seem to specify a unique solution: Given a list xs = [x_1, x_2, . . . , x_n], the sequence of successive maxima ssm xs is the longest subsequence [x_j1, x_j2, x_j3..x_jk] such that j_1 = 1 and j_m j_n = x_jm x_jn. For example, xs = [3, 1, 3, 4, 9, 2, 10, 7] = ssm xs = [3, 4, 9, 10]. Define ssm in terms of foldl. From this specification, I infer: ssm [] = [] ssm [1] = [1] ssm [1, 2, 3]= [1, 2, 3] ssm [1, 0, 3, 2] = [1, 3] However, what is ssm [1,0,100,2,3,4,5]? Is it [1, 100] or [1, 2, 3, 4, 5]? I think the latter, but am not certain. Whichever it is, what's the solution? Thanks. Not particularly efficient, but module SSM where import Data.List (maximumBy) import Data.Ord ssm :: Ord a = [a] - [a] ssm = reverse . maximumBy (comparing length) . foldl comb [[]] where comb [[]] a = [[a]] comb lists a = do xs@(h:_) - lists if h a then [xs,a:xs] else [xs] I think it is impossible to implement ssm as foldl f z without any post-processing and since foldl can't foresee what comes in the remainder of the list, you must keep several candidates around. You can probably make it more efficient by removing all lists lst@(h:_) where there's a longer list with head = h or an equally long list with head h in the store (but doing that efficiently is not trivial). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Has anybody replicated =~ s/../../ or even something more basic for doing replacements with pcre haskell regexen?
Except that there is nothing like =~ s in haskell, as far as I can tell. I was mulling over this and thinking, the nicest solution for this -- from the lens of perl evangelism anyway -- would be to have some way of accessing the perl6 language =~ s mechanism in pugs, which would get us everything in perl 5 =~, and also all the cool grammar stuff that comes in perl6, which seems 90% of the way to parsec in terms of power but with a thought out huffman-optimized syntax. Accordingly I am trying to load pugs in ghci, about which more at http://perlmonks.org/?node_id=750768 2009/3/14 Brandon S. Allbery KF8NH allb...@ece.cmu.edu: On 2009 Mar 14, at 19:01, Thomas Hartman wrote: FWIW, the problem I was trying to solve was deleting single newlines but not strings of newlines in a document. Dead simple for pcre-regex with lookaround. But, I think, impossible with posix regex. s/(^|[^\n])\n($|[^\n])/\1\2/g; POSIX regexen may be ugly, but they're capable. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
Am Montag, 16. März 2009 00:47 schrieb Jonathan Cast: On Mon, 2009-03-16 at 00:14 +0100, Daniel Fischer wrote: However, I understand unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded. Where is this taken from? If GHC's library docs try to imply that the From the documentation of System.IO.Unsafe. This version of those docs: http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.htm l leaves unsafeInterleaveIO completely un-documented. So I'm still not sure what you're quoting from. The documentation haddock-0.9 built when I compiled ghc-6.8.3 last year. programmer can predict when an unsafeInterleaveIO'd operation takes place --- well, then they shouldn't. I'm starting to suspect that not starting from a proper denotational theory of IO was a major mistake for GHC's IO system (which Haskell 1.3 in part adopted). Maybe. as explicitly allowing the programmer to say do it if and when the result is needed, not before. Haskell's order of evaluation is undefined, so this doesn't really allow the programmer to constrain when the effects are performed much. The full paragraph from the report: The I/O monad used by Haskell mediates between the values natural to a functional language and the actions that characterize I/O operations and imperative programming in general. The order of evaluation of expressions in Haskell is constrained only by data dependencies; an implementation has a great deal of freedom in choosing this order. Actions, however, must be ordered in a well-defined manner for program execution -- and I/O in particular -- to be meaningful. Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. I read it as saying that IO *does* allow the programmer to control when the effects are performed. Right. But by using forkIO or unsafeInterleaveIO you waive that ability. That depends on the specification of unsafeInterleaveIO. If it is unspecified order of evaluation, then yes, if it is do when needed, not before, as my local documentation can be interpreted, then unsafeInterleaveIO reduces that ability, but doesn't completely remove it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most elegant funciton for removing adjacent duplicates from a list using foldl and foldr
R J wrote:
I need to write an implementation using foldl, and a separate implementation using foldr,
of a function, remdups xs, that removes adjacent duplicate items from the
list xs. For example, remdups [1,2,2,3,3,3,1,1]= [1,2,3,1].
My approach is first to write a direct recursion, as follows:
remdups :: (Eq a) = [a] - [a]
remdups []= []
remdups (x : []) = [x]
remdups (x : xx : xs) = if x == xx then remdups (x : xs) else x : remdups
(xx : xs)
This code works, but it has three cases, not usual two, namely [] and (x : xs).
You should take a look at the page on declaration style vs expression
style:
http://haskell.org/haskellwiki/Declaration_vs._expression_style
At the risk of doing homework, it is always the case that you can
decompose complex pattern matching into basic pattern matching (which
for lists means it always has two cases, since list has two
constructors).[1]
remdups [] = ...#1
remdups (x:[]) = ...#2
remdups (x:(xx:xs)) = ...#3
== {desugar pattern-matching into case}
remdups = \a - case a of
[] - ...#1
(x:[]) - ...#2
(x:(xx:xs)) - ...#3
== {desugar case into case}
remdups = \a - case a of
[]- ...#1
(x:b) - case b of
[] - ...#2
(xx:xs) - ...#3
This transformation explicitly gives a name to the second argument of
the first (:) which is beneficial since it means you don't need to
allocate a new one that's identical to the old one in order to pass to
the recursion. For the Then we know x==xx therefore (x:xs) == (xx:xs),
for the Else we need (xx:xs), in both cases we already have an (xx:xs)
laying around, namely b.
If you want to give a name like this without manually desugaring the
case statements yourself, then you can use an as-pattern like (x:
b@(xx:xs)) which will bind the variable b to the value (xx:xs) just like
above.
[1] This would not be true if, for example, the language could express
non-linear terms like in Prolog and other logic languages. Pattern
matching can still be decomposed in such languages, but they need to
introduce unification constraints along with the smaller patterns, to
ensure correctness of the transformation.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
On Mon, 2009-03-16 at 01:04 +0100, Daniel Fischer wrote: Am Montag, 16. März 2009 00:47 schrieb Jonathan Cast: On Mon, 2009-03-16 at 00:14 +0100, Daniel Fischer wrote: However, I understand unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded. Where is this taken from? If GHC's library docs try to imply that the From the documentation of System.IO.Unsafe. This version of those docs: http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.htm l leaves unsafeInterleaveIO completely un-documented. So I'm still not sure what you're quoting from. The documentation haddock-0.9 built when I compiled ghc-6.8.3 last year. So it's a GHC (and base) major version out of date. programmer can predict when an unsafeInterleaveIO'd operation takes place --- well, then they shouldn't. I'm starting to suspect that not starting from a proper denotational theory of IO was a major mistake for GHC's IO system (which Haskell 1.3 in part adopted). Maybe. as explicitly allowing the programmer to say do it if and when the result is needed, not before. Haskell's order of evaluation is undefined, so this doesn't really allow the programmer to constrain when the effects are performed much. The full paragraph from the report: The I/O monad used by Haskell mediates between the values natural to a functional language and the actions that characterize I/O operations and imperative programming in general. The order of evaluation of expressions in Haskell is constrained only by data dependencies; an implementation has a great deal of freedom in choosing this order. Actions, however, must be ordered in a well-defined manner for program execution -- and I/O in particular -- to be meaningful. Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order. I read it as saying that IO *does* allow the programmer to control when the effects are performed. Right. But by using forkIO or unsafeInterleaveIO you waive that ability. That depends on the specification of unsafeInterleaveIO. If it is unspecified order of evaluation, then yes, if it is do when needed, not before, Note that `when needed' is still dependent on the (still unspecified) (non-IO) Haskell evaluation order. Also note that, to demonstrate any strong claims about unsafeInterleaveIO, you need to show that the compiler *must* perform in such-and-such a way, not simply that it *will* or that it *may*. as my local documentation can be interpreted, then unsafeInterleaveIO reduces that ability, but doesn't completely remove it. Sure. The question is whether the compiler has still enough options for re-ordering the program that transforming a program according to the standard equational axiomatic semantics for Haskell doesn't change the set of options the compiler has for the behavior of its generated code. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
Yusaku Hashimoto wrote: Hello, I was studying about what unsafeInterleaveIO is.I understood unsafeInterleaveIO takes an IO action, and delays it. But I couldn't find any reason why unsafeInterleaveIO is unsafe. I have already read an example in http://www.haskell.org/pipermail/haskell-cafe/2009-March/057101.html says lazy IO may break purity, but I think real matter in this example are wrong use of seq. did I misread? For example: I have some universal state in IO. We'll call it an IORef, but it could be anything, like reading lines from a file. And I have some method for accessing and updating that state. next r = do n - readIORef r writeIORef r (n+1) return n Now, if I use unsafeInterleaveIO: main = do r - newIORef 0 x - do a - unsafeInterleaveIO (next r) b - unsafeInterleaveIO (next r) return (a,b) ... The values of a and b in x are entirely arbitrary, and are only set at the point when they are first accessed. They're not just arbitrary between which is 0 and which is 1, they could be *any* pair of values (other than equal) since the reference r is still in scope and other code in the ... could affect it before we access a and b, or between the two accesses. The arbitrariness is not random in the statistical sense, but rather is an oracle for determining the order in which evaluation has occurred. Consider, as an illustration these two alternatives for the ...: fst x `seq` snd x `seq` return x vs snd x `seq` fst x `seq` return x In this example, main will return (0,1) or (1,0) depending on which was chosen. You are right in that the issue lies in seq, but that's a red herring. Having made x, we can pass it along to any function, ignore the output of that function, and inspect x in order to know the order of strictness in that function. Moreover, let's have two pure implementations, f and g, of the same mathematical function. Even if f and g are close enough to correctly give the same output for inputs with _|_ in them, we may be able to observe the fact that they arrive at those answers differently by passing in our x. Given that such observations are possible, it is no longer safe to exchange f and g for one another, despite the fact that they are pure and give the same output for all (meaningful) inputs. This example is somewhat artificial because we set up x to use unsafeInterleaveIO in the bad way. For the intended use cases where it is indeed (arguably) safe, we would need to be sure to manually thread the state through the pure value (e.g. x) such that the final value is sane. For instance, in lazy I/O where we're constructing a list of lines/bytes/whatever, we need to ensure that any access to the Nth element of the list will first force the (N-1)th element, so that we ensure that the list comes out in the same order as if we forced all of them at construction time. For things like arbitrary symbol generation, unsafeInterleaveIO is perfectly fine because the order and identity of the symbols generated is irrelevant, but more importantly it is safe because the IO that's going on is not actually I/O. For arbitrary symbol generation, we could use unsafeInterleaveST instead, and that would be better because it accurately describes the effects. For any IO value which has real I/O effects, unsafeInterleaveIO is almost never correct because the ordering of effects on the real world (or whether the effects occur at all) depends entirely on the evaluation behavior of the program, which can vary by compiler, by compiler version, or even between different runs of the same compiled binary. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
On Sun, Mar 15, 2009 at 1:56 PM, Jonathan Cast jonathancc...@fastmail.fm wrote: But not if you switch the (x - ...) and (y - ...) parts: main = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 y - readIORef r x - case f v of 0 - return 0 n - return (n - 1) print y Now the IORef is read before the case has a chance to trigger the writing. But if the compiler is free to do this itself, what guarantee do I have that it won't? You don't really have any guarantee; the compiler is free to assume that v is a pure integer and that f is a pure function from integers to integers. Therefore, it can assume that the only observable affect of calling f v is non-termination. Note that unsafeInterleaveIO *breaks* this assumption; that is why it is unsafe. I erred previously in saying that this was allowed if f is total; it does still evaluate f v either way. But I can correct my argument as follows: the only observable effect from the (x - ...) line is non-termination. And the compiler can prove that there *no* observable effect of readIORef until the value is used or the reference is written by another function. So it is free to make this reordering anyways, as the only observable effect could have been non-termination which will be observed immediately after. When you use unsafeInterleaveIO or unsafePerformIO, you are required prove that its use does not break these invariants; that, for example, you don't read or write from IORefs that could be accessed elsewhere in the program. These are proofs that the compiler can and does make in some situations; it can reorder sequential readIORef calls if it thinks one or the other might be more efficient. It can evaluate foldl as if it was foldl' if it proves the arguments strict enough that non-termination behavior is identical (ghc -O2 does this, for example). The language has them as escape hatches that allow you to write code that would not otherwise be possible, by shifting more of a proof obligation on to the programmer. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe
On Sun, 2009-03-15 at 18:11 -0700, Ryan Ingram wrote: On Sun, Mar 15, 2009 at 1:56 PM, Jonathan Cast jonathancc...@fastmail.fm wrote: But not if you switch the (x - ...) and (y - ...) parts: main = do r - newIORef 0 v - unsafeInterleaveIO $ do writeIORef r 1 return 1 y - readIORef r x - case f v of 0 - return 0 n - return (n - 1) print y Now the IORef is read before the case has a chance to trigger the writing. But if the compiler is free to do this itself, what guarantee do I have that it won't? You don't really have any guarantee; the compiler is free to assume that v is a pure integer and that f is a pure function from integers to integers. Therefore, it can assume that the only observable affect of calling f v is non-termination. Note that unsafeInterleaveIO *breaks* this assumption; [Ignored; begging the question] jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.Binary, Data.Text and errors
Hi all, I have noticed that in both Data.Binary and Data.Text (which is still experimental, but still), the decode functions can be undefined (i.e. bottom) if they encounter malformed input. What is the preferred way to use these functions in a safe way? For example, if one writes data to a disk using Data.Binary and wants to read it back in at a later date, how can one ensure that it is valid so that Data.Binary does not hit an error? Or do you just have to catch the exception in the IO Monad? Alex ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] libgmp for GHC 6.10.1 on Mac OS X 10.5
I'm trying to install GHC 6.10.1 on Mac OS X 10.5 (PowerPC). I installed Xcode 3.1.2. I built libgmp 4.2.4 and installed it in /usr/local/lib. When I do ./configure in GHC's dist directory, however, I get: bash-3.2$ ./configure checking build system type... powerpc-apple-darwin9.6.0 checking host system type... powerpc-apple-darwin9.6.0 checking target system type... powerpc-apple-darwin9.6.0 Which we'll further canonicalise into: powerpc-apple-darwin checking for path to top of build tree... dyld: Library not loaded: /usr/local/lib/libgmp.3.dylib Referenced from: /Users/family/Desktop/Downloads/ghc-6.10.1/dist/utils/pwd/pwd Reason: no suitable image found. Did find: /usr/local/lib/libgmp.3.dylib: mach-o, but wrong architecture /usr/local/lib/libgmp.3.dylib: mach-o, but wrong architecture configure: error: cannot determine current directory Any ideas what I'm doing wrong? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] libgmp for GHC 6.10.1 on Mac OS X 10.5
By default GMP builds for x86_64. Do ./configure ABI=32 to build 32- bit libraries for GHC. On Mar 15, 2009, at 10:54 PM, Dean Herington wrote: I'm trying to install GHC 6.10.1 on Mac OS X 10.5 (PowerPC). I installed Xcode 3.1.2. I built libgmp 4.2.4 and installed it in / usr/local/lib. When I do ./configure in GHC's dist directory, however, I get: bash-3.2$ ./configure checking build system type... powerpc-apple-darwin9.6.0 checking host system type... powerpc-apple-darwin9.6.0 checking target system type... powerpc-apple-darwin9.6.0 Which we'll further canonicalise into: powerpc-apple-darwin checking for path to top of build tree... dyld: Library not loaded: / usr/local/lib/libgmp.3.dylib Referenced from: /Users/family/Desktop/Downloads/ghc-6.10.1/dist/ utils/pwd/pwd Reason: no suitable image found. Did find: /usr/local/lib/libgmp.3.dylib: mach-o, but wrong architecture /usr/local/lib/libgmp.3.dylib: mach-o, but wrong architecture configure: error: cannot determine current directory Any ideas what I'm doing wrong? Thanks. ___ 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] Data.Binary, Data.Text and errors
On Sun, Mar 15, 2009 at 8:40 PM, Alexander Dunlap alexander.dun...@gmail.com wrote: I have noticed that in both Data.Binary and Data.Text (which is still experimental, but still), the decode functions can be undefined (i.e. bottom) if they encounter malformed input. For decoding Unicode, it's typical to provide a flexible API that can do one of the following on a bad encoding: - Substitute a character - Skip it - Return the partial decode - Throw an exception I just haven't gotten there yet. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: is there a version of hsffig that builds on a recent versin of haskell?
i can try to fix it if i can get some help. i've never used cabal.
any idea why i am getting this:
anato...@anatolyy-linux /shared/anatolyy/hsffig-1.0 $ cabal install
Warning: HSFFIG.cabal: The field hs-source-dir is deprecated, please use
hs-source-dirs
Warning: HSFFIG.cabal: The field hs-source-dir is deprecated, please use
hs-source-dirs
Warning: HSFFIG.cabal: The field hs-source-dir is deprecated, please use
hs-source-dirs
Resolving dependencies...
Configuring HSFFIG-1.0...
configure: searching for ghc in path.
configure: found ghc at /usr/bin/ghc
/usr/bin/ghc --version tmp16646
configure: looking for package tool: ghc-pkg near compiler in /usr/bin/ghc
configure: found package tool in /usr/bin/ghc-pkg
configure: Using install prefix: /shared/anatolyy/.cabal
configure: Using compiler: /usr/bin/ghc
configure: Compiler flavor: GHC
configure: Compiler version: 6.10.1
configure: Using package tool: /usr/bin/ghc-pkg
configure: No haddock found
configure: No happy found
configure: No alex found
configure: Using hsc2hs: /usr/bin/hsc2hs
configure: No cpphs found
configure: Reading installed packages...
/usr/bin/ghc-pkg --user list tmp16646
cannot parse package list
cabal: Error: some packages failed to install:
HSFFIG-1.0 failed during the configure step. The exception was:
exit: ExitFailure 1
anato...@anatolyy-linux /shared/anatolyy/hsffig-1.0 $ /usr/bin/ghc-pkg
--user list
/usr2/anatolyy/.ghc/x86_64-linux-6.10.1/package.conf:
{FiniteMap-0.1}, {HUnit-1.2.0.3}, {X11-1.4.5}, {haskell98-1.0.1.0},
{html-1.0.1.2}, {mtl-1.1.0.2}, {parsec-2.1.0.1}, {process-1.0.1.1},
{regex-base-0.93.1}, {regex-compat-0.92}, {regex-posix-0.94.1},
{text-0.1}, {xmonad-0.8.1}
On Sun, Mar 15, 2009 at 11:20 AM, Dmitry Golubovsky
golubov...@gmail.com wrote:
On Mar 15, 4:03 am, Anatoly Yakovenko aeyakove...@gmail.com wrote:
is there a version of hsffig that builds on a recent versin of haskell?
___
Haskell-Cafe mailing list
haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
Unfortunately no. There have been too many changes in GCC and GHC
since, and too low interest to the project from other developers, so I
did not maintain it.
Dmitry.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A new haskell tools project
Hi all: I have just created an haskell work toolset project in google code. Currently there are only a few tools to process YUV image files I wrote before. Welcome you attend in to improve my code or to add in your tools. And also pleasure to get your advices. http://code.google.com/p/haskellworkingtools/ Regards -- L.Guo 2009-03-16 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design Patterns by Gamma or equivalent
G'day all. Quoting wren ng thornton w...@freegeek.org: Most of the (particular) problems OO design patterns solve are non-issues in Haskell because the language is more expressive. ...and vice versa. Some of the design patterns that we use in Haskell, for example, are to overcome the fact that Haskell doesn't have mutable global state. A number of other patterns can actually be written down once and for all (in higher-order functions like foldr, map,...) instead of needing repetition. This is also true in many OO languages. A lot of the GoF book, for example, can be implemented as libraries in Ada or C++. And then there are some things like monoids which fall somewhere between idiom and pearl. Things like monoids are constructions from algebra. Abstract algebra and design patterns have a lot in common. They're based on the same idea, in fact: When a pattern keeps showing up, define it and give it a name so you can talk about it independently of any specific implementation. Or to put it another way, category theory is the pattern language of mathematics. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
