- Haskell-Cafe - Haskell.org

Quasi quotation question
by jean-christophe mincke 20 Nov '10

20 Nov '10

Hello, Is it possible for a quasi quoter to have access to information about haskell identifiers declared before the quasi-quotation? I tried the 'reify' function but without success. Just as in the following exemple: a = 6 x = [$expr|a|] Where the generated haskell code is a= 6 x = a Thank you Regards J-C

2 1

GitIt
by Andrew Coppin 19 Nov '10

19 Nov '10

The other day, I did a slightly foolish thing. I uttered the command cabal install gitit Actually, while I was "foolish", it actually worked better than you'd think. It wanted to install several thousand billion packages, but all of them compiled without issue. Well, all except one. You see, for reasons that I have yet to determine, cabal is *convinced* that gitit transitively requires the "unix" package. Astonishingly, this doesn't work on Windows. :-P Question: Why does 90% of the network-related stuff on Hackage require the unix package? What's in there that's so network-related? I don't understand. We've *got* a portable "network" package that works on all platforms, so...? Anyway, on further investigation, it appears that the culprit is "cautious-file". If a certain CPP flag it set, "unix" gets added to the Build-Depends: field. Except... I didn't set any CPP flags! What the hell? So I manually edit the package description (!), and now it builds and installs perfectly happily. So now I tell cabal to install gitit again... and it immediately tries to install unix, even though the only package that (it thinks) requires unix is already installed? Wuh? So I unpack gitit and tell cabal to build it. Building takes about 30 seconds. *Linking* takes about 4 minutes (??!) And then it fails due to some missing symbols. (No, I don't remember off the top of my head what they were.) At this point, I am completely lost. Does anybody have any ideas on how I can make GitIt work, short of installing Linux? I've searched and searched and I can't see a pre-built binary anywhere.

2 2

Impredicative Types
by Gregory Crosswhite 19 Nov '10

19 Nov '10

Hey everyone! I haven't had a chance to try out GHC 7 myself, but I saw in the documentation that Impredicative Types are still supported. Is this true? I thought that they were on their way out because they overcomplicated type checking; has this plan been changed? Cheers, Greg

3 5

a simple question about types
by Jerzy M 19 Nov '10

19 Nov '10

Hallo, let me take this simple function: (2*). If I check its type :t (2*) I'll obtain (2*) :: (Num a) => a -> a But now it suffices to write g = (2*) and check :t g to obtain g :: Integer -> Integer One more combination, now I write h x = (2*) x and check once more :t h to get h :: (Num a) => a -> a So my question is: why (in this second example) Integer is inferred? What makes a difference? Jerz

6 6

Problem with linking HDBC-ODBC
by hanjoosten 19 Nov '10

19 Nov '10

Hi Yesterday I upgraded to the new version of hdbc-odbc (2.2.3.1.). Then I rebuilt my own project, but the linker gives an error: . . . [88 of 90] Compiling CC ( CC.hs, C:\eclipseworkspace_fp1\ampersand\out\CC.o ) [89 of 90] Compiling Parser ( Parser.hs, C:\eclipseworkspace_fp1\ampersand\out\Parser.o ) [90 of 90] Compiling Main ( Main.hs, C:\eclipseworkspace_fp1\ampersand\out\Main.o ) Linking C:\eclipseworkspace_fp1\ampersand\bin\adl.exe ... C:\Documents and Settings\nl22118\Application Data\cabal\HDBC-odbc-2.2.3.1\ghc-6.12.3/libHSHDBC-odbc-2.2.3.1.a(Statement.o):fake:(.text+0x1a3d): undefined reference to `SQLNumParams' C:\Documents and Settings\nl22118\Application Data\cabal\HDBC-odbc-2.2.3.1\ghc-6.12.3/libHSHDBC-odbc-2.2.3.1.a(Statement.o):fake:(.text+0x3961): undefined reference to `SQLNumParams' collect2: ld returned 1 exit status Is there anything I do wrong? My environment is a windows machine. I use the haskell-platform. I upgraded to the current version of hdbc-odbc using cabal install. Any suggestions are welcome. -- View this message in context: http://haskell.1045720.n5.nabble.com/Problem-with-linking-HDBC-ODBC-tp32721… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 0

borked windows environment, want to start over
by Michael Litchard 19 Nov '10

19 Nov '10

I think I may have borked things good using cygwin. I want to remove it and do a clean install of haskell platform w/out cygwin. What do I need to do to make sure all configuration files have been removed?

6 9

How to generalize executing a series of commands, based on a list?
by Peter Schmitz 19 Nov '10

19 Nov '10

I am able to use System.Cmd (system) to invoke a shell command and interpret the results. Please see the code below that works okay for one such command. (I invoke a program, passing two args.) I am wondering how to generalize this to do likewise for a series of commands, where the varying args (filenames, in this case) are in a list ('inOutLeafs'). I will also want to accumulate some results; probably just a failure count at this time. Any advice or pointers to examples would be much appreciated. Thanks in advance, -- Peter > run :: ... -> IO (Int) -- will return a fail count > run > -- some args to this function here... > = do > -- ... set up: inputLeafs, outputLeafs, etc. > > -- zip two lists of filenames: > let inOutLeafs = zip inputLeafs outputLeafs > > -- the first pair for the first command: > let (inFile1,outFile1) = head inOutLeafs > > -- build 1st command using 1st pair of filenames: > let cmd1 = ... > > exitCode <- system cmd1 > case (exitCode) of > ExitSuccess -> do > putStrLn $ "-- OK." > return 0 > ExitFailure failCnt -> do > putStrLn $ "-- Failed: " ++ show failCnt > return 1

4 6

Space not reclaimed by GC
by Neil Mitchell 18 Nov '10

18 Nov '10

Hi, I have a program which runs, then calls performGC multiple times. I'd expect all (or nearly all) of the memory to be freed by that point. But it isn't. Given this program: import Language.Haskell.Exts.Annotated -- from haskell-src-exts import System.Mem main :: IO () main = do let src = fromParseResult $ parseFileContents $ "data C = C {a :: F {- " ++ replicate 400000 'd' ++ " -} }" putStrLn $ "Total length is: " ++ show (length $ show $ src) performGC performGC performGC I run with: ghc --make Temp.hs -rtsopts && Temp.exe +RTS -G1 -S (the use of 1 generation is to make sure all GC's clear up everything, the leak still happens without it). I am using GHC 7.0.1 I get the output: Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap ... lots of values ... 16187336 9598808 9600428 0.05 0.06 0.47 0.66 0 0 (Gen: 0) 19513288 11571104 11572724 0.06 0.07 0.55 0.77 0 0 (Gen: 0) 23519176 13948292 13949912 0.09 0.08 0.67 0.89 0 0 (Gen: 0) Total length is: 4226 24645752 548 2091128 0.00 0.00 0.75 0.98 0 0 (Gen: 0) 20 540 2091120 0.00 0.00 0.75 0.99 0 0 (Gen: 0) 0 540 2091120 0.00 0.00 0.75 1.00 0 0 (Gen: 0) 1288 844 3028 0.00 0.00 0.75 1.01 0 0 (Gen: 0) 0 0.00 0.00 162,592,312 bytes allocated in the heap 81,004,756 bytes copied during GC 13,949,912 bytes maximum residency (30 sample(s)) 226,344 bytes maximum slop 63 MB total memory in use (6 MB lost due to fragmentation) Generation 0: 30 collections, 0 parallel, 0.48s, 0.51s elapsed INIT time 0.02s ( 0.02s elapsed) MUT time 0.25s ( 0.47s elapsed) GC time 0.48s ( 0.51s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.75s ( 1.01s elapsed) %GC time 64.6% (50.6% elapsed) Alloc rate 613,093,182 bytes per MUT second Productivity 33.3% of total user, 24.7% of total elapsed QUESTION 1: My reading of this report is that performGC leaves 2091120 of live data. However, the program seems to run a GC on termination, when only 3028 bytes of data are left. Why is all the data not released on performGC? QUESTION 2: It seems that the haskell-src-exts parser has some kind of space leak in "data C = C {a :: F {- ddddd -} }", but not in "data C = C {a :: F} {- ddddd -}". That's fair enough, but is it because it's a space leak that performGC doesn't get the data? If I change to the second form then the in use memory after performGC is about 3Kb. I found that if I did the parseFileContents/print bit once I get 2Mb of leak, if I do it twice I get 2Mb, and if I do it three times I get 1Mb of leak, which really confused me. Thanks, Neil

1 0

[ANNOUNCE] A Haskell interface to Lego Mindstorms NXT
by Mitar 18 Nov '10

18 Nov '10

Hi! I have just published my library which provides Haskell interface to Lego Mindstorms NXT over Bluetooth. http://hackage.haskell.org/package/NXT So take your NXTs out of your closets or out of your children hands and try it out! ;-) Feel free to contribute additional features, interfaces for more sensors and propose or write other (example) programs. I also more than welcome any comments as it is my first library in Haskell. So if you have any suggestion about code improvements or some other best practices, I would really like to hear them. Currently haddock documentation does not compile because of this bug: http://hackage.haskell.org/trac/hackage/ticket/656 Can anybody help with fixing this bug? It would be much nicer to see all documentation on HackageDB I made. Mitar

1 0

Papers discussing interpreters for call by need?
by oleg＠okmij.org 18 Nov '10

18 Nov '10

David Sankel wrote: > I'm writing an interpreter for a call by need language... Is anyone > aware of any papers out there that go into detail on the construction > of an actual interpreter? You might find the following call-by-need interpreter useful: http://okmij.org/ftp/tagless-final/tagless-typed.html#call-by-any http://okmij.org/ftp/tagless-final/course/CBAny.hs (the files also implement interpreters for the other two popular strategies). The key to call-by-need is the `share' function, whose more complex instance is described in the paper mentioned here yesterday: http://okmij.org/ftp/Computation/monads.html#lazy-sharing-nondet

1 0

Haskell Weekly News: Issue 159 - November 17, 2010
by Daniel Santa Cruz 18 Nov '10

18 Nov '10

Welcome to issue 159 of the HWN, a newsletter covering developments in the [1]Haskell community in the week of November 07 - 13. We have a new GHC to celebrate! On November 16 the GHC team announced the [2]release of GHC 7.0.1. Plenty of goodness here, with many bug fixes and numerous performance improvements over the previous 6.12 branch. The good folks at GHC remind us that most users should countinue to use the Haskell Platform. This "release is aimed primarily at package maintainers and early adopters." Many kudos to the team! Curious about the most active members of the #haskell IRC channel? Out of around 28K "utterances" in the channel this week, 24% of them where spoken by the top 5 most active members. Not suprisingly, the dear lambdabot is at the top of the list. lambdabot 2094 kmc 1263 jmcarthur 1221 Eduard_Munteanu 1142 EvanR-work 1007 This week we had 299 messages posted to Haskell-Cafe (down 79 from last week), 26 stories posted to Reddit (4 less than last week), 36 questions posted to StackOverflow (4 less than last week), and 135 updates to Hackage (39 more than last week). Fun to see the different package maintainers upgrading their packages to the new GHC. Announcements Simon Meier uploaded [3]blaze-builder, a library which provides an abstraction of buffered output of byte streams and several convenience functions to exploit it. He notes that blaze-builder was inspired by the Data.Binary.Builder module. David Peixotto introduced the [4]Fibon benchmark tools and suite for running and analyzing programs. It includes an optional set of benchmark programs, including many taken from Hackage. Tom Lokhorst uploaded [5]language-cil, a library for manipulating Common Intermediate Language, the lowest level language used by Microsoft .NET and Mono. Janis Voigtländer announced that the [6]Haskell Communities and Activities Report is now available in both PDF and HTML format. Check it out and see what others in the community are doing. The list of contributors should be enough to convince you to read it! Top Reddit Stories * Manatee - a Haskell integrated environment written in Haskell Domain: hackage.haskell.org, Score: 34, Comments: 11 On Reddit: http://www.reddit.com/r/haskell/comments/e43y6/manatee_a_haskell_integrated… Original: http://hackage.haskell.org/package/manatee * A Neighborhood of Infinity: Statistical Fingertrees Domain: blog.sigfpe.com, Score: 31, Comments: 4 On Reddit: http://www.reddit.com/r/haskell/comments/e3iph/a_neighborhood_of_infinity_s… Original: http://blog.sigfpe.com/2010/11/statistical-fingertrees.html * November 2010 edition of the Haskell Communities and Activities Report Domain: haskell.org, Score: 28, Comments: 3 On Reddit: http://www.reddit.com/r/haskell/comments/e3dps/november_2010_edition_of_the… Original: http://haskell.org/communities/11-2010/html/report.html * Please Break Yesod Domain: docs.yesodweb.com, Score: 28, Comments: 0 On Reddit: http://www.reddit.com/r/haskell/comments/e4qfk/please_break_yesod/ Original: http://docs.yesodweb.com/blog/please-break-yesod/ * "Atomo - The programmer's programmable programming language" -- written in Haskell Domain: atomo-lang.org, Score: 28, Comments: 10 On Reddit: http://www.reddit.com/r/haskell/comments/e5m3i/atomo_the_programmers_progra… Original: http://atomo-lang.org/ * Language.Cil Domain: hackage.haskell.org, Score: 27, Comments: 11 On Reddit: http://www.reddit.com/r/haskell/comments/e2fwm/languagecil/ Original: http://hackage.haskell.org/package/language-cil * Defragmenting lazy bytestrings for better performance Domain: lambda-view.blogspot.com, Score: 25, Comments: 0 On Reddit: http://www.reddit.com/r/haskell/comments/e4cbg/defragmenting_lazy_bytestrin… Original: http://lambda-view.blogspot.com/2010/11/defragmenting-lazy-bytestrings.html * "We are looking for someone who has experience in porting **from** Haskell to java" Domain: haskell.org, Score: 22, Comments: 33 On Reddit: http://www.reddit.com/r/haskell/comments/e4km8/we_are_looking_for_someone_w… Original: http://www.haskell.org/pipermail/haskell-cafe/2010-November/086228.html * Zeno: Automatically Prove Haskell Program Properties Domain: doc.ic.ac.uk, Score: 21, Comments: 5 On Reddit: http://www.reddit.com/r/haskell/comments/e5ph3/zeno_automatically_prove_has… Original: http://www.doc.ic.ac.uk/~ws506/tryzeno/ * Tips on a Computer Algebra System in Haskell? Domain: self.haskell, Score: 20, Comments: 17 On Reddit: http://www.reddit.com/r/haskell/comments/e348f/tips_on_a_computer_algebra_s… Original: http://www.reddit.com/r/haskell/comments/e348f/tips_on_a_computer_algebra_s… Top StackOverflow Questions * Is performance of partial or curried functions well defined in Haskell? votes: 13, answers: 4 http://stackoverflow.com/questions/4166924/is-performance-of-partial-or-cur… * What Self Balancing Tree is simplest in Functional Programming? votes: 11, answers: 3 http://stackoverflow.com/questions/4166027/what-self-balancing-tree-is-simp… * Attoparsec allocates a ton of memory on large 'take' call. votes: 7, answers: 0 http://stackoverflow.com/questions/4151265/attoparsec-allocates-a-ton-of-me… * Emacs Haskell indentation votes: 7, answers: 1 http://stackoverflow.com/questions/4169962/emacs-haskell-indentation * What is the difference between Pattern Matching and Guards? votes: 5, answers: 4 http://stackoverflow.com/questions/4156727/what-is-the-difference-between-p… * Impact on style of GHC -Wall votes: 5, answers: 4 http://stackoverflow.com/questions/4174629/impact-on-style-of-ghc-wall * Cartesian product votes: 4, answers: 9 http://stackoverflow.com/questions/4119730/cartesian-product * What's wrong with my type signatures here? votes: 4, answers: 1 http://stackoverflow.com/questions/4125692/whats-wrong-with-my-type-signatu… * combining StateT and State votes: 4, answers: 2 http://stackoverflow.com/questions/4138671/combining-statet-and-state * Useful projects in Haskell votes: 4, answers: 2 http://stackoverflow.com/questions/4167864/useful-projects-in-haskell Quotes of the week * hpc: (<$>) = fmap; (<*>) = magic * medfly: it's awesome not to be an expert here. you ask questions that you think are difficult and they are so easy to others that they are all excited to explain it to you. * EvanR: think of [grant applications] as the interface to the real world, like the IO monad * ray: every paul graham essay contains an ad-hoc, informally specified implementation of a good idea About the Haskell Weekly News New editions are posted to [7]the Haskell mailing list as well as to [8]the Haskell Sequence and [9]Planet Haskell. [10]RSS is also available, and headlines appear on [11]haskell.org. To help create new editions of this newsletter, please send stories to dstcruz * at * gmail * dot * com. The code used to produce this version of the newsletter is not yet publicly available, as it is a complete hack designed to get things started again. Until next time, Daniel Santa Cruz References 1. http://haskell.org/ 2. http://new-www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.ht… 3. http://article.gmane.org/gmane.comp.lang.haskell.general/18283 4. http://article.gmane.org/gmane.comp.lang.haskell.general/18288 5. http://groups.google.com/group/haskell-cafe/browse_thread/thread/9f73730058… 6. http://groups.google.com/group/haskell-cafe/browse_thread/thread/860f3a2e9c… 7. http://www.haskell.org/mailman/listinfo/haskell 8. http://sequence.complete.org/ 9. http://planet.haskell.org/ 10. http://sequence.complete.org/node/feed 11. http://haskell.org/

2 1

Papers discussing interpreters for call by need?
by David Sankel 18 Nov '10

18 Nov '10

I'm writing an interpreter for a call by need language and have been doing a direct implementation of the Launchbury semantics. My problem is that in the variable rule, an alpha conversion is done that, as far as I understand, is going to hinder any tail call optimization. I realize that the intent of Launchbury's paper is to come up with a theoretical framework for call by need, not to guide an implementation per say. Is anyone aware of any papers out there that go into detail on the construction of an actual interpreter? TIA, David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

2 2

[ANNOUNCE] Parallel Haskell project underway
by Dmitry Astapov 17 Nov '10

17 Nov '10

Parallel Haskell project underway GHC HQ and Well-Typed are pleased to report that work has started on the MSR-funded project to push the real-world use of parallel Haskell. We will be working with four industrial partners over the next two years, with the aim of demonstrating that parallel Haskell can be employed successfully in industrial projects. The participating organizations are: * Dragonfly (New Zealand) * IIJ Innovation Institute Inc. (Japan) * Los Alamos National Laboratory (USA) * Willow Garage Inc. (USA) Each group is working on their own project, applying parallel Haskell and their domain-specific expertise. In addition to providing advice on Haskell tools and techniques, we will work with these partners to identify and resolve any issues that are hindering progress. We are prepared to handle issues covering anything from the compiler and runtime system, through to platform, tool and library problems. All the participants are working on complex, real-world problems. Three projects involve scientific problems, and the fourth involves network servers. Three of the projects are targeting single-node SMP systems, while the fourth is targeting clusters. In two cases, Haskell will be directly pitted against existing code written in C or C++. Project progress reports will be posted to the Well-Typed blog [1] and to the new Parallel Haskell mailing list [2]. [1]: http://www.well-typed.com/blog/ [2]: http://groups.google.com/group/parallel-haskell == Dragonfly == http://www.dragonfly.co.nz/ Participants: Finlay Thompson, Edward Abraham Cloudy Bayes: Hierarchical Bayesian modeling in Haskell The Cloudy Bayes project aims to develop a fast Bayesian model fitter that takes advantage of modern multiprocessor machines. It will support model descriptions in the BUGS model description language (WinBUGS, OpenBUGS, and JAGS). It will be implemented as an embedded domain specific language (EDSL) within Haskell. A wide range of model hierarchical Bayesian model structures will be possible, including many of the models used in medical, ecological, and biological sciences. Cloudy Bayes will provide an easy to use interface for describing models, running Monte Carlo Markov chain (MCMC) fitters, diagnosing performance and convergence criteria as it runs, and collecting output for post-processing. Haskell's strong type system will be used to ensure that model descriptions make sense, providing a fast, safe development cycle. == IIJ Innovation Institute Inc. == http://www.iij-ii.co.jp/en/ Participants: Kazu Yamamoto Haskell is suitable for many kinds of domain, and GHC's support for lightweight threads makes it attractive for concurrency applications. An exception has been network server programming because GHC 6.12 and earlier have an IO manager that is limited to 1024 network sockets. The upcoming GHC 7 has a new IO manager implementation that gets rid of this limitation. This project will implement several network servers to demonstrate that Haskell is suitable for network servers that handle a massive number of concurrent connections. == Los Alamos National Laboratory == http://www.lanl.gov/ Participants: Michael Buksas, Timothy M. Kelley This project will use parallel Haskell to implement high-performance Monte Carlo algorithms, a class of algorithms which use randomness to sample large or otherwise intractable solution spaces. The initial goal is a particle-based MC algorithm suitable for modeling the flow of radiation, with application to problems in astrophysics. From this, the project is expected to move to identification of suitable abstractions for expressing a wider variety of Monte Carlo algorithms, and using models for different physical phenomena. == Willow Garage == http://www.willowgarage.com/ Participants: Ryan Grant Distributed Rigid Body Dynamics in ROS Willow Garage seeks a high-level representation for a distributed rigid body dynamics simulation, capable of excellent parallel speedup on current and foreseeable hardware, yet linking to existing optimized libraries for low-level message passing and matrix math. This project will drive API, performance, and profiling tool requirements for Haskell's interface to the Message Passing Interface (MPI) specification, an industry-standard in High Performance Computing (HPC), as used on clusters of many nodes. Competing internal initiatives use C++/MPI and CUDA directly. Willow Garage aims to lay the groundwork for personal robotics applications in everyday life. ROS (Robot Operating System - ROS.org) is an open source, meta-operating system for your robot. -- Dmitry Astapov Well-Typed LLP, http://www.well-typed.com/

2 2

Re: Making monadic code more concise
by oleg＠okmij.org 17 Nov '10

17 Nov '10

Ling Yang wrote > I think a good question as a starting point is whether it's possible > to do this 'monadic instance transformation' for any typeclass, and > whether or not we were lucky to have been able to instance Num so > easily (as Num, Fractional can just be seen as algebras over some base > type plus a coercion function, making them unusually easy to lift if > most typeclasses actually don't fit this description). > > In general, what this seems to be is a transformation on functions > that also depends explicitly on type signatures. For example in Num: Things start to break down when we get to the higher order. In the first order, it is indeed easy to see that the monadification of the term Int -> Int -> Int should/could be m Int -> m Int -> m Int Indeed, liftM2 realizes this transformation. But what about (Int -> Int) -> Int ? Should it be (m Int -> m Int) -> m Int ? A moment of thought shows that there is no total function of the type Monad m => ((Int -> Int) -> Int) -> ((m Int -> m Int) -> m Int) because there is no way, in general, to get from (m Int -> m Int) to the pure function Int->Int. That is, we can't write Monad m => (m Int -> m Int) -> m (Int->Int) One may try tabulation (for finite domains) tf f = do vt <- f (return True) vf <- f (return False) return $ \x -> if x then vt else vf but that doesn't quite work: what if the resulting function is never invoked on the True argument. We have needlessly computed that value, vt. Worse, we have incurred the effect of computing vt; that effect could be failure. We have needlessly failed. One can say: we need runnable > class (Monad m) => Runnable m where > exit : m a -> a are there many monads that are members of that typeclass? For example, Maybe cannot be Runnable; otherwise, what is (exit Nothing)? Any Error or MonadPlus monad can't be Runnable.

