Re: [Haskell-cafe] Re: [Haskell] ANN: Real World Haskell, now shipping
Is it possible to order it from France yet ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: Real World Haskell, now shipping
dav.vire+haskell: Is it possible to order it from France yet ? http://www.amazon.fr/Real-World-Haskell-Bryan-OSullivan/dp/0596514980/ref=sr_1_1?ie=UTF8s=english-booksqid=1227687031sr=8-1 ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: Real World Haskell, now shipping
On Wed, Nov 26, 2008 at 9:10 AM, Don Stewart [EMAIL PROTECTED] wrote: dav.vire+haskell: Is it possible to order it from France yet ? http://www.amazon.fr/Real-World-Haskell-Bryan-OSullivan/dp/0596514980/ref=sr_1_1?ie=UTF8s=english-booksqid=1227687031sr=8-1 Actually right now I was logging in to Amazon.fr to check :) Thanks. I'm going to order 3 copies and offer 2 for christmas. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: Real World Haskell, now shipping
Actually right now I was logging in to Amazon.fr to check :) It's not available yet on Amazon.fr. I've ordered them anyway, but I'm warned that I will not have them for christmas :( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: Real World Haskell, now shipping
Excerpts from david48's message of Wed Nov 26 09:31:54 +0100 2008: Actually right now I was logging in to Amazon.fr to check :) It's not available yet on Amazon.fr. I've ordered them anyway, but I'm warned that I will not have them for christmas :( I've ordered it on Amazon.fr some months ago and it's planned for the 10 December. -- Nicolas Pouillard aka Ertai ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Problem getting code from AFP08 parallel tutorial to run in parallel
Don Stewart wrote: olivier.boudry: On Tue, Nov 25, 2008 at 3:07 PM, Simon Marlow [EMAIL PROTECTED] wrote: Yes, it's a scheduling bug. I'll make sure it gets fixed for 6.10.2. If you have more sparks then you shouldn't see this problem. Also, GHC HEAD is quite a lot better with parallel programs than 6.10.1, I'll try to get around to posting some figures sometime. Yes, I tried it with 3 sparks and it works, Thanks for your help, What does the code look like? Simon : should we be start to try tthe HEAD for par stuff? Please do - also I'm on the lookout for good benchmarks to add to nofib/parallel. Particularly programs that you think should speed up in parallel but don't - sometimes that helps us find bottlenecks in the runtime. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: Real World Haskell, now shipping
Very excited to receive my copy! Congrats to the 3 of you! On Tue, Nov 25, 2008 at 9:15 PM, Bryan O'Sullivan [EMAIL PROTECTED]wrote: Good evening - John Goerzen, Don Stewart and I are delighted to announce the availability of our book, Real World Haskell. It is 710 pages long, and published by O'Reilly Media. This is the first book to comprehensively cover modern Haskell programming. From an introduction to functional programming, it focuses on teaching through many worked examples. We discuss the awkward squad of I/O, concurrency, and exceptions. We cover network programming, databases, and system hacking. We motivate and work with monoids, applicative functors, monads, and monad transformers. We show you how to debug code, and how to ship well-tested software. Better yet, the book is available under a Creative Commons license, so you can read as much of it as you please before you buy: http://book.realworldhaskell.org/ We developed this book with the enthusiastic and voluble support of the Haskell community, and we are proud to share our work in a fashion that will help newcomers to our field. And best of all, if you order now (at least in North America), you can have a copy of the book in your hands in a matter of days. Thank you from all of us to our friends in the Haskell world who have been so generous with their feedback and kind words! ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IRC question
Does anyone have an IRC client hiding somewhere that is console friendly (I IRC from a screen session) which is also extensible in Haskell? http://www.haskell.org/hircules/ Last update was over 5 years ago - you could try to still build it. But it uses gtk2hs, not ncurses. Personally, I've thought about this as a project *several* times in the past, and somewhere around here, I might have a few bits of code thrown together laying around. The -main- reasons I haven't worked on it any more than I have already is because: A) I was under the impression I was still the only one looking for something like this - or maybe lots of people want an 'xmonad equivilant' of their IRC Client? :) B) My uni. blocks 6667 for some reason, so in order to connect with a terminal IRC client outside of here, I need to use SSL. And there are *no* good SSL wrappers out there at all for Haskell as it stands - this alone is a major inhibitor of usage; I know I always want my clients with SSL support. C) I've been busy. That said, if you would like to really get something started and perhaps hack on some stuff, that would be terrifically fun and interesting. Does anybody have name candidates? Perhaps we should go with the yi scheme from confucianism - the zhi (knowledge) IRC client? ;) Thanks, Jason Austin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs
Hi everybody, This advisory is for people who have installed darcs 2.1.2 via the Cabal build method. As you may have noticed, the cabalised darcs sometimes fails with errors like Codec.Compression.Zlib: incorrect data check Why this happens Older versions of darcs can to produce gzipped files with broken CRCs. We never noticed this because our homegrown wrapper around the C libz library does not pick up these errors. Lately, we have been working on adopting the Haskell zlib wrapper, which is made available by default in darcs.cabal. This new wrapper is more stringent and fails when it encounters these files. Workaround 1 : use C libz instead of Haskell zlib - So how can you work around these errors? If you are building darcs on any Unix-y operating system (e.g. Linux or MacOS X), you can cabal configure darcs to use the old C libz binding: cabal configure -f external-zlib This will restore our homegrown wrapper which ignores the broken CRCs (note that the darcs head no longer *produces* these broken files, thanks to debugging by Matthias Andree and to a bugfix by David Roundy; http://bugs.darcs.net/issue844 for details). In principle, the same advice applies for Windows users, with more details hopefully to follow on how the C libz in a GHC-accesible location. Details to follow. In the meantime, you can either build darcs using the old configure and make technique (assuming you have MSYS and related tools), or use a binary that does not use the Haskell zlib wrapper (for example, by downgrading to http://www.haskell.org/~simonmar/darcs-2.0.2+75.zip ) Workaround 2 : fix your broken gzipped files If you have control over the repositories with broken gzipped files, it should be possible to repair these files by gunzipping them and then redo-ing the gzip. We think that the attached script should help. Please report back if this is not the case. How we will fix this problem in the long term - I'm very sorry for the grief this has caused. To begin with, we will ensure that the 2.2 release gets more testing before releasing it in January. It will also handle these broken CRCs more gracefully. Our plan is to - either extend darcs repair or provide a Haskell script to fix these broken files - detect the broken files and advise users to run darcs repair (or the script) as needed - somewhere in the future, disallow broken CRC files whilst still advising users on how to fix their files. Many thanks! -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: workarounds for Codec.Compression.Zlib errors in darcs
On Wed, Nov 26, 2008 at 14:38:32 +, Eric Kow wrote: Workaround 2 : fix your broken gzipped files If you have control over the repositories with broken gzipped files, it should be possible to repair these files by gunzipping them and then redo-ing the gzip. We think that the attached script should help. Please report back if this is not the case. No advisory is complete without a forgotten attachment. Here it is. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 fix-darcs-crc.sh Description: Bourne shell script signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IRC question
2008/11/26 Galchin, Vasili [EMAIL PROTECTED]: Hello, I am using Ubuntu Linux and I want to get the Haskell IRC feed. What IRC client can I use and how to configure? Thanks, Vasili If you are an Emacs user, then you can either use rcirc or erc M-x erc RET RET RET RET /join #haskell RET -Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] template haskell overly conservative during splicing?
Thanks for the bug report. I've fixed the bug: see http://hackage.haskell.org/trac/ghc/ticket/2817 Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Nicolas Frisby | Sent: 04 November 2008 01:03 | To: haskell Cafe | Subject: [Haskell-cafe] template haskell overly conservative during splicing? | | When using template haskell (via Derive) to generate this (exact) instance: | | instance Foldable ((-) Int) = Foldable | Data.Derivable.InterpreterLib.Test.List | where foldMap f (Cons x0 x1) = (const mempty Cons `mappend` | foldMap f x0) `mappend` foldMap f x1 | foldMap f (Nil) = const mempty Nil | | I realize the context is insatisfiable. My issue, is that I can't even | reach that challenge. I get this error instead: | |Malformed type AppT ArrowT (ConT GHC.Base.Int) | When splicing generated code into the program | | I couldn't find an existing ticket or discussion for this issue | relying on the phrase malformed type. I couldn't even find the | source that generates that string in haskell-src, template-haskell, or | ghc-6.8.2. Can anybody help? | | Thanks for your time. | ___ | 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: [Haskell] ANN: Real World Haskell, now shipping
I'd love it if people took a photo of the book arriving. With enough photos , I could put together a gallery of Haskell around the world :-) Here's my copy arriving last night, http://www.realworldhaskell.org/blog/2008/11/25/real-world-haskell-is-shipping/ And Dino's digital version, http://galois.com/~dons/images/20081121_dm_838.jpg Drop me a line with a photo of yours arriving, and your location, and I'll add it to the gallery. Cheers, Don donnie: Mine arrives in two days; I can't wait! :) Thanks for all your hard work, and to all the members of the community which provided comments/suggestions to improve the book. __ Donnie Jones On Wed, Nov 26, 2008 at 12:15 AM, Bryan O'Sullivan [EMAIL PROTECTED] wrote: Good evening - John Goerzen, Don Stewart and I are delighted to announce the availability of our book, Real World Haskell. It is 710 pages long, and published by O'Reilly Media. This is the first book to comprehensively cover modern Haskell programming. From an introduction to functional programming, it focuses on teaching through many worked examples. We discuss the awkward squad of I/O, concurrency, and exceptions. We cover network programming, databases, and system hacking. We motivate and work with monoids, applicative functors, monads, and monad transformers. We show you how to debug code, and how to ship well-tested software. Better yet, the book is available under a Creative Commons license, so you can read as much of it as you please before you buy: [2]http://book.realworldhaskell.org/ We developed this book with the enthusiastic and voluble support of the Haskell community, and we are proud to share our work in a fashion that will help newcomers to our field. And best of all, if you order now (at least in North America), you can have a copy of the book in your hands in a matter of days. Thank you from all of us to our friends in the Haskell world who have been so generous with their feedback and kind words! ___ Haskell mailing list [EMAIL PROTECTED] [4]http://www.haskell.org/mailman/listinfo/haskell References Visible links 1. mailto:[EMAIL PROTECTED] 2. http://book.realworldhaskell.org/ 3. mailto:[EMAIL PROTECTED] 4. http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monads with take-out options
Greg Meredith wrote: Haskellians, Some monads come with take-out options, e.g. * List * Set In the sense that if unit : A - List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad. Some monads do not come with take-out options, IO being a notorious example. Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available. To amplify other people's comments: List A is just as on the fence as Maybe. [] plays the role of Nothing. Some monads require that you put something in, before you take anything out [r - a, s - (a,s), known to their friends as reader and state] Error is similar to Maybe, but with a more informative Nothing. Most monads provide some kind of runM :: ## - m a - ## a where the ## are meta-syntax, indicating that you might need to pass something in, and you might get something slightly 'funny' out. Something based upon 'a' but not entirely 'a'. The taxonomy of monads is pretty much expressed in the types of these 'run' functions, I think. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monads with take-out options
On Wed, 2008-11-26 at 19:09 +, Jules Bean wrote: Greg Meredith wrote: Haskellians, Some monads come with take-out options, e.g. * List * Set In the sense that if unit : A - List A is given by unit a = [a], then taking the head of a list can be used to retrieve values from inside the monad. Some monads do not come with take-out options, IO being a notorious example. Some monads, like Maybe, sit on the fence about take-out. They'll provide it when it's available. To amplify other people's comments: List A is just as on the fence as Maybe. [] plays the role of Nothing. Some monads require that you put something in, before you take anything out [r - a, s - (a,s), known to their friends as reader and state] Error is similar to Maybe, but with a more informative Nothing. Most monads provide some kind of runM :: ## - m a - ## a More precisely, runM :: f (m a) - g a Where f and g are usually functors. Maybe, of course, has the nice property that g = m. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows vs. Linux x64
On Wednesday 26 November 2008 02:16:26 John Meacham wrote: On Tue, Nov 25, 2008 at 09:39:35PM +0100, Ketil Malde wrote: This corresponds to my experiences - 64 bits is slower, something I've ascribed to the cost of increased pointer size. ghc unfortunatly also uses 64 bit integers when in 64 bit mode, so the cost paid is increased due to that as well, Also since each math instruction needs an extra byte telling it to work on 64 bit data so the code is less dense. I've done little exeriment to confirm this. Created simple pgm and ran it with +RTS -s option on couple different harwareOS configurations. main = (putStrLn . show . head . drop 50) prim divides d n = rem n d == 0 ldf' :: (Integral a) = [a] - a - a ldf' (k:ks) n | divides k n = k | k^2 n = n | otherwise = ldf' ks n prim = filter (\x - ldf' (2:prim) x == x) [3..] Results of experiment: Win32 Core2Duo 1.8GHz 1GB RAM 17 Mb total memory in use MUT time 56.97s ( 57.02s elapsed) %GC time 0.5% Win32 Core2Duo 2.2GHz 2GB RAM 17 Mb total memory in use MUT time 57.44s ( 57.53s elapsed) %GC time 0.7% (0.8% elapsed) Win32 P4 2.8GHz 1GB RAM 17 Mb total memory in use MUT time 171.64s (175.78s elapsed) %GC time 1.7% (1.5% elapsed) Linux64 Core2Duo 2.2GHz 2GB RAM 41 MB total memory in use (1 MB lost due to fragmentation) MUT time 68.26s ( 68.92s elapsed) %GC time 0.9% (1.1% elapsed) Linux32 Core2Duo 2.3GHz 4GB RAM 17 Mb total memory in use MUT time 51.77s ( 51.83s elapsed) %GC time 0.5% (0.6% elapsed) Experiment confirms your explanations. Also interesting how slow P4 is in comparison to C2D. Best and thanks. Bartek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Wait for *either* MVar to be set
Peter Verswyvelen wrote: ... by spawning and killing two threads (which might be an expensive operation, I'm not sure) pretty cheap in GHC -- they're not system threads Am I wrong in this? If so, is this something that might be considered as a future enhancement in the GHC libraries and runtime? Also, look at STM (e.g. TVars), which is designed to do what you want more directly, I think. (timeouts might still use the GHC-thread thing. Don't worry about its performance unless you're measurably suffering from it...) -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: workarounds for Codec.Compression.Zlib errors in darcs
On Wed, Nov 26, 2008 at 14:38:32 +, Eric Kow wrote: Workaround 1 : use C libz instead of Haskell zlib - So how can you work around these errors? If you are building darcs on any Unix-y operating system (e.g. Linux or MacOS X), you can cabal configure darcs to use the old C libz binding: cabal configure -f external-zlib My advice here is incorrect. We want the /opposite/ cabal configure -f -external-zlib Although note that a new version of darcs 2.1.2.3 will be soon on hackage with the new default (unfortunately this makes darcs a bit harder to build on Windows unless you're willing to use Workaround #2 of actually fixing your .gz files) -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow PGP Key ID: 08AC04F9 signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Instances that shouldn't overlap
Hi, I'm trying to set up some operators for applicative versions of prelude types. For instance: -- | Applicative Equality. class (Eq a) = AppEq f a where (.==.), (./=.) :: f a - f a - f Bool instance (Applicative f, Eq a) = AppEq f a where (.==.) = liftA2 (==) (./=.) = liftA2 (/=) Hopefully the intention is fairly straightforward: if f is an instance of Applicative then the lifted implementation of the underlying type. Otherwise I can just give my own instance, which is useful for things that wrap prelude types but where fmap doesn't work. For instance: data (Ord a) = Interval a = Interval a a instance (Ord a) = AppEq Interval a where i1@(Interval _ u1) .==. i2@(Interval _ u2) | isSingleton i1 isSingleton i2 u1 == u2 = Interval True True | has i1 u2 || has i2 u1= Interval False True | otherwise = Interval False False i1 ./=. i2 = let Interval b1 b2 = (i1 .==. i2) in Interval (not b2) (not b1) isSingleton :: (Ord a) = Interval a - Bool isSingleton (Interval lower upper) = lower == upper has :: (Ord a) = Interval a - a - Bool has (Interval lower upper) v = v = lower v = upper You can't (easily) define fmap for Interval because the function given as an argument might not be monotonic. So instead you have to write custom implementations for each lifted function, as shown here for (.==.) and (./=.) . The same principle works for AppOrd, AppNum etc, but I'm trying to solve the problem for just AppEq for now. This compiles, but when I try to use it I get this in ghci: *Interval let i1 = Interval 4 5 *Interval let i2 = Interval 4 6 *Interval i1 .==. i2 interactive:1:0: Overlapping instances for AppEq Interval Integer arising from a use of `.==.' at interactive:1:0-9 Matching instances: instance (Ord a) = AppEq Interval a -- Defined at Interval.hs:(22,0)-(27,78) instance (Control.Applicative.Applicative f, Eq a) = AppEq f a -- Defined at AppPrelude.hs:(32,0)-(34,23) In the expression: i1 .==. i2 In the definition of `it': it = i1 .==. i2 I'm puzzled, because Interval is not an instance of Applicative, so the second instance doesn't apply. Can anyone help me out? I'm using ghc 6.8.3, so its possible that this was a bug fixed in 6.10. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances that shouldn't overlap
Paul Johnson wrote:
Hi,
I'm trying to set up some operators for applicative versions of
prelude types.
I forgot to mention, I'm using {-# OPTIONS_GHC
-fallow-undecidable-instances -XFlexibleInstances
-XMultiParamTypeClasses #-}
Paul.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Compilers
Don Stewart wrote: Noteworthy, * lhc-20081121: “Lhc Haskell Compiler” Interesting. I can't find out any information about this... From time to time you do hear about Haskell compilers that aren't GHC, but I'm not aware of any other compilers that are production-grade yet. Has anybody ever made one? (Hugs is the only one I know of...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Wait for *either* MVar to be set
In fact: import Control.Concurrent.STM import Control.Concurrent.STM.TMVar -- gets a value from one of a list of TMVars takeTMVars :: [TMVar a] - STM (TMVar a, a) takeTMVars = foldr fetch retry where fetch v act = (takeTMVar v = \a - return (v, a)) `orElse` act -- puts the given value into exactly one of a list of TMVars putTMVars :: [TMVar a] - a - STM (TMVar a) putTMVars vs a = foldr put retry vs where put v act = (putTMVar v a return v) `orElse` act -- ryan On Wed, Nov 26, 2008 at 11:41 AM, Isaac Dupree [EMAIL PROTECTED] wrote: Peter Verswyvelen wrote: ... by spawning and killing two threads (which might be an expensive operation, I'm not sure) pretty cheap in GHC -- they're not system threads Am I wrong in this? If so, is this something that might be considered as a future enhancement in the GHC libraries and runtime? Also, look at STM (e.g. TVars), which is designed to do what you want more directly, I think. (timeouts might still use the GHC-thread thing. Don't worry about its performance unless you're measurably suffering from it...) -Isaac ___ 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] Compilers
Hello Andrew, On Wed, Nov 26, 2008 at 4:24 PM, Andrew Coppin [EMAIL PROTECTED]wrote: Don Stewart wrote: Noteworthy, * lhc-20081121: Lhc Haskell Compiler Interesting. I can't find out any information about this... Here is the current homepage for the LHC project: http://lhc.seize.it/ Hope that helps. __ Donnie Jones ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
Jake McArthur wrote: Andrew Coppin wrote: Don Stewart wrote: Noteworthy, * lhc-20081121: “Lhc Haskell Compiler” Interesting. I can't find out any information about this... It is a fork of the JHC compiler, which should be easier to look up. There is also Hugs, as you mentioned. In addition, you may want to look at YHC and NHC. Yeah, the implementations page on the Wiki basically says that there's GHC and Hugs, and there's also these things called YHC, NHC and JHC. All the documentation I've read makes these latter compilers sound highly experimental and unusable. (I don't recall specifically which of them, but I remember hearing it can't even compile the Prelude yet.) They seem like small projects which are probably interesting to hack with, but not much use if you're trying to produce production-grade compiled code to give to a customer... OTOH, I haven't ever attempted to *use* any of these compilers. I only read about them... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Real World Haskell, now shipping
Bryan O'Sullivan wrote: Good evening - John Goerzen, Don Stewart and I are delighted to announce the availability of our book, Real World Haskell. It is 710 pages long, and published by O'Reilly Media. You know, I *was* going to rush out and buy this as soon as it hit the shelves. I was really excited that this book was actually being made, etc. But then I sat and read some of it online, and the more I read it, the more I didn't like it. :-( That sounds horribly negative when these guys have just spend I don't know *how* long perfecting the thing, and I feel like I ought to say something positive as well to make it sound less harsh. But... it all seemed a bit muddled to me. I thought chapter 1 was very strong, and the rest seemed to ramble from topic to topic. I was left feeling kinda disapointed. Then again, one day I sat down and tried to draw a diagram of the essential concepts, techniques and syntax of Haskell and how they're related... The result looked like alphabet soup! It's not clear how you start to explain anything without immediately needing to explain 20 other things you just used to explain the first thing. (Somebody commented recursive tutorials for a recursive language. It was meant as an insult, but I actually kinda like it...) Given that that's the case, I'm not really sure that I could do any better than the Three Kings, so maybe I should just shuffle off and keep my comments to myself. :-/ What I *haven't* done yet is read the chapters where they try to claim that database programming is possible in Haskell. I'll have to do that at some point. Maybe this is where they reveal the Secret Formula that makes this stuff actually work properly... but somehow I doubt it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances that shouldn't overlap
A common mistake (and a confusing bit about typeclasses) is that whether or not the constraints on an instance apply are irrelevant. Specifically, the code instance (Applicative f, Eq a) = AppEq f a means that, given any types f and a, I can tell you how to make them an instance of AppEq. But I also ask you to please add the constraints Applicative f and Eq a. That is to say, only the stuff on the right of the = apply when determining whether an instance applies. If you take out the overlapping specific instance for Interval, the compiler will give you a different error: No instance for Applicative Interval. You can see what happened here: the compiler wants an instance for AppEq Interval Integer. It sees the instance AppEq f a and adds the constraints Ord Integer and Applicative Interval. Ord Integer is already fulfilled, but it can't discharge the constraint on Applicative, so the compile fails. Similarily, in your case, the compiler can't decide whether to apply the Ord a = AppEq Interval a instance, or the Applicative f, Eq a = AppEq f a instance; the right hand sides of the instance declarations both match (and add different constraints to the left hand side). You can use -XOverlappingInstances, but beware, dragons lie in that direction. I think this is a fundamental weakness of the typeclass system, but I haven't seen a design that avoids it for code as complicated as this. On Wed, Nov 26, 2008 at 12:05 PM, Paul Johnson [EMAIL PROTECTED] wrote: Hi, I'm trying to set up some operators for applicative versions of prelude types. For instance: -- | Applicative Equality. class (Eq a) = AppEq f a where (.==.), (./=.) :: f a - f a - f Bool instance (Applicative f, Eq a) = AppEq f a where (.==.) = liftA2 (==) (./=.) = liftA2 (/=) Hopefully the intention is fairly straightforward: if f is an instance of Applicative then the lifted implementation of the underlying type. Otherwise I can just give my own instance, which is useful for things that wrap prelude types but where fmap doesn't work. For instance: data (Ord a) = Interval a = Interval a a instance (Ord a) = AppEq Interval a where i1@(Interval _ u1) .==. i2@(Interval _ u2) | isSingleton i1 isSingleton i2 u1 == u2 = Interval True True | has i1 u2 || has i2 u1= Interval False True | otherwise = Interval False False i1 ./=. i2 = let Interval b1 b2 = (i1 .==. i2) in Interval (not b2) (not b1) isSingleton :: (Ord a) = Interval a - Bool isSingleton (Interval lower upper) = lower == upper has :: (Ord a) = Interval a - a - Bool has (Interval lower upper) v = v = lower v = upper You can't (easily) define fmap for Interval because the function given as an argument might not be monotonic. So instead you have to write custom implementations for each lifted function, as shown here for (.==.) and (./=.) . The same principle works for AppOrd, AppNum etc, but I'm trying to solve the problem for just AppEq for now. This compiles, but when I try to use it I get this in ghci: *Interval let i1 = Interval 4 5 *Interval let i2 = Interval 4 6 *Interval i1 .==. i2 interactive:1:0: Overlapping instances for AppEq Interval Integer arising from a use of `.==.' at interactive:1:0-9 Matching instances: instance (Ord a) = AppEq Interval a -- Defined at Interval.hs:(22,0)-(27,78) instance (Control.Applicative.Applicative f, Eq a) = AppEq f a -- Defined at AppPrelude.hs:(32,0)-(34,23) In the expression: i1 .==. i2 In the definition of `it': it = i1 .==. i2 I'm puzzled, because Interval is not an instance of Applicative, so the second instance doesn't apply. Can anyone help me out? I'm using ghc 6.8.3, so its possible that this was a bug fixed in 6.10. Paul. ___ 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] Instances that shouldn't overlap
Maybe it'd be more intuitive if written backwards: AppEq f a = (Applicative f, Eq a) or even AppEq f a = (Applicative f, Eq a) On 27 Nov 2008, at 00:39, Ryan Ingram wrote: A common mistake (and a confusing bit about typeclasses) is that whether or not the constraints on an instance apply are irrelevant. Specifically, the code instance (Applicative f, Eq a) = AppEq f a means that, given any types f and a, I can tell you how to make them an instance of AppEq. But I also ask you to please add the constraints Applicative f and Eq a. That is to say, only the stuff on the right of the = apply when determining whether an instance applies. If you take out the overlapping specific instance for Interval, the compiler will give you a different error: No instance for Applicative Interval. You can see what happened here: the compiler wants an instance for AppEq Interval Integer. It sees the instance AppEq f a and adds the constraints Ord Integer and Applicative Interval. Ord Integer is already fulfilled, but it can't discharge the constraint on Applicative, so the compile fails. Similarily, in your case, the compiler can't decide whether to apply the Ord a = AppEq Interval a instance, or the Applicative f, Eq a = AppEq f a instance; the right hand sides of the instance declarations both match (and add different constraints to the left hand side). You can use -XOverlappingInstances, but beware, dragons lie in that direction. I think this is a fundamental weakness of the typeclass system, but I haven't seen a design that avoids it for code as complicated as this. On Wed, Nov 26, 2008 at 12:05 PM, Paul Johnson [EMAIL PROTECTED] wrote: Hi, I'm trying to set up some operators for applicative versions of prelude types. For instance: -- | Applicative Equality. class (Eq a) = AppEq f a where (.==.), (./=.) :: f a - f a - f Bool instance (Applicative f, Eq a) = AppEq f a where (.==.) = liftA2 (==) (./=.) = liftA2 (/=) Hopefully the intention is fairly straightforward: if f is an instance of Applicative then the lifted implementation of the underlying type. Otherwise I can just give my own instance, which is useful for things that wrap prelude types but where fmap doesn't work. For instance: data (Ord a) = Interval a = Interval a a instance (Ord a) = AppEq Interval a where i1@(Interval _ u1) .==. i2@(Interval _ u2) | isSingleton i1 isSingleton i2 u1 == u2 = Interval True True | has i1 u2 || has i2 u1= Interval False True | otherwise = Interval False False i1 ./=. i2 = let Interval b1 b2 = (i1 .==. i2) in Interval (not b2) (not b1) isSingleton :: (Ord a) = Interval a - Bool isSingleton (Interval lower upper) = lower == upper has :: (Ord a) = Interval a - a - Bool has (Interval lower upper) v = v = lower v = upper You can't (easily) define fmap for Interval because the function given as an argument might not be monotonic. So instead you have to write custom implementations for each lifted function, as shown here for (.==.) and (./=.) . The same principle works for AppOrd, AppNum etc, but I'm trying to solve the problem for just AppEq for now. This compiles, but when I try to use it I get this in ghci: *Interval let i1 = Interval 4 5 *Interval let i2 = Interval 4 6 *Interval i1 .==. i2 interactive:1:0: Overlapping instances for AppEq Interval Integer arising from a use of `.==.' at interactive:1:0-9 Matching instances: instance (Ord a) = AppEq Interval a -- Defined at Interval.hs:(22,0)-(27,78) instance (Control.Applicative.Applicative f, Eq a) = AppEq f a -- Defined at AppPrelude.hs:(32,0)-(34,23) In the expression: i1 .==. i2 In the definition of `it': it = i1 .==. i2 I'm puzzled, because Interval is not an instance of Applicative, so the second instance doesn't apply. Can anyone help me out? I'm using ghc 6.8.3, so its possible that this was a bug fixed in 6.10. Paul. ___ 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] Compilers
Donnie Jones wrote: Here is the current homepage for the LHC project: http://lhc.seize.it/ Hope that helps. Yes. I found that - it just didn't *say* very much. ;-) I guess like many small projects, they're too busy *doing* it to have time to document it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On Wed, Nov 26, 2008 at 03:29:43PM -0600, Jake McArthur wrote: Interesting. I can't find out any information about this... It is a fork of the JHC compiler, which should be easier to look up. There is also Hugs, as you mentioned. In addition, you may want to look at YHC and NHC. Hmm.. This one is news to me. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Finalisers
Here's an interesting question... Is it possible to attach finalisers to a value? (That is, have some Haskell code executed when the item in question is reclaimed by the GC.) I'm interested in knowing whether a particular data structure is shared (i.e., whether it's safe to mutate it or whether it must be copied first), and a simple reference-counting scheme looks like the easiest option. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On Wed, Nov 26, 2008 at 09:35:01PM +, Andrew Coppin wrote: It is a fork of the JHC compiler, which should be easier to look up. There is also Hugs, as you mentioned. In addition, you may want to look at YHC and NHC. Yeah, the implementations page on the Wiki basically says that there's GHC and Hugs, and there's also these things called YHC, NHC and JHC. All the documentation I've read makes these latter compilers sound highly experimental and unusable. I would't call nhc experimental; it's quite usable, at least for standard Haskell-98 stuff (plus some language extensions). Ciao, Kili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Instances that shouldn't overlap
On Wed, Nov 26, 2008 at 1:54 PM, Miguel Mitrofanov [EMAIL PROTECTED] wrote: Maybe it'd be more intuitive if written backwards: AppEq f a = (Applicative f, Eq a) or even AppEq f a = (Applicative f, Eq a) The first is good, the second isn't. The first says the right thing: if you can prove Applicative f and Eq a, you have a way to prove AppEq f a. The second has the implication the wrong way around. Classes get the implication wrong too: class Eq a = Ord a doesn't say that if you can prove Eq a you can prove Ord a; it says that if you can prove Ord a you can prove Eq a /g -- I am in here ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finalisers
andrewcoppin: Here's an interesting question... Is it possible to attach finalisers to a value? (That is, have some Haskell code executed when the item in question is reclaimed by the GC.) I'm interested in knowing whether a particular data structure is shared (i.e., whether it's safe to mutate it or whether it must be copied first), and a simple reference-counting scheme looks like the easiest option. Yes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On Wed, Nov 26, 2008 at 4:58 PM, Matthias Kilian [EMAIL PROTECTED] wrote: On Wed, Nov 26, 2008 at 09:35:01PM +, Andrew Coppin wrote: It is a fork of the JHC compiler, which should be easier to look up. There is also Hugs, as you mentioned. In addition, you may want to look at YHC and NHC. Yeah, the implementations page on the Wiki basically says that there's GHC and Hugs, and there's also these things called YHC, NHC and JHC. All the documentation I've read makes these latter compilers sound highly experimental and unusable. I would't call nhc experimental; it's quite usable, at least for standard Haskell-98 stuff (plus some language extensions). How old is nhc? I've always thought of it as one of the big three, but I don't really know how far back it goes compared to ghc. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Wait for *either* MVar to be set
On Wed, 2008-11-26 at 13:25 -0800, Ryan Ingram wrote: In fact: import Control.Concurrent.STM import Control.Concurrent.STM.TMVar -- gets a value from one of a list of TMVars takeTMVars :: [TMVar a] - STM (TMVar a, a) takeTMVars = foldr fetch retry where fetch v act = (takeTMVar v = \a - return (v, a)) `orElse` act -- puts the given value into exactly one of a list of TMVars putTMVars :: [TMVar a] - a - STM (TMVar a) putTMVars vs a = foldr put retry vs where put v act = (putTMVar v a return v) `orElse` act Of course those are TMVars, using STM. So in STM it is easy, whereas with MVars it is a bit harder. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs
On Wed, 2008-11-26 at 14:38 +, Eric Kow wrote: Hi everybody, This advisory is for people who have installed darcs 2.1.2 via the Cabal build method. As you may have noticed, the cabalised darcs sometimes fails with errors like Codec.Compression.Zlib: incorrect data check Why this happens Older versions of darcs can to produce gzipped files with broken CRCs. We never noticed this because our homegrown wrapper around the C libz library does not pick up these errors. I should note that one moral of this story is to check that your FFI imports are correct. That is, check they import the foreign functions at the right Haskell types. In this case the mistake was that the foreign function returned a C int, but the Haskell foreign import declaration stated that the C function returned IO () rather than IO CInt. This is where a tool really helps. The hsc2hs tool cannot check the cross-language type consistency while c2hs can. It reads the C header files and generates the FFI imports at the correct Haskell types. The downside is that c2hs is not shipped with ghc, it is a bit slower and it's not quite so good with structures. I think there is a need for a tool like c2hs but that works in a checking mode rather than in a generating mode. It would use much of the same code as c2hs but it would read the C header files and the .hs file (via ghc api) and check that the FFI imports are using the right types. That way it could be run to check a package without the checker tool being needed at build time on every platform. The downside would be that some C header files differ between platforms and c2hs handles this fine while a checker tool might say it's ok on one platform and that may not carry over to another. Still, it would be an improvement on just using raw FFI imports (or hsc2hs, which is really the same thing). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs
duncan.coutts: On Wed, 2008-11-26 at 14:38 +, Eric Kow wrote: Hi everybody, This advisory is for people who have installed darcs 2.1.2 via the Cabal build method. As you may have noticed, the cabalised darcs sometimes fails with errors like Codec.Compression.Zlib: incorrect data check Why this happens Older versions of darcs can to produce gzipped files with broken CRCs. We never noticed this because our homegrown wrapper around the C libz library does not pick up these errors. I should note that one moral of this story is to check that your FFI imports are correct. That is, check they import the foreign functions at the right Haskell types. In this case the mistake was that the foreign function returned a C int, but the Haskell foreign import declaration stated that the C function returned IO () rather than IO CInt. This is where a tool really helps. The hsc2hs tool cannot check the cross-language type consistency while c2hs can. It reads the C header files and generates the FFI imports at the correct Haskell types. The downside is that c2hs is not shipped with ghc, it is a bit slower and it's not quite so good with structures. I think there is a need for a tool like c2hs but that works in a checking mode rather than in a generating mode. It would use much of the same code as c2hs but it would read the C header files and the .hs file (via ghc api) and check that the FFI imports are using the right types. That way it could be run to check a package without the checker tool being needed at build time on every platform. The downside would be that some C header files differ between platforms and c2hs handles this fine while a checker tool might say it's ok on one platform and that may not carry over to another. Still, it would be an improvement on just using raw FFI imports (or hsc2hs, which is really the same thing). Yes, this plagued xmonad's X11 bindings: almost all bugs in the last 12 months were due to FFI bindings. I'd love a hsc2hs -Wall mode. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On Wed, Nov 26, 2008 at 11:14 PM, David Menendez [EMAIL PROTECTED] wrote: How old is nhc? I've always thought of it as one of the big three, but I don't really know how far back it goes compared to ghc. The following page suggests that it was released mid 1994 but there could of course have been earlier releases. http://www.cs.chalmers.se/pub/haskell/nhc/old/ Perhaps Malcolm Wallace knows more. Cheers, Josef ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs
Hello Duncan, Thursday, November 27, 2008, 1:28:21 AM, you wrote: checking mode rather than in a generating mode. It would use much of the same code as c2hs but it would read the C header files and the .hs file (via ghc api) and check that the FFI imports are using the right types. there is FFI imports generator (HSFFIG?), written by Dmitry Golubovsky -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs
On Wed, 2008-11-26 at 14:30 -0800, Don Stewart wrote: I think there is a need for a tool like c2hs but that works in a checking mode rather than in a generating mode. It would use much of the same code as c2hs but it would read the C header files and the .hs file (via ghc api) and check that the FFI imports are using the right types. That way it could be run to check a package without the checker tool being needed at build time on every platform. The downside would be that some C header files differ between platforms and c2hs handles this fine while a checker tool might say it's ok on one platform and that may not carry over to another. Still, it would be an improvement on just using raw FFI imports (or hsc2hs, which is really the same thing). Yes, this plagued xmonad's X11 bindings: almost all bugs in the last 12 months were due to FFI bindings. I'd love a hsc2hs -Wall mode. Right, but it cannot be hsc2hs. The model of hsc2hs simply does cannot support such a thing because it does not actually know the C types of anything. It would have to be more on the model of c2hs, using Language.C to work out the C types and then map them to Haskell ones, to check they're the same as the declared types in the .hs files. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs
... to work out the C types and then map them to Haskell ones, to check they're the same as the declared types in the .hs files. I'd like to point out that the FFI specification already has such a mechanism. That is, if you use the optional specification of a header file for each foreign import, and if your Haskell compiler can compile via C, then any checking that types match between Haskell and C can be performed automatically, by the backend C compiler. [ OK, so that is not the whole story, and there are good reasons why it might not always work out, but I still think it was an important principle in the original FFI design. ] Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build tools and Cabal
On Tue, Nov 25, 2008 at 8:18 PM, Duncan Coutts [EMAIL PROTECTED] wrote: On Tue, 2008-11-25 at 01:30 +, John Lato wrote: Hello, Cabal allows specifying arguments for tools it recognizes on the command line, e.g. runhaskell Setup.hs configure --c2hs-option=some_option Unfortunately, I can't find a way to make this work with .cabal (or .buildinfo) files, except for the specific cases of ghc, hugs, and nhc98 options. Am I missing something? No. If not, could this be added easily? Yes, but it's not clear that we should. It would be very helpful as I'm trying to work around the broken cpp Apple provides. Perhaps we should do the workaround once rather than adding the workaround to every package. What is the problem exactly? This is with c2hs on a Mac. Using $ cpp --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367) Copyright (C) 2005 Free Software Foundation, Inc. $ c2hs -d trace --cppopts=-I/Library/Frameworks/CsoundLib.framework/Headers Interface.chs Attempting to read file `Interface.chs'... ...parsing `Interface'... ...successfully loaded `Interface'. Invoking cpp as `cpp -x=c -I/Library/Frameworks/CsoundLib.framework/Headers Interface.chs.h Interface.i'... Attempting to read file `Interface.i'... ...parsing `Interface.i'... c2hs: Error in C header file. /usr/include/sys/resource.h:167: (column 1) [FATAL] Syntax error! The symbol `/' does not fit here. This error appears in other files too, at least /usr/include/sys/signal.h. There are also some errors caused by the csound.h file, but I can probably get the csound maintainers to change that. The problem with csound.h is that it has a few #defines preceded by whitespace, which Apple's cpp chooses to leave in the output rather than process. The problem with signal.h and resource.h is that they have //comments, which cpp again chooses to retain, causing the error when Interface.i is being parsed. Oddly, cpp leaves the //comments in place even when called with -x=c++. My workaround is to configure with --c2hs-option=--cpp=gcc --c2hs-option=--cppopt=-E --c2hs-option=--cppopt=-xc. This has the desired behavior, but it's a lot for a user to type in. I could make a script to call configure with the correct options, but that sort of system-dependent configuration seems like exactly the sort of thing that cabal and configure are supposed to be able to work out. So that's the problem. I don't know if this should be addressed as a cabal issue or a c2hs issue. I would say that it's Apple's problem, but that won't help moving to a solution. I'm not even sure that Apple's software is doing anything technical incorrect. Regards, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs
On Wed, Nov 26, 2008 at 3:16 PM, Malcolm Wallace [EMAIL PROTECTED] wrote: ... to work out the C types and then map them to Haskell ones, to check they're the same as the declared types in the .hs files. I'd like to point out that the FFI specification already has such a mechanism. That is, if you use the optional specification of a header file for each foreign import, and if your Haskell compiler can compile via C, then any checking that types match between Haskell and C can be performed automatically, by the backend C compiler. [ OK, so that is not the whole story, and there are good reasons why it might not always work out, but I still think it was an important principle in the original FFI design. ] Would this method work with return types since C compilers tend to let you ignore those? In this example that brought up this discussion it was in fact an ignored return value that caused the problem. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finalisers
Possible, yes. Advisable, no. There is no guarantee that the finaliser is ever run, they are expensive (since they need to be kept separately and checked after each GC) and there are easier methods. Lava [1] uses a very lightweight sharing detection mechanism. Depending on your problem you might also want to look at Oleg's approach to explicit sharing in a DSL [2]. [1]: http://www.cs.chalmers.se/~koen/Lava/papers.html [2]: http://www.mail-archive.com/haskell-cafe@haskell.org/msg37765.html 2008/11/26 Andrew Coppin [EMAIL PROTECTED]: Here's an interesting question... Is it possible to attach finalisers to a value? (That is, have some Haskell code executed when the item in question is reclaimed by the GC.) I'm interested in knowing whether a particular data structure is shared (i.e., whether it's safe to mutate it or whether it must be copied first), and a simple reference-counting scheme looks like the easiest option. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On 27/11/2008, at 8:35 AM, Andrew Coppin wrote: Jake McArthur wrote: Andrew Coppin wrote: Don Stewart wrote: Noteworthy, * lhc-20081121: “Lhc Haskell Compiler” Interesting. I can't find out any information about this... It is a fork of the JHC compiler, which should be easier to look up. There is also Hugs, as you mentioned. In addition, you may want to look at YHC and NHC. Yeah, the implementations page on the Wiki basically says that there's GHC and Hugs, and there's also these things called YHC, NHC and JHC. All the documentation I've read makes these latter compilers sound highly experimental and unusable. (I don't recall specifically which of them, but I remember hearing it can't even compile the Prelude yet.) They seem like small projects which are probably interesting to hack with, but not much use if you're trying to produce production-grade compiled code to give to a customer... OTOH, I haven't ever attempted to *use* any of these compilers. I only read about them... Don't forget hbc. There's plenty of information about all the compilers in the history of haskell paper, including a timeline: http://research.microsoft.com/users/simonpj/papers/history-of-haskell/index.htm Cheers, Bernie.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On 27 Nov 2008, at 10:56 am, Andrew Coppin wrote: Donnie Jones wrote: Here is the current homepage for the LHC project: http://lhc.seize.it/ Yes. I found that - it just didn't *say* very much. ;-) I really really wish there were just one more sentence on that page saying WHY there is a fork of JHC. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On Wed, Nov 26, 2008 at 6:19 PM, Richard O'Keefe [EMAIL PROTECTED] wrote: On 27 Nov 2008, at 10:56 am, Andrew Coppin wrote: Donnie Jones wrote: Here is the current homepage for the LHC project: http://lhc.seize.it/ Yes. I found that - it just didn't *say* very much. ;-) I really really wish there were just one more sentence on that page saying WHY there is a fork of JHC. I spoke with the author of the fork a bit in IRC around the time it happened and my understanding is that: 1) John sternly objects to using cabal as the build system for JHC 2) JHC was seeing very little development activity by John 3) The author of the fork has philosophically different ideas about project management I really hope JHC and LHC can continue to share code and are able to be collaborating projects instead of competing ones. We can see that LHC already has an increase in activity and the new team that is forming is very interested in clean up and factorization. That is, I've seen some good discussions about using libraries instead of project specific functionality between LHC contributors. I hope John doesn't take the fork as any sort of aggressive or insulting action. He's made a compiler that is sufficiently interesting to have users that want to take over. I'm not involved in either fork in either way, but it's quite interesting to watch and I can see parallels to a different Haskell project. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Philip Wadler video on Howard-Curry Correspondence ???
Hello, I am reading re-reading Prof. Wadler paper Proofs are Programs: 19th Century Logic and 21st Century Computing but also want to re-read watch his video on same subject. ??? Very kind thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need machine for DPH benchmarking
Hi all, we, the DPH team, are at the moment in the very unfortunate situation of not having a proper machine for running our benchmarks on. Could a kind soul maybe give us (i.e., me) access to a quadcore or 2xquadcore x86 Linux or OS X machine? I only need to build ghc on it and run small benchmarks which never take more than a couple of minutes, maybe once every couple of days or so. We do need to use all cores, though, so no other CPU-intensive processes can be running during benchmarking. This is only for a week or two, until we get our own machine. We would be eternally grateful and won't forget you when DPH takes over the world. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Instances that shouldn't overlap
Paul Johnson wrote: class (Eq a) = AppEq f a where instance (Applicative f, Eq a) = AppEq f a where instance (Ord a) = AppEq Interval a where In Haskell, instances are selected based solely on the types in the head. Constraints like `Applicative f' are not consulted when the instance is being selected. Rather, constraints are checked after the instance has been selected. The above two instances are overlapping since Interval is a particular case of `f'. That said, it is possible to select an instance based on constraints. The approach is described at http://haskell.org/haskellwiki/GHC/AdvancedOverlap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
