- Haskell-Cafe - Haskell.org

Re: Iteratee rest and monad instance
by John Lato 14 Jun '10

14 Jun '10

> From: Tilo Wiklund <noteventime(a)gmail.com> > > I am probably missing something obvious or something relating to > optimisation/server software but defining iteratees as "Iteratee s a = > Cont (s -> Either (s, a) (Iteratee s a))" seems to lead to a more > natural monad instance, and does not suffer from (what seems to me to > be an issue) having to make predictions about the stream it will be > passed. > > My question is thus, why the "rest" stream has to be carried by an > Iteratee constructor, rather then be part of the value of the > continuation function. Bas's reply is spot-on. To directly answer your question, there is no technical reason and both implementations are possible (among others). The reasons for the choice (at least in the iteratee library) have to do with the types that arise for enumerators and iteratee combinators for a given implementation. There is a good discussion of this in the comments in Oleg's source code. Currently I prefer the CPS-style. It looks more complicated, and it can't be written in Haskell-98, but otherwise it seems easier to use with comparable (or better) performance. Other factors (chunk size, chunk type) seem to have a much more significant effect on performance than this. There are performance differences between the two IterateeG/IterGV implementations, but as far as I know neither one is better overall. John

1 0

Re: learning advanced haskell
by John Lato 14 Jun '10

14 Jun '10

> From: Aran Donohue <aran.donohue(a)gmail.com> > > Hi Cafe, > > I've been doing Haskell for a few months, and I've written some mid-sized > programs and many small ones. I've read lots of documentation and many > papers, but I'm having difficulty making the jump into some of the advanced > concepts I've read about. > > How do people build intuitions for things like RankNTypes and arrows? (Is > the answer "Get a PhD in type theory?") Normally I learn by coding up little > exercise programs, but for these I don't have good intuitions about the > kinds of toy problems I ought to try to solve that would lead me to > understand these tools better. I read as much as I can. On the cafe, Planet Haskell, papers, whatever. If I don't understand a paper, I leave it be for a while then come back to it in a few weeks/months. Usually I'll be able to make further headway. Also don't try to read too much at once. The literature is quite dense and I find it useful to let things sit and percolate for a while. For the specific cases of RankNTypes and arrows I had nearly opposite experiences. I understood RankNTypes immediately, in that I expected higher-rank behavior and was surprised when code didn't work that way. Arrows were particularly difficult for me (for much the same reason as the Monoid class, incidentally). I understood the concept of arrows, but was unable to figure out how to actually *do* anything with them for some time. I'm still not sure that I have a great idea of when arrows are useful as a computational abstraction; they seem to be used more for the notation and convenience functions than anything else. > I understand the motivation for other concepts like iteratees, zippers and > functional reactive programming, but there seem to be few entry-level > resources. John Lato's recent Iteratee article is a notable exception*. This is exactly what I was aiming for, so I really appreciate hearing your comments. I'm a beginner in many areas as well, so I also would like to see more entry-level resources. > > Hints? Tips? "Here's how I did it"? _______ is a great program to write to > get to learn ______? > Stuff I have a decent understanding of: RankNTypes - Look at this function > makeString :: (Show b, Show c) => (a -> a) -> b -> c -> String > makeString f b c = show (f b) ++ show (f c) If you try to call it as e.g. > makeString id 0 "foo" GHC provides a type error. This doesn't work because when GHC unifies the types, it does something like this: 1) the first argument, f, is a function with type a -> a 2) the function f is applied to an Integer, so f :: Integer -> Integer 3) the function f is applied to a String, so f :: String -> String 4) there are conflicting types for f, so bail out Even though you declare f :: a -> a, that 'a' must be set to exactly *one* value within the call, where makeString tries to apply it to values with different types. This is rank-1 polymorphism. RankNTypes fixes this by allowing us to specify that the "f" function is supposed to be polymorphic within the makeString function (rank-2 polymorphism) as opposed to the standard rank-1 polymorphism: > makeString2 :: (Show b, Show c) => (forall a. a -> a) -> b -> c -> String calling makeString2 does the right thing. That's pretty much the whole story of Rank2Polymorphism. RankNPolymorphism is exactly the same with nested levels of forall's. One really useful feature of this is that it provides a sort of inversion-of-control for polymorphism. Typically the caller has the ability to define the types when a function is called, as happens with the b and c parameters to makeString2. But in the first argument the *callee* determines the type values of the function! The caller knows only that the function must take one argument and return a result of the same type (which also means "id" is the only interesting function of the appropriate type). The callee is free to instantiate the given function with *any types it wants*. This is also what makes the ST monad safe incidentally. Arrows - Toy project: write a small program and use arrow notation to combine functions. Write the zipWith version of the "fib" function with arrows. Most of the stuff on the web is pretty readable IMHO. Yampa is a good place to move beyond "Arrow" and into "ArrowLoop". Zippers - Toy project: anything that keeps track of decisions in a tree. Mapping a path as in Theseus and the Zipper seems good. I learned it by implementing a user history function. Template Haskell - Toy project: programatically generating data declarations seems like a good starting point because it's relatively simple and can't be done with normal code. Instances are a good follow-up. Of course this is only a small portion of what TH can do, but it's a start. Bulat's tutorials are the best on this topic I'm aware of. I left out a lot of stuff that I'm still working with myself (SYB, Finally Tagless, category-extras, ...). > Thanks in advance, > Aran > > * Even in this article, he busted out (>=>). And it appears that the > iteratee library's actual design is more sophisticated than the design > presented. Well, yes. If the library implementation (or Oleg's examples) were the same as the implementation I presented, there probably would have been no need for the article! John

1 0

parsec: how to get end location
by Roman Cheplyaka 14 Jun '10

14 Jun '10

Suppose I have some parser 'p'. I want to parse it as well as get its span in the text. So I could write \begin{code] pWithLocation = do loc_start <- getPosition pval <- p loc_end <- getPosition return (pval,loc_start,loc_end) \end{code} except that loc_end gives me the location _after_ 'p'. In case when 'p' has consumed trailing newline I see no way to recover the end location of 'p' (it is the last column of the previous line). So, can I do anything with this without patching parsec? I use parsec3 if it matters. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain

5 5

Difficulties with tagless - create "primitives" or compose them
by Günther Schmidt 14 Jun '10

14 Jun '10

Hi list, there is one thing about the "Finally tagless" EDSL approach that really confuses me: (Well more than one actually but this one more so) When to decide to introduce a term as a primitive in the syntax class and when to define it from primitives already defined. For example this one here: type Arr exp a b = exp a -> exp b class EDSL exp where lam :: (exp a -> exp b) -> exp (Arr exp a b) app :: exp (Arr exp a b) -> exp a -> exp b int :: Int -> exp Int -- Integer literal add :: exp Int -> exp Int -> exp Int sub :: exp Int -> exp Int -> exp Int mul :: exp Int -> exp Int -> exp Int Let's take "mul" here, defined as a "primitive", in other words defined in the EDSL class. Technically, with lam, app and add already defined, I could have defined "mul" outside the EDSL class, just built from the 3 primitive operators. Of course doing so then does not give me the possibility to choose alternative evaluation strategies for "mul" itself, only for lam, app and add. So what is a good measure for deciding when to define a term primitive or not? Günther

3 4

How to "Show" an Operation?
by Martin Drautzburg 14 Jun '10

14 Jun '10

Dear all, If I have a problem where I have to select from a set of operations, how would I print the result? Example: If I can chose from (x+y), (x*y), (x^2+y)... and I feed them all into my problem solver and it finds that "(x*y) is right", how can I print that string? -- Martin

6 7

GeneralizedNewtypeDeriving and TypeFamilies
by Max Cantor 14 Jun '10

14 Jun '10

So I understand from http://hackage.haskell.org/trac/ghc/ticket/4083 that GeneralizedNewtypeDeriving doesn't play well with TypeFamilies. But, if a typeclass is only using type synonyms, is there any reason why newtype deriving would not work? For a toy example: class Cls a where type MyType a foo :: MyType a -> in this case, if you have something like: instance Cls () where type MyType () = () foo = id would: newtype Bar = Bar () deriving (Cls) be well defined? Thanks, Max

1 0

Graph type
by C K Kashyap 14 Jun '10

14 Jun '10

Hi, I am trying to write a routine that would generate a graph - where each vertex would be a string. type Graph v = [(v,[v])] -- list of tuples of vertices and adjacent vertices list addEdgeToGraph :: Graph -> String -> String -> Graph I am having trouble coming up with the body of this function - that takes the original graph, and an edge (string -> string) and the produces the new graph. -- Regards, Kashyap

3 4

Announce: Properties-0.0.2
by Alberto G. Corona 13 Jun '10

13 Jun '10

http://hackage.haskell.org/package/properties-0.0.2 <http://hackage.haskell.org/package/properties-0.0.2>Properties can use QuickCheck properties in the same way than assertions are used, for causal debugging of real programs. It also add an human readable structure for grouping properties for classes or libraries. The properties can then be tested in the instance´s body or in programs as if they were assertions. The main advantage is that the compliance of properties can be done with the complete data range that the real application generates (hopefully, with an pleasant separation of real code and debug code). This is a simple example: stringProperty= [Property <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…> "length" (\(x, y)-> length (x++y)== length x + length y)] main= do let s= "hello " let s2= "world" print $ s++ s2 `verify <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>` stringProperty `with <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>`(s,s2) print "that's all!" It is possible to check quickCheck style properties. The same example with a quickCheck-style property: quickCheckProperty x y= length (x++y)== length x + length y main= do let s= "hello " let s2= "world" print $ s++ s2 `verify <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>` [Property "stringSumLength" $ uncurry quickCheckProperty] `with <http://hackage.haskell.org/packages/archive/properties/0.0.2/doc/html/Test-…>`(s,s2) print "that's all!" The package include a more sophisticated example. I Hope that this would be useful Alberto

1 0

Harder than you'd think
by Andrew Coppin 13 Jun '10

13 Jun '10

So the other day I was writing some code, and I ended up wanting to have a collection of data indexed in more than one way. In other words, I wanted fast lookup with several different keys. Initially I built something using two Data.Map objects to represent the two lookup keys, but then I needed up needing more keys per value than that, so I decided I should write a small library to abstract the whole thing. What I ended up writing is this: http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=25782 It sorta kinda works, but man, take a look at the first line. That's *a lot* of type-system abuse to make it go. And it strikes me that if you had two keys, both of which happen to have the same type (e.g., String)... what then? On the other hand, it's not like you can go lookup :: KeyID -> Key -> Container -> Maybe Value since the type of both the container and the key depend on which key you want to access. Man, this is way, way harder than I realised! Does anybody have a less-insane way of doing this?

6 8

Re: [Haskell-cafe] Harder than you'd think
by Andrew Coppin 13 Jun '10

13 Jun '10

Philippa Cowderoy wrote: > On 13/06/2010 14:52, Andrew Coppin wrote: >> Marc Weber wrote: >>>> Does anybody have a less-insane way of doing this? >>> >>> Sure: >>> type MyMap = Map (KeyID, Key) Value >>> >>> Don't use multiple keys. Put the keys into a tuple and use that as key. >>> >>> Let me know whether this is what you were looking for. >> >> Trouble is, this requires you to have *all* the keys to perform a >> single lookup. You can't do a lookup on just one attribute. >> > > No it doesn't - think sum/or, not product/and, your tuple's (KeyID, > Key) not (Key1, Key2, Key3...). > Oh, I see - so you enter (1, author), (2, date), (3, time), etc? That then requires all keys to have the same type - although I think for my needs I can put together an ADT to fix that...

1 0

Fwd: [Haskell-cafe] Literate programming
by aditya siram 13 Jun '10

13 Jun '10

I understand that this becomes less of an issue when > you become more experienced with haskell. Still it will always be a good > way > to promote haskel-style solutions. > I dunno, John uses noweb to good effect. Things like import statements along with the function definition are pretty nice and not achievable with Literate Haskell. > > I don't have any problems with LaTeX, but a less verbose solution would do > just fine. > You don't really need to know a lot of LaTex to use noweb. I'm no LaTex expert and I found the source easy to read. > My biggest problem is actually literate programming in conjunction with > leksah. Can anybody comment on this issue? Do you guys use leskah at all? > Unfortunately literate programming doesn't really have the tool support yet. I use emacs for Haskell development and loading Haskell code in to the REPL will be an issue if you're editing a noweb file. Currently this is the only thing keeping me from starting a large (> 2000 LOC) literate project -deech > > -- > Martin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

Literate programming
by Martin Drautzburg 13 Jun '10

13 Jun '10

Hello all, Is literate programming something you guys actually do (I only know that Paul Hudak does), or is it basically a nice idea from days gone by? In case you do, then how do you do it? Do you use lhs2TeX or what? Do you use "bird" style of full-blown LaTeX? Does any of you use leksah? I failed to see any support for literate programming in leksah. It candies the backslashes in e.g. \documentclass{article} to λdocumentclass{article}. In case you don't, then how do you document your code? If you write a paper which explains what your code does, then how do you do that? -- Martin

7 7

Fwd: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
by Carlos Camarao 13 Jun '10

13 Jun '10

I forgot to cc the message below to haskell-cafe... ---------- Forwarded message ---------- From: Carlos Camarao <carlos.camarao(a)gmail.com> Date: Thu, Jun 10, 2010 at 4:40 PM Subject: Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma To: "Brandon S. Allbery KF8NH" <allbery(a)ece.cmu.edu> On Wed, Jun 9, 2010 at 1:51 AM, Brandon S. Allbery KF8NH < allbery(a)ece.cmu.edu> wrote: > On Jun 8, 2010, at 15:32 , Job Vranish wrote: > > It seems like this would make working with MPTCs much easier. > When programming, I generally want to only specify the minimum amount of > information to make my code logically unambiguous. > If the code contains enough information to infer the proper instantiation > without the use of an FD, then I shouldn't need to add a FD. > It seems like this would have much more of a "it just works" feel than the > currently alternatives. > > > I can't help but think that the "it just works" mentality leads to duck > typing. > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com > system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > Perhaps I am missing something, but if we have, say, quack o::IO() (or in_the_forest o:: IO(), or, say, f o:: Bool ( en.wikipedia.org/wiki/Duck_typing)) then: "o" can be a duck, or a dragon, that quacks, but there is no dynamic binding: o's type must be the only type with a function quack in this context (it cannot be both duck and dragon in this context, one being chosen dynamically according to the value of "o"). This avoids the problem of calling quack for an incorrect value (there can be no dragons into a pond, trying to impersonate a duck). Cheers, Carlos

1 0

Re: [Gtk2hs-users] Woes on MacOS 10.6 - linking issues -now working, but Glade is missing in v0.11 and v0.10.1 still won't compile SOLVED compile of 10.1
by Brett Giles 13 Jun '10

13 Jun '10

Finally figured it out - leave the scripts for ghc and hsc2hs alone and do the configure for gtk2hs 0.10.11 like this: ./configure --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' On Jun 12,2010, at 3:53 PM, Brett Giles wrote: > Hi everyone, > > Thanks for the variety of suggestions - I resolved this by uninstalling the Haskell-platform DMG based package and using the one from macports. I then, as mentioned elsewhere, manually modified my hsc2hs shell script to ensure the correct code was generated. > > However, I see that the cabal install for version 11 contains no Glade modules. I saw there was a patch posted by Andy Stewart for it a while back, is there any ETA for it for the public? > > I am, (so sad for me:) a bit hooped as I was going to give a demo of a program in a couple of days, but my code depends heavily on Glade and I can't seem to get the prior version of Gtk2HS (0.10.1) to compile at all. (Issues with x86_64 vs i386 - but I have tried for three hours to get the magic combination of modifications to the ghc script, the hsc2hs script and environment variable to no avail). > > If anyone has had luck on getting the 10.1 version to build (on a brand new install of OSx v10.6.3, macports Haskell Platform meaning GHC is 6.10.4, I'd love to hear how you did it. > > (I did check out the variety of tickets related to this, especially http://hackage.haskell.org/trac/ghc/ticket/3400 and the recent conversations on this list between Chris K. and Axel. > > > On Jun 11,2010, at 2:40 AM, Axel Simon wrote: > >> Hi Brett, >> >> On 11.06.2010, at 04:53, Brett Giles wrote: >> >>> Hi Folks >>> >>> I seem to have Gtk2HS 0.11 installed, but not quite working. Interestingly, I can run a demo, such as the hello/World.hs example, directly in ghci. However, when I try to do a ghc --make on any code containing gtk2hs I get a link error like this: >>> >>> Undefined symbols: >>> "_iconv_close", referenced from: >>> _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) >>> (maybe you meant: _hs_iconv_close) >>> "_iconv", referenced from: >>> _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) >>> (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) >>> "_iconv_open", referenced from: >>> _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) >>> (maybe you meant: _hs_iconv_open) >>> ld: symbol(s) not found >>> >>> >>> I do have libiconv installed as a universal library via macports. gtk, glade etc., are also universal installed via macports. >>> >> >>> I downloaded the OSX Haskell Platform package and am running ghc 6.12.1 >>> >> >> >> The iconv issue is usually that you also have a libiconv that Apple ships. The platform ghc probably links against that while macports (and thus Gtk+) uses its own. I have no idea who's to blame here but I guess you should be trying to change your LD_LIBRARY_PATH or your DYLD_LIBRARY_PATH to /opt/sw since that contains the more complete version. >> >> Cheers, >> Axel > > Brett Giles > Grad Student, Formal Methods, Category Theory, > University of Calgary > brett.giles(a)ucalgary.ca > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Gtk2hs-users mailing list > Gtk2hs-users(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > Brett Giles Grad Student, Formal Methods, Category Theory, University of Calgary brett.giles(a)ucalgary.ca

1 0

Re: [Haskell] ANNOUNCE: Sifflet visual programming language, release 0.1.7
by Henning Thielemann 13 Jun '10

13 Jun '10

On Fri, 11 Jun 2010, Ben Millwood wrote: > On Fri, Jun 11, 2010 at 2:52 PM, Henning Thielemann > <lemming(a)henning-thielemann.de> wrote: >> >> I'm uncertain whether fgl conforms to the package versioning policy, but >> if it does, then changes in its Cabal file should not bother sifflet. >> Thus upper bound fgl < 5.4.3 should be restrictive enough. >> > > The PVP says that one of the first two numbers are required to change > if an API change is likely to break code using it, so < 5.5 would > probably suffice. A bump to fgl-5.4.3 might include API *extensions* that may break sifflet, if it imports entire FGL modules in an unqualified way.

4 3

Similarities between web programming and functional programming
by Nilanjan Raychaudhuri 13 Jun '10

13 Jun '10

Hi all, As a newbie into functional programming and especially Haskell I am curious to know how functional programming style fits into building web applications? And how it compares to building web apps in Ruby or Java. Any pointer to article/literature will be helpful. Thanks Nilanjan

3 2

Re: [Gtk2hs-users] Woes on MacOS 10.6 - linking issues -now working, but Glade is missing in v0.11 and v0.10.1 still won't compile
by Brett Giles 13 Jun '10

13 Jun '10

Hi everyone, Thanks for the variety of suggestions - I resolved this by uninstalling the Haskell-platform DMG based package and using the one from macports. I then, as mentioned elsewhere, manually modified my hsc2hs shell script to ensure the correct code was generated. However, I see that the cabal install for version 11 contains no Glade modules. I saw there was a patch posted by Andy Stewart for it a while back, is there any ETA for it for the public? I am, (so sad for me:) a bit hooped as I was going to give a demo of a program in a couple of days, but my code depends heavily on Glade and I can't seem to get the prior version of Gtk2HS (0.10.1) to compile at all. (Issues with x86_64 vs i386 - but I have tried for three hours to get the magic combination of modifications to the ghc script, the hsc2hs script and environment variable to no avail). If anyone has had luck on getting the 10.1 version to build (on a brand new install of OSx v10.6.3, macports Haskell Platform meaning GHC is 6.10.4, I'd love to hear how you did it. (I did check out the variety of tickets related to this, especially http://hackage.haskell.org/trac/ghc/ticket/3400 and the recent conversations on this list between Chris K. and Axel. > > > On Jun 11,2010, at 2:40 AM, Axel Simon wrote: > >> Hi Brett, >> >> On 11.06.2010, at 04:53, Brett Giles wrote: >> >>> Hi Folks >>> >>> I seem to have Gtk2HS 0.11 installed, but not quite working. Interestingly, I can run a demo, such as the hello/World.hs example, directly in ghci. However, when I try to do a ghc --make on any code containing gtk2hs I get a link error like this: >>> >>> Undefined symbols: >>> "_iconv_close", referenced from: >>> _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) >>> (maybe you meant: _hs_iconv_close) >>> "_iconv", referenced from: >>> _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) >>> (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) >>> "_iconv_open", referenced from: >>> _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) >>> (maybe you meant: _hs_iconv_open) >>> ld: symbol(s) not found >>> >>> >>> I do have libiconv installed as a universal library via macports. gtk, glade etc., are also universal installed via macports. >>> >> >>> I downloaded the OSX Haskell Platform package and am running ghc 6.12.1 >>> >> >> >> The iconv issue is usually that you also have a libiconv that Apple ships. The platform ghc probably links against that while macports (and thus Gtk+) uses its own. I have no idea who's to blame here but I guess you should be trying to change your LD_LIBRARY_PATH or your DYLD_LIBRARY_PATH to /opt/sw since that contains the more complete version. >> >> Cheers, >> Axel Brett Giles Grad Student, Formal Methods, Category Theory, University of Calgary brett.giles(a)ucalgary.ca

1 0

Looking for Haskell presenter in/around Columbus area
by Nilanjan Raychaudhuri 13 Jun '10

13 Jun '10

Hi all, I run a small meet up group called "Columbus polyglot programmer meet up group" ( http://www.meetup.com/The-Columbus-Polyglot-Programmers-Meetup-Group/) where bunch of us get together once in a month and talk about various programming languages. There is quite a bit of interest in Haskell and functional programming in general among the group. I was wondering whether anyone from the list who lives around Columbus, ohio area would be interested to talk about Haskell. Thanks Nilanjan

1 0

Iteratee rest and monad instance
by Tilo Wiklund 12 Jun '10

12 Jun '10

I've mostly been studying the Iteratee IO slides (with notes), so these things may already have been noted elsewhere (though I have not been able to find them with my cursory search). Also excuse my probably somewhat confused terminology, I hope I get the point across anyway. In both the slides and the current hackage package "finished" iteratees carry with them (in the constructor) the rest of the stream. I may miss something obvious here, but this seems to lead to some fishy details in the monad instance of iteratees presented in the slides. Firstly the iteratee given by return/pure has to carry with it a rest before a stream comes into the picture, though I guess one could argue that (Chunk "") is some kind of identity but this does not seem to be enforced in any way. Furthermore in the bind operator the rest of the iteratee from the bound (RHS) function seems to be ignored at some times and not at others (depending on the rest of the bound LHS value). I am probably missing something obvious or something relating to optimisation/server software but defining iteratees as "Iteratee s a = Cont (s -> Either (s, a) (Iteratee s a))" seems to lead to a more natural monad instance, and does not suffer from (what seems to me to be an issue) having to make predictions about the stream it will be passed. My question is thus, why the "rest" stream has to be carried by an Iteratee constructor, rather then be part of the value of the continuation function.

2 1

GATD and pattern matching
by Dupont Corentin 12 Jun '10

12 Jun '10

Hello, I am making a little GATD: > {-# LANGUAGE GADTs#-} > data Obs a where > Equal :: Obs a -> Obs a -> Obs Bool > Plus :: (Num a) => Obs a -> Obs a -> Obs a (etc..) > instance Show t => Show (Obs t) where > show (Equal a b) = (show a) ++ " Equal " ++ (show b) > show (Plus a b) = (show a) ++ " Plus " ++ (show b) > instance Eq t => Eq (Obs t) where > a `Equal` b == c `Equal` d = (a == c) && (b == d) > a `Plus` b == c `Plus` d = (a == c) && (b == d) The Equal constructor causes me problems, while the Plus is fine: test3.lhs:8:26: Could not deduce (Show a) from the context (t ~ Bool) arising from a use of `show' at test3.lhs:8:26-31 Possible fix: add (Show a) to the context of the constructor `Equal' In the first argument of `(++)', namely `(show a)' In the expression: (show a) ++ " Equal " ++ (show b) In the definition of `show': show (Equal a b) = (show a) ++ " Equal " ++ (show b) I guess this is because GADT refines type with pattern matching. Since Equal return type is Obs Bool and not Obs a, it cannot bind the type variable a to belong to Show. I don't see how to precise the type in the pattern match. I have another problem: test3.lhs:12:41: Couldn't match expected type `a' against inferred type `a1' `a' is a rigid type variable bound by the constructor `Equal' at test3.lhs:12:8 `a1' is a rigid type variable bound by the constructor `Equal' at test3.lhs:12:23 Expected type: Obs a Inferred type: Obs a1 In the second argument of `(==)', namely `c' In the first argument of `(&&)', namely `(a == c)' Cheers, Corentin

8 14

Re: [Haskell-cafe] Problems with threading?
by Isaac Gouy 12 Jun '10

12 Jun '10

--- On Thu, 6/10/10, Louis Wasserman <wasserman.louis(a)gmail.com> wrote: > Date: Thursday, June 10, 2010, 1:32 AM > Yeah, Control.Parallel would be nice to have. Heck, ideally I could get > the whole Haskell Platform, which would be a reasonable comparison to > the huge Java and C++ libraries accessible to those languages. And having the whole Haskell Platform still isn't enough to compile those regex-dna programs.

1 0

Code review of text-xml-generic
by Oscar Finnsson 11 Jun '10

11 Jun '10

Hi, I've been working on a (de)serialization package from/to XML (using SYB) and wondering if anyone feels like giving me a quick code review before I upload it to hackagedb. The source code can be found at http://github.com/finnsson/Text.XML.Generic It is *heavily* inspired by Text.JSON.Generic. The three files DataEx.hs (slightly modified version of Olegs code), ExGeneric.hs and ExTestGeneric.hs are not part of the package yet since I haven't got the deserialization to work for existentials yet (but I haven't given up!). I plan to upload the package to hackagedb by the end of this weekend so any comments before (and after) are more than welcome. -- Oscar

1 0

Encoding the encoding type of a string into its type
by Christopher Done 11 Jun '10

11 Jun '10

There are a lot of issues with string encoding type mismatches. Especially "automatic" conversions. This mailing list gets enough posts about encoding confusions. Would it make sense to make the string depend on its encoding type? E.g. a String UTF16 cannot be used with putStrLn :: String UTF8, it has to be used with putStrLn :: String UTF16. Provided the fundamental functions that read and write strings are type safe, there'll be no mix-ups? I'll think about this more later. Just putting the question out there so that I remember when I get home.

2 1

Re: [Haskell] Woes on MacOS 10.6 - linking issues
by Pepe Iborra 11 Jun '10

11 Jun '10

(moving to the cafe) There is an incompatibility between the version of iconv in Mac Os and the one included in MacPorts. As the RTS of the build of ghc in the Haskell Platform is linked against Mac Os iconv, you cannot use it with the build of gtk2hs from MacPorts. This is a known issue already commented elsewhere, in case you haven't found it already: http://www.mail-archive.com/haskell-cafe@haskell.org/msg69139.html http://stackoverflow.com/questions/2726248/ghc-6-12-and-macports Cheers, On Fri, Jun 11, 2010 at 4:53 AM, Brett Giles <brett.giles(a)ucalgary.ca> wrote: > Hi Folks > > I seem to have Gtk2HS 0.11 installed, but not quite working. Interestingly, I can run a demo, such as the hello/World.hs example, directly in ghci. However, when I try to do a ghc --make on any code containing gtk2hs I get a link error like this: > > Undefined symbols: > "_iconv_close", referenced from: > _hs_iconv_close in libHSbase-4.2.0.0.a(iconv.o) > (maybe you meant: _hs_iconv_close) > "_iconv", referenced from: > _hs_iconv in libHSbase-4.2.0.0.a(iconv.o) > (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) > "_iconv_open", referenced from: > _hs_iconv_open in libHSbase-4.2.0.0.a(iconv.o) > (maybe you meant: _hs_iconv_open) > ld: symbol(s) not found > > > I do have libiconv installed as a universal library via macports. gtk, glade etc., are also universal installed via macports. > > I downloaded the OSX Haskell Platform package and am running ghc 6.12.1 > > Other programs seem to be having some issues as well though, For instance, a command line program seems to compile fine, but when it runs I get the message: > > $ emlqpl (<<<--- My "successfully" compiled program - batch only, no gtk items) > dyld: Library not loaded: /opt/local/lib/libgtk-quartz-2.0.0.dylib > Referenced from: /usr/local/bin/emlqpl > Reason: image not found > Trace/BPT trap > > > > Does anyone have any suggestions? > > Brett Giles > Grad Student, Formal Methods, Category Theory, > University of Calgary > brett.giles(a)ucalgary.ca > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- -- José Iborra http://www.dsic.upv.es/~jiborra -- UPV Valencia Telf. (+34) 96 387 00 00 (ext) 83529 -- Camino de Vera s/n. 46022 Valencia (Spain)

1 0

Re: package naming policy (was: Please check your dependencies on fgl)
by John Lato 11 Jun '10

11 Jun '10

> From: Don Stewart <dons(a)galois.com> > > ivan.miljenovic: >> Thomas Bereknyei are currently re-writing fgl (just about completely >> from scratch) and we plan to make an initial release to get feedback >> on the API in the next few weeks. >> >> However, I'm sending this email out now to warn people that I highly >> doubt any code that was written for the current version of fgl >> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the >> new version. > > How about you give the library a different name then -- so as not to > break all those programs? > > A complete rewrite with a new maintainer: fgl-awesome I would like to argue against this practice, i.e. re-naming new, incompatible versions of existing packages. I think it's bad for the following reasons: 1. It makes development by new users more difficult by fracturing the package-space (the "Which version of QuickCheck should I use?" problem). Since this is already an acknowledged issue, I think it's better that developers not add to it. 2. It discourages adoption of the latest version despite any benefits the later version may provide. This also leads to greater incompatibility between dependent packages. 3. For packages in the platform, I believe this will create uncertainty about which package(s) should be included with new major releases. 4. It adds to the maintainer workload as the same person or team will often be responsible for both packages. I do agree that there are legitimate reasons why users may decide to remain with older versions, however I think that in nearly all cases the proper solution is to follow the PVP and for users to include upper dependency bounds in .cabal files. In particular, for the very common case of compatibility with older code, an upper dependency bound seems like the correct approach. IMHO changing a package name should be for when developers intend to continue development (not just maintenance releases) along both branches. My 2 cents, anyway. John

5 8

Re: [Haskell-cafe] How to "Show" an Operation?
by Martin Drautzburg 11 Jun '10

11 Jun '10

On Monday, 7. June 2010 23:28:08 Evan Laforge wrote: > I just meant you could add instances: > > instance Functor (Named a) where fmap f named = named { val_of = f > (val_of named) } > instance Applicative (Named a) where ... likewise, but maybe not a > great fit unless you have a "no name" for 'pure' So far so good. However my "Named" things are all functions and I don't see I ever want to map over any of them. But what I'd like to do is use them like ordinary functions as in: f::Named (Int->Int) f x Is there a way to do this, other than writing apply::Named Int ->Int apply n x = (val_of n) x -- Martin

6 12

Help with Bird problem 3.3.3
by Peter Hilal 11 Jun '10

11 Jun '10

I'm working my way through Bird's _Introduction to Functional Programming Using Haskell_. I'd appreciate any help with problem 3.3.3, which is: "Division of natural numbers can be specified by the condition (n * m) / n = m for all positive n and all m. Construct a program for division and prove that it meets the specification." The required construction relies on the following definitions: data Nat = Zero| Succ Nat (+) :: Nat -> Nat m + Zero = m m + Succ n = Succ (m + n) (*) :: Nat -> Nat m * Zero = Zero m * Succ n = m * n + m Proceeding as Bird does in Sec. 3.2.2, where he derives the definition of "-" from the specification "(m + n) - n = m", I've so far gotten the first case, in which m matches the pattern "Zero", simply by (i) substituting Zero for m in the specification, (ii) substituting Succ n for n in the specification (solely because n is constrained to be positive), and (iii) reducing by applying the first equation of "*": Case Zero: (Succ n * Zero) / Succ n = Zero ≡ {first equation of "*"} Zero / Succ n = Zero Easy enough, and completely intuitive, since we expect Zero divided by any non-Zero finite number to be Zero. The next case, in which m matches the pattern "Succ m", is where I get stuck, and I really have no intuition about what the definition is supposed to be. My first step is to substitute "Succ m" for "m" in the given specification, and to substitute Succ n for n in the specification (for the same reason, as above, that n is constrained to be positive), and then to use the definition of "*" to reduce the equation: Case Succ m: Succ n * Succ m / Succ n = Succ m ≡ {second equation of "*"} (Succ n * m + Succ n) / Succ n = Succ m Where do I go from here? Thank you so much.

5 4

Thread scheduling
by Andrew Coppin 11 Jun '10

11 Jun '10

Control.Concurrent provides the threadDelay function, which allows you to make the current thread sleep until T=now+X. However, I can't find any way of making the current thread sleep until T=X. In other words, I want to specify an absolute wakeup time, not a relative one. What's even more frustrating is that, reading the source code, it appears that the internal RTS primitive *is* actually using an absolute time, but this isn't exposed anywhere that I can get at. Is there any danger that this could be fixed at some point? (I might also interject something about Data.Time, which seems to hardly let me do anything, but strictly that's a seperate topic...)

4 4

ANN: bytestring-trie 0.2.2 (major bugfix)
by wren ng thornton 11 Jun '10

11 Jun '10

-------------------------------------------- -- bytestring-trie 0.2.2 (major bugfix) -------------------------------------------- Another release for efficient finite maps from (byte)strings to values. This version corrects a major bug affecting all users who merge tries. -------------------------------------------- -- Changes (since 0.1.4) -------------------------------------------- * Corrected a major bug in mergeBy which caused conflicting values to be merged in the wrong order. Since this is a core function, all other merging-based functions are affected as well (e.g., unionR, unionL,...). The bug was filed by Gregory Crosswhite (thanks!). * added Data.Trie.Convenience.fromListWith --- A variant of 'fromListR' that takes a function for combining values on conflict. * generalized the type of toListBy * removed KeyString and KeyElem aliases * documentation tweaks -------------------------------------------- -- Future work -------------------------------------------- * Worked on explicit definitions for foldl and foldr, as opposed to the default definitions given by Foldable using Endo. The suggested definitions are around 3x faster than the old definitions, however the order of folding is different than foldrWithKey (which seems to have the correct order). These definitions are not currently being used, but perhaps the future will see faster folding functions for Tries. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/package/bytestring-trie Darcs: http://community.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://community.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring… -- Live well, ~wren

1 0

QuickCheck 2
by wren ng thornton 11 Jun '10

11 Jun '10

Since GHC 6.12 ships with QC2 it looks like it's finally time to get around to converting some old testing scripts. Unfortunately, one of the things I couldn't figure out last time I looked (and hence why I haven't switched) is how to reconfigure the configuration parameters to the driver function. Is there a porting guide anywhere, or how else can I adjust the configuration parameters (in particular, the configMaxTest and configMaxFail parameters)? -- Live well, ~wren

2 3

Re: [Haskell-cafe] Problems with threading?
by Isaac Gouy 11 Jun '10

11 Jun '10

--- On Thu, 6/10/10, Louis Wasserman <wasserman.louis(a)gmail.com> wrote: > Date: Thursday, June 10, 2010, 1:32 AM > Yeah, Control.Parallel would be nice to have. Heck, ideally I could get > the whole Haskell Platform, which would be a reasonable comparison to > the huge Java and C++ libraries accessible to those languages. > Out of curiosity, though, Haskell's thread-ring implementation just > tumbled down the rankings http://shootout.alioth.debian.org > /u64q/program.php?test=threadring&lang=ghc&id=3. Previously, it'd been > doing most of its work on a single core, now it's spread out. Any ideas > for fixin' it? (I'm going to to try using forkOnIO.) There are 4 sets of "rankings" so - http://shootout.alioth.debian.org/u64/program.php?test=threadring&lang=ghc&… I have been wondering what approach is recommended when one part of a program would be a lot faster with -threaded but other parts of the program would be a lot faster without -threaded. I can see that the C++ and Fortran and ... programmers would just wrap part of their program source code with a pragma.

3 6

Re: [Haskell-cafe] Problems with threading?
by Isaac Gouy 10 Jun '10

10 Jun '10

--- On Thu, 6/10/10, Louis Wasserman <wasserman.louis(a)gmail.com> wrote: > Date: Thursday, June 10, 2010, 11:25 AM > > There are 4 sets of "rankings" so - > > http://shootout.alioth.debian.org/u64/program.php?test=threadring&lang=ghc&… > Yes, but Haskell used to be doing much better specifically on the u64q, > which was why I was surprised. I tend not to believe "used to be doing much better" comments until I'm shown the numbers ;-)

1 0

Haskell logo
by Andrew Coppin 10 Jun '10

10 Jun '10

I just visited haskell.org and noticed that the old logo is back. Anybody know when/why this happened?

2 1

Contacting Planet Haskell
by Jason Dagit 10 Jun '10

10 Jun '10

Hello, I recently tried to send an email to the planet Haskell admins. The webpage says to use planet(a)community.haskell.org. The mail was undelivered after several days and the daemon gave up trying to deliver it. My sending did overlap with the haskell.org downtown but I don't think that should have been a problem because: 1) It looks like it retried after haskell.org was back up 2) I'm pretty sure community is a different host than haskell.org 3) Shouldn't a backup mx handle this? Thanks, Jason

2 2

Removing alternate items from a list
by R J 10 Jun '10

10 Jun '10

What's the cleanest definition for a function f :: [a] -> [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? _________________________________________________________________ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

14 23

A Finally Tagless Pi Calculus
by Edward Kmett 10 Jun '10

10 Jun '10

Keegan McAllister gave a very nice talk at Boston Haskell last night about "First Class Concurrency". His slides are available online at http://t0rch.org/ His final few slides covered the Pi calculus: http://en.wikipedia.org/wiki/Pi_calculus I took a few minutes over lunch to dash out a finally tagless version of the pi calculus interpreter presented by Keegan, since the topic of how much nicer it would look in HOAS came up during the meeting. For more information on finally tagless encodings, see: http://www.cs.rutgers.edu/~ccshan/tagless/jfp.pdf<http://www.cs.rutgers.edu/%7Eccshan/tagless/jfp.pdf> Of course, Keegan went farther and defined an encoding of the lambda calculus into the pi calculus, but I leave that as an exercise for the reader. ;) -Edward Kmett > {-# LANGUAGE Rank2Types, TypeFamilies, FlexibleInstances #-} > module Pi where > import Control.Applicative > import Control.Concurrent A finally tagless encoding of the Pi calculus. Symantics is a portmanteau of Syntax and Semantics. > class Symantics p where > type Name p :: * > new :: (Name p -> p) -> p > out :: Name p -> Name p -> p -> p > (|||) :: p -> p -> p > inn :: Name p -> (Name p -> p) -> p > rep :: p -> p > nil :: p > embed :: IO () -> p Type level fixed points > newtype Nu f = Nu { nu :: f (Nu f) } > fork :: IO () -> IO () > fork a = forkIO a >> return () > forever :: IO a -> IO a > forever p = p >> forever p Executable semantics > instance Symantics (IO ()) where > type Name (IO ()) = Nu Chan > new f = Nu <$> newChan >>= f > a ||| b = forkIO a >> fork b > inn (Nu x) f = readChan x >>= fork . f > out (Nu x) y b = writeChan x y >> b > rep = forever > nil = return () > embed = id A closed pi calculus term > newtype Pi = Pi { runPi :: forall a. Symantics a => a } > run :: Pi -> IO () > run (Pi a) = a > example = Pi (new $ \z -> (new $ \x -> out x z nil > ||| (inn x $ \y -> out y x $ inn x $ \ y -> nil)) > ||| inn z (\v -> out v v nil)) A pretty printer for the pi calculus > newtype Pretty = Pretty { runPretty :: [String] -> Int -> ShowS } > > instance Symantics Pretty where > type Name Pretty = String > new f = Pretty $ \(v:vs) n -> > showParen (n > 10) $ > showString "nu " . showString v . showString ". " . > runPretty (f v) vs 10 > out x y b = Pretty $ \vs n -> > showParen (n > 10) $ > showString x . showChar '<' . showString y . showString ">. " . > runPretty b vs 10 > inn x f = Pretty $ \(v:vs) n -> > showParen (n > 10) $ > showString x . showChar '(' . showString v . showString "). " . > runPretty (f v) vs 10 > p ||| q = Pretty $ \vs n -> > showParen (n > 4) $ > runPretty p vs 5 . > showString " | " . > runPretty q vs 4 > rep p = Pretty $ \vs n -> > showParen (n > 10) $ > showString "!" . > runPretty p vs 10 > nil = Pretty $ \_ _ -> showChar '0' > embed io = Pretty $ \_ _ -> showString "{IO}" > instance Show Pi where > showsPrec n (Pi p) = runPretty p vars n > where > vars = fmap return vs ++ > [i : show j | j <- [1..], i <- vs] where > vs = ['a'..'z'] Pi> example nu a. (nu b. (b<a>. 0 | b(c). c<b>. b(d). 0) | a(b). b<b>. 0)

4 4

Re: [Haskell-cafe] Removing alternate items from a list
by John Lato 10 Jun '10

10 Jun '10

> From: Markus L?ll <markus.l2ll(a)gmail.com> > > So out of curiosity i took the definitions given in this thread, and > tried to run timing-tests. > Here's what I ran: >> ghc -prof -auto-all -o Test Test.h >> Test +RTS -p > and then looked in the Test.prof file. I think this is a poor approach for timing tests, for two reasons: 1) -O or -O2. Reporting performance results from non-optimized builds is often highly misleading. 2) -auto-all inhibits performance of code, sometimes significantly. You'd be better off using a non-profiling build and criterion. Plus criterion does the statistics for you and warns about possibly invalid samples. John

1 0

Execution call graph pruning
by C K Kashyap 10 Jun '10

10 Jun '10

Hi, I have a call grah which contains information of the edges in the following format caller callee count (time spent by the caller) =================================== foo bar 10 100 xxx yyy 20 10 zzz yyy 10 10 (I used pintool pintool.org to generate this call graph) Now, the problem is that the graph is huge and it take a long to render using 'dot' or use any visualizing tool. Even if they render, it's too cluttered to be useful. I wanted to prune the graph in such a way that I'd have only the edges corresponding to the top 10% of the time consumers. What would be a good way to do such a thing? Has anyone written some utility that I could use? -- Regards, Kashyap

2 2

Strange discrepancy between Emacs interpreter and command-line on windows
by Arnaud Bailly 10 Jun '10

10 Jun '10

Hello, I have a strange issue which sprang today out of nowhere. When I load a certain file using bytestring package in Ghci using emacs, I got the following error: Couldn't match expected type `Data.ByteString.Internal.ByteString' against inferred type `bytestring-0.9.1.4:Data.ByteString.Internal.ByteString' In the second argument of `hPutStrLn', namely `(fromString msgs)' In a stmt of a 'do' expression: hPutStrLn cnx (fromString msgs) The same file compiles fine on the command-line. I have a single installation of haskell platform, using ghc 6.10.4, on windows XP. Thanks for any help, Arnaud Bailly

4 5

Stone age programming for space age hardware?
by Michael Schuerig 09 Jun '10

09 Jun '10

A few days ago, I watched a presentation by Gerard Holzmann on the development methodology and programming techniques used at JPL for writing the software for the next Mars mission. I found the talk entertaining and learned a few things. http://www.infoq.com/presentations/Scrub-Spin Among the arsenal of methods they use to ensure correctness is model checking for the algorithms used as well as rather restrictive coding standards. Well, model checking sounds good, real formal oomph. But the coding itself? For one thing, they're using C. On top of that, the coding standards prohibit dynamic memory allocation, recursion, and loops without explicit bounds; see [*] for more details. I was dumbfounded, although I have known all this. I have no personal experience with either embedded or real time software, but I've been aware that C still is the most popular language for that purpose and that coding standards are very restrictive. The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. I have a hunch that the real restrictions of this kind of software are not concerned with fixed memory, iterations, whatever, but rather with guaranteed bounds. If that is indeed the case, how feasible would it be to prove relevant properties for systems programmed in Haskell? Michael [*] http://spinroot.com/gerard/pdf/Power_of_Ten.pdf -- Michael Schuerig mailto:michael@schuerig.de http://www.schuerig.de/michael/

6 9

strange errors with unix-compat
by Günther Schmidt 09 Jun '10

09 Jun '10

Hello, when compiling unix-compat I get this: 4 of 4] Compiling System.PosixCompat.Extensions ( dist/build/System/PosixCompat/Extensions.hs, dist/build/System/PosixCompat/Extensions.o ) cbits/HsUnixCompat.c: In function `unix_major': cbits/HsUnixCompat.c:4:0: warning: implicit declaration of function `major' cbits/HsUnixCompat.c: In function `unix_minor': cbits/HsUnixCompat.c:8:0: warning: implicit declaration of function `minor' cbits/HsUnixCompat.c: In function `unix_makedev': cbits/HsUnixCompat.c:12:0: warning: implicit declaration of function `makedev' /usr/gnu/bin/ar: creatin and an ghci -package gives me this: GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. ghc: /home/guenni/.cabal/lib/unix-compat-0.1.2.1/ghc-6.10.4/HSunix-compat-0.1.2.1.o: unknown symbol `major' Loading package unix-compat-0.1.2.1 ... linking ... ghc: unable to load package `unix-compat-0.1.2.1' How can I fix this? Günther

2 1

Monadic presentation of delimited continuations and dissection
by Greg Meredith 09 Jun '10

09 Jun '10

Dear Haskellians, After reading through the Dybvig, Jones and Sabry paper on the monadic presentation of delimited continuations, it seems like one can come up with a direct representation of the control contexts and meta continuations framework as an instance of McBride's dissection mechanism. Do either of you know if that work has already been done? McBride doesn't use that as an example in his Clowns and Jokers paper. Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com

1 0

HP/Cygwin and Curl
by Chris Dornan 09 Jun '10

09 Jun '10

Hi, I am trying to install the curl 1.3.5 hackage on the latest Haskell Platform (2010.1.0.0) on Windows 7. I have installed lib-curl-devel (7.19.6-1) on CygWin but I can't use Cygwin as (apparently) every attempt to install a package ends like this: C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin\windres: can't open temporary file `\/cca01252.irc': No such file or directory Using cabal-install with MSYS generally works. Can HP be used with Cygwin? I have yet to find a way of installing Curl so that the curl hackage will recognise it-does anybody know how to do this? (I couldn't find any explanation of how HP can be used with Cygwin or how to install Curl for use with the hackage. If anyone knows where I can get these that would be fine much appreciated; the Haskell.org outage is compounding this.) Thanks in advance! Vhris

5 11

Re: Rewriting a famous library and using the same name: pros and consf
by John Lato 09 Jun '10

09 Jun '10

> From: Stephen Tetley <stephen.tetley(a)gmail.com> > > Hello all > > While new libraries develop at pace, their documentation rarely does; > so I'd have to disagree with John's claim that re-naming libraries > makes development by new users harder. I'd argue that having tutorials > not work for later revisions is more confusing than having various > packages doing the same thing. I'd also contend that beginners are > better off lagging behind the cutting edge and using Parsec 2, > QuickCheck 1, Haskore-vintage, as the earlier version all have > comprehensive documentation - Parsec 2 and Haskore have extensive > manual/tutorials, QuickCheck 1 was small enough that the original > QuickCheck paper covered its use. Lagging behind the cutting edge is one thing, but learning possibly-deprecated or soon-to-be-obsolete interfaces is another. I would contend that in each case the intention is for the earlier version to be superseded because of significant (hopefully user-driven) benefits provided by the new design. Now beginners are in the very frustrating situation of having invested time with a codebase that they learn is obsolete. Depending on the significance of the changes, some amount of that knowledge can be carried forward, but it's a disheartening position to be in and I would expect a few could give up entirely at that point. I think that's worse than floundering around with no documentation at all. Of course a better solution is for maintainers to update their manuals! > > An advantage of separate names (both for the package name and module > name-space) is that its easier to have both packages installed at the > same time - the old one to work with while learning the package, the > new one if other installed packages depend on it. This can still be > done with package-hiding but its less straight-forward. With proper .cabal files and dependency bounds this isn't an issue. If you're working in ghci I think it's the same amount of work either way, at least with my workflow.

4 3

Proposal to solve Haskell's MPTC dilemma
by Carlos Camarao 09 Jun '10

09 Jun '10

This message presents, informally, a proposal to solve Haskell's MPTC (multi-parameter type class) dilemma. If this informal proposal turns out to be acceptable, we (I am a volunteer) can proceed and make a concrete proposal. The proposal has been published in the SBLP'2009 proceedings and is available at www.dcc.ufmg.br/~camarao/CT/solution-to-MPTC-dilemma.pdf The well-known dilemma (hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma) is that it is generally accepted that MPTCs are very useful, but their introduction is thought to require the introduction also of FDs (Functional Dependencies) or another mechanism like ATs (Associated Types) and FDs are tricky and ATs, somewhat in a similar situation, have been defined more recently and there is less experience with its use. In www.haskell.org/ghc/dist/current/docs/html/users_guide/type-class-extension… there exists a solution to the termination problem related to the introduction of MPTCs in Haskell. In our proposal, neither FDs nor any other mechanism like ATs are needed in order to introduce MPTCs in Haskell; the only change we have to make is in the ambiguity rule. This is explained below. The termination problem is essentially ortogonal and can be dealt with, with minor changes, as described in the solution presented in the above mentioned (type-class-extensions) web page. Let us review the ambiguity rule used in Haskell-98 and after that the ambiguity rule used in GHC. Haskell-98 ambiguity rule (which is adequate for Haskell-98's single parameter type classes) is: a type C => T is ambiguous iff there is a type variable v that occurs in the "context" (constraint set) C but not in the simple (unconstrained) type T. For example: forall a.(Show a, Read a)=>String is ambiguous, because "a" occurs in the constraints (Show a,Read a) but not in the simple type (String). In the context of MPTCs, this rule alone is not enough. Consider, for example (Example 1): class F a b where f:: a->b class O a where o:: a and k = f o:: (C a b,O a) => b Type forall a b. (C a b,O a) => b can be considered to be not ambiguos, since overloading resolution can be defined so that instantiation of "b" can "determine" that "a" should also be instantiated (as FD b|->a does), thus resolving the overloading. GHC, since at least version 6.8, makes significant progress towards a definition of ambiguity in the context of MPTCs; GHC 6.10.3 Users Guide says (section 7.8.1.1): "GHC imposes the following restrictions on the constraints in a type signature. Consider the type: forall tv1..tvn (c1, ...,cn) => type. ... Each universally quantified type variable tvi must be reachable from type. A type variable a is reachable if it appears in the same constraint as either a type variable free in the type, or another reachable type variable. For example, type variable "a" in constraint (O a) in the example above is reachable, because it appears in (C a b) (the same constraint as type variable "b", which occurs in the simple type). Our proposal is: consider unreachability not as indication of ambiguity but as a condition to trigger overloading resolution (in a similar way that FDs trigger overloading resolution): when there is at least one unreachable variable and overloading is found not to be resolved, then we have ambiguity. Overloading is resolved iff there is a unique substitution that can be used to specialize the constraint set to one, available in the current context, such that the specialized constraint does not contain unreachable type variables. (A formal definition, with full details, is in the cited SBLP'09 paper.) Consider, in Example 1, that we have a single instance of F and O, say: instance F Bool Bool where f = not instance O Bool where o = True and consider also that "k" is used as in e.g.: kb = not k According to our proposal, kb is well-typed. Its type is Bool. This occurs because (F a b, O a)=>Bool can be simplified to Bool, since there exists a single substitution that unifies the constraints with instances (F Bool Bool) and (O Bool) available in the current context, namely S = (a|->Bool,b|->Bool). As another example (Example 2), consider: {-# NoMonomorphismRestriction, MultiParameterTypeClasses #-} data Matrix = ... data Vector = ... class Mult a b c where (*):: a ! b ! c instance Mult Matrix Vector Matrix where (*) = ... instance Mult Matrix Vector Vector where (*) = ... m1:: Matrix = ... m2:: Vector = ... m3:: Vector = ... m = (m1 * m2) * m3 GHC gives the following type to m: m :: forall a, b. (Mult Matrix Vector a, Mult a Vector b) => b However, "m" cannot be used effectively in a program compiled with GHC: if we annotate m::Matrix, a type error is reported. This occurs because the type inferred for "m" includes constraints (Mult Matrix Vector a, Mult a Vector Matrix) and, with b|->Matrix, type variable "a" appears only in the constraint set, and this type is considered ambiguous. Similarly, if "m" is annotated with type Vector, the type is also considered ambiguous. There is no means of specializing type variable "a" occurring in the type of "m" to Matrix. And no FD may be used in order to achieve such specialization, because we do not have here a FD: "a" and "b" do not determine "c" in class Mult: for (a,b = Matrix,Vector), we can have "c" equal to either Matrix or Vector. According to our proposal, type m:: forall a. (Mult Matrix Vector a, Mult a Vector Matrix)) => Matrix is not ambiguous, in the context of the class and instance declarations of Example 2 (since "a" can be instantiated to Matrix), whereas type m:: forall a.(Mult Matrix Vector a, Mult a Vector Matrix)) => Vector is ambiguous in this context. We would like to encourage compiler front-end developers to change Haskell's ambiguity rule, and test with as many examples as desired, including recurring examples that appear in Haskell mailing lists involving MPTCs, FDs etc. We would like to hear and discuss your doubts, opinions, comments, criticisms etc. Cheers, Carlos

10 20

Tricks with GMap -- question about conflicts w/ indexed type families
by oleg＠okmij.org 09 Jun '10

09 Jun '10

Ryan Newton wrote: > What I would next *like* to do is something like the following: > > import qualified Data.IntMap as DI > instance FitInWord t => GMapKey t where > data GMap t v = GMapInt (DI.IntMap v) deriving Show > > The problem is that there's already a more general instance of GMapKey > that handles pairs by representing them as nested GMaps: > > instance (GMapKey a, GMapKey b) => GMapKey (a, b) where > data GMap (a, b) v = GMapPair (GMap a (GMap b v)) > .... > > Ideally, I want both of these to coexist (and to prioritize the more > specific one). With normal type classes, OverlappingInstances can > handle this, but with type families I get an error like the > following: First of all, if we forget about data families, OverlappingInstances still won't give us the desired behavior. GHC chooses overlapping instances based only on the instance head type, disregarding all constraints. Therefore, when asked to choose an instance for GMapKey (Int16,Int16), GHC would choose the second instance as it is more specific: the type (a,b) is more specific that the type t. Again, the constraints such as FitInWord are not used when choosing instances. This issue is discussed in detail at Choosing a type-class instance based on the context http://okmij.org/ftp/Haskell/types.html#class-based-overloading and on the Wiki Page http://haskell.org/haskellwiki/GHC/AdvancedOverlap These pages explain how can we make class constraints bear on the instance selection. But we still have the second problem: data families do not permit overlapping declarations. At first blush, it appears impossible to define GMapKey for specific pairs and default to the generic GMap instance for general pairs. Fortunately, a solution exists, shown below. The idea is to define an auxiliary type class (without data families). Such a type class permits overlapping instances and so makes possible the desired behavior of specific instances with the generic default. {-# LANGUAGE FlexibleInstances, FlexibleContexts #-} {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE OverlappingInstances #-} module GM where import Data.Int import Data.Word import Data.Bits import qualified Data.IntMap as IM -- ===== Begin a simplified GMap package -- A simplified class GMapKey class GMapKey t where data GMap t :: * -> * empty :: GMap t v lookup :: t -> GMap t v -> Maybe v instance GMapKey Int16 where data GMap Int16 v = GMI16 (IM.IntMap v) empty = GMI16 $ IM.empty lookup k (GMI16 m) = IM.lookup (fromIntegral k) m instance GMapKey Int32 where data GMap Int32 v = GMI32 (IM.IntMap v) empty = GMI32 $ IM.empty lookup k (GMI32 m) = IM.lookup (fromIntegral k) m -- Generic instance for pairs instance (GMapKey a, GMapKey b) => GMapKey (a, b) where data GMap (a, b) v = GMapPair (GMap a (GMap b v)) empty = GMapPair $ empty lookup k (GMapPair m) = error "Invoking the generic instance for pairs" -- ===== End the simplified GMap package -- The following is an optimization, which should appear in a different -- module. The optimization should not disturb the original GMap code. -- The following optimization is Ryan Newton's code -- A class for values that fit within one word class FitInWord v where toWord :: v -> Word fromWord :: Word -> v instance FitInWord (Int16,Int16) where toWord (a,b) = shiftL (fromIntegral a) 16 + (fromIntegral b) fromWord n = (fromIntegral$ shiftR n 16, fromIntegral$ n .&. 0xFFFF) -- Now we wish to define optimized instances of GMapKey for -- pairs of items that fit within a word. -- The following answers Ryan Newton's question -- Define our own product type, to avoid overlapping instances with the -- general GMapKey for pairs -- It's a newtype: it has no run-time overhead newtype OptimalPair a b = OptimalPair (a,b) instance FitInWord (a,b) => GMapKey (OptimalPair a b) where data GMap (OptimalPair a b) v = GMapInt (IM.IntMap v) deriving Show empty = GMapInt IM.empty lookup (OptimalPair k) (GMapInt m) = IM.lookup (fromIntegral$ toWord k) m -- Auxiliary class to choose the appropriate pair class ChoosePairRepr a b pr | a b -> pr where choose_pair :: (a,b) -> pr choosen_pair :: pr -> (a,b) instance ChoosePairRepr Int16 Int16 (OptimalPair Int16 Int16) where choose_pair = OptimalPair choosen_pair (OptimalPair p) = p -- Repeat the above for all other optimal pairs: -- (Int8, Int16), (Int16, Int8), etc. -- Template Haskell is very good to generate all such boiler-plate instances -- Choose a generic pair for all other pairs of values instance pr ~ (a,b) => ChoosePairRepr a b pr where choose_pair = id choosen_pair = id -- tests -- A specific instance is chosen test1 = let m = empty in GM.lookup (choose_pair (1::Int16,2::Int16)) m -- Nothing -- A general pair instance is chosen test2 = let m = empty in GM.lookup (choose_pair (1::Int32,2::Int16)) m -- *** Exception: Invoking the generic instance for pairs

1 0

Fwd: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
by Jake McArthur 09 Jun '10

09 Jun '10

Sorry, I hit Reply instead of Reply To All. ---------- Forwarded message ---------- From: Jake McArthur <jake.mcarthur(a)gmail.com> Date: Tue, Jun 8, 2010 at 6:16 PM Subject: Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons To: Don Stewart <dons(a)galois.com> Making a new name for an existing package subverts the intended meaning of major revision numbers. Libraries that break as a result of a major revision should have had more specific dependencies, and tutorials that go out of date should also have specified the version number of the package for which they were intended. It's a package maintainer's responsibility to respect version number conventions. I don't believe it is a package maintainer's responsibility to account for blatant misuse of it. - Jake

1 0

Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
by Ivan Lazar Miljenovic 09 Jun '10

09 Jun '10

Ian Lynagh <igloo(a)earth.li> writes: > On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: > >> A complete rewrite with a new maintainer: fgl-awesome > > In 10 years time, we don't want to have > fgl > fgl-awesome > fgl-great > fgl-joe > which all do the same thing, and have an unclear relationship to each > other. Definitely (though hopefully we wouldn't pick names like "fgl-awesome" anyway...). > I think the important question is: Once the new FGL is finished, will > there be a good reason (other than backwards compatibility) for people > to use the current FGL? > > If yes, then different names should be used. Otherwise, no matter how > different the API is, keeping the same name is the right thing to do. And this is why we're going to request the community's input on our API design: to try and avoid the situation where there's a specific reason to keep using the old one. As it stands, the only real advantage that I can think of is that the new version uses extensions, the old version doesn't (and hence is more compatible). > So if there is consensus that the new design is a better fgl, I think it > ought to keep the name. Which is what we're trying to build (the consensus, that is). Don has started a wiki page with the arguments here, and I've already added my 2c: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

Problems with threading?
by Louis Wasserman 09 Jun '10

09 Jun '10

While working on the Shootout, I noticed the following benchmarks: http://shootout.alioth.debian.org/u64/program.php?test=chameneosredux&lang=… <http://shootout.alioth.debian.org/u64/program.php?test=chameneosredux&lang=…> http://shootout.alioth.debian.org/u64q/program.php?test=chameneosredux&lang… The same program becomes almost 4 times slower when compiled with --threaded and run with +RTS -N5 -- even though the multi-core benchmark really only ever uses one processor. Other languages seem to have found a way of arranging these threads in a way such that parallelism actually happens, but as it stands, compiling this benchmark without --threaded actually makes Haskell competitive against the genuinely parallel alternatives in other languages...which is unusual by itself. I wanted to throw this out for people to discuss, because I'd like to see it improved. As it stands, I'm going to submit a version which asks not to be compiled with --threaded (and has a few other improvements). <http://shootout.alioth.debian.org/u64q/program.php?test=chameneosredux&lang…> Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

4 4

Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
by Alexander Solla 08 Jun '10

08 Jun '10

On Jun 8, 2010, at 2:38 AM, Alberto G. Corona wrote: > This is`t a manifestation of the Curry-Howard isomorphism? Yes, basically. If we rephrase the isomorphism as "a proof is a program, the formula it proves is a type for the program" (as Wikipedia states it), we can see the connection. The "characterization" of prelBreak I gave is a "type" for prelBreak. The type is richer than we can express in the Haskell type system ("prelbreak accepts a proposition p and a list xs, and returns a pair whose first element is the largest prefix of xs for which no x satisfies p, and whose second element is the complement of the first, taken in xs."), but we can still reason about the richer type mathematically, and the Curry-Howard isomorphism applies to it.

1 0