3 4

Re: ANNOUNCE zeno 0.1.0
by Petr Pudlak 17 Nov '10

17 Nov '10

Hi Will, I was wondering, Zeno capable of proving just equational statements, or is it able to prove more general statements about programs? In particular, it would be interesting if Zeno would be able to prove that a function is total by verifying that it uses only structural (inductive) recursion (on a well defined inductive type), i.e. each recursive function call must be on a syntactic subcomponent of its parameter. And dually, one might want to prove that a function is corecursive, meaning that each recursive call is guarded by a constructor. Best regards, Petr > Hi all, > > My masters project Zeno was recently mentioned on this mailing list so > I thought I'd announce that I've just finished a major update to it, > bringing it slightly closer to being something useful. Zeno is a fully > automated inductive theorem proving tool for Haskell programs. You can > express a property such as "takeWhile p xs ++ dropWhile p xs === xs" > and it will prove it to be true for all values of p :: a -> Bool and > xs :: [a], over all types a, using only the function definitions. > > Now that it's updated it can use polymorphic types/functions, and you > express properties in Haskell itself (thanks to SPJ for the > suggestion). It still can't use all of Haskell's syntax: you can't > have internal functions (let/where can only assign values), and you > can't use type-classed polymorphic variables in function definitions - > you'll have to create a monomorphic instance of the function -but I > hope to have these added reasonably soon. It's also still missing > primitive-types/IO/imports so it still can't be used with any > real-world Haskell code, it's more a bit of theorem proving "fun". > > You can try it out at http://www.doc.ic.ac.uk/~ws506/tryzeno, the code > file given there has some provable properties about a few prelude > functions among other things. > > Another feature is that it lists all the sub-properties it has proven > within each proof. When it verifies insertion-sort "sorted (insertsort > xs) === True" it also proves the antisymmetry of "<=" and that the > "insert" function preserves the "sorted" property. > > Any suggestions or feedback would be greatly appreciated. > > Cheers, > > Will

5 7

typeclass namespace rational?
by Jonathan Geddes 17 Nov '10

17 Nov '10

cafe, Data Constructors and Type Constructors don't share the same namespace. You see code like the following all the time: > data MyRecord = MyRecord {...} This is possible because Data Constructors are used in different parts of the code than Type Constructors so there's never any ambiguity. Type Classes, on the other hand, share the same namespace as Type Constructors. You can't define this: >class String s where > ... > >instance String String where > ... >instance String ByteString where > ... >instance String Text where > ... Not that I'm running out of valid haskell identifiers or anything :P, I'm just wondering: what's the rationale behind keeping Type Classes and Type Constructors in the same namespace? I can't think of any ambiguity there would be if they each had their own namespace. And In some cases it would be convenient to be able to define both a concrete representation and an abstract one with the same name as in the String class example above. --Jonathan

3 3

Re: [Haskell] intent-typing
by Tillmann Rendel 16 Nov '10

16 Nov '10

