Re: [GHC] #3060: impossible internal bug while building darcs
#3060: impossible internal bug while building darcs -+-- Reporter: quick |Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.10.1 Severity: major | Resolution: invalid Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: x86 | -+-- Comment (by simonpj): I'm glad you're rolling again, but I'm still mystified. That Can't find interface-file declaration message sounds just like a stale interface file, which can give all sorts of trouble. What happens if you now install unix-2.3.1.0 in your fresh GHC 6.10? (When I say install I mean using Cabal or something so that you compile it from scratch; a binary download won't do.) If installing the unix package breaks the build, something is still wrong. Re Quickcheck, GHC 6.10 has a new implementation of exceptions. I think you can get the old one back with some package incantation like -package base-3, but I'm not certain. Ask the libraries list. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3060#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid]
It's a bit unusual, but it shows up in a situation like this data T a where T1 :: T Int T2 :: T Bool x :: T Char ...case x of { ... } In this case no patterns can match, so the entire case should be unreachable. In this situation the entire case is replaced by (error Impossible alternative). (Should really say Unreachable case expression.) It's quite difficult to make this happen without the enclosing code also being unreachable and discarded, which is why I flagged it. You could do some -dverbose-core2core stuff to see it happening if you liked, but no, it should not be harmful. Simon From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 04 March 2009 19:55 To: glasgow-haskell-bugs@haskell.org Subject: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid] I'm getting this message from ghc 6.11.20090115: mkCase: null alts wild_Xs{v} [lid] a{v ace2} [lid] My code compiles and seems to run okay. Is it anything to worry about? ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3027: Specialisation rules fail because dictionary projections do not match
#3027: Specialisation rules fail because dictionary projections do not match --+- Reporter: malcolm.wall...@cs.york.ac.uk |Owner: Type: bug| Status: closed Priority: normal |Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --+- Changes (by simonpj): * milestone: = _|_ Comment: Oh I see. I'm not going to investigate 6.8.2, because we won't make a new release on that branch. If and when you have time to characterise the performance lossage wrt 6.8.2 I'd be v happy to investigate. I hate things going slower. But no rush. I'll leave the ticket open (although you might want to close it and open a new one when you get to this). Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3027#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3073: Avoid reconstructing dictionaries in recursive instance methods
#3073: Avoid reconstructing dictionaries in recursive instance methods ---+ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.1 Severity: normal| Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ Ganesh writes: I have a problem in GHC 6.10 with functions in a class instance calling other functions in the same class instance. It seems that the dictionary is freshly constructed for this call, despite being already available. The reason I care is that I want to memoise some expensive computations inside the dictionary for each instance. [Obviously I also have to make sure that the dictionary isn't constructed multiple times by external callers, but I can make other arrangements to ensure that.] To see the problem in action, run main from the attached code. In GHC 6.8 and before, this only executes the trace statement once. In GHC 6.10, the trace statement executes twice, at all optimisation levels. This seems related to #2902, but I'm a little unclear on whether it's the same problem or not. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3073 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3074: Template Haskell does not support type families.
#3074: Template Haskell does not support type families. +--- Reporter: Serguey Zefirov | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: template haskell, type families | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple +--- {{{ {-# LANGUAGE TemplateHaskell, TypeFamilies #-} import Language.Haskell.TH type family A a $((\x - x = (runIO . (print . ppr)) return []) $ [d|type instance A (Maybe Int) = Int|]) }}} GHCi load result: {{{ [1 of 1] Compiling Main ( a.hs, interpreted ) type A = GHC.Types.Int Ok, modules loaded: Main. }}} TySynD has list of Names as an argument list whereas type families header should have a list of Types. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3074 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1876: Complete shared library support
#1876: Complete shared library support -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: high |Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal| Resolution: Keywords:| Difficulty: Difficult (1 week) Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonmar): see also #3072 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1876#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3041: Arch independent binary representations
#3041: Arch independent binary representations -+-- Reporter: nomeata |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: Unknown/Multiple | -+-- Comment (by duncan): Replying to [comment:9 simonmar]: Replying to [comment:7 igloo]: Is there a reason for GHC not to use `Data.Binary` too? The only reason I can think of would be to avoid the extra dependency, but if haddock uses it then the GHC build depends on it anyway. Personally, I don't think it's a strong enough reason to maintain our own Binary anyway. I've been lead to believe that the performance of `Data.Binary` isn't as good as our `Binary` library. I don't have figures to back that up, but performance of reading interface files is pretty important to us. So I've been holding off on switching until `Data.Binary` has had some tuning. There was a regression in the performance of `Data.Binary` from ghc-6.8 to 6.10 which is perhaps what you're thinking of. Prior to that it was several times faster (10x at the time of the binary-0.4 release) than `NewBinary` which I believe was basically ghc's binary implementation extracted into a standalone library. Don looked at the performance regression so is best placed to say if the latest release brings performance back up to what it was with 6.8. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3041#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3041: Arch independent binary representations
#3041: Arch independent binary representations -+-- Reporter: nomeata |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: Unknown/Multiple | -+-- Comment (by simonmar): Replying to [comment:10 duncan]: Replying to [comment:9 simonmar]: I've been lead to believe that the performance of `Data.Binary` isn't as good as our `Binary` library. I don't have figures to back that up, but performance of reading interface files is pretty important to us. So I've been holding off on switching until `Data.Binary` has had some tuning. There was a regression in the performance of `Data.Binary` from ghc-6.8 to 6.10 which is perhaps what you're thinking of. Prior to that it was several times faster (10x at the time of the binary-0.4 release) than `NewBinary` which I believe was basically ghc's binary implementation extracted into a standalone library. Don looked at the performance regression so is best placed to say if the latest release brings performance back up to what it was with 6.8. `NewBinary` is somewhat slower than GHC's binary library, IIRC, because it added support for using a more compact serialisation format based on bits rather than bytes. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3041#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3069: misspelled word in description of syntax extensions: s/enerated/enumerated/
#3069: misspelled word in description of syntax extensions: s/enerated/enumerated/ -+-- Reporter: nr|Owner: igloo Type: merge | Status: closed Priority: normal|Milestone: Component: Documentation | Version: 6.11 Severity: trivial | Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3069#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3068: broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html
#3068: broken link in http://www.haskell.org/ghc/docs/latest/html/users_guide /special-ids.html -+-- Reporter: nr|Owner: igloo Type: bug | Status: closed Priority: normal|Milestone: Component: Documentation | Version: 6.11 Severity: minor | Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Fixed in HEAD and 6.10. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3068#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3066: Crash with bogus FFI declaration
#3066: Crash with bogus FFI declaration --+- Reporter: simonpj|Owner: simonpj Type: bug| Status: closed Priority: high |Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: ffi/should_fail/T3066 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --+- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Both merged, as well as {{{ Thu Mar 5 01:09:35 PST 2009 simo...@microsoft.com * Finally fix Trac #3066 Ignore-this: 8734c1799f854d9da6be76a9c134335e This is a fix to Tue Mar 3 17:42:58 GMT 2009 simo...@microsoft.com * Fix Trac #3066: checking argument types in foreign calls which I embarassingly got wrong. Have to be careful when expanding recursive newtypes. Pls merge. }}} Oh, the perils of putting The fix is easy. in a commit message! :-) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3066#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3025: Possible PiDigits memory explosion regression
#3025: Possible PiDigits memory explosion regression -+-- Reporter: japple|Owner: igloo Type: bug | Status: closed Priority: high |Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Looks fixed in the 6.10 branch. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3025#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3004: Makefile needs to improve treatment of HsColour
#3004: Makefile needs to improve treatment of HsColour -+-- Reporter: nr|Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * difficulty: = Unknown * resolution: = fixed Comment: OK, HsColour should now be required by the buildbots, and when validating, but not for normal builds: {{{ Thu Mar 5 13:27:23 GMT 2009 Ian Lynagh ig...@earth.li * By default, only HsColour the docs if we find HsColour. Fixes trac #3004. If you manually set HSCOLOUR_SRCS=YES then the build will fail if HsColour wasn't found. }}} (in HEAD and 6.10) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3004#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2983: Segmentation fault in ray tracer with certain options
#2983: Segmentation fault in ray tracer with certain options --+- Reporter: thoughtpolice |Owner: igloo Type: bug| Status: closed Priority: high |Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: seg fault, ray tracer | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86| --+- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: As Simon M pointed out, the #2917 fix won't fix this after all. I've now made gcc not generate SSE instructions in both HEAD and 6.10, which fixes the bug: {{{ Thu Mar 5 14:20:50 GMT 2009 Ian Lynagh ig...@earth.li * On OS X/x86, tell gcc to generate instructions for i686. Fixes trac #2983. By default, gcc on OS X will generate SSE instructions, which need things 16-byte aligned, but we don't 16-byte align things. Thus drop back to generic i686 compatibility. }}} -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2983#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2615: ghci doesn't play nice with linker scripts
#2615: ghci doesn't play nice with linker scripts -+-- Reporter: AlecBerryman |Owner: Type: bug | Status: new Priority: normal|Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: Unknown/Multiple | -+-- Changes (by igloo): * owner: igloo = -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2615#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2670: Record selectors behaving badly wrt optimisation
#2670: Record selectors behaving badly wrt optimisation -+-- Reporter: simonmar |Owner: igloo Type: bug | Status: closed Priority: normal|Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: We decided that a test is too hard, so closing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2670#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2757: runghc doesn't respond to --help / --version
#2757: runghc doesn't respond to --help / --version -+-- Reporter: simonmar |Owner: igloo Type: bug | Status: closed Priority: normal|Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal| Resolution: fixed Keywords:| Difficulty: Easy (1 hr) Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: reopened = closed * resolution: = fixed Comment: Fixed in HEAD and 6.10: {{{ Thu Mar 5 16:20:45 GMT 2009 Ian Lynagh ig...@earth.li * Add --version to runghc. Trac #2757. We use the GHC version number, as the old runghc one doesn't seem very useful. }}} -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2757#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #3075: validation requires a tool that is not included in utils
#3075: validation requires a tool that is not included in utils ---+ Reporter: nr | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11| Severity: major Keywords: | Testcase: Os: Linux | Architecture: x86 ---+ At present it is not possible to validate without HsColour, but HsColour is not included in utils. To make matters worse, HsColour is not available through Debian, and even cabal, which could be used to install HsColour, is not available through Debian. To require me to install Cabal to install HsColour to validate changes made to GHC's back end is at least one too many levels of indirection. (I routinely build GHC on three different computers, and a fourth is not unheard of, so if the installation isn't easily supported by my existing Linux distros, I want no part of it.) I'd like the validate/build process changed to reach one of two outcomes: 1. It becomes permissible to validate without HsColour, and this happens by default and automatically on systems where HsColour is not present. 1. HsColour is included in utils, and the validate script automatically finds it there and builds it at need. P.S. I am quite grateful for the earlier work that enables me to build the compiler without HsColour. But I also want to be able to contribute changes. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3075 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Deep fmap with GADTs and type families.
Greetings, Someone on comp.lang.functional was asking how to map through arbitrary nestings of lists, so I thought I'd demonstrate how his non-working ML function could actually be typed in GHC, like so: --- snip --- {-# LANGUAGE TypeFamilies, GADTs, EmptyDataDecls, Rank2Types, ScopedTypeVariables #-} data Z data S n data Nat n where Z :: Nat Z S :: Nat n - Nat (S n) type family Nest n (f :: * - *) a :: * type instance Nest Z f a = f a type instance Nest (S n) f a = f (Nest n f a) deepMap :: Nat n - (a - b) - Nest n [] a - Nest n [] b deepMap Z f = map f deepMap (S n) f = map (deepMap n f) --- snip --- This works. However, the straight forward generalisation doesn't: --- snip --- deepFMap :: Functor f = Nat n - (a - b) - Nest n f a - Nest n f b deepFMap Z f = fmap f deepFMap (S n) f = fmap (deepFMap n f) --- snip --- This fails with a couple errors like: Map.hs:25:19: Couldn't match expected type `Nest n1 f b' against inferred type `Nest n1 f1 b' In the expression: fmap (deepFMap n f) In the definition of `deepFMap': deepFMap (S n) f = fmap (deepFMap n f) for reasons I don't really understand. So I tried the following: --- snip --- newtype FuntorD f = F { fdmap :: forall a b. (a - b) - f a - f b } deepFDMap :: FunctorD f - Nat n - (a - b) - Nest n f a - Nest n f b deepFDMap d Z f = fdmap d f deepFDMap d (S n) f = fdmap d (deepFDMap d n f) --- snip --- This works, but to my surprise deepFMap = deepFDMap (F fmap) gives the exact same error as above. Bringing my situation to #haskell, two solutions were found: --- snip --- deepFMap :: forall n f a b. Functor f = Nat n - (a - b) - Nest n f a - Nest n f b deepFMap = deepFDMap (F fmap :: FunctorD f) data Proxy (f :: * - *) = Proxy deepFMap' :: Functor f = Proxy f - Nat n - (a - b) - Nest n f a - Nest n f b deepFMap' _ Z f = fmap f deepFMap' p (S n) f = fmap (deepFMap p n f) --- snip --- But we've so far not been able to find a way of merely annotating the original into working. So, I was wondering if any of the more knowledgeable folks here could illuminate what's going wrong here, and whether I should expect my original code to work or not. Thanks in advance. -- Dan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Deep fmap with GADTs and type families.
David Menendez: On Thu, Mar 5, 2009 at 10:07 PM, Dan Doel dan.d...@gmail.com wrote: But we've so far not been able to find a way of merely annotating the original into working. So, I was wondering if any of the more knowledgeable folks here could illuminate what's going wrong here, and whether I should expect my original code to work or not. I'll bet the problem has to do with the fact that f only appears in Nest n f a, so the type checker can't figure out what f is. Exactly. In other words, the signature is ambiguous. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Lazy IO breaks purity
I don't see any breaking of referential transparence in your code. Every time you do an IO operation the result is basically non-deterministic since you are talking to the outside world. You're assuming the IO has some kind of semantics that Haskell makes no promises about. I'm not saying that this isn't a problem, because it is. But it doesn't break referential transparency, it just makes the semantics of IO even more complicated. (I don't have a formal proof that unsafeInterleaveIO cannot break RT, but I've not seen an example where it does yet.) -- Lennart On Thu, Mar 5, 2009 at 2:12 AM, o...@okmij.org wrote: We demonstrate how lazy IO breaks referential transparency. A pure function of the type Int-Int-Int gives different integers depending on the order of evaluation of its arguments. Our Haskell98 code uses nothing but the standard input. We conclude that extolling the purity of Haskell and advertising lazy IO is inconsistent. Henning Thielemann wrote on Haskell-Cafe: Say I have a chain of functions: read a file, ... write that to a file, all of these functions are written in a lazy way, which is currently considered good style Lazy IO should not be considered good style. One of the common definitions of purity is that pure expressions should evaluate to the same results regardless of evaluation order, or that equals can be substituted for equals. If an expression of the type Int evaluates to 1, we should be able to replace every occurrence of the expression with 1 without changing the results and other observables. The expression (read s) where s is the result of the (hGetContents h1) action has the pure type, e.g., Int. Yet its evaluation does more than just producing an integer: it may also close a file associated with the handle h1. Closing the file has an observable effect: the file descriptor, which is a scarce resource, is freed. Some OS lock the open file, or prevent operations such as renaming and deletion on the open file. A file system whose file is open cannot be unmounted. Suppose I use an Haskell application such as an editor to process data from a removable drive. I mount the drive, tell the application the file name. The (still running) application finished with the file and displayed the result. And yet I can't unplug the removable drive, because it turns out that the final result was produced without needing to read all the data from the file, and the file remains unclosed. Some people say: the programmer should have used seq. That is the admission of guilt! An expression (read s)::Int that evaluates to 1 is equal to 1. So, one should be able substitute (read s) with 1. If the result of evaluating 1 turns out not needed for the final outcome, then not evaluating (read s) should not affect the outcome. And yet it does. One uses seq to force evaluation of an expression even if the result may be unused. Thus the expression of a pure type has *side-effect*. The advice about using seq reminds me of advice given to C programmers that they should not free a malloc'ed pointer twice, dereference a zero pointer and write past the boundary of an array. If lazy IO is considered good style given the proper use of seq, then C should be considered safe given the proper use of pointers and arrays. Side affects like closing a file are observable in the external world. A program may observe these effects, in an IO monad. One can argue there are no guarantees at all about what happens in the IO monad. Can side-effects of lazy IO be observable in _pure_ Haskell code, in functions with pure type? Yes, they can. The examples are depressingly easy to write, once one realizes that reading does have side effects, POSIX provides for file descriptor aliasing, and sharing becomes observable with side effects. Here is a simple Haskell98 code. {- Haskell98! -} module Main where import System.IO import System.Posix.IO (fdToHandle, stdInput) -- f1 and f2 are both pure functions, with the pure type. -- Both compute the result of the subtraction e1 - e2. -- The only difference between them is the sequence of -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 -- For really pure functions, that difference should not be observable f1, f2:: Int - Int - Int f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 read_int s = read . head . words $ s main = do let h1 = stdin h2 - fdToHandle stdInput s1 - hGetContents h1 s2 - hGetContents h2 print $ f1 (read_int s1) (read_int s2) -- print $ f2 (read_int s1) (read_int s2) One can compile it with GHC (I used 6.8.2, with and without -O2) and run like this ~ /tmp/a.out 1 2 -1 That is, we run the program and type 1 and 2 as the inputs. The program prints out the result, -1. If we comment out the line print $ f1 (read_int s1) (read_int s2) and uncomment out the last line the transcript looks like
Re: [Haskell] ANN: pandoc 1.2
On Mar 1, 2009, at 8:21 PM, John MacFarlane wrote: I'm pleased to announce the release of pandoc version 1.2 (uploaded today to HackageDB). The most significant new feature is support for literate Haskell. That is a very useful feature. It let's us mash-up pandoc and lhs2TeX to create nicely formatted PDFs from literate Haskell formatted as markdown: pandoc --to=latex+lhs --custom-header=header.tex program.lhs |\ lhs2TeX --output=program pdflatex program The file header.tex must contain an appropriate document style and the line %include lhs2TeX.fmt A slight drawback is that code written indented or between ~~~ (and hence not meant to be executed) is converted to a `verbatim` environment. As a consequence, lhs2TeX does not use the same formatting as in code blocks. To fix this we can insert this in the pipe: sed s/\\begin{verbatim}/\\begin{spec}/ |\ sed s/\\end{verbatim}/\\end{spec}/ but of course this is hack, that does not work, if we want to write the replaced strings somewhere in our document.. Unfortunately, I did not manage to use the citeproc extension to get references in the text and a bibliography at the end of the latex file, thus need to resort to \cite{...} in the source code and bibtex. Nevertheless, a very useful tool! Cheers, Sebastian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Definitions of purity and Lazy IO
As Amr Sabry aptly observed more than a decade ago discussions of purity and referential transparency usually lead to confusion and disagreement. His JFP paper provided the needed rigor and argued that Haskell even _with regular file (stream) IO_ is pure. As was shown yesterday, with Lazy IO, Haskell is not pure. Before we discuss definitions, let us note the motivations. Suppose I have a Haskell program. As every single (compiled) Haskell program it has the main function, of the type IO a for some a. It must use IO, at least to print the final result, the observation of the program. Suppose the program contains the expression e1 + e2 adding two integer expressions. Can I replace this expression with e2 + e1 and be sure the observations of my program are unaffected? If one says that ``you should assume that every IO operation returns a random result'' then we have no ability to reason about any real Haskell program. We can't be sure of soundness of any compiler optimization. So, Haskell is far worse than C!? With C, Xavier Leroy has managed to create a provably correct optimizing compiler, and mechanically _prove_ the soundness of all optimizations. A C program, just like a Haskell program, must use IO at least to print the final result. We can never hope to build a provably correct compiler for Haskell? We cannot prove observational equivalences of any real Haskell program? Isn't that sad? The formal question is thus: are the following two expressions f1 and f2, of a *pure type* Int-Int-Int f1, f2:: Int - Int - Int f1 = \e1 e2 - case (e1,e2) of (1,_) - e1 - e2 (_,_) - e1 - e2 f2 = \e1 e2 - case (e1,e2) of (_,1) - e1 - e2 (_,_) - e1 - e2 equal? Before one invokes an equational theory or says that both these expressions are just integer subtraction, let me clarify the question: are f1 and f2 at least weakly observationally equivalent? That is, for any program context C[] such that C[f1] is well-typed, the program C[f2] must too be well-typed, and if one can observe the result of C[f1] and of C[f2], the two observations must be identical. The observation of a program may (and often does) involve side-effects and IO (more on it below). The message posted yesterday exhibited a context C[] that distinguishes f1 from f2. Thus, in presence of Lazy IO, any equational theory that equates f1 and f2 cannot be sound. I don't think one can design such a context C[] using the regular, eager file IO. Amr Sabry in a paper ``What is a Purely Functional Language?'' J. Functional Programming, 8(1), 1-22, Jan. 1998. http://www.cs.indiana.edu/~sabry/papers/purelyFunctional.ps proposed the definition of purity, see p 2 and Definition 4.7. The definition essentially states that call-by-name, call-by-value and call-by-need evaluation functions must be weakly equivalent. These evaluation functions map programs to observables. The part of evaluation dealing with observing the answers may have side effects! Sec 5.1 rigorously shows that lambda-calculus with global state and destructive mutation may be called pure functional, if effects are regarded as values and the program is written in what we now call a monadic style (whose idea was proposed by Reynolds back in 1981 when studying Idealized Algol). The end of Sec 5.1 remarks that IO can be treated that way -- and in fact, Appendix D of Haskell report 1.2 indeed had described such a semantics of IO: http://haskell.org/definition/haskell-report-1.2.ps.gz (the appendix starts on p. 139). Thanks to Paul Hudak for pointing this out three years ago. Thus Haskell even with IO may be called pure functional. With Lazy IO, it can no longer be called pure functional as different orders of evaluation of arguments of a function lead to different program observations. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Definitions of purity and Lazy IO
On Thu, 2009-03-05 at 20:11 -0800, o...@okmij.org wrote: As Amr Sabry aptly observed more than a decade ago discussions of purity and referential transparency usually lead to confusion and disagreement. His JFP paper provided the needed rigor and argued that Haskell even _with regular file (stream) IO_ is pure. As was shown yesterday, with Lazy IO, Haskell is not pure. Before we discuss definitions, let us note the motivations. Suppose I have a Haskell program. As every single (compiled) Haskell program it has the main function, of the type IO a for some a. It must use IO, at least to print the final result, the observation of the program. Suppose the program contains the expression e1 + e2 adding two integer expressions. Can I replace this expression with e2 + e1 and be sure the observations of my program are unaffected? If one says that ``you should assume that every IO operation returns a random result'' then we have no ability to reason about any real Haskell. I think that `real' is a poor term to use in this context. In any case, we don't really need to assert that *any* IO action is non-deterministic; we just have to assert that: a) The result returned by unsafeInterleaveIO is non-deterministic, and b) The point in the execution thread when the side effects performed by unsafeInterleaveIO are inserted is non-deterministic. As for the first claim: we have *stronger* guarantees for unsafeInterleaveIO than for getStdRandom. As for the second claim: we have *stronger* guarantees for unsafeInterleavIO than for forkIO. I don't think it removes all possibility of reasoning about Haskell programs to say these things. You might want to stop hyper-ventilating. We can't be sure of soundness of any compiler optimization. Nope. *You* claim, without proof, that re-writing x `seq` y `seq` x - y to y `seq` x `seq` x - y is an un-sound optimization, for Haskell. *We* claim it is perfectly sound. Who is denying the soundness of Haskell optimization again? So, Haskell is far worse than C!? With C, Xavier Leroy has managed to create a provably correct optimizing compiler, and mechanically _prove_ the soundness of all optimizations. And plenty of C programs have situations where the relative ordering of side effects is undefined. In fact, quite a few syntactically valid, well-typed, conforming C programs are declared `undefined' (and hence not *strictly* conforming) by the standard, because their meaning depends on the order of evaluation beyond the degree to which it is well-defined. So C is hardly `far [better]' than Haskell in this regard! A C program, just like a Haskell program, must use IO at least to print the final result. We can never hope to build a provably correct compiler for Haskell? We cannot prove observational equivalences of any real Haskell program? Isn't that sad? The formal question is thus: are the following two expressions f1 and f2, of a *pure type* Int-Int-Int f1, f2:: Int - Int - Int f1 = \e1 e2 - case (e1,e2) of (1,_) - e1 - e2 (_,_) - e1 - e2 f2 = \e1 e2 - case (e1,e2) of (_,1) - e1 - e2 (_,_) - e1 - e2 equal? Before one invokes an equational theory or says that both these expressions are just integer subtraction, let me clarify the question: are f1 and f2 at least weakly observationally equivalent? How weak? That is, for any program context C[] such that C[f1] is well-typed, the program C[f2] must too be well-typed, and if one can observe the result of C[f1] and of C[f2], the two observations must be identical. Every time? For every context? What about the context do x - getStdRandom random y - getStdRandom random print $ [] x y ? By the standard above, f1 is not even observationally equivalent to *itself*. The observation of a program may (and often does) involve side-effects and IO (more on it below). The message posted yesterday exhibited a context C[] that distinguishes f1 from f2. Thus, in presence of Lazy IO, any equational theory that equates f1 and f2 cannot be sound. I don't think one can design such a context C[] using the regular, eager file IO. Amr Sabry in a paper ``What is a Purely Functional Language?'' J. Functional Programming, 8(1), 1-22, Jan. 1998. http://www.cs.indiana.edu/~sabry/papers/purelyFunctional.ps proposed the definition of purity, see p 2 and Definition 4.7. The definition essentially states that call-by-name, call-by-value and call-by-need evaluation functions must be weakly equivalent. How weakly? (False undefined) gives different answers under call-by-name and call-by-value, but I don't think calling Haskell `unpure' because it exists is useful. These evaluation functions map programs to observables. The part of evaluation dealing with observing the answers may have side effects! Sec 5.1 rigorously shows that lambda-calculus with global state
[Haskell] (fwd) Haskell Career Opportunity
James Wood, Senior Consultant of The Kaizen Partnership, has posted the following message on fa.haskell about a Haskell career opportunity, so I am forwarding it to here for your information: On Thu, 5 Mar 2009 07:00:57 -0800 (PST), in fa.haskell James Wood woo...@gmail.com wrote: Dear All I am a headhunter with a focus on tech developers predominantly in the finance sector. Part of my focus is functional programmers especially in Haskell, OCaml, F#. I am not sure if I am allowed to post this here but I figured it might be relevant to some of you and so took a chance. I'm currently working on a role for an Investment Bank which has emerged unscathed from the economic turmoil and is actively looking for highly advanced Haskell programmers. Ideally candidates will have a MSc or PhD in Computer Science or Mathematics and will be very comfortable programming in Haskell. The team is part of the front- office quant analytics group and is using functional programming in novel ways to solve some interesting problems both in both technology and risk modelling. They are looking to add several more key hires over the year. Finance experience is not necessary but can be advantageous. Location can be flexible. There are only a few banks who have seriously invested in functional programming and actually incorporate it as part of their infrastructure. If anyone is interested in discussing this with me feel free to give me a ring or email my work email, jw...@kaizenpartnership.co.uk Thanks James James Wood Senior Consultant The Kaizen Partnership +44 (0) 20 7710 0280 -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: Zippers
On 3/5/09, Ryan Ingram ryani.s...@gmail.com wrote: ... Here is the problem with your update: tree = Fork (Leaf 1) (Leaf 2) ztree = initZ tree test = fromJust $ do z1 - moveLeft ztree let z2 = update z1 3 z3 - moveUp z2 z4 - moveLeft z3 this z4 I'd expect test to equal 3, but I believe with your code that it still equals 1. As apfelmus said, update needs to completely re-construct the zipper structure with the tied knot, which defeats the purpose of using a zipper in the first place. I got it. I dont't know what your expression tied knot is referring to but I got the point. Thanks. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help optimizing memory usage for a program
Don Stewart ha scritto: manlio_perillo: Hi. After some work I have managed to implement two simple programs that parse the Netflix Prize data set. For details about the Netflix Prize, there was a post by Kenneth Hoste some time ago. I have cabalized the program, and made available here: http://haskell.mperillo.ath.cx/netflix-0.0.1.tar.gz [...] Seems like a useful benchmark of a number of things. Any chance you'll upload it to hackage? Not the package as it is now. And I first need to write a program that generates a reasonable data set. But, yes, I will upload it to hackage, if it can be useful. What name should I use? How should I categorize it? Regards Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Zippers
Cristiano Paris wrote: Ryan Ingram wrote: ... Here is the problem with your update: tree = Fork (Leaf 1) (Leaf 2) ztree = initZ tree test = fromJust $ do z1 - moveLeft ztree let z2 = update z1 3 z3 - moveUp z2 z4 - moveLeft z3 this z4 I'd expect test to equal 3, but I believe with your code that it still equals 1. As apfelmus said, update needs to completely re-construct the zipper structure with the tied knot, which defeats the purpose of using a zipper in the first place. I got it. I dont't know what your expression tied knot is referring to but I got the point. In doInitZ , you're basically using the s itself to define the moveLeft and moveRight fields of s . You could as well write it as initZ t = doInitZ Nothing t where doInitZ c (Leaf a) = ZContext c Nothing Nothing $ Just a doInitZ c t@(Fork l r) = s where s = ZContext c (Just $ doInitZ (Just s) l) (Just $ doInitZ (Just s) r) Nothing Such self-reference is usually called tying the knot, see also http://www.haskell.org/haskellwiki/Tying_the_Knot Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monadic MapReduce
Anish Muttreja ha scritto: [...] How about this. Is there a reason why I can't replace the variables b and c in the type signature of mapReduce with with (IO b') and (IO c'). b and c can be any types. mapReduce :: Strategy (IO b')-- evaluation strategy for mapping - (a - IO b') -- map function - Strategy (IO c')-- evaluation strategy for reduction - ([IO b'] - (IO c'))-- reduce function - [a] -- list to map over - (IO c') Just remember to wrap all values back in the IO monad. The other day I found, with google, a definizion of mapReduce, that make use of forkIO to execute piece of IO actions on separate threads. I can't find it anymore... Anish Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Zippers
On Thu, Mar 5, 2009 at 11:21 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: ... Such self-reference is usually called tying the knot, see also http://www.haskell.org/haskellwiki/Tying_the_Knot I didn't know. Would you call this Tying the knot as well? http://yi-editor.blogspot.com/2008/12/prototypes-encoding-oo-style.html Thank you. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3
Bulat Ziganshin ha scritto: Hello Manlio, Tuesday, March 3, 2009, 5:35:33 PM, you wrote: There are 100,000,000 ratings, so I create 100,000,000 arrays containing only one element. every array needs ~30 bytes - it's a minimal memory block ghc can alloc for variable-sized objects. multiple this by 3 to account for copying GC behavior Ok, this explains memory usage; thanks. IMHO, this informations should go in the wiki; they may be insignificant for normal applications, but when one starts to deal with huge amount of data, 10 bytes per item make an important difference. Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make a dock window for xmonad using gtk2hs?
On Thursday 05 March 2009 09:45:51 Magicloud Magiclouds wrote: I am confused. Code like this works in other WM, except xmonad. You code does not set _NET_WM_STRUT property. And because of that xmonad doesn't treat it specifically. You can inspect you window properties using `xprop' utility. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary stack overflow with Data.Sequence String
Hi Gwern, I get String/Data.Binary issues too. My suggestion would be to change your strings to ByteString's, serisalise, and then do the reverse conversion when reading. Interestingly, a String and a ByteString have identical Data.Binary reps, but in my experiments converting, including the cost of BS.unpack, makes the reading substantially cheaper. Thanks Neil On Thu, Mar 5, 2009 at 2:33 AM, Gwern Branwen gwe...@gmail.com wrote: On Tue, Mar 3, 2009 at 11:50 PM, Spencer Janssen spencerjans...@gmail.com wrote: On Tue, Mar 3, 2009 at 10:30 PM, Gwern Branwen gwe...@gmail.com wrote: So recently I've been having issues with Data.Binary Data.Sequence; I serialize a 'Seq String' You can see the file here: http://code.haskell.org/yi/Yi/IReader.hs The relevant function seems to be: -- | Read in database from 'dbLocation' and then parse it into an 'ArticleDB'. readDB :: YiM ArticleDB readDB = io $ (dbLocation = r) `catch` (\_ - return empty) where r x = fmap (decode . BL.fromChunks . return) $ B.readFile x -- We read in with strict bytestrings to guarantee the file is closed, -- and then we convert it to the lazy bytestring data.binary expects. -- This is inefficient, but alas... My current serialized file is about 9.4M. I originally thought that the issue might be the recent upgrade in Yi to binary 0.5, but I unpulled patches back to past that, and the problem still manifested. Whenever yi tries to read the articles.db file, it stack overflows. It actually stack-overflowed on even smaller files, but I managed to bump the size upwards, it seems, by the strict-Bytestring trick. Unfortunately, my personal file has since passed whatever that limit was. I've read carefully the previous threads on Data.Binary and Data.Map stack-overflows, but none of them seem to help; hacking some $!s or seqs into readDB seems to make no difference, and Seq is supposed to be a strict datastructure already! Doing things in GHCi has been tedious, and hasn't enlightened me much: sometimes things overflow and sometimes they don't. It's all very frustrating and I'm seriously considering going back to using the original read/show code unless anyone knows how to fix this - that approach may be many times slower, but I know it will work. -- gwern Have you tried the darcs version of binary? It has a new instance which looks more efficient than the old. Cheers, Spencer Janssen I have. It still stack-overflows on my 9.8 meg file. (The magic number seems to be somewhere between 9 and 10 megabytes.) -- gwern ___ 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] Re: Theory about uncurried functions
Ha. There's even a wiki page on the paradoxes of set theory http://en.wikipedia.org/wiki/Paradoxes_of_set_theory If I recall correctly, a math professor once told me that it is not yet proven if the cardinality of the power set of the natural numbers is larger or smaller or equal than the cardinality of the real numbers... But that is many many years ago so don't shoot me if I'm wrong :) 2009/3/4 Luke Palmer lrpal...@gmail.com On Wed, Mar 4, 2009 at 3:38 PM, Achim Schneider bars...@web.de wrote: There's not much to understand about CT, anyway: It's actually nearly as trivial as set theory. You mean that theory which predicts the existence of infinitely many infinities; in fact for any cardinal, there are at least that many cardinals? That theory in which aleph_1 and 2^aleph_0 are definitely comparable, but we provably cannot compare them? The theory which has omega_0 omega_1 omega_2 ... omega_omega ..., where obviously omega_a is much larger than a... except for when it catches its tail and omega_alpha = alpha for some crazy-ass alpha. I don't think set theory is trivial in the least. I think it is complicated, convoluted, often anti-intuitive and nonconstructive. Category theory is much more trivial, and that's what makes it powerful. (Although training yourself to think categorically is quite difficult, I'm finding) One part of the benefit starts when you begin to categorise different kind of categories, in the same way that understanding monads is easiest if you just consider their difference to applicative functors. It's a system inviting you to tackle a problem with scrutiny, neither tempting you to generalise way beyond computability, nor burdening you with formal proof requirements or shackling you to some other ball and chain. Sadly, almost all texts about CT are absolutely useless: They tend to focus either on pure mathematical abstraction, lacking applicability, or tell you the story for a particular application of CT to a specific topic, loosing themselves in detail without providing the bigger picture. That's why I liked that Rosetta stone paper so much: I still don't understand anything more about physics, but I see how working inside a category with specific features and limitations is the exact right thing to do for those guys, and why you wouldn't want to do a PL that works in the same category. Throwing lambda calculus at a problem that doesn't happen to be a DSL or some other language of some sort is a bad idea. I seem to understand that for some time now, being especially fond of automata[1] to model autonomous, interacting agents, but CT made me grok it. The future will show how far it will pull my thinking out of the Turing tarpit. [1] Which aren't, at all, objects. Finite automata don't go bottom in any case, at least not if you don't happen to shoot them and their health drops below zero. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
Am Donnerstag, 5. März 2009 13:09 schrieb Peter Verswyvelen: Ha. There's even a wiki page on the paradoxes of set theory http://en.wikipedia.org/wiki/Paradoxes_of_set_theory If I recall correctly, a math professor once told me that it is not yet proven if the cardinality of the power set of the natural numbers is larger or smaller or equal than the cardinality of the real numbers... But that is many many years ago so don't shoot me if I'm wrong :) In standard NBG set theory, it is easy to prove that card(P(N)) == card(R). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Finding the Convex Hull (Problem 12 of Real World Haskell)
I wrote a solution to this problem, but it appears to return incorrect results. There's a pastebin of the code at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2121 and a picture of the inputs, outputs, and expected results graphed at http://img510.imageshack.us/img510/9971/resultsg.jpg I'm wondering if this is a flaw in my code, my understanding of the problem, or both. Any ideas on how to track this one down would be very much appreciated. Thank you! -- ヽ(^o^)ノ -rob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
Lennart Augustsson wrote: I don't see any breaking of referential transparence in your code. Every time you do an IO operation the result is basically non-deterministic since you are talking to the outside world. You're assuming the IO has some kind of semantics that Haskell makes no promises about. I'm not saying that this isn't a problem, because it is. But it doesn't break referential transparency, it just makes the semantics of IO even more complicated. (I don't have a formal proof that unsafeInterleaveIO cannot break RT, but I've not seen an example where it does yet.) So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) Cheers, Simon -- Lennart On Thu, Mar 5, 2009 at 2:12 AM, o...@okmij.org wrote: We demonstrate how lazy IO breaks referential transparency. A pure function of the type Int-Int-Int gives different integers depending on the order of evaluation of its arguments. Our Haskell98 code uses nothing but the standard input. We conclude that extolling the purity of Haskell and advertising lazy IO is inconsistent. Henning Thielemann wrote on Haskell-Cafe: Say I have a chain of functions: read a file, ... write that to a file, all of these functions are written in a lazy way, which is currently considered good style Lazy IO should not be considered good style. One of the common definitions of purity is that pure expressions should evaluate to the same results regardless of evaluation order, or that equals can be substituted for equals. If an expression of the type Int evaluates to 1, we should be able to replace every occurrence of the expression with 1 without changing the results and other observables. The expression (read s) where s is the result of the (hGetContents h1) action has the pure type, e.g., Int. Yet its evaluation does more than just producing an integer: it may also close a file associated with the handle h1. Closing the file has an observable effect: the file descriptor, which is a scarce resource, is freed. Some OS lock the open file, or prevent operations such as renaming and deletion on the open file. A file system whose file is open cannot be unmounted. Suppose I use an Haskell application such as an editor to process data from a removable drive. I mount the drive, tell the application the file name. The (still running) application finished with the file and displayed the result. And yet I can't unplug the removable drive, because it turns out that the final result was produced without needing to read all the data from the file, and the file remains unclosed. Some people say: the programmer should have used seq. That is the admission of guilt! An expression (read s)::Int that evaluates to 1 is equal to 1. So, one should be able substitute (read s) with 1. If the result of evaluating 1 turns out not needed for the final outcome, then not evaluating (read s) should not affect the outcome. And yet it does. One uses seq to force evaluation of an expression even if the result may be unused. Thus the expression of a pure type has *side-effect*. The advice about using seq reminds me of advice given to C programmers that they should not free a malloc'ed pointer twice, dereference a zero pointer and write past the boundary of an array. If lazy IO is considered good style given the proper use of seq, then C should be considered safe given the proper use of pointers and arrays. Side affects like closing a file are observable in the external world. A program may observe these effects, in an IO monad. One can argue there are no guarantees at all about what happens in the IO monad. Can side-effects of lazy IO be observable in _pure_ Haskell code, in functions with pure type? Yes, they can. The examples are depressingly easy to write, once one realizes that reading does have side effects, POSIX provides for file descriptor aliasing, and sharing becomes observable with side effects. Here is a simple Haskell98 code. {- Haskell98! -} module Main where import System.IO import System.Posix.IO (fdToHandle, stdInput) -- f1 and f2 are both pure functions, with the pure type. -- Both compute the result of the subtraction e1 - e2. -- The only difference between them is the sequence of -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 -- For really pure functions, that difference should not be observable f1, f2:: Int - Int - Int f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 read_int s = read . head . words $ s main = do let h1 = stdin h2 - fdToHandle stdInput s1 - hGetContents h1 s2 - hGetContents h2 print $ f1 (read_int s1) (read_int s2) -- print $ f2 (read_int
Re: [Haskell-cafe] How to make a dock window for xmonad using gtk2hs?
On Wed, Mar 04, 2009 at 10:59:53PM -0500, Brandon S. Allbery KF8NH wrote: On 2009 Mar 4, at 21:40, Magicloud Magiclouds wrote: Could someone give me a sample or something I could learn from? Thanks. (xmobar is open source, you could look through its source) xmobar is not open source. xmobar is FREE software! here's the relevant bits (from Xmobar.hs) setProperties :: Rectangle - Config - Display - Window - [Rectangle] - IO () setProperties r c d w srs = do a1 - internAtom d _NET_WM_STRUT_PARTIALFalse c1 - internAtom d CARDINAL False a2 - internAtom d _NET_WM_WINDOW_TYPE False c2 - internAtom d ATOM False v - internAtom d _NET_WM_WINDOW_TYPE_DOCK False changeProperty32 d w a1 c1 propModeReplace $ map fi $ getStrutValues r (position c) (getRootWindowHeight srs) changeProperty32 d w a2 c2 propModeReplace [fromIntegral v] hope this helps. Best, Andrea ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding the Convex Hull (Problem 12 of Real World Haskell)
Whenever I'm looking for a bug in Haskell code, I find it helpful to start by seeing if I can simplify the code any first. In this case, there are a couple of things I notice: - validPointsOf is just a filter. It would be easier to write valid :: MyDirection - Bool and then validPointsOf = filter (valid . snd) - Similarly, there's no need to write your own minimum-finder and call it lowestY. Instead, write (or derive!) an Ord instance, and then use the standard prelude function minimum - a small simplification of sortByCoTan: sortByCoTan pivot = sortBy (comparing (coTan pivot)) Hope this helps! 2009/3/5 Rob Crowther weila...@gmail.com I wrote a solution to this problem, but it appears to return incorrect results. There's a pastebin of the code at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2121 and a picture of the inputs, outputs, and expected results graphed at http://img510.imageshack.us/img510/9971/resultsg.jpg I'm wondering if this is a flaw in my code, my understanding of the problem, or both. Any ideas on how to track this one down would be very much appreciated. Thank you! -- ヽ(^o^)ノ -rob ___ 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] Re: Theory about uncurried functions
On 5 Mar 2009, at 13:29, Daniel Fischer wrote: In standard NBG set theory, it is easy to prove that card(P(N)) == card(R). No, it is an axiom: Cohen showed in 1963 (mentioned in Mendelson, Introduction to Mathematical Logic) that the continuum hypothesis (CH) is independent of NBG+(AC)+(Axiom of Restriction), where AC is the axiom of choice. Thus you can assume CH or its negation (which is intuitively somewhat strange). AC is independent of NGB, so you can assume it or its negation (also intuitively strange), though GHC (generalized CH, for any cardinality) + NBG implies AC (result by Sierpinski 1947 and Specker 1954). GHC says that for any set x, there are no cardinalities between card x and card 2^x (the power-set cardinality). Since card ω card R by Cantors diagonal method, and card R = card 2^ω since R can be constructed out of binary sequences (and since the interval [0, 1] and R can be shown having the same cardinalities), GHC implies card R = card 2^ω. (Here, ω is a lower case omega, denoting the first infinite ordinal.) Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding the Convex Hull (Problem 12 of Real World Haskell)
Am Donnerstag, 5. März 2009 13:40 schrieb Rob Crowther: I wrote a solution to this problem, but it appears to return incorrect results. There's a pastebin of the code at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2121 and a picture of the inputs, outputs, and expected results graphed at http://img510.imageshack.us/img510/9971/resultsg.jpg I'm wondering if this is a flaw in my code, my understanding of the problem, or both. Definitely flawed code, probably based on incorrect understanding of the algorithm. Any ideas on how to track this one down would be very much appreciated. To track it down, it would be helpful to look at the intermediate results and see where they differ in what way from your expectations. *ConvexHull let pointlist :: [Point2D]; pointlist = [(0,0), (2,0), (4,0), (6,0), (5,-2), (5,2), (0,4), (6,4), (5,6)] *ConvexHull lowestY pointlist (5.0,-2.0) *ConvexHull sortByCoTan it pointlist [(0.0,0.0),(2.0,0.0),(0.0,4.0),(4.0,0.0),(5.0,2.0),(5.0,6.0),(6.0,4.0),(5.0,-2.0),(6.0,0.0)] *ConvexHull let sortedpoints = it *ConvexHull listOfTurns sortedpoints [MyRight,MyLeft,MyRight,MyRight,MyLeft,MyLeft,MyRight] *ConvexHull zip sortedpoints (MyStraight:MyStraight:it) [((0.0,0.0),MyStraight),((2.0,0.0),MyStraight),((0.0,4.0),MyRight),((4.0,0.0),MyLeft),((5.0,2.0),MyRight),((5.0,6.0),MyRight),((6.0,4.0),MyLeft),((5.0,-2.0),MyLeft),((6.0,0.0),MyRight)] *ConvexHull validPointsOf it Thank you! *ConvexHull let ly = lowestY pointlist *ConvexHull coTan ly ly NaN First, you'd want to separate the point with lowest y-coordinate from the rest, like lowestY :: [Point2D] - (Point2D,[Point2D]) lowestY (x:xs) = foldr update (x,[]) xs where update a (b,cs) = -- left as an exercise Then it might be a good idea to make sortByCoTan insensitive to other points with the same lowest y-coordinate, and of course, sort only the points other than the starting point. Also, the way the points are sorted, you'll walk clockwise around the boundary, so you'd never turn left, only proceed straight or turn right. But the turn at each point does not depend on its neighbours in the list sorted by cotangent, but on which points have so far been chosen, so you have to compute the turn based on that. The selection of points is considerably more complicated than just looking at the turn, consider e.g. [(0,0), (-2,2), (-2,3),(-1,3),(0,4),(1,4),(2,6),(3,9)]. When you have three points a, b and c, and you go from a via b to c, the turn at b is right, iff crossProduct a b c 0 left, iff crossProduct a b c 0. HTH, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
Am Donnerstag, 5. März 2009 14:58 schrieb Hans Aberg: On 5 Mar 2009, at 13:29, Daniel Fischer wrote: In standard NBG set theory, it is easy to prove that card(P(N)) == card(R). No, it is an axiom: Cohen showed in 1963 (mentioned in Mendelson, Introduction to Mathematical Logic) that the continuum hypothesis (CH) is independent of NBG+(AC)+(Axiom of Restriction), where AC is the axiom of choice. Yes, but the continuum hypothesis is 2^Aleph_0 == Aleph_1, which is quite something different from 2^Aleph_0 == card(R). You can show the latter easily with the Cantor-Bernstein theorem, independent of CH or AC. Thus you can assume CH or its negation (which is intuitively somewhat strange). AC is independent of NGB, so you can assume it or its negation (also intuitively strange), though GHC (generalized CH, for any cardinality) + NBG implies AC (result by Sierpinski 1947 and Specker 1954). GHC says that for any set x, there are no cardinalities between card x and card 2^x (the power-set cardinality). Since card ω card R by Cantors diagonal method, and card R = card 2^ω since R can be constructed out of binary sequences (and since the interval [0, 1] and R can be shown having the same cardinalities), GHC implies card R = card 2^ω. (Here, ω is a lower case omega, denoting the first infinite ordinal.) Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
2009/3/5 Hans Aberg hab...@math.su.se: GHC says that for any set x, there are no cardinalities between card x and No it doesn't. It says there is a syntax error in my code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
Am Donnerstag, 5. März 2009 15:12 schrieb Daniel Fischer: Yes, but the continuum hypothesis is 2^Aleph_0 == Aleph_1, which is quite something different from 2^Aleph_0 == card(R). You can show the latter easily with the Cantor-Bernstein theorem, independent of CH or AC. Just to flesh this up a bit: let f : P(N) - R be given by f(M) = sum [2*3^(-k) | k - M ] f is easily seen to be injective. define g : (0,1) - P(N) by let x = sum [a_k*2^(-k) | k in N (\{0}), a_k in {0,1}, infinitely many a_k = 1] and then g(x) = {k | a_k = 1} again clearly g is an injection. Now the Cantor-Bernstein theorem asserts there is a bijection between the two sets. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
On 5 Mar 2009, at 15:12, Daniel Fischer wrote: No, it is an axiom: Cohen showed in 1963 (mentioned in Mendelson, Introduction to Mathematical Logic) that the continuum hypothesis (CH) is independent of NBG+(AC)+(Axiom of Restriction), where AC is the axiom of choice. Yes, but the continuum hypothesis is 2^Aleph_0 == Aleph_1, which is quite something different from 2^Aleph_0 == card(R). Yes, right, card R = 2^Aleph_0, as you said, and Aleph_1 is defined as the smallest cardinal greater than Aleph_0. Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] missing support to Data.Binary for uvector package
Hi. I'm still having problems with the uvector package. I have an IntMap (UArr xxx) data type, and I want to serialize it to disk, in binary format. I'm using the uvector package from http://patch-tag.com/repo/pumpkin-uvector/home The problem is with missing instance declarations, for Hyperstrict data type and Data.Array.Vector.UArr.UPrim. For the former, the instance is simple, but for the latter I have no idea about what to do. The full error message (GHC 6.8.2): No instance for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) arising from a use of `encode' at bin/process-data-1.hs:72:18-36 Possible fix: add an instance declaration for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
You're assuming that IO operations have semantics. From the Haskell program's point of view, and when reasoning about Haskell programs (not their interaction with the world) you should assume that every IO operation returns a random result. The way Oleg's program behaves does not break RT under the random result assumption. What could break RT is if you could do this f :: Int - Int - someIOoperation let x = f 0; y = f 0 and end up with x and y not being equal. It's (of course) easy to construct someIOoperation that has this behaviour (using FFI), but I don't think you can construct it just using the normal IO operations and unsafeInterleaveIO. But as I said, I think this is a problem anyway, because IO without semantics is rather useless. -- Lennart On Thu, Mar 5, 2009 at 1:08 PM, Simon Marlow marlo...@gmail.com wrote: Lennart Augustsson wrote: I don't see any breaking of referential transparence in your code. Every time you do an IO operation the result is basically non-deterministic since you are talking to the outside world. You're assuming the IO has some kind of semantics that Haskell makes no promises about. I'm not saying that this isn't a problem, because it is. But it doesn't break referential transparency, it just makes the semantics of IO even more complicated. (I don't have a formal proof that unsafeInterleaveIO cannot break RT, but I've not seen an example where it does yet.) So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) Cheers, Simon -- Lennart On Thu, Mar 5, 2009 at 2:12 AM, o...@okmij.org wrote: We demonstrate how lazy IO breaks referential transparency. A pure function of the type Int-Int-Int gives different integers depending on the order of evaluation of its arguments. Our Haskell98 code uses nothing but the standard input. We conclude that extolling the purity of Haskell and advertising lazy IO is inconsistent. Henning Thielemann wrote on Haskell-Cafe: Say I have a chain of functions: read a file, ... write that to a file, all of these functions are written in a lazy way, which is currently considered good style Lazy IO should not be considered good style. One of the common definitions of purity is that pure expressions should evaluate to the same results regardless of evaluation order, or that equals can be substituted for equals. If an expression of the type Int evaluates to 1, we should be able to replace every occurrence of the expression with 1 without changing the results and other observables. The expression (read s) where s is the result of the (hGetContents h1) action has the pure type, e.g., Int. Yet its evaluation does more than just producing an integer: it may also close a file associated with the handle h1. Closing the file has an observable effect: the file descriptor, which is a scarce resource, is freed. Some OS lock the open file, or prevent operations such as renaming and deletion on the open file. A file system whose file is open cannot be unmounted. Suppose I use an Haskell application such as an editor to process data from a removable drive. I mount the drive, tell the application the file name. The (still running) application finished with the file and displayed the result. And yet I can't unplug the removable drive, because it turns out that the final result was produced without needing to read all the data from the file, and the file remains unclosed. Some people say: the programmer should have used seq. That is the admission of guilt! An expression (read s)::Int that evaluates to 1 is equal to 1. So, one should be able substitute (read s) with 1. If the result of evaluating 1 turns out not needed for the final outcome, then not evaluating (read s) should not affect the outcome. And yet it does. One uses seq to force evaluation of an expression even if the result may be unused. Thus the expression of a pure type has *side-effect*. The advice about using seq reminds me of advice given to C programmers that they should not free a malloc'ed pointer twice, dereference a zero pointer and write past the boundary of an array. If lazy IO is considered good style given the proper use of seq, then C should be considered safe given the proper use of pointers and arrays. Side affects like closing a file are observable in the external world. A program may observe these effects, in an IO monad. One can argue there are no guarantees at all about what happens in the IO monad. Can side-effects of lazy IO be observable in _pure_ Haskell code, in functions with pure type? Yes, they can. The examples are depressingly easy to write, once one realizes
Re: [Haskell-cafe] Re: Theory about uncurried functions
On 5 Mar 2009, at 15:23, Daniel Fischer wrote: Just to flesh this up a bit: let f : P(N) - R be given by f(M) = sum [2*3^(-k) | k - M ] f is easily seen to be injective. define g : (0,1) - P(N) by let x = sum [a_k*2^(-k) | k in N (\{0}), a_k in {0,1}, infinitely many a_k = 1] and then g(x) = {k | a_k = 1} again clearly g is an injection. Now the Cantor-Bernstein theorem asserts there is a bijection between the two sets. I think one just defines an equivalence relation of elements mapped to each other by a finite number of iterations of f o g and g o f. The equivalence classes are then at most countable. So one can set up a bijection on each equivalence class: easy for at most countable sets. Then paste it together. The axiom of choice probably implicit here. Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
On Thu, 2009-03-05 at 13:08 +, Simon Marlow wrote: Lennart Augustsson wrote: I don't see any breaking of referential transparence in your code. Every time you do an IO operation the result is basically non-deterministic since you are talking to the outside world. You're assuming the IO has some kind of semantics that Haskell makes no promises about. I'm not saying that this isn't a problem, because it is. But it doesn't break referential transparency, it just makes the semantics of IO even more complicated. (I don't have a formal proof that unsafeInterleaveIO cannot break RT, but I've not seen an example where it does yet.) So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) That's the charm of denotational semantics --- you're outside the laws of physics. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
Am Donnerstag, 5. März 2009 16:55 schrieb Hans Aberg: On 5 Mar 2009, at 15:23, Daniel Fischer wrote: Just to flesh this up a bit: let f : P(N) - R be given by f(M) = sum [2*3^(-k) | k - M ] f is easily seen to be injective. define g : (0,1) - P(N) by let x = sum [a_k*2^(-k) | k in N (\{0}), a_k in {0,1}, infinitely many a_k = 1] and then g(x) = {k | a_k = 1} again clearly g is an injection. Now the Cantor-Bernstein theorem asserts there is a bijection between the two sets. I think one just defines an equivalence relation of elements mapped to each other by a finite number of iterations of f o g and g o f. The equivalence classes are then at most countable. So one can set up a bijection on each equivalence class: easy for at most countable sets. Then paste it together. The axiom of choice probably implicit here. Cantor-Bernstein doesn't require choice (may be different for intuitionists). http://en.wikipedia.org/wiki/Cantor-Bernstein_theorem Hans Aberg Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
On Thu, Mar 5, 2009 at 2:08 PM, Simon Marlow marlo...@gmail.com wrote: So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) As it turns out, time-travel as a vehicle for computation has a long tradition in the more advanced systems; see http://www.frc.ri.cmu.edu/~hpm/project.archive/general.articles/1991/TempComp.html for an example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
On 5 Mar 2009, at 17:06, Daniel Fischer wrote: Cantor-Bernstein doesn't require choice (may be different for intuitionists). http://en.wikipedia.org/wiki/Cantor-Bernstein_theorem Yes, that is right, Mendelson says that. - I find it hard to figure out when it is used, as it is so intuitive. Mendelson says AC is in fact equivalent proving all x, y: card x = card y or card y = card x Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] missing support to Data.Binary for uvector package
Hi Manlio, I'm not sure the whole list wants to hear about bugs in my modifications to an alpha library! :-) But basically, I haven't added a Binary instance for productions like that yet. This isn't trivial, but shouldn't be hard. Otherwise, using the unsafe serialization functions I provide in that same module might give you better luck (at the cost of some safety). But uvector, no matter how awesome the fusion work Don and others did on it, is definitely not finished yet. Be prepared to hack a lot (and maybe crash a fair amount) if you want to use it. Hope this helps, Dan On Thu, Mar 5, 2009 at 9:54 AM, Manlio Perillo manlio_peri...@libero.it wrote: Hi. I'm still having problems with the uvector package. I have an IntMap (UArr xxx) data type, and I want to serialize it to disk, in binary format. I'm using the uvector package from http://patch-tag.com/repo/pumpkin-uvector/home The problem is with missing instance declarations, for Hyperstrict data type and Data.Array.Vector.UArr.UPrim. For the former, the instance is simple, but for the latter I have no idea about what to do. The full error message (GHC 6.8.2): No instance for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) arising from a use of `encode' at bin/process-data-1.hs:72:18-36 Possible fix: add an instance declaration for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) Thanks Manlio Perillo ___ 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] Re: [Haskell] Lazy IO breaks purity
On Thu, Mar 5, 2009 at 7:08 AM, Simon Marlow marlo...@gmail.com wrote: So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) Surely there's a quantum mechanical metaphor waiting to happen here. getCat :: IO Cat If getCat appears in a program text, does it denote or not? Or both? If it does, is the cat alive or dead? (Apologies to Schrodingerhttp://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat). -gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make a dock window for xmonad using gtk2hs?
On 2009 Mar 5, at 8:21, Andrea Rossato wrote: On Wed, Mar 04, 2009 at 10:59:53PM -0500, Brandon S. Allbery KF8NH wrote: On 2009 Mar 4, at 21:40, Magicloud Magiclouds wrote: Could someone give me a sample or something I could learn from? Thanks. (xmobar is open source, you could look through its source) xmobar is not open source. xmobar is FREE software! I don't do fundamentalist religion... -- 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 universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: MPI
On Wed, Mar 4, 2009 at 5:03 PM, FFT fft1...@gmail.com wrote: Are MPI bindings still the best way of using Haskell on Beowulf clusters? It's my feeling that the bindings stagnated, or are they just very mature? What's the story with distributed memory multiprocessing? Are Haskell programmers uninterested in it, or are things other than MPI used with it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monadic MapReduce
On Tue, Mar 03, 2009 at 07:27:35AM -1000, Tim Newsham wrote: How about this. Is there a reason why I can't replace the variables b and c in the type signature of mapReduce with with (IO b') and (IO c'). b and c can be any types. mapReduce :: Strategy (IO b')-- evaluation strategy for mapping - (a - IO b') -- map function - Strategy (IO c')-- evaluation strategy for reduction - ([IO b'] - (IO c'))-- reduce function - [a] -- list to map over - (IO c') Just remember to wrap all values back in the IO monad. Remember, the idea of map-reduce is to provide a very restrictive programming interface so that you have a lot of flexibility in your execution strategy. If you start loosening the interface you will still be able to execute the program, but you may not be able to perform all the great optimizations you want to perform. For example, if you are using IO actions that are stateful, what are the semantics? Can one map action affect other map actions? Does this imply an ordering of the map functions? Does this imply they all run on the same machine or at least have state communicated between the machines on which they run? Yes, IO actions in mapReduce will introduce all these questions. I thought Manlio's example was a case where the IO actions consist only of reading an entire file into a string and no ordering or dependence between map actions is implied. I have a similar application where this, unsafe as it is, might be useful. I need to read in a large number of CSV files, with numeric columns, and group columns with high correlation together. I have yet to try my own suggestion though. I have tried the first approach I suggested, read in the contents into strings and work with the normal map-reduce. That does keep the handles open till map-reduce is done. The austere interface precludes any of these issues, and therein lies the beauty. Anish Btw. I prefer the sawzall formulation over the map-reduce formulation. A sawzall program just specifies how to map some data to a monoid and the system is free to mappend the monoid values in whatever order it wants (by applying associativity). Thanks for the tip, I wasn't aware of this. At least in the map-reduce formulation in this thread, the fold is completely specified by the user and not optimized further. So the sawazall formulation seems promising, because sometimes the fold action is more expensive than the map action. And while we are talking about different formulations, the code here http://article.gmane.org/gmane.comp.lang.haskell.cafe/41944 splits the list of operands into chunks and does the fold action in parallel on each chunk. This actually works well for me, though I find the semantics a little hard to remember. Anish Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hint and Ambiguous Type issue
I've been working on a little project, and one of the things I need to do is dynamically compile and import a Haskell Source file containing filtering definitions. I've written a small monad called Filter which is simply: type Filter a = Reader (Config, Email) a To encompass all the email filtering. The method I need to import, filterMain, has type: filterMain :: Deliverable a = Filter a where Deliverable is a type class which abstracts over delivery to a path in the file system. The notion is that I can write a type like: data DEmail = {email :: Email, path :: FilePath} newtype Maildir = MD DEmail instance Deliverable Maildir where {- ... omitted -} However, Filter a should not be restricted to Deliverable types- it also encompasses the results of regular expression matching, etc, which are not -- in general -- Deliverable instances. My question is this, when importing the file containing the definitions of filterMain, I have the following code to grab filterMain and return it as a function. getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain fMainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) (as :: Deliverable a = Filter a)) return (fMain) However, when I try to compile this, I get the type error: Hackmain.hs:70:43: Ambiguous type variable `a' in the constraint: `Deliverable a' arising from a use of `getFilterMainStuff' at Hackmain.hs:70:43-60 Probable fix: add a type signature that fixes these type variable(s) My understanding is that a type like Foo a = Bar a (where Foo is a class and Bar is a datatype) would simply restrict the values of a to only those implementing Foo. But evidently I'm wrong. Is there a good (read, easy... :) ) fix to this? Any help would be greatly appreciated. /Joe PS. All the actual code is on patch-tag, here http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at that directly, the relevant files are in Src, namely, Hackmain.hs, Filter.hs, and Deliverable.hs 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] Test if a file is empty or stat in haskell
I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
Am Donnerstag, 5. März 2009 19:48 schrieb Joseph Fredette: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain fMainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) (as :: Deliverable a = Filter a)) Without looking at more code, the type variable a here is a fresh type variable, not the one from getFilterMain's signature. return (fMain) Maybe bringing the type variable a into scope in the function body by {-# LANGUAGE ScopedTypeVariables #-} getFilterMain :: forall a. Deliverable a = FilePath - Interpreter (Filter, a) would suffice. However, when I try to compile this, I get the type error: Hackmain.hs:70:43: Ambiguous type variable `a' in the constraint: `Deliverable a' arising from a use of `getFilterMainStuff' at Hackmain.hs:70:43-60 Probable fix: add a type signature that fixes these type variable(s) My understanding is that a type like Foo a = Bar a (where Foo is a class and Bar is a datatype) would simply restrict the values of a to only those implementing Foo. But evidently I'm wrong. Is there a good (read, easy... :) ) fix to this? Any help would be greatly appreciated. /Joe PS. All the actual code is on patch-tag, here http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at that directly, the relevant files are in Src, namely, Hackmain.hs, Filter.hs, and Deliverable.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
Am Donnerstag, 5. März 2009 19:56 schrieb Anish Muttreja: I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? If you're on a *nixy OS, System.Posix.Files getFileStatus, fileSize ... dunno if Windows has similar functionality. A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
On Thu, 05 Mar 2009 19:56:42 +0100, Anish Muttreja anishmuttr...@gmail.com wrote: I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish Searching for size with Hoogle lead me to System.IO.hFileSize: hFileSize :: Handle - IO Integer For a handle hdl which attached to a physical file, hFileSize hdl returns the size of that file in 8-bit bytes. -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
On Thu, Mar 05, 2009 at 08:15:03PM +0100, Daniel Fischer wrote: Am Donnerstag, 5. März 2009 19:56 schrieb Anish Muttreja: I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? If you're on a *nixy OS, System.Posix.Files getFileStatus, fileSize ... Great, thanks. dunno if Windows has similar functionality. I am on Linux. BTW, Hoogle does not seem to know about System.Posix.Files, though it did point me to System.IO.FileSize which would also have served the purpose. http://www.haskell.org/hoogle/?hoogle=fileSize Thanks, Anish A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary stack overflow with Data.Sequence String
Avoid unpack! ndmitchell: Hi Gwern, I get String/Data.Binary issues too. My suggestion would be to change your strings to ByteString's, serisalise, and then do the reverse conversion when reading. Interestingly, a String and a ByteString have identical Data.Binary reps, but in my experiments converting, including the cost of BS.unpack, makes the reading substantially cheaper. Thanks Neil On Thu, Mar 5, 2009 at 2:33 AM, Gwern Branwen gwe...@gmail.com wrote: On Tue, Mar 3, 2009 at 11:50 PM, Spencer Janssen spencerjans...@gmail.com wrote: On Tue, Mar 3, 2009 at 10:30 PM, Gwern Branwen gwe...@gmail.com wrote: So recently I've been having issues with Data.Binary Data.Sequence; I serialize a 'Seq String' You can see the file here: http://code.haskell.org/yi/Yi/IReader.hs The relevant function seems to be: -- | Read in database from 'dbLocation' and then parse it into an 'ArticleDB'. readDB :: YiM ArticleDB readDB = io $ (dbLocation = r) `catch` (\_ - return empty) where r x = fmap (decode . BL.fromChunks . return) $ B.readFile x -- We read in with strict bytestrings to guarantee the file is closed, -- and then we convert it to the lazy bytestring data.binary expects. -- This is inefficient, but alas... My current serialized file is about 9.4M. I originally thought that the issue might be the recent upgrade in Yi to binary 0.5, but I unpulled patches back to past that, and the problem still manifested. Whenever yi tries to read the articles.db file, it stack overflows. It actually stack-overflowed on even smaller files, but I managed to bump the size upwards, it seems, by the strict-Bytestring trick. Unfortunately, my personal file has since passed whatever that limit was. I've read carefully the previous threads on Data.Binary and Data.Map stack-overflows, but none of them seem to help; hacking some $!s or seqs into readDB seems to make no difference, and Seq is supposed to be a strict datastructure already! Doing things in GHCi has been tedious, and hasn't enlightened me much: sometimes things overflow and sometimes they don't. It's all very frustrating and I'm seriously considering going back to using the original read/show code unless anyone knows how to fix this - that approach may be many times slower, but I know it will work. -- gwern Have you tried the darcs version of binary? It has a new instance which looks more efficient than the old. Cheers, Spencer Janssen I have. It still stack-overflows on my 9.8 meg file. (The magic number seems to be somewhere between 9 and 10 megabytes.) -- gwern ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] missing support to Data.Binary for uvector package
manlio_perillo: Hi. I'm still having problems with the uvector package. I have an IntMap (UArr xxx) data type, and I want to serialize it to disk, in binary format. I'm using the uvector package from http://patch-tag.com/repo/pumpkin-uvector/home The problem is with missing instance declarations, for Hyperstrict data type and Data.Array.Vector.UArr.UPrim. For the former, the instance is simple, but for the latter I have no idea about what to do. The full error message (GHC 6.8.2): No instance for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) arising from a use of `encode' at bin/process-data-1.hs:72:18-36 Possible fix: add an instance declaration for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) uvector is alpha/experimental. You should expect to write instances/patches if you chose to use it! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make a dock window for xmonad using gtk2hs?
On Thu, Mar 05, 2009 at 12:50:20PM -0500, Brandon S. Allbery KF8NH wrote: On 2009 Mar 5, at 8:21, Andrea Rossato wrote: xmobar is not open source. xmobar is FREE software! I don't do fundamentalist religion... qualifying as fundamentalism the avoidance of cheap marketing strategies is just a ... cheap marketing strategy. cheers, andrea ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary stack overflow with Data.Sequence String
Avoid massive reductions in runtime while maintaining the same API? I did move to using ByteString's internally for those bits later on, but reading String's from Data.Binary with a ByteString+unpack went much more quickly than reading String's On Thu, Mar 5, 2009 at 7:35 PM, Don Stewart d...@galois.com wrote: Avoid unpack! ndmitchell: Hi Gwern, I get String/Data.Binary issues too. My suggestion would be to change your strings to ByteString's, serisalise, and then do the reverse conversion when reading. Interestingly, a String and a ByteString have identical Data.Binary reps, but in my experiments converting, including the cost of BS.unpack, makes the reading substantially cheaper. Thanks Neil On Thu, Mar 5, 2009 at 2:33 AM, Gwern Branwen gwe...@gmail.com wrote: On Tue, Mar 3, 2009 at 11:50 PM, Spencer Janssen spencerjans...@gmail.com wrote: On Tue, Mar 3, 2009 at 10:30 PM, Gwern Branwen gwe...@gmail.com wrote: So recently I've been having issues with Data.Binary Data.Sequence; I serialize a 'Seq String' You can see the file here: http://code.haskell.org/yi/Yi/IReader.hs The relevant function seems to be: -- | Read in database from 'dbLocation' and then parse it into an 'ArticleDB'. readDB :: YiM ArticleDB readDB = io $ (dbLocation = r) `catch` (\_ - return empty) where r x = fmap (decode . BL.fromChunks . return) $ B.readFile x -- We read in with strict bytestrings to guarantee the file is closed, -- and then we convert it to the lazy bytestring data.binary expects. -- This is inefficient, but alas... My current serialized file is about 9.4M. I originally thought that the issue might be the recent upgrade in Yi to binary 0.5, but I unpulled patches back to past that, and the problem still manifested. Whenever yi tries to read the articles.db file, it stack overflows. It actually stack-overflowed on even smaller files, but I managed to bump the size upwards, it seems, by the strict-Bytestring trick. Unfortunately, my personal file has since passed whatever that limit was. I've read carefully the previous threads on Data.Binary and Data.Map stack-overflows, but none of them seem to help; hacking some $!s or seqs into readDB seems to make no difference, and Seq is supposed to be a strict datastructure already! Doing things in GHCi has been tedious, and hasn't enlightened me much: sometimes things overflow and sometimes they don't. It's all very frustrating and I'm seriously considering going back to using the original read/show code unless anyone knows how to fix this - that approach may be many times slower, but I know it will work. -- gwern Have you tried the darcs version of binary? It has a new instance which looks more efficient than the old. Cheers, Spencer Janssen I have. It still stack-overflows on my 9.8 meg file. (The magic number seems to be somewhere between 9 and 10 megabytes.) -- gwern ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
Hi I am on Linux. BTW, Hoogle does not seem to know about System.Posix.Files, though it did point me to System.IO.FileSize which would also have served the purpose. To build the Hoogle libraries I need to build the packages. I run Windows not Linux, so its a bit difficult to index System.Posix - but I am trying to shortly. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
This doesn't seem to do it, same type error... Maybe I need to use some kind of witness type -- to inform the compiler of the type of a @ runtime? Daniel Fischer wrote: Am Donnerstag, 5. März 2009 19:48 schrieb Joseph Fredette: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain fMainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) (as :: Deliverable a = Filter a)) Without looking at more code, the type variable a here is a fresh type variable, not the one from getFilterMain's signature. return (fMain) Maybe bringing the type variable a into scope in the function body by {-# LANGUAGE ScopedTypeVariables #-} getFilterMain :: forall a. Deliverable a = FilePath - Interpreter (Filter, a) would suffice. However, when I try to compile this, I get the type error: Hackmain.hs:70:43: Ambiguous type variable `a' in the constraint: `Deliverable a' arising from a use of `getFilterMainStuff' at Hackmain.hs:70:43-60 Probable fix: add a type signature that fixes these type variable(s) My understanding is that a type like Foo a = Bar a (where Foo is a class and Bar is a datatype) would simply restrict the values of a to only those implementing Foo. But evidently I'm wrong. Is there a good (read, easy... :) ) fix to this? Any help would be greatly appreciated. /Joe PS. All the actual code is on patch-tag, here http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at that directly, the relevant files are in Src, namely, Hackmain.hs, Filter.hs, and Deliverable.hs 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] Test if a file is empty or stat in haskell
getFileStatus, fileSize ... Great, thanks. BTW, Hoogle does not seem to know about System.Posix.Files, though it did point me to System.IO.FileSize which would also have served the purpose. Yep, this was discussed in a Hoogle and Network.Socket thread I started last week. There is a wiki for summarizing thoughts [1]. Some time this weekend or next week I intend to submit a Hoogle ticket proposing what I see as an agreeable outcome. At that point I hope Neil will accept and maybe even find time to write code. The final step would involve me buying Neil a beer - I've lots of beer-debt to the Haskell community. [1] http://haskell.org/haskellwiki/Hoogle/Packages ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
So, by using the Haskell interpreter, you're using the not-very-well-supported dynamically-typed subset of Haskell. You can tell this from the type signature of interpret: interpret :: Typeable a = String - a - Interpreter a as :: Typeable a = a as = undefined (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html) In particular, the as argument to interpret is specifying what type you want the interpreted result to be typechecked against; the interpretation fails if it doesn't match that type. But you need the result type to be an instance of Typeable; (forall a. Deliverable a = Filter a) most certainly is not. Off the top of my head, you have a couple of directions you can take this. (1) Make Typeable a superclass of Deliverable, saying that all deliverable things must be dynamically typeable. Then derive Typeable on Filter, and have the result be of type Filter a using ScopedTypeVariables as suggested before. (You can also pass infer to the interpreter and let the compiler try to figure out the result type instead of passing (as :: SomeType).) (2) Make a newtype wrapper around Filter and give it an instance of Typeable, and add a constraint to filterMain that the result type in the filter is also typeable. Then unwrap the newtype after the interpreter completes. Good luck; I've never tried to use the Haskell interpreter before, so I'm curious how well it works and what problems you have with it! -- ryan 2009/3/5 Joseph Fredette jfred...@gmail.com: I've been working on a little project, and one of the things I need to do is dynamically compile and import a Haskell Source file containing filtering definitions. I've written a small monad called Filter which is simply: type Filter a = Reader (Config, Email) a To encompass all the email filtering. The method I need to import, filterMain, has type: filterMain :: Deliverable a = Filter a where Deliverable is a type class which abstracts over delivery to a path in the file system. The notion is that I can write a type like: data DEmail = {email :: Email, path :: FilePath} newtype Maildir = MD DEmail instance Deliverable Maildir where {- ... omitted -} However, Filter a should not be restricted to Deliverable types- it also encompasses the results of regular expression matching, etc, which are not -- in general -- Deliverable instances. My question is this, when importing the file containing the definitions of filterMain, I have the following code to grab filterMain and return it as a function. getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain fMainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) (as :: Deliverable a = Filter a)) return (fMain) However, when I try to compile this, I get the type error: Hackmain.hs:70:43: Ambiguous type variable `a' in the constraint: `Deliverable a' arising from a use of `getFilterMainStuff' at Hackmain.hs:70:43-60 Probable fix: add a type signature that fixes these type variable(s) My understanding is that a type like Foo a = Bar a (where Foo is a class and Bar is a datatype) would simply restrict the values of a to only those implementing Foo. But evidently I'm wrong. Is there a good (read, easy... :) ) fix to this? Any help would be greatly appreciated. /Joe PS. All the actual code is on patch-tag, here http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at that directly, the relevant files are in Src, namely, Hackmain.hs, Filter.hs, and Deliverable.hs ___ 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] Re: Theory about uncurried functions
Luke Palmer lrpal...@gmail.com wrote: I don't think set theory is trivial in the least. I think it is complicated, convoluted, often anti-intuitive and nonconstructive. Waaagh! I mean trivial in the mathematical sense, as in how far away from the axioms you are. The other kind of triviality of set theory just proves the point I made about CT vs. lambda calculus. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Theory about uncurried functions
To wrap up: While formalising, there is always a tradeoff between complexity of the theory you're using and the complexity of it being applied to some specific topic. Category theory hits a very, very sweet spot there. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
So, I tried both of those things, both each alone and together. No dice. Same error, so I reverted back to the original. :( However, I was, after some random type signature insertions, able to convert the problem into a different one, via: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain MainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: Deliverable a = Filter a) Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: fMain :: Filter a (bound at Hackmain.hs:77:1) In the first argument of `return', namely `(fMain :: (Deliverable a) = Filter a)' In the expression: return (fMain :: (Deliverable a) = Filter a) In the expression: do loadModules [fMainLoc] setTopLevelModules [(takeWhile (/= '.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: (Deliverable a) = Filter a) I'm thinking that this might be more easily solved -- I do think I understand the issue. somehow, I need to tell the compiler that the 'a' used in the return statement (return (fMain :: ...)) is the same as the 'a' in the type sig for the whole function. While I ponder this, and hopefully receive some more help -- thanks again Dan, Ryan -- Are there any other options besides Hint that might -- at least in the short term -- make this easier? I'd really like to finish this up. I'm _so_ close to getting it done. Thanks, /Joe Ryan Ingram wrote: So, by using the Haskell interpreter, you're using the not-very-well-supported dynamically-typed subset of Haskell. You can tell this from the type signature of interpret: interpret :: Typeable a = String - a - Interpreter a as :: Typeable a = a as = undefined (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html) In particular, the as argument to interpret is specifying what type you want the interpreted result to be typechecked against; the interpretation fails if it doesn't match that type. But you need the result type to be an instance of Typeable; (forall a. Deliverable a = Filter a) most certainly is not. Off the top of my head, you have a couple of directions you can take this. (1) Make Typeable a superclass of Deliverable, saying that all deliverable things must be dynamically typeable. Then derive Typeable on Filter, and have the result be of type Filter a using ScopedTypeVariables as suggested before. (You can also pass infer to the interpreter and let the compiler try to figure out the result type instead of passing (as :: SomeType).) (2) Make a newtype wrapper around Filter and give it an instance of Typeable, and add a constraint to filterMain that the result type in the filter is also typeable. Then unwrap the newtype after the interpreter completes. Good luck; I've never tried to use the Haskell interpreter before, so I'm curious how well it works and what problems you have with it! -- ryan 2009/3/5 Joseph Fredette jfred...@gmail.com: I've been working on a little project, and one of the things I need to do is dynamically compile and import a Haskell Source file containing filtering definitions. I've written a small monad called Filter which is simply: type Filter a = Reader (Config, Email) a To encompass all the email filtering. The method I need to import, filterMain, has type: filterMain :: Deliverable a = Filter a where Deliverable is a type class which abstracts over delivery to a path in the file system. The notion is that I can write a type like: data DEmail = {email :: Email, path :: FilePath} newtype Maildir = MD DEmail instance Deliverable Maildir where {- ... omitted -} However, Filter a should not be restricted to Deliverable types- it also encompasses the results of regular expression matching, etc, which are not -- in general -- Deliverable instances. My question is this, when importing the file containing the definitions of filterMain, I have the following code to grab filterMain and return it as a function. getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain fMainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) (as :: Deliverable a = Filter a)) return (fMain) However, when I try to compile this, I get the type error: Hackmain.hs:70:43: Ambiguous type variable `a' in the constraint: `Deliverable a'
[Haskell-cafe] Haskell Logo Voting will start soon!
Hi there! It's been quiet for a while around the 'new logo' competition, but here is how it is going to work: The list with options can be found here (for now): http://community.haskell.org/~eelco/poll.html Notice that some (very) similar logos are grouped as one option (thanks to Ian Lynagh) All submissions compete, so that still makes more than a 100 options! The voting system we'll use is the Condorcet Internet Voting System (http://www.cs.cornell.edu/andru/civs.html ). The poll won't be public, but every subscriber to Haskell-Cafe will get a (private) voting ballot by email. The poll will (probably) start March 16 and run for about a week (don't worry, there will be a strict deadline communicated). When the poll is over, the results will be viewable by everybody. The CIVS allows easy grouping and ordering, so the task of ordering 100 options should be doable within 5-10 minutes. If you're in a hurry you can do it a lot faster, just pick your favorite and put it first. If you want to learn more about condorcet voting, the CIVS site and Wikipedia are your friends. I'll supervise the poll and make sure it's started, stopped and all Haskell-Cafe subscribers get a ballot (Simon Marlow provided the email addresses). Since I'm going on a (probably internet deprived) holiday for a week _and_ to make sure I haven't overlooked anything, I'm announcing it now but won't start the poll till March 16. Of course, I'd love to hear about anything that I missed and/or that might influence the voting process in a significant way. (There are probably some people subscribed with multiple addresses, but I'll be using the subscriber list from yesterday, so signing up now with lots of addresses won't get you more ballots ;) -- Regards, Eelco Lempsink PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Left fold enumerator - a real pearl overlooked?
On Wed, 4 Mar 2009, John Lato wrote: John A. De Goes schrieb: Elsewhere, laziness can be a real boon, so I don't understand your question, Why have laziness in Haskell at all? As I have written, many libaries process their data lazily (or could be changed to do so without altering their interface) but their interface can forbid application to data that is fetched from the outside world. Say you are used to 'map', 'filter', 'foldr' - you cannot use them on data fetched by the iteratee/enumerator approach. Thank you for replying to this; it's good to see what features people would like to make iteratees more useful. Where did you get the idea that you can't use 'map'? What I meant was, that you cannot just use the functions you are used from Data.List. You need functions adapted to Iteratee. This also implies that all libraries written in terms of Data.List functions cannot be used as they are. Maybe it's a good time to review those libraries, whether they need lists at all, or whether they would also work with functionality that can be provided by Iteratees. The question, whether libraries should be bound to lists and Strings did already arise with ByteStrings. So Iteratees may be just one more reason to generalize the libraries. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell Logo Voting will start soon!
Eelco Lempsink ee...@lempsink.nl wrote: The poll won't be public, but every subscriber to Haskell-Cafe will get a (private) voting ballot by email. What about us gmane users? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Logo Voting will start soon!
eelco: Hi there! It's been quiet for a while around the 'new logo' competition, but here is how it is going to work: The list with options can be found here (for now): http://community.haskell.org/~eelco/poll.html Notice that some (very) similar logos are grouped as one option (thanks to Ian Lynagh) All submissions compete, so that still makes more than a 100 options! The voting system we'll use is the Condorcet Internet Voting System (http://www.cs.cornell.edu/andru/civs.html). The poll won't be public, but every subscriber to Haskell-Cafe will get a (private) voting ballot by email. The poll will (probably) start March 16 and run for about a week (don't worry, there will be a strict deadline communicated). When the poll is over, the results will be viewable by everybody. The CIVS allows easy grouping and ordering, so the task of ordering 100 options should be doable within 5-10 minutes. If you're in a hurry you can do it a lot faster, just pick your favorite and put it first. If you want to learn more about condorcet voting, the CIVS site and Wikipedia are your friends. I'll supervise the poll and make sure it's started, stopped and all Haskell-Cafe subscribers get a ballot (Simon Marlow provided the email addresses). Since I'm going on a (probably internet deprived) holiday for a week _and_ to make sure I haven't overlooked anything, I'm announcing it now but won't start the poll till March 16. Of course, I'd love to hear about anything that I missed and/or that might influence the voting process in a significant way. (There are probably some people subscribed with multiple addresses, but I'll be using the subscriber list from yesterday, so signing up now with lots of addresses won't get you more ballots ;) Excellent work Eelco, and thanks for pushing this forward! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do you have to use fix with forkio?
In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. fix $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. \loop - do (nr', line) - readChan chan' when (nr /= http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:/= nr') $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? -- Daryoush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, 2009-03-05 at 15:36 -0800, Daryoush Mehrtash wrote: In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ fix $ \loop - do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, 2009-03-05 at 16:12 -0800, Jonathan Cast wrote: On Thu, 2009-03-05 at 15:36 -0800, Daryoush Mehrtash wrote: In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ fix $ \loop - do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Both are poorish style. reader - forkIO $ forever $ do (nr', line) - readChan; when (nr /= nr') $ putStrLn hdl line ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
Hi I've downloaded Hackmain from patch-tag, but I'm getting a different error. The error I get is: Hackmain.hs:63:10: No instance for (Data.Typeable.Typeable2 Control.Monad.Reader.Reader) arising from a use of `interpret' at Hackmain.hs:63:10-67 Hint requires the interpreted values to be an instance of Typeable in order to check, in runtime, that the interpreted value matches the type declared at compile. Therefore, you need to make sure that (Filter a) is indeed an instance of Typeable. Since you have Filter a = Reader (Config, Email) a, you probably need to - Derive Config and Email instances for Filter, - Manually provide Typeable instances for Reader a b, something along the lines of: instance (Typeable a, Typeable b) = Typeable (Reader a b) where... (I don't know why this isn't done in the mtl) - Change the signature to: getFilterMain :: (Typeable a, Deliverable a) = FilePath - Interpreter (Filter a) Also, you can try using infer instead of as :: Hope that helps Daniel On Mar 5, 2009, at 8:47 PM, Joseph Fredette wrote: So, I tried both of those things, both each alone and together. No dice. Same error, so I reverted back to the original. :( However, I was, after some random type signature insertions, able to convert the problem into a different one, via: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain MainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: Deliverable a = Filter a) Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: fMain :: Filter a (bound at Hackmain.hs:77:1) In the first argument of `return', namely `(fMain :: (Deliverable a) = Filter a)' In the expression: return (fMain :: (Deliverable a) = Filter a) In the expression: do loadModules [fMainLoc] setTopLevelModules [(takeWhile (/= '.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: (Deliverable a) = Filter a) I'm thinking that this might be more easily solved -- I do think I understand the issue. somehow, I need to tell the compiler that the 'a' used in the return statement (return (fMain :: ...)) is the same as the 'a' in the type sig for the whole function. While I ponder this, and hopefully receive some more help -- thanks again Dan, Ryan -- Are there any other options besides Hint that might -- at least in the short term -- make this easier? I'd really like to finish this up. I'm _so_ close to getting it done. Thanks, /Joe Ryan Ingram wrote: So, by using the Haskell interpreter, you're using the not-very-well-supported dynamically-typed subset of Haskell. You can tell this from the type signature of interpret: interpret :: Typeable a = String - a - Interpreter a as :: Typeable a = a as = undefined (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html) In particular, the as argument to interpret is specifying what type you want the interpreted result to be typechecked against; the interpretation fails if it doesn't match that type. But you need the result type to be an instance of Typeable; (forall a. Deliverable a = Filter a) most certainly is not. Off the top of my head, you have a couple of directions you can take this. (1) Make Typeable a superclass of Deliverable, saying that all deliverable things must be dynamically typeable. Then derive Typeable on Filter, and have the result be of type Filter a using ScopedTypeVariables as suggested before. (You can also pass infer to the interpreter and let the compiler try to figure out the result type instead of passing (as :: SomeType).) (2) Make a newtype wrapper around Filter and give it an instance of Typeable, and add a constraint to filterMain that the result type in the filter is also typeable. Then unwrap the newtype after the interpreter completes. Good luck; I've never tried to use the Haskell interpreter before, so I'm curious how well it works and what problems you have with it! -- ryan 2009/3/5 Joseph Fredette jfred...@gmail.com: I've been working on a little project, and one of the things I need to do is dynamically compile and import a Haskell Source file containing filtering definitions. I've written a small monad called Filter which is simply: type Filter a = Reader (Config, Email) a To encompass all the email filtering. The method I need to import, filterMain, has type: filterMain :: Deliverable a = Filter a where Deliverable is a type class which abstracts over delivery to a path in the file system. The notion is that I can write a type
Re: [Haskell-cafe] Re: Left fold enumerator - a real pearl overlooked?
On Thu, 2009-03-05 at 23:52 +0100, Henning Thielemann wrote: On Wed, 4 Mar 2009, John Lato wrote: John A. De Goes schrieb: Elsewhere, laziness can be a real boon, so I don't understand your question, Why have laziness in Haskell at all? As I have written, many libaries process their data lazily (or could be changed to do so without altering their interface) but their interface can forbid application to data that is fetched from the outside world. Say you are used to 'map', 'filter', 'foldr' - you cannot use them on data fetched by the iteratee/enumerator approach. Thank you for replying to this; it's good to see what features people would like to make iteratees more useful. Where did you get the idea that you can't use 'map'? What I meant was, that you cannot just use the functions you are used from Data.List. You need functions adapted to Iteratee. This also implies that all libraries written in terms of Data.List functions cannot be used as they are. Maybe it's a good time to review those libraries, whether they need lists at all, or whether they would also work with functionality that can be provided by Iteratees. The question, whether libraries should be bound to lists and Strings did already arise with ByteStrings. So Iteratees may be just one more reason to generalize the libraries. In most cases we can get the list version from a continuation based version. A continuation based version can also be used to implement an iterator version. Leaving aside the amount of work, I've been trying to think of how to do a iterator version at all for some libs. Specifically, my zlib binding. Currently the zlib package provides functions on lazy bytestrings: compress, decompress :: ByteString - ByteString This hides all the complications of blocks and filling and draining buffers. However since it uses lazy bytestrings it is most naturally used with lazy io. The question is can I make an interface that also keeps the devotees of iterator based IO happy and also lets me implement the existing api above. I cannot see how to do it. Note that compress and decompress are pure. This is something that I want to keep. I don't want to go back to using IO for a pure operation like compression just for the sake of iterator IO. The problem of course is that while zlib compression is pure overall, there is an internal state thread. That must be threaded linearly. We cannot hand out a continuation that can be run multiple times. Lining up the zlib state thread with the memoising lazy list works perfectly. I cannot see how we do the same with an iterator interface. I'm not saying it cannot be done. On the contrary, I would like to see it done. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Difficulties in accessing inner elements of data types
Hi David, I'm working on a Haskell library for interacting with emacs org files. For those that do not know, an org file is a structured outline style file that has nested headings, text, tables and other elements. Great! Sounds like fun. :) Now, this all works as expected (files are correctly being parsed and written), however I am having a lot of trouble trying to come up with a decent API to work with this. While writing an OrgFile is fairly easy, reading (and accessing inner parts) of an org file is very tedious, and modifying them is horrendous. I can imagine. However, I don't know if this is even possible, how to do it, or if there is a better alternative to this. I would really apreciate any hints with regards to this. It would be useful to know if there are other libraries that also face this problem, and how they solved it. I definite agree with Neil: I think generic programming is exactly what you are looking for. Fortunately, there are a number of libraries available to help you solve your problem. The next problem is figuring out which one and learning how to it. For this purpose, a comparison of libraries for generic programming in Haskell was recently published: http://www.cs.uu.nl/wiki/Alexey/ComparingLibrariesForGenericProgrammingInHaskell That should give you an idea of what's out there and the pros and cons of each library. I found your example particularly interesting, so I decided to try out a solution in EMGM (Extensible and Modular Generics for the Masses). I wrote up my experiment here: http://splonderzoek.blogspot.com/2009/03/experiments-with-emgm-emacs-org-files.html More information on EMGM is here: http://www.cs.uu.nl/wiki/GenericProgramming/EMGM I'd be happy to help you figure out if EMGM is appropriate for other things you want to do. Good luck with your library! Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
Oh, crap- I must have never pushed the latest patches, I did put the typeable instances in all the appropriate places. And provided a (maybe incorrect? Though I'm fairly sure that shouldn't affect the bug I'm having now) Typeable implementation for Reader, but I still get this ambiguous type. I'll push the current version asap. Thanks. /Joe Daniel Gorín wrote: Hi I've downloaded Hackmain from patch-tag, but I'm getting a different error. The error I get is: Hackmain.hs:63:10: No instance for (Data.Typeable.Typeable2 Control.Monad.Reader.Reader) arising from a use of `interpret' at Hackmain.hs:63:10-67 Hint requires the interpreted values to be an instance of Typeable in order to check, in runtime, that the interpreted value matches the type declared at compile. Therefore, you need to make sure that (Filter a) is indeed an instance of Typeable. Since you have Filter a = Reader (Config, Email) a, you probably need to - Derive Config and Email instances for Filter, - Manually provide Typeable instances for Reader a b, something along the lines of: instance (Typeable a, Typeable b) = Typeable (Reader a b) where... (I don't know why this isn't done in the mtl) - Change the signature to: getFilterMain :: (Typeable a, Deliverable a) = FilePath - Interpreter (Filter a) Also, you can try using infer instead of as :: Hope that helps Daniel On Mar 5, 2009, at 8:47 PM, Joseph Fredette wrote: So, I tried both of those things, both each alone and together. No dice. Same error, so I reverted back to the original. :( However, I was, after some random type signature insertions, able to convert the problem into a different one, via: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain MainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: Deliverable a = Filter a) Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: fMain :: Filter a (bound at Hackmain.hs:77:1) In the first argument of `return', namely `(fMain :: (Deliverable a) = Filter a)' In the expression: return (fMain :: (Deliverable a) = Filter a) In the expression: do loadModules [fMainLoc] setTopLevelModules [(takeWhile (/= '.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: (Deliverable a) = Filter a) I'm thinking that this might be more easily solved -- I do think I understand the issue. somehow, I need to tell the compiler that the 'a' used in the return statement (return (fMain :: ...)) is the same as the 'a' in the type sig for the whole function. While I ponder this, and hopefully receive some more help -- thanks again Dan, Ryan -- Are there any other options besides Hint that might -- at least in the short term -- make this easier? I'd really like to finish this up. I'm _so_ close to getting it done. Thanks, /Joe Ryan Ingram wrote: So, by using the Haskell interpreter, you're using the not-very-well-supported dynamically-typed subset of Haskell. You can tell this from the type signature of interpret: interpret :: Typeable a = String - a - Interpreter a as :: Typeable a = a as = undefined (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html) In particular, the as argument to interpret is specifying what type you want the interpreted result to be typechecked against; the interpretation fails if it doesn't match that type. But you need the result type to be an instance of Typeable; (forall a. Deliverable a = Filter a) most certainly is not. Off the top of my head, you have a couple of directions you can take this. (1) Make Typeable a superclass of Deliverable, saying that all deliverable things must be dynamically typeable. Then derive Typeable on Filter, and have the result be of type Filter a using ScopedTypeVariables as suggested before. (You can also pass infer to the interpreter and let the compiler try to figure out the result type instead of passing (as :: SomeType).) (2) Make a newtype wrapper around Filter and give it an instance of Typeable, and add a constraint to filterMain that the result type in the filter is also typeable. Then unwrap the newtype after the interpreter completes. Good luck; I've never tried to use the Haskell interpreter before, so I'm curious how well it works and what problems you have with it! -- ryan 2009/3/5 Joseph Fredette jfred...@gmail.com: I've been working on a little project, and one of the things I need to do is dynamically compile and import a Haskell Source file containing filtering definitions. I've written a small monad
Re: [Haskell-cafe] do you have to use fix with forkio?
Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. Thanks, Donn cave PS - granted that forever is a fine alternative to either, I suppose it doesn't affect the style comparison above. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave d...@avvanta.com wrote: Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see let foo = ... Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with: fix $ \foo - ... I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself. I know that it's a simple matter of scanning to the corresponding in, but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Calculating with list comprehension
I can calculate non-nested list comprehensions without a problem, but am unable to calculate nested comprehensions involving, for example, the generation of a list of pairs where the first and separate elements are drawn from two separate lists, as in: [(a, b) | a - [1..3], b - [1..2]] How does one calculate the expansion of this list? The two rules for expanding list comprehensions are: 1. Generator rule: [e | x - xs, Q] = concat (map f xs) where f x = [e | Q] 2. Guard rule: [e | p, Q]= if p then [e | Q] else [] There is a third rule that I've seen on the Internet, not in an authoritative text: [e | Q1 , Q2] = concat [ [e | Q 2] | Q1 ] I don't understand what this third rule means, or whether it's relevant. Concat and map are defined as: concat :: [[a]] - [a] concat []= [] concat (xs:xss) = xs ++ concat xss map :: (a - b) - [a] - [b] map f [] = [] map f (x:xs) = f x : (map f xs) Any help is appreciated. _ Windows Live™: Life without walls. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calculating with list comprehension
Keep in mind this is a *lexical* rewrite. In the generator rule x and e are not independent: x is a pattern (which introduces a bind variable) and e is an expression (with free variables, one of which may be bound by x) After one application of the generator rule, we get (using a lambda expression instead of introducing a fresh function name f): concatMap (\a - [(a,b) | b - [1..2]]) [1..3] After another: concatMap (\a - concatMap (\b - [(a,b)]) [1..2]) [1..3] Note that the a - and b - map into \a - and \b - and bind the free variables a and b in the expression (a,b). Dan R J wrote: I can calculate non-nested list comprehensions without a problem, but am unable to calculate nested comprehensions involving, for example, the generation of a list of pairs where the first and separate elements are drawn from two separate lists, as in: [(a, b) | a - [1..3], b - [1..2]] How does one calculate the expansion of this list? The two rules for expanding list comprehensions are: 1. Generator rule: [e | x - xs, Q] = concat (map f xs) where f x = [e | Q] 2. Guard rule: [e | p, Q]= if p then [e | Q] else [] There is a third rule that I've seen on the Internet, not in an authoritative text: [e | Q1 , Q2] = concat [ [e | Q 2] | Q1 ] I don't understand what this third rule means, or whether it's relevant. Concat and map are defined as: concat :: [[a]] - [a] concat []= [] concat (xs:xss) = xs ++ concat xss map :: (a - b) - [a] - [b] map f [] = [] map f (x:xs) = f x : (map f xs) Any help is appreciated. Windows Live™: Keep your life in sync. Check it out. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1b_explore_032009 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
Ok, so I've pulled the latest version and the error I get now is: Hackmain.hs:70:43: Ambiguous type variable `a' in the constraint: `Deliverable a' arising from a use of `getFilterMainStuff' at Hackmain.hs: 70:43-60 Probable fix: add a type signature that fixes these type variable(s) Function getFilterMainStuff compiles just fine . The offending line is in buildConf and reads: (inboxL, fMain) - runUnsafeInterpreter . getFilterMainStuff $ filterMainL The problem is that GHC can't figure out the type of fMain. It infers (Filter a), but doesn't know what is a and therefore how to build a proper dictionary to pass to getFilterMainStuff. Observe that you would get a similar error message if you just defined: f = show . read I can get it to compile by providing a type annotation for fMain: (inboxL, fMain) - runUnsafeInterpreter . getFilterMainStuff $ filterMainL let _ = fMain :: Filter MaildirEmail So once you use fMain somewhere and GHC can infer it's type, everything should work fine. Daniel On Mar 5, 2009, at 11:26 PM, Joseph Fredette wrote: Oh, crap- I must have never pushed the latest patches, I did put the typeable instances in all the appropriate places. And provided a (maybe incorrect? Though I'm fairly sure that shouldn't affect the bug I'm having now) Typeable implementation for Reader, but I still get this ambiguous type. I'll push the current version asap. Thanks. /Joe Daniel Gorín wrote: Hi I've downloaded Hackmain from patch-tag, but I'm getting a different error. The error I get is: Hackmain.hs:63:10: No instance for (Data.Typeable.Typeable2 Control.Monad.Reader.Reader) arising from a use of `interpret' at Hackmain.hs:63:10-67 Hint requires the interpreted values to be an instance of Typeable in order to check, in runtime, that the interpreted value matches the type declared at compile. Therefore, you need to make sure that (Filter a) is indeed an instance of Typeable. Since you have Filter a = Reader (Config, Email) a, you probably need to - Derive Config and Email instances for Filter, - Manually provide Typeable instances for Reader a b, something along the lines of: instance (Typeable a, Typeable b) = Typeable (Reader a b) where... (I don't know why this isn't done in the mtl) - Change the signature to: getFilterMain :: (Typeable a, Deliverable a) = FilePath - Interpreter (Filter a) Also, you can try using infer instead of as :: Hope that helps Daniel On Mar 5, 2009, at 8:47 PM, Joseph Fredette wrote: So, I tried both of those things, both each alone and together. No dice. Same error, so I reverted back to the original. :( However, I was, after some random type signature insertions, able to convert the problem into a different one, via: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain MainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/ ='.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: Deliverable a = Filter a) Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: fMain :: Filter a (bound at Hackmain.hs:77:1) In the first argument of `return', namely `(fMain :: (Deliverable a) = Filter a)' In the expression: return (fMain :: (Deliverable a) = Filter a) In the expression: do loadModules [fMainLoc] setTopLevelModules [(takeWhile (/= '.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: (Deliverable a) = Filter a) I'm thinking that this might be more easily solved -- I do think I understand the issue. somehow, I need to tell the compiler that the 'a' used in the return statement (return (fMain :: ...)) is the same as the 'a' in the type sig for the whole function. While I ponder this, and hopefully receive some more help -- thanks again Dan, Ryan -- Are there any other options besides Hint that might -- at least in the short term -- make this easier? I'd really like to finish this up. I'm _so_ close to getting it done. Thanks, /Joe Ryan Ingram wrote: So, by using the Haskell interpreter, you're using the not-very-well-supported dynamically-typed subset of Haskell. You can tell this from the type signature of interpret: interpret :: Typeable a = String - a - Interpreter a as :: Typeable a = a as = undefined (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html) In particular, the as argument to interpret is specifying what type you want the interpreted result to be typechecked against; the interpretation fails if it doesn't match that type. But you need the result type to be an instance of
Re: [Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
On 2009 Mar 5, at 8:08, Simon Marlow wrote: So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) ...hasn't sigfpe demonstrated time travel using comonads? -- 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 universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Difficulties in accessing inner elements of data types
Well thanks to everyone that has replied so far - I've had an interesting time trying out different ideas. Firstly, for Neil Mitchell's suggestions regarding uniplate: I read through both uniplate and scrap your boilerplate libraries (found the second after reading about uniplate). For whatever reason, I understood syb better than uniplate (but thats probably just me). This actually worked quite well (note that I've changed the data types slightly, but it doesn't change the code that much): eitherOr :: Either a b - Either a b - Either a b eitherOr x@(Right _) _ = x eitherOr _ y = y getP14Desc :: OrgElement - Either ErrString String getP14Desc org = everything eitherOr (Left descError `mkQ` findDesc) = everything eitherOr (Left findError `mkQ` findP14) org where findP14 h@(Heading {headingName=name}) | name == Project14 = Right h findP14 _ = Left findError findDesc (Paragraph {paragraphText=text}) | text =~ Description = Right text findDesc _ = Left findError descError = Couldn't find description for project findError = Couldn't find project. While it isn't that many less loc than my original code, it was much simpler to get working. Also, the find methods could easily be factored out. My second problem, adding the tag Hard to Project2 was also fairly simple: addHardTag org = everywhere (mkT addTagToP2) org where addTagToP2 h@(Heading {headingName=name}) | name == Project 2 = everywhere (mkT addTag) h addTagToP2 x = x addTag text | text =~ Tags: = text ++ ,newtag However, I also wanted to try out Tim Docker's suggestion for using data- accessor. That seemed to also be very promising, except for one thing - data- accessor doesn't seem to be able to cope with multiple constructors! The code for this was faily simple though, so I went about making it work for multiple constructors. The original definition for an Accessor d f (where d is the datatype and f is the type of the field) was Cons {decons :: d - f - (d, f)} -- (this wasn't exported by the module though) There is a problem with that for multiple constructors though - its possible that there will be no return for a given accessor. Eg running get headingName' (Paragraph some text) would not be possible. So I changed the code to this: newtype Accessor1 d f = Accessor (d - Maybe f, f - d - d) If the getter failed, Nothing is returned. If the setter failed, it acts like id. After using that for a while I realized there was potential to have an accessor automatically access all the children of a data type. This could be achieved by changing the return type of the getter to [f], and changing the setter function to a modifier function: newtype MultiConAccessor d f = MultiConAccessor ((d - [f]),((f - f) - d - d)) I also wrote the chain function, which joins to accessors together After a lot of definitions (although most should be able to be automated with template haskell), I could use the code: projectAccessor name = headingChildren' `chain` -- top level elements headingChildren' `chain` -- level 2 liftFilterS (== name) headingName' getP14Desc2 = getVal $ projectAccessor Project14 `chain` headingChildren' `chain` liftFilterS (=~ Description:) paragraphText' `chain` paragraphText' addHardTag2 = modVal (projectAccessor Project 2 `chain` headingChildren' `chain` liftFilterS (=~ Tags:) paragraphText' `chain` paragraphText') (++ ,newtag) I've posted all the code at http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1778#a1778 It isn't very well documented, as I was just experimenting with this. Finally, thanks Sean for your response. That blog post was very nice! Your solution also looks good (especially since most of the code was automated). I haven't had a chance to have a close look at EMGM but will in the next couple of days. So I've gone from having no solution a few days ago to having 3 or 4 now! Not sure which solution I will stick with, any seem to do the job. So thanks everyone! David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe