June 2010 - Haskell-Cafe

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