Hi, Marcus Sundman wrote: > Hi, how would one go about implementing (or using if it's supported > out-of-the-box) intent-typing* for haskell? A basic technique is to use newtype declarations to declare separate types for separate intents. module StringSafety ( SafeString () , UnsafeString () , quote , considerUnsafe ) where newtype SafeString = SafeString String newtype UnsafeString = UnsafeString String considerUnsafe :: String -> UnsafeString considerUnsafe s = UnsafeString s quote :: UnsafeString -> SafeString quote (UnsafeString s) = SafeString s' where s' = ... s ... This module does not export the SafeString and UnsafeString constructors, so we can be sure that no other code in the program can invent SafeStrings which are not really safe. Every string can be safely treated as unsafe, however, so we export a function considerUnsafe which does so. Now, if we type our interface to the outside world as getInput :: ... -> UnsafeString sendOutput :: SafeString -> ... we can be sure that a return value from getInput needs to pass through quote on its way to sendOutput, because quote is the only way to produce a SafeString. This guarantuees safety. It has, however, a practical problem: We can't use the usual String functions on UnsafeString or SafeString values. For instance, we can't concatenate two UnsafeStrings using (++). A naive solution would be to provide separate (++) functions for unsafe and safe strings: append_safe :: SafeString -> SafeString -> SafeString append_safe (SafeString x) (SafeString y) = SafeString (x ++ y) append_unsafe :: SafeString -> SafeString -> SafeString append_unsafe (UnsafeString x) (UnsafeString y) = UnsafeString (x ++ y) Note that at least append_safe needs to be implemented in and exported from the StringSafety module. That is a good thing, because this function needs to be carefully checked for safety. The programmer needs to prove (or unit-test, or at least think about) the following theorem: If a and b are safe strings, so is a ++ b. After this fact has been established, other modules are free to use append_safe however they like without possibly compromising safety. Now, the above approach should work, but is still rather impractical: We need to copy the definitions of all String functions for unsafe and safe strings. However, since the bodies of all these copies are actually identical, so we can use parametric polymorphism to abstract over the difference between UnsafeString and SafeString. One way to achieve this is to use phantom types. With phantom types, we declare only a single newtype for both safe and unsafe strings, but we annotate that type with an additional flag to distinguish safe from unsafe uses. module StringSafety ( AnnotatedString () , Safe () , Unsafe () , quote , considerUnsafe , append ) where data Safe = Safe data Unsafe = Unsafe newtype AnnotatedString safety = AnnotatedString String considerUnsafe :: String -> AnnotatedString Unsafe considerUnsafe s = AnnotatedString s quote :: AnnotatedString Unsafe -> AnnotatedString Safe quote (AnnotatedString s) = AnnotatedString s' where s' = ... s ... append :: AnnotatedString a -> AnnotatedString a -> AnnotatedString a append (AnnotatedString x) (AnnotatedString y) = AnnotatedString (x ++ y) Note that AnnotatedString does not really use its type parameter safety: That's why it is called a phantom type. The data constructor AnnotatedString can be freely used to convert between safe and unsafe strings, so we better not export it from the module. Inside the module, uses of the data constructor gives rise to proof obligations as above. So the programmer needs to reason that the following is true to justify the implementation and export of append: If x and y have the same safety level, then (x ++ y) has again that same safety level. So now, we still have to write a wrapper around each string operation, but at least we need to write only one such wrapper for all intents, not a separate wrapper for each intent. There is an inconvenience left: We can't concatenate safe and unsafe strings, because both arguments to append need to have exactly the same type. To fix this, we first have to figure out what the result of sucha concatenation would be: It would be an unsafe string, because at least one of the inputs is unsafe. We need to teach this kind of reasoning to the compiler, for instance, using type families: type family Join a b type instance Join Safe Safe = Safe type instance Join Safe Unsafe = Unsafe type instance Join Unsafe Safe = Unsafe type instance Join Unsafe Unsafe = Unsafe The idea is that (Join a b) is the safety level of the result of an operation which consumes data of safety level a and b. I called the type family Join because the safety levels form a lattice, with unsafe levels higher then safe levels, and the type family computes the join operation for that lattice. So we are encoding a simple static analysis into the type system here! Using this lattice structure of safety level, we can give a more polymorphic type to append: append :: AnnotatedString a -> AnnotatedString b -> AnnotatedString (Join a b) The implementation can remain unchanged. Now, the programmer needs to reason that the following statement is true to justify this type of append: (x ++ y) is at least as safe as the least safe of x and y. So to conclude, statically checked intent-typing can be expressed in Haskell using newtype wrappers with phantom types, and possibly some type-level computation on these phantom types to teach the compiler domain knowledge about the intents. Tillmann PS. Crossposted to the haskell cafe, please consider dropping haskell(a)haskell.org when answering.

3 2

Re: Add haskell-src as an official machine-readable component of the Haskell standard
by Niklas Broberg 16 Nov '10

16 Nov '10

(Moving to Café) > (Examples of controversies possible in haskell-src: we have the Hs > prefix on constructors everywhere, we can't provide fixity information > (and the haskell-src-exts implementation of this is unsatisfactory in > several important ways) ... What ways? http://trac.haskell.org/haskell-src-exts/ :-) Cheers, /Niklas

2 1

Bracket around every IO computation monad
by Mitar 16 Nov '10

16 Nov '10

Hi! I have a class Neuron which has (among others) two functions: attach and deattach. I would like to make a way to call a list/stack/bunch of attach functions in a way that if any of those fail (by exception), deattach for previously already attached values (called attach on them) are deattached (called deattach on them). I have come up with such way: data Growable where Growable :: Neuron n => LiveNeuron n -> Growable growNeurons :: [IO Growable] -> IO [Growable] growNeurons attaches = growNeurons' attaches [] where growNeurons' [] ls = return ls growNeurons' (a:ats) ls = bracketOnError a (\(Growable l) -> deattach l) (\l -> growNeurons' ats (l:ls)) So I give growNeurons a list of attach actions and it returns a list of attached values ((live)neurons). This works nice, but syntax to use it is ugly: neurons <- growNeurons [ do { a <- attach nerve1; return $ Growable a }, do { a <- attach nerve2; return $ Growable a }, do { a <- attach nerve3; return $ Growable a } ] Types of attach and deattach are (if I simplify): attach :: Nerve n -> IO (LiveNeuron n) deattach :: LiveNeuron n -> IO () Growable is only used so that I can put actions of different type in the list. It seems to me that all this could be wrapped into a monad. So that I would be able to call something like: neurons <- growNeurons' $ do attach nerve1 attach nerve2 attach nerve3 Where I would be allowed to call actions of a special type class which defined also clean-up function (in my case called deattach). And which would be called if there was any exception thrown (and then at the end rethrown). Otherwise, the result would be a list of all computed values. In my case all this in IO monad. So it is possible that evaluation of monad actions would be stacked inside of bracketOnError and in a case of error clean-up functions would be called, otherwise returns a list of results? Mitar

5 14

Updating Haskell Packages through Archlinux becoming A Pain
by Mathew de Detrich 16 Nov '10

16 Nov '10

Well basically, I haven't update my Haskell libraries for some time now (around a month) so when I finally got around to updating my Haskell packages (which are installed through Archlinux's AUR) my GHC installation broke (again). This has been happening for some time now (I have been having this problem for around a year) Basically it occurs when pacman updates a package using an AUR package, which cabal refuses to install because it can break other packages (yet the package still gets installed according to pacman). So this means I have to manually go through /usr/lib/ghc-6.12.3/package.conf.d and manually updating all the package hashes while doing some manual dependency tracking through ghc-check This honestly starting to become annoying, is there any ideas or plans on how to resolve this issue. The end user shouldn't have to be dealing with this, and if installing a package can break the system, it shouldn't be 'semi' installed in the first place

4 5

Annual dutch functional programming day, january 7 2011
by Christiaan Baaij 16 Nov '10

16 Nov '10

The annual Dutch functional programming day will take place soon: Date: Friday, January 7th, 2011 Location: University of Twente, Enschede During the day there will be several presentation related to FP-oriented research results, the use of FP concepts in industry, and the use of FP in education. Of course there is also plenty of opportunity to talk, exchange information, give demo's, and to meet old friends. Most participants are 'advanced' functional programmers; but those who recently developed an interest in all that is FP are of course more than welcome to join. Tradition dictates that at the end of the day we will enjoy a dinner together with those who wish join (at your own costs). You can register for the event by sending an email to me, Christiaan Baaij (c.p.r.baaij(a)utwente.nl) More information can be found at the website: http://caes.ewi.utwente.nl/External/NLFP Please indicate if you want to give presentation, and if you like to attend the dinner afterwards. Please also register if you only want to participate, as we have to know for how many people we should order lunch. There is of course NO participation fee. See you the 7th of January! Christiaan Baaij

1 0

dynamic loading of code on windows
by Arnaud Bailly 16 Nov '10

16 Nov '10

Hello, I recently tried to cabal install plugins on a windows box and it failed with the following error: Resolving dependencies... Downloading plugins-1.5.1.4... Configuring plugins-1.5.1.4... cabal: The package has a './configure' script. This requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. cabal: Error: some packages failed to install: plugins-1.5.1.4 failed during the configure step. The exception was: ExitFailure 1 What solution can I use to load dynamically code in a cross-platform way ? Thanks in advance Arnaud

5 8

Quasiquoter invocation no longer requires/allows a leading dollar sign.
by Michael Snoyman 16 Nov '10

16 Nov '10

Sorry, maybe I missed the memo on this one, but I just noticed this change to quasi-quotation syntax on the GHC 7 upgrade page[1]. So if GHC 6.12 *requires* the dollar sign, and GHC 7 *rejects* the dollar sign, is there any way to write code that will run on both? Is there a reason we can't keep the dollar sign as supported syntax for a release or two to make for a cleaner migration? Michael [1] http://haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_7#Quasiqu…

3 4

Error installing hp2any-graph on Snow Leopard
by Mark Spezzano 16 Nov '10

16 Nov '10

Hi, I get the following error when doing a 'cabal install hp2any-graph' (the profiling tool) Does anyone know why? (I'm running Snow Leopard and I've tried using other flags suggested...but with no success). GLUT is already installed via MacPorts and via cabal. Resolving dependencies... Configuring hp2any-graph-0.5.2... cabal: Missing dependency on a foreign library: * Missing C library: glut This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. cabal: Error: some packages failed to install: hp2any-graph-0.5.2 failed during the configure step. The exception was: ExitFailure 1 Thanks in advance, Mark

3 4

Ralf Laemmel's riddle on surviving without the monad transformation library
by C K Kashyap 16 Nov '10

16 Nov '10

Hi, Can someone provide me the solution to the following riddle that Ralf asked in his lecture at http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Dr-Ralf-Lmmel-Advance… Riddle: define a custom made monad (only involving (->) and Either String) to survive without the monad transformation library. -- Regards, Kashyap

2 2

Is there any way to prevent a computation from being shared?
by Petr Prokhorenkov 16 Nov '10

16 Nov '10

I've came upon very a strange situation with memory consumption. The smallest test case I've been able to come up with is the following: import Data.List wtf d = head . dropWhile (< 10^100) . map (*d) $ enumFrom 2 main = do print $ wtf 1 print $ wtf 2 -- Everything is ok without this line Expected result is that program runs in constant space. What really happening is that the program consumes memory until killed. If second call to wtf is removed, memory usage stays constant while the program is working. The problem is in that list returned from enumFrom is being saved between calls to wtf. Is there any way to overcome this? -- Regards, Petr

3 3

Error handling with safer-file-handling
by Florian Weimer 16 Nov '10

16 Nov '10

How am I supposed to write an exception handle for an invocation of System.IO.SaferFileHandles.openFile? Currently, I have got this: case req of Open path -> do handle <-openFile (asAbsPath path) ReadMode liftIO $ forcePut result Success run handle Follwing safer-file-handling-examples, I rewrote it to: case req of Open path -> do (do runRegionT $ do handle <-openFile (asAbsPath path) ReadMode liftIO $ forcePut result Success run handle) `catch` \(e :: IOException) -> do liftIO $ forcePut result $ Failure $ show e (I would rather like to apply the handler to the openFile invocation only, but the above matches the example code more closely.) But this gives me a nice error message: Handles.hs:48:17: Could not deduce (Control.Monad.CatchIO.MonadCatchIO (RegionT s IO)) from the context () arising from a use of `catch' at Handles.hs:(48,17)-(54,50) Possible fix: add (Control.Monad.CatchIO.MonadCatchIO (RegionT s IO)) to the context of the polymorphic type `forall s. RegionT s pr α' or add an instance declaration for (Control.Monad.CatchIO.MonadCatchIO (RegionT s IO)) In the expression: do { (do { runRegionT $ do { handle <- openFile (asAbsPath path) ReadMode; .... } }) } `catch` \ (e :: IOException) -> do { liftIO $ forcePut result $ Failure $ show e } In a case alternative: Open path -> do { (do { runRegionT $ do { ... } }) } `catch` \ (e :: IOException) -> do { liftIO $ forcePut result $ Failure $ show e } In the expression: case req of { Open path -> do { (do { runRegionT $ ... }) } `catch` \ (e :: IOException) -> do { ... } Close -> return () _ -> liftIO $ forcePut result $ Failure "handle not open" } safer-file-handling-examples results in similar error messages, after applying the s/runTopRegion/runRegionT/ fix. This is with GHC 6.12.1, with ScopedTypeVariables enabled.

2 1

Re: [Haskell-cafe] Making monadic code more concise
by Alberto G. Corona 16 Nov '10

16 Nov '10

I like your autolifting stuff, and the runnable concept. > 2010/11/15 Ling Yang <lyang(a)cs.stanford.edu> > > See my reply to Alex's post for my perspective on how this relates to >> applicative functors, reproduced here: >> >> >> This, to me, is a big hint that applicative functors could be useful. >> > >> >Indeed, the ideas here also apply to applicative functors; it is just the >> lifting primitives that will be different; instead of having liftM<N>, we >> can use <$> and <*> to lift the functions. We could have done this for Num >> and Maybe (suppose Maybe is an instance of Applicative): >> > >> >instance (Num a) => Num (Maybe a) where >> > (+) = \x y -> (+) <$> x <*> y >> > (-) = \x y -> (-) <$> x <*> y >> > (*) = \x y -> (+) <$> x <*> y >> > abs = abs <$> >> > signum = signum <$> >> > fromInteger = pure . fromInteger >> > >> >The larger goal remains the same: autolifting in a principled manner. >> > >> >However, you actually bring up a very good point; what if it is really >> only the applicative functors that this method works on in general, that >> there is no 'use case' for considering this autolifting for monads in >> particular? >> >I think the answer lies in the fact that monads can be 'flattened;' that >> is, realizations of the type m (m a) -> m a are mechanical (in the form of >> 'join') given that >>= is defined. This is important when we have a >> typeclass that also has monadic signatures. To be more concrete, consider >> how this function could be used in a 'monadic DSL': >> > >> >enter x = case x of >> > 0 -> Nothing >> > _ -> Just "hi" >> > >> >The type of 'enter' is one case of the general from 'a -> M b'. If we >> were instancing a typeclass that had an 'a -> M b' function, we'd need a >> function of type 'M a -> M b'. This would be accomplished by >> > >> >enter' = join . liftM enter >> > >> >So the set of lifting primitives must include at least some way to get M >> a -> M b from 'a -> M b'---which requires that M is a monad, not just an >> applicative functor. >> > >> >Thanks for the mention of applicative functors; I should have included >> them in the original post. >> > >> >Lingfeng Yang >> >lyang at cs dot stanford dot edu >> > >> >> I should have included a mention of Applicative in my original post. >> >> > Part of the reason Num was so easy is that all the functions produce >> > values whose type is the class parameter. Your Num instance could >> > almost be completely generic for any ((Applicative f, Num a) => f a), >> > except that Num demands instances of Eq and Show, neither of which can >> > be blindly lifted the way the numeric operations can. >> >> > I imagine it should be fairly obvious why you can't write a >> > non-trivial generic instance (Show a) => Show (M a) that would work >> > for any possible monad M--you'd need a function (show :: M a -> >> > String) which is impossible for abstract types like IO, as well as >> > function types like the State monad. The same applies to (==), of >> > course. Trivial instances are always possible, e.g. show _ = "[not >> > showable]", but then you don't get sensible behavior when a >> > non-trivial instance does exist, such as for Maybe or []. >> >> Good point. This is where we can start defining restrictions for when >> this automatic lifting can or cannot take place. I reference the >> concept of 'runnable monads' here, from >> >> "[Erwig and Ren 2004] Monadification of Functional Programs" >> >> A 'runnable monad' is a monad with an exit function: >> >> class (Monad m) => Runnable m where >> exit : m a -> a >> >> And yes, for monads like IO, no one would really have a need for >> 'exit' outside of the cases where they need unsafePerformIO. However, >> for Maybe and Prob, 'exit' is extremely useful. In fact, in the >> probability monad, if you could not exit the monad, you could not get >> anything done, as the real use is around sampling and computing >> probabilities, which are of non-monadic types. >> >> Provided M is a runnable monad, >> >> class (Show a) => Show (M a) where >> show = show . exit >> >> I'm aware of the limitations of this approach; I just want to come up >> with a set of primitives that characterize the cases where >> autolifting/monadic instancing is useful. >> >> >> On Mon, Nov 15, 2010 at 11:19 AM, C. McCann <cam(a)uptoisomorphism.net> >> wrote: >> > On Mon, Nov 15, 2010 at 12:43 PM, Ling Yang <lyang(a)cs.stanford.edu> >> wrote: >> >> Specifically: There are some DSLs that can be largely expressed as >> monads, >> >> that inherently play nicely with expressions on non-monadic values. >> >> We'd like to use the functions that already work on the non-monadic >> >> values for monadic values without calls to liftM all over the place. >> > >> > It's worth noting that using liftM is possibly the worst possible way >> > to do this, aesthetically speaking. To start with, liftM is just fmap >> > with a gratuitous Monad constraint added on top. Any instance of Monad >> > can (and should) also be an instance of Functor, and if the instances >> > aren't buggy, then liftM f = (>>= return . f) = fmap f. >> > >> > Additionally, in many cases readability is improved by using (<$>), an >> > operator synonym for fmap, found in Control.Applicative, I believe. >> > >> >> The probability monad is a good example. >> >> >> > [snip] >> >> I'm interested in shortening the description of 'test', as it is >> >> really just a 'formal addition' of random variables. One can use liftM >> >> for that: >> >> >> >> test = liftM2 (+) (coin 0.5) (coin 0.5) >> > >> > Also on the subject of Control.Applicative, note that independent >> > probabilities like this don't actually require a monad, merely the >> > ability to lift currying into the underlying functor, which is what >> > Applicative provides. The operator ((<*>) :: f (a -> b) -> f a -> f b) >> > is convenient for writing such expressions, e.g.: >> > >> > test = (+) <$> coin 0.5 <*> coin 0.5 >> > >> > Monads are only required for lifting control flow into the functor, >> > which in this case amounts to conditional probability. You would not, >> > for example, be able to easily use simple lifted functions to write >> > "roll a 6-sided die, flip a coin as many times as the die shows, then >> > count how many flips were heads". >> > >> >> I think a good question as a starting point is whether it's possible >> >> to do this 'monadic instance transformation' for any typeclass, and >> >> whether or not we were lucky to have been able to instance Num so >> >> easily (as Num, Fractional can just be seen as algebras over some base >> >> type plus a coercion function, making them unusually easy to lift if >> >> most typeclasses actually don't fit this description). >> > >> > Part of the reason Num was so easy is that all the functions produce >> > values whose type is the class parameter. Your Num instance could >> > almost be completely generic for any ((Applicative f, Num a) => f a), >> > except that Num demands instances of Eq and Show, neither of which can >> > be blindly lifted the way the numeric operations can. >> > >> > I imagine it should be fairly obvious why you can't write a >> > non-trivial generic instance (Show a) => Show (M a) that would work >> > for any possible monad M--you'd need a function (show :: M a -> >> > String) which is impossible for abstract types like IO, as well as >> > function types like the State monad. The same applies to (==), of >> > course. Trivial instances are always possible, e.g. show _ = "[not >> > showable]", but then you don't get sensible behavior when a >> > non-trivial instance does exist, such as for Maybe or []. >> > >> >> Note that if we consider this in a 'monadification' context, where we >> >> are making some choice for each lifted function, treating it as >> >> entering, exiting, or computing in the monad, instancing the typeclass >> >> leads to very few choices for each: the monadic versions of +, -, * >> >> must be obtained with "liftM2",the monadic versions of negate, abs, >> >> signum must be obtained with "liftM", and the monadic version of >> >> fromInteger must be obtained with "return . " >> > >> > Again, this is pretty much the motivation and purpose of >> > Control.Applicative. Depending on how you want to look at it, the >> > underlying concept is either lifting multi-argument functions into the >> > functor step by step, or lifting tuples into the functor, e.g. (f a, f >> > b) -> f (a, b); the equivalence is recovered using fmap with either >> > (curry id) or (uncurry id). >> > >> > Note that things do get more complicated if you have to deal with the >> > full monadic structure, but since you're lifting functions that have >> > no knowledge of the functor whatsoever they pretty much have to be >> > independent of it. >> > >> >> I suppose I'm basically suggesting that the 'next step' is to somehow >> >> do this calculation of types on real type values, and use an inductive >> >> programming tool like Djinn to realize the type signatures. I think >> >> the general programming technique this is getting at is an orthogonal >> >> version of LISP style where one goes back and forth between types and >> >> functions, rather than data and code. I would also appreciate any >> >> pointers to works in that area. >> > >> > Well, I don't think there's any good way to do this in Haskell >> > directly, in general. There's a GHC extension that can automatically >> > derive Functor for many types, but nothing to automatically derive >> > Applicative as far as I know (other than in trivial cases with newtype >> > deriving)--I suspect due to Applicative instances being far less often >> > uniquely determined than for Functor. And while a fully generic >> > instance can be written and used for any Applicative and Num, the >> > impossibility of sensible instances for Show and Eq, combined with the >> > context-blind nature of Haskell's instance resolution, means that it >> > can't be written directly in full generality. It would, however, be >> > fairly trivial to manufacture instance declarations for specific types >> > using some sort of preprocessor, assuming Show/Eq instances have been >> > written manually or by creating trivial ones. >> > >> > Anyway, you may want to read the paper that introduced Applicative, >> > since that seems to describe the subset of generic lifted functions >> > you're after: http://www.soi.city.ac.uk/~ross/papers/Applicative.html >> > >> > If for some reason you'd rather continue listening to me talk about >> > it, I wrote an extended ode to Applicative on Stack Overflow some time >> > back that was apparently well-received: >> > >> http://stackoverflow.com/questions/3242361/haskell-how-is-pronounced/324285… >> > >> > - C. >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >

1 0

Making monadic code more concise
by Ling Yang 16 Nov '10

16 Nov '10

Hi, I'm fairly new to Haskell and recently came across some programming tricks for reducing monadic overhead, and am wondering what higher-level concepts they map to. It would be great to get some pointers to related work. Background: I'm a graduate student whose research interests include methods for implementing domain specific languages. Recently, I have been trying to get more familiar with Haskell and implementing DSLs in it. I'm coming from having a fair bit of experience in Python so I know the basics of functional programming. However, I'm much less familiar with Haskell. In particular I have little to no internal map from existing DSL implementation techniques to the Haskell extensions that would no doubt make DSL implementations easier (and when they are *not* needed). I also don't have a complete picture of the functional programming research that would inform these techniques. I would greatly appreciate it if I could get pointers to the appropriate references so I can really get going on this. Specifically: There are some DSLs that can be largely expressed as monads, that inherently play nicely with expressions on non-monadic values. We'd like to use the functions that already work on the non-monadic values for monadic values without calls to liftM all over the place. The probability monad is a good example. import Control.Monad import Data.List newtype Prob a = Prob { getDist :: [(a, Float)] } deriving (Eq, Show) multiply :: Prob (Prob a) -> Prob a multiply (Prob xs) = Prob $ concat $ map multAll xs where multAll (Prob innerxs, p) = map (\(x, r) -> (x, p * r)) innerxs instance Functor Prob where fmap f (Prob xs) = Prob $ map (\(x, p) -> (f x, p)) xs instance Monad Prob where return x = Prob [(x, 1.0)] x >>= f = multiply (fmap f x) In this monad, >>= hides the multiplying-out of conditional probabilities that happen during the composition of a random variable with a conditional distribution. coin x = Prob [(1, x), (0, 1 - x)] test = do x <- (coin 0.5) y <- (coin 0.5) return $ x + y *Main> test Prob {getDist = [(2,0.25),(1,0.25),(1,0.25),(0,0.25)]} We can use a 'sum out' function to get more useful results: sumOut :: (Ord a) => Prob a -> Prob a sumOut (Prob xs) = Prob $ map (\kvs -> foldr1 sumTwoPoints kvs) eqValues where eqValues = groupBy (\x y -> (fst x == fst y)) $ sortBy compare xs sumTwoPoints (v1, p1) (v2, p2) = (v1, p1 + p2) *Main> sumOut test Prob {getDist = [(0,0.25),(1,0.5),(2,0.25)]} I'm interested in shortening the description of 'test', as it is really just a 'formal addition' of random variables. One can use liftM for that: test = liftM2 (+) (coin 0.5) (coin 0.5) It seems what I'm leading into here is making functions on ordinary values polymorphic over their monadic versions; I think this is the desire for 'autolifting' or 'monadification' that has been mentioned in works such as HaRE http://www.haskell.org/pipermail/haskell/2005-March/015557.html One alternate way of doing this, however, is instancing the typeclasses of the ordinary values with their monadic versions: instance (Num a) => Num (Prob a) where (+) = liftM2 (+) (*) = liftM2 (*) abs = liftM abs signum = liftM signum fromInteger = return . fromInteger instance (Fractional a) => Fractional (Prob a) where fromRational = return . fromRational (/) = liftM2 (/) Note that already, even though each function in the typeclass had to be manually lifted, this eliminates more overhead compared to lifting every function used, because any function with a general enough type bound can work with both monadic and non-monadic values, not just the ones in the typeclass: *Main> sumOut $ (coin 0.5) + (coin 0.5) + (coin 0.5) Prob {getDist = [(0,0.125),(1,0.375),(2,0.375),(3,0.125)]} *Main> let foo x y z = (x + y) * z *Main> sumOut $ foo (coin 0.5) (coin 0.5) (coin 0.5) Prob {getDist = [(0,0.625),(1,0.25),(2,0.125)]} Because of the implementation of fromInteger as return . fromInteger, we also 'luck out' and have the ability to mix ordinary and non-monadic values in the same expression: *Main> 1 + coin 0.5 / 2 Prob {getDist = [(1.5,0.5),(1.0,0.5)]} My question is, what are the higher-level concepts at play here? The motivation is that it should be possible to automatically do this typeclass instancing, letting us get the benefits of concise monadic expressions without manually instancing the typeclasses. Indeed, I didn't have this idea in Haskell; I'm coming from Python where one can realize the automatic instances: if we take the view that classes in Python are combined datatypes and instanced typeclasses, we can use the meta-object protocol to look inside one class's representation and output another class with liftM-ed (or return . -ed) methods and a custom constructor. I realize Template Haskell gives you the ability to reify instance/class declarations, but perhaps there's a less heavyweight way (or there should be). I think a good question as a starting point is whether it's possible to do this 'monadic instance transformation' for any typeclass, and whether or not we were lucky to have been able to instance Num so easily (as Num, Fractional can just be seen as algebras over some base type plus a coercion function, making them unusually easy to lift if most typeclasses actually don't fit this description). In general, what this seems to be is a transformation on functions that also depends explicitly on type signatures. For example in Num: class (Eq a, Show a) => Num a where (+), (-), (*) :: a -> a -> a negate, abs, signum :: a -> a fromInteger :: Integer -> a instance (Num a) => Num (Prob a) where (+) = liftM2 (+) -- Prob a -> Prob a -> Prob a (*) = liftM2 (*) -- Prob a -> Prob a -> Prob a abs = liftM abs -- Prob a -> Prob a signum = liftM signum -- Prob a -> Prob a fromInteger = return . fromInteger -- Integer -> Prob a Note that if we consider this in a 'monadification' context, where we are making some choice for each lifted function, treating it as entering, exiting, or computing in the monad, instancing the typeclass leads to very few choices for each: the monadic versions of +, -, * must be obtained with "liftM2",the monadic versions of negate, abs, signum must be obtained with "liftM", and the monadic version of fromInteger must be obtained with "return . " I think this is what we're doing in general: if we had a typeclass C with a type variable a, with some set of type signatures in which 'a' appears bound, we can do "instance C (M a)" for some monad M if there is some way to realize the resulting set of type signatures where every bound occurence of 'a' is replaced with 'M a'. The following script illustrates precisely what I mean by this: data Typ = Gr String -- Irreducible grounded type, like Int or Bool | Con String Typ -- Type constructor applied to a type of kind *, i.e., IO String, Maybe (Prob Int) | Arr Typ Typ -- Function T1 -> T2 | Tup (Typ, Typ) -- Tuple (T1, T2) deriving Eq instance Show Typ where show (Gr a) = a show (Con m a) = "(" ++ m ++ " " ++ show a ++ ")" show (Arr a b) = "(" ++ show a ++ " -> " ++ show b ++ ")" show (Tup (x, y)) = "(" ++ show x ++ ", " ++ show y ++ ")" --let a = b in expr for our type signature calculus typlet :: Typ -> Typ -> Typ -> Typ typlet a b expr = case a == expr of False -> typletdown a b expr True -> b typletdown a b (Tup (x, y)) = Tup (typlet a b x, typlet a b y) typletdown a b (Arr x y) = Arr (typlet a b x) (typlet a b y) typletdown a b (Con str c) = Con str (typlet a b c) typletdown a b (Gr s) = Gr s monadify a b expr = typlet a (Con b a) expr -- class declaration : the free type variable, with a list of signatures type ClassDecl = (Typ, [Typ]) -- monadify class signatures monadic_sigs :: ClassDecl -> String -> ClassDecl monadic_sigs (btyp, sigs) it = (Con it btyp, map (\sig -> monadify btyp it sig) sigs) -- Num mkNum = (Gr "a", [ (Gr "a") `Arr` ((Gr "a") `Arr` (Gr "a")), -- (+), (-), (*) (Gr "a") `Arr` (Gr "a"), -- abs, signum, negate (Gr "Integer") `Arr` (Gr "a")]) -- fromInteger main = do let testexpr =(Gr "a") `Arr` ((Gr "a") `Arr` (Gr "a")) print "Sample type signature:" print testexpr print "Monadified:" print $ monadify (Gr "a") "Prob" testexpr print $ "Num typeclass signatures:" print $ mkNum print "Signatures of the functions needed for instance (Num a) => Num (Prob a):" print $ monadic_sigs mkNum "Prob" I suppose I'm basically suggesting that the 'next step' is to somehow do this calculation of types on real type values, and use an inductive programming tool like Djinn to realize the type signatures. I think the general programming technique this is getting at is an orthogonal version of LISP style where one goes back and forth between types and functions, rather than data and code. I would also appreciate any pointers to works in that area. Thanks for any leads, Lingfeng Yang lyang at cs dot stanford dot edu

4 4

Concurrent with monads
by Jiansen He 16 Nov '10

16 Nov '10

Hi cafe, I wounder if it is possible to tell a haskell system that two computations with side effects could be executed concurrently. Here is an affected example: Suppose two people want to compare their age, but do not want to leak their personal information. The following program reads one person's age after another then send back compared result. age :: IO () age = do i <- readIntFrom a j <- readIntFrom b writeTo a (i-j) writeTo b (j-i) How can I express the fact that two readings could be carried out in any order? Best Regards Jiansen

2 1

Hood on Hackage is an interesting way to see intermediate data structures.
by caseyh＠istar.ca 15 Nov '10

15 Nov '10

Hood on Hackage is an interesting way to see intermediate data structures. {-# LANGUAGE NoMonomorphismRestriction #-} -- Fold Behaviour Observed module Folding where -- See Hood on Hackage import Observe import Data.List n = 10::Int fr = foldr (observe "Add" (+)) 0 [1..n] fl = foldl (observe "Add" (+)) 0 [1..n] frr = foldr (observe "Add" (+)) 0 (reverse [1..n]) flr = foldl (observe "Add" (+)) 0 (reverse [1..n]) fro = printO fr flo = printO fl frro = printO frr flro = printO flr fl' = foldl' (observe "Add" (+)) 0 [1..n] flr' = foldl' (observe "Add" (+)) 0 (reverse [1..n]) flo' = printO fl' flro' = printO flr'

1 0

Making monadic code more concise
by lyang 15 Nov '10

15 Nov '10

> This, to me, is a big hint that applicative functors could be useful. Indeed, the ideas here also apply to applicative functors; it is just the lifting primitives that will be different; instead of having liftM<N>, we can use <$> and <*> to lift the functions. We could have done this for Num and Maybe (suppose Maybe is an instance of Applicative): instance (Num a) => Num (Maybe a) where (+) = \x y -> (+) <$> x <*> y (-) = \x y -> (-) <$> x <*> y (*) = \x y -> (+) <$> x <*> y abs = abs <$> signum = signum <$> fromInteger = pure . fromInteger The larger goal remains the same: autolifting in a principled manner. However, you actually bring up a very good point; what if it is really only the applicative functors that this method works on in general, that there is no 'use case' for considering this autolifting for monads in particular? I think the answer lies in the fact that monads can be 'flattened;' that is, realizations of the type m (m a) -> m a are mechanical (in the form of 'join') given that >>= is defined. This is important when we have a typeclass that also has monadic signatures. To be more concrete, consider how this function could be used in a 'monadic DSL': enter x = case x of 0 -> Nothing _ -> Just "hi" The type of 'enter' is one case of the general from 'a -> M b'. If we were instancing a typeclass that had an 'a -> M b' function, we'd need a function of type 'M a -> M b'. This would be accomplished by enter' = join . liftM enter So the set of lifting primitives must include at least some way to get M a -> M b from 'a -> M b'---which requires that M is a monad, not just an applicative functor. Thanks for the mention of applicative functors; I should have included them in the original post. Lingfeng Yang lyang at cs dot stanford dot edu

1 0

Announcement: the Haskell.org committee has formed
by Don Stewart 15 Nov '10

15 Nov '10

= The haskell.org committee has formed = http://haskellorg.wordpress.com/2010/11/15/the-haskell-org-committee-has-fo… In recent years, haskell.org has started to receive assets, e.g. Google Summer Of Code funds, donations for Hackathons, and a Sparc machine for use in GHC development. We have also started spending this money: on the community server, on a server to take over hosting haskell.org itself, and on the haskell.org domain name. There is also interest in running fundraising drives for specific things such as Hackathon sponsorship and hosting fees. To resolve who is responsible for haskell.org’s infrastructure development, open nominations were held to form a haskell.org committee, based on representatives from the open source Haskell community. Nominations were received, and we are pleased to announce that the new committee has formed. The current members of the committee are: • Don Stewart [chair] • Edward Z. Yang • Ganesh Sittampalam • Ian Lynagh • Johan Tibell • Malcolm Wallace • Vo Minh Thu Members are expected to serve a 3 year term, and terms are staggered so that 2 or 3 members step down each year. = What we’re working on = Over the past year, two of the core infrastructure nodes: www.haskell.org (which hosts the main wiki), and code.haskell.org (which hosts a lot of project repositories) have become increasingly unreliable. To address this, a new high-spec, dedicated host was purchased, which will be used to replace both services. The commitee is now working directly to solve these issues: • Moving www.haskell.org (and the mailing lists) from Yale to the new dedicated host. • Migrating the code.haskell.org host to a VM on the new machine. More news on this work shortly. = Stay up to date = To help people better keep up to date on the status of the haskell.org infrastructure, stay up to date via: • Online: http://haskellorg.wordpress.com/ • Twitter: http://twitter.com/haskellorg - get status updates about haskell.org services via twitter. • Email: committee(a)haskell.org - To get in touch with the committee, use the committee @ haskell.org address.

1 0

http://www.haskell.org/ is down !
by Pasqualino "Titto" Assini 15 Nov '10

15 Nov '10

Hi, is haskell.org being updated or, as I fear, Haskell's HQ has been overrun by a mob of PHPers ? If so, I am ready to fight ! titto P.S. Just need to find my Excalibur, oh god, the wife just sent it to the Dry Cleaner. -- Pasqualino "Titto" Assini, Ph.D. http://quid2.org/

2 1

Re: [Haskell-cafe] Concurrent with monads
by John Lato 15 Nov '10

15 Nov '10

> > From: Jiansen He <jiansenhe(a)googlemail.com> > > Hi cafe, > > I wounder if it is possible to tell a haskell system that two computations > with side effects could be executed concurrently. > > Here is an affected example: > > Suppose two people want to compare their age, but do not want to leak their > personal information. The following program reads one person's age after > another then send back compared result. > > age :: IO () > age = do > i <- readIntFrom a > j <- readIntFrom b > writeTo a (i-j) > writeTo b (j-i) > > How can I express the fact that two readings could be carried out in any > order? The best approach is probably to fork a thread for each concurrent evaluation. There are a few packages on Hackage that can help with this; I've used threads[1] and spawn[2] successfully. If the "readIntFrom" function is meant to be responding to a client, a threaded model may make sense organizationally, but for this to be a performance benefit there needs to be sufficient work for each thread to carry out. Haskell threads are lighter than Posix threads, but there's still overhead involved. There is an alternative I hesitate to mention because it involves some voodoo, but Roman Leshchinskiy came up with a clever technique that might be appropriate if you want the behavior of "par" but for IO[3]. [1] http://hackage.haskell.org/package/threads [2] http://hackage.haskell.org/package/spawn [3] http://unlines.wordpress.com/2010/04/21/sparking-imperatives/

1 0

Opportunity: Spring semester internship on Haskell project at Intel
by Ryan Newton 15 Nov '10

15 Nov '10

Dear Haskellers, We're looking for outstanding candidates for an internship in Spring 2011. The internship will be in a suburb of Boston (Hudson, MA). Graduate students and talented undergraduates are welcome to apply, but time is a bit short. We are a small research group run directly by the CTO<http://www.intel.com/pressroom/kits/bios/plowney.htm>of Intel's Developer Products Division. Our group works on high-level parallel programming tools<http://software.intel.com/en-us/articles/intel-concurrent-collections-for-c…>(including for Haskell<http://software.intel.com/en-us/blogs/2010/05/27/announcing-intel-concurren…>) and applies binary translation <http://www.pintool.org/> to various problems; also we collaborate closely with Intel's various developer tools teams (Cilk <http://supertech.csail.mit.edu/cilk/>, TBB<http://www.threadingbuildingblocks.org/>, etc). We are looking for someone to work on a new, self-contained Haskell project to create an eDSL that targets the ArBB virtual machine (VM) for vectorization. One possible solution is to adapt existing projects that target CUDA (e.g. accelerate <http://hackage.haskell.org/package/accelerate>and Nikola <%20http://www.eecs.harvard.edu/%7Emainland/projects/nikola/>). Array Building Blocks (ArBB)<http://software.intel.com/en-us/articles/intel-array-building-blocks/>is an interesting and ambitious project that attempts to bring metaprogramming and eDSLs to the masses. It's based on research by Michael Mccool at Waterloo that he used to found a company, RapidMind<http://en.wikipedia.org/wiki/RapidMind>, which was later bought by Intel. The basic idea is that the VM abstracts over the thread and vectorization capabilities of CPUs, GPUs, and other manycore chips<http://www.intel.com/pressroom/archive/releases/20100531comp.htm>. The VM defines a restricted compute language and provides a managed (yes, garbage collected) environment. Using the normal eDSL and metaprogramming tricks the user writes a portable program in a host language streams ASTs to the VM at runtime. These vector programs include the usual aggregate array operations and high level transformations (map, fold, etc), and the VM can perform fusion/deforestation optimizations while JITting vector codes. The VM API for generating programs is a simple C API<http://software.intel.com/sites/products/documentation/arbb/arbb_manual_win…>that can be called from anywhere. The ArBB team is anxious to demonstrate language frontends for other languages, and Haskell is a good candidate. The official requisition will be available at the Intel Jobs site shortly, but in the meantime if you are interested, please forward your CV to me at ryan.r.newton(a)intel.com . Cheers, -Ryan LOCATION: Hudson, MA DURATION: 3-6 Months, flexible START: Some flexibility, ~January, 2011 EXPERIENCE: Expert Haskell/GHC programmer. Interest in research a plus. LOCATION NOTE: With a car it is possible to live in Cambridge or Boston and reverse-commute to our location. (Working offsite two days a week is possible.)

1 1

Re: [Haskell] intent-typing
by Max Rabkin 15 Nov '10

15 Nov '10

I still don't understand what intent typing is, but this particular problem is discussed (with a type-based, statically checked solution) at http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-st… --Max On Mon, Nov 15, 2010 at 17:17, Marcus Sundman <sundman(a)iki.fi> wrote: > Hi, how would one go about implementing (or using if it's supported > out-of-the-box) intent-typing* for haskell? > > *) Intent-typing is compiler/verifier/parser enforced typing similar to > "apps hungarian" notation. E.g., say I have a webapp with fields for a > user's first name and last name, which I at some point show on another > webpage that the user loads, which is a typical XSS vulnerability situation. > So I have 2 functions, getParam(...) and setParam(...), which return the > value of a user-provided parameter and gives a parameter to the template > displayed to the user, respectively. I want to somehow flag the > getParam(...)-function as returning a user-provided string (say, > "unsafe-string"), and the setParam(...)-function as requiring a safely > encoded string (say, "safe-string"), so that if I sometimes forget to run > the user-provided string through some anti-xss-encoding thingy (which would > take an "unsafe-string" and return a "safe-string"), and don't (unit-)test > this particular aspect of said code, then some verifier thingy (preferably a > static verifier) would notice this and show me a warning. > > Cheers, > Marcus > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

Parsing bytestream
by C K Kashyap 15 Nov '10

15 Nov '10

Hi, I've been trying to implement the RFB (VNC) protocol and I was exploring a neat way of parsing the protocol bytestream. The protocol specifies that the client first sends a byte that identifies the command then a sequence of word8, word16, word32 and paddings. I've tried to capture that logic with the function below. commandFormat :: Word8 -> [Int] -- 0 for padding bytes commandFormat c | c == setPixelFormat = [0,0,0,1,1,1,1,2,2,2,1,1,1,0,0,0] | c == setEncodings = [0,2] | c == framebufferUpdateRequest = [0,2,2,2,2] | c == keyEvent = [1,2,4] | c == pointerEvent = [1,2,2] | c == clientCutText = [0,0,0,4] | otherwise = [] What I am struggling with is a function like this - parseCommand :: Word8 -> ByteStream -> [Int] parseCommand command byteStream = ... I want the function to use the commandFormat above and return me a list of integers -- for example - if the command is keyEvent and the bytestream is "<1> <0> <2> <0> <0> <0> <3>" The output should be -> [1,2,3]!!! -> That way, I can process it easily. I'd appreciate some help on this very much. -- Regards, Kashyap

5 13

Curious data family bug
by Michael Snoyman 15 Nov '10

15 Nov '10

Hey all, While trying to get a commit pushed for Yesod[1], Alexander Dunlap pointed out one of his programs didn't work with the new code. After some investigation, I was able to reproduce the bug with the following code snippet: {-# LANGUAGE TypeFamilies #-} data family Foo a data Bar = Bar data instance Foo Bar = Bar1 | Bar2 | Bar3 | Bar4 | Bar5 | Bar6 | Bar7 | Bar8 | Bar9 deriving Eq This produces: Couldn't match expected type `Main.R:FooBar' against inferred type `Foo Bar' NB: `Foo' is a type function In the first argument of `Main.$con2tag_R:FooBar', namely `a' In the expression: (Main.$con2tag_R:FooBar a) In the expression: case (Main.$con2tag_R:FooBar a) of { a# -> case (Main.$con2tag_R:FooBar b) of { b# -> (a# GHC.Prim.==# b#) } } The especially strange thing about this bug is that it only occurs when there are more than 8 constructors; if I remove Bar9, everything seems to work. Does anyone have experience with this occuring? Michael [1] http://docs.yesodweb.com/blog/please-break-yesod/

3 3

date parsing and formatting
by Alex Baranosky 15 Nov '10

15 Nov '10

I've been working with Haskell's Date.Time modules to parse a date like 12-4-1999 or 1-31-1999. I tried: parseDay :: String -> Day parseDay s = readTime defaultTimeLocale "%m%d%Y" s And I think it wants my months and days to have exactly two digits instead of 1 or 2... What's the proper way to do this? Also, I'd like to print out my Day in this format: 12/4/1999 what's the Haskell way to? Thanks for the help. Alex

2 1

Encoding problem (?)
by llama＠ruomad.net 15 Nov '10

15 Nov '10

Hello, I have this strange problem, with the same program (simple) behaving differently when run from console and from WinGHCi. Platform is Windows XP. Haskell Platform 2.0.0. The program : import IO import Data.Maybe tfind s = lookup (head s) $ zip "\232\222" "12" main = do h <- readFile "g:\\CODE\\rlib\\test.txt" putStrLn h print $ tfind h The file test.txt only contains a "è" (should be \232). Encoding is ANSI. I compile the pgm from WinGHCi : Prelude> :! ghc --make "ftest2.hs" and run it from WinGHCi : Prelude> :! ftest2.exe è Just '1' Now if I use the _same_ compiled program from cmd line : g:\CODE\rlib>ftest2.exe è Just '2' Is there any plausible explanation ? Bruno

2 1

[ANN] shpider-0.1.1
by John Morrice 14 Nov '10

14 Nov '10

Shpider is a web automation library for Haskell. It allows you to quickly write crawlers, and for simple cases ( like following links ) even without reading the page source. Shpider is on hackage at http://hackage.haskell.org/package/shpider Shpider development repository is now on github at https://github.com/elginer/shpider Shpider 0.1.1 now compiles on ghc-6.12, with the latest version of tagsoup-parsec. Thanks to Noriyuki OHKAWA for a patch! John Morrice

1 0

how do i resolve these screwy cabal errors
by Anatoly Yakovenko 14 Nov '10

14 Nov '10

package derive-2.3.0.2-ad85bd58710fede3f840a467e84c403e is unusable due to missing or recursive dependencies: haskell-src-exts-1.9.4-e0f8c55bea9fc97376aa3598dfdca6d6 package derive-2.4.1-415d44d2f93198aab5dff67866c17b64 is unusable due to missing or recursive dependencies: haskell-src-exts-1.9.4-e0f8c55bea9fc97376aa3598dfdca6d6 what does that mean? i reinstalled haskell-src-exts and derive, doesn't seem to make any difference Linking dist/build/derive/derive ... Installing library in /home/anatolyy/.cabal/lib/derive-2.4.1/ghc-6.12.3 Installing executable(s) in /home/anatolyy/.cabal/bin Registering derive-2.4.1... /home/anatolyy/.cabal/lib/haskell-src-exts-1.9.4/ghc-6.12.3 Registering haskell-src-exts-1.9.4... so i cant import Data.DeriveTH

1 1

Compiler constraints in cabal
by Reiner Pope 13 Nov '10

13 Nov '10

Hi, I have a library, hmatrix-static, on Hackage. Version 0.3 (the current version) compiles with ghc-6.12. Let's say I want to upgrade my library using new features in ghc-7.0, and then release these upgrades as version 0.4. Is there any way to state in my cabal file that this new version will no longer compile under ghc-6.12? The reason I would like to state this is so that a user with ghc-6.12 can do 'cabal install hmatrix-static' (or do a cabal install of a program depending on hmatrix-static) and see that cabal will install version 0.3 rather than attempt to install version 0.4 and fail. Thanks for your help. Reiner

7 10

Type-Directed Name Resolution for Records?
by John Smith 13 Nov '10

13 Nov '10

Two significant points which have emerged from the TDNR thread are: -The wiki page combines two orthogonal proposals: type-directed name resolution, which requires no special syntax, and the x.f syntax, which does not require TDNR. -Implementing both proposals may be a desired fix for the record system, but their use in the rest of the language is more controversial. I would therefore like to propose that TDNR (both parts thereof) be implemented for record accessors. In the fullness of time, the community may come to some consensus regarding the implementation of either or both of these features in the rest of the language.

1 0

xml packages
by Permjacov Evgeniy 13 Nov '10

13 Nov '10

First question. As I saw in sources, both hxt and haxml uses [Char]'s. this is very inefficient. I want to know, does any effective parser for haskell, written in haskell, exists. Efficient means using ByteString to store strings and possibly building representations that shares one string for all similiary named elements. If there is no, is anyone interested in writing one? Second question. I'd like to have a package for read-write-edit SVG graphics. I think, xslt (both transformations and formatting object) are interesting too. Is anyone considering writing such packages?

4 3

a problem about Regex in Real World Haskell
by wolf python london 13 Nov '10

13 Nov '10

hi ,folks , I'm a newbie of haskell and learn haskell using the textbook "Real World Haskell". in the page 201, ghci> "good food" =~ ".ood" :: [String] my output is here https://gist.github.com/675024 it doesn't match what the textbook gives . And I found the ebook of Real World Haskell doesn't match it ,either(just like my output ) . I was wondering How I can fix this problem about Regex. much thanks ~ -- ________________________ wolf python london(WPL) Do as you soul should do ! ________________________

2 2

HUnit Control.Exception assertFailure?
by Mark Spezzano 13 Nov '10

13 Nov '10

Hi, I'm trying to follow some examples of HUnit from a webpage. Basically I want my _application_ code to call the "error" function when a certain condition is met (namely when a supplied String to a function is longer than 80 characters). I want my _test_ code to "catch" this error. Unfortunately the example code that I'm following uses the older style of Exception handling. Does anyone know how to catch this exception using the newer Control.Exception module? Basically I want to 1. Call error msg when String length > 80 for some function 2. Catch thrown error from step 1 and do absolutely nothing. (i.e. the "expected failure" was caught) 3. If the error is uncaught (in step 2; for whatever reason) then call "assertFailure somemsg" and my _test_ code should fail since the error it was expecting to occur didn't happen. Thanks, Mark Spezzano

1 0

Type Directed Name Resolution
by John Smith 13 Nov '10

13 Nov '10

Type-directed name resolution, as originally proposed for Haskell', has now been proposed for GHC. Obvious benefits of this are that conflicting function names from imported modules can be used without qualification (verbose) or pseudo-Hungarian renaming (verbose, and requires that you control the source, and perform the same renaming in all dependencies). This is important for both readability and programming in the large, particularly where records are concerned, as the duplicate name problem cannot be alleviated with typeclasses, and it is often desirable to have the same field names for many records in the same module. http://hackage.haskell.org/trac/ghc/ticket/4479 http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResoluti…

30 66

Serialization of (a -> b) and IO a
by C. McCann 13 Nov '10

13 Nov '10

Oops, forgot to send this to the list... sorry, Sjoerd. On Thu, Nov 11, 2010 at 11:54 AM, Sjoerd Visscher <sjoerd(a)w3future.com> wrote: >> You would lose many uses of equational reasoning in your programs. Have you >> every substituted 'x * 2' for the expression 'x + x' in one of your programs, >> or vice versa? You can no longer do that, because someone may be serializing >> the function you're writing, checking how it's implemented, and relying it. > > Yes, but it would not break any existing code. It would only break code that knowingly did the wrong thing. Or code that unknowingly depends transitively on code that does the wrong thing. In that regard it would be much like unsafePerformIO, and about as trustworthy. Better off just having any such "serialize" be safely in IO, and let people who want to live dangerously just use unsafePerformIO to get around it. >> We already have a weak case of this, since (\x -> undefined x) can be >> distinguished from undefined using seq, but that can be hand-waved away by not >> worrying about bottoms so much. That isn't going to work for serialize. > > Why not? I'd venture that perhaps because seq only behaves differently when one possible outcome is _|_. An unsafe serialize could distinguish between two non-bottom values, which means the sketchy behavior could be free to wreak havoc in code that's not crashing. For instance, assuming serialize can be applied to functions of any type, it would probably be trivial to write a function (isExpr :: a -> Bool) that reports whether an arbitrary term is a primitive value or the result of some expression, which then lets you write a function with type (forall a. a -> a) that is NOT equivalent to id, which could then be passed freely into any other piece of code you like. That sounds like buckets of fun, doesn't it? - C.

6 12