July 2007 - Haskell-Cafe

Re: [Haskell] View patterns in GHC: Request for feedback
by Simon Marlow 01 Aug '07

01 Aug '07

Dan Licata wrote: > Simon PJ and I are implementing view patterns, a way of pattern matching > against abstract datatypes, in GHC. Our design is described here: > > http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns > > If you have any comments or suggestions about this design, we'd love to > hear them. You can respond to this list (and we can take it to > haskell-cafe if the thread gets long) or, if you prefer, directly to me. At the risk of being a spoil-sport, I have a somewhat negative take on view patterns. Not because I think they're particularly bad, but because I don't think they're significantly useful enough to warrant adding to the language, at least if we also have pattern guards. All of the examples on the wiki page can be written in the same number of lines, sometimes with fewer characters, using pattern guards or some other existing Haskell idiom (e.g. the bit parsing example is much more nicely expressed using a bit-parsing monad). I believe adding yet another idiom will be detrimental: too much choice is bad. To my eyes, mixing bound and binding occurrences of variables in patterns in an arbitrarily nested way is sure to lead to confusion. The existing idioms all have a one-level deep notion of bound/binding scope, and in order to get more nesting you have to start naming things: this is good, IMO. Not that I think we should omit a language feature because it *could* be used to write obfuscated code; no, in this case I think nesting more than one level deep will *always* lead to obfuscated code. The use of the right-arrow is confusing, especially on the left of a case alternative or in a lambda expression. The main argument in favour of view patterns is: > it's possible that people would start routinely hiding the data > representation and exporting view functions instead, which would be an > excellent thing. My impression is that most of the time a data structure has a clever internal representation that you don't want to expose anyway. This is supported by the data structures we have in the base package, all these are abstract: Data.Set, Data.IntSet, Data.Map, Data.IntMap Data.Graph, Data.Sequence, Data.Bytestring, Data.Array, Data.HashTable, Data.Ratio(Rational) and most export view-like things (e.g. Data.Set.toList). The modules I found that export non-abstract types that should really be abstract: Data.Complex, Data.Tree So I don't think there's an overwhelming amount of stuff that would change if we had view patterns. In GHC itself most of our data structures are already abstract too. The View class is nice, even with just pattern guards. I'd be in favour of making it standard and actively encouraging its use. Cheers, Simon

17 43

Newbie question about Haskell skills progress
by peterv 01 Aug '07

01 Aug '07

Having only a couple of days of practice programming Haskell (but having read lots of books and docs), I find myself writing very explicit low level code using inner "aux" functions (accumulators and loops). Then I force myself to revise the code, replacing these aux functions with suitable higher-order functions from the library. However, I would like to use these higher order functions right away, without using low-level aux constructs, which is most likely caused by my very long history of imperative programming. Is this the "normal" way of progressing in Haskell, or should I consider a different approach? Thanks, Peter

4 3

infinite list of random elements
by Chad Scherrer 01 Aug '07

01 Aug '07

I'm trying to do something I thought would be pretty simple, but it's giving me trouble. Given a list, say [1,2,3], I'd like to be able to generate an infinite list of random elements from that list, in this case maybe [1,2,1,3,2,1,3,2,3,1,2,...]. I'm using IO for random purely due to laziness (my own, not Haskell's). I was thinking the best way to do this might be to first write this function: randomElts :: [a] -> [IO a] randomElts [] = [] randomElts [x] = repeat (return x) randomElts xs = repeat r where bds = (1, length xs) xArr = listArray bds xs r = do i <- randomRIO bds return (xArr ! i) Then I should be able to do this in ghci: > sequence . take 5 $ randomElts [1,2,3] [*** Exception: stack overflow Any idea what's going on? I thought laziness (Haskell's, not my own) would save me on this one. Thanks! Chad

9 13

Operational Semantics of Haskell
by Lewis-Sandy, Darrell 01 Aug '07

01 Aug '07

Is there a good source for the operational semantics of Haskell? I am trying to squeeze the most efficiency out of a bit of code and am looking to remove unnecessary reductions.

4 3

Newbie question about automatic memoization
by peterv 31 Jul '07

31 Jul '07

Does Haskell support any form of automatic memorization? For example, does the function iterate f x which expands to [x, f(x), f(f(x)), f(f(f(x))), … gets slower and slower each iteration, or can it take advantage of the fact that f is referentially transparent and hence can be "memoized / cached"? Thanks, Peter No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.476 / Virus Database: 269.10.25/926 - Release Date: 29/07/2007 23:14

5 5

problem building lambdabot
by Michael Vanier 31 Jul '07

31 Jul '07

When I try to build lambdabot, I get this: Configuring lambdabot-4.0... configure: Dependency base-any: using base-2.1.1 configure: Dependency unix-any: using unix-2.1 configure: Dependency network-any: using network-2.0.1 configure: Dependency parsec-any: using parsec-2.0 configure: Dependency mtl-any: using mtl-1.0.1 configure: Dependency haskell-src-any: using haskell-src-1.0.1 configure: Dependency readline-any: using readline-1.0 configure: Dependency QuickCheck-any: using QuickCheck-1.0.1 Setup.hs: cannot satisfy dependency arrows-any I'm using ghc 6.6.1 compiled from source (by me) on Debian Linux. I thought that arrows were included with the ghc distribution. Does anyone know what's happening and how to fix it? TIA, Mike

4 9

curious hxt error
by brad clawsie 31 Jul '07

31 Jul '07

i am having a problem with hxt, i was wondering if anyone here has experience with it. in particular, i find that the xread function chokes on xml files with xml declarations, and i am not sure why. consider this sample script: module Main where import Text.XML.HXT.Parser main = do xml <- getContents print $ head $ xread xml and this file content (test.xml): <?xml version="1.0"?> <foo><bar>BAR1</bar><bar>BAR2</bar></foo> running: $ runhaskell hxt.hs < test.xml NTree (XError 2 "\"string: \"<?xml version=\\\"1.0\\\"?>\\n<foo><bar>BAR1</ba...\"\" (line 1, column 6):\nunexpected xml\nexpecting legal XML name character\n") [] which clearly indicates a choke on the xml declaration but if i remove the xml declaration, i see no errors and i am able to get a valid data structure printing out any ideas? thanks brad

2 1

problem implementing an EDSL in Haskell
by Daniil Elovkov 31 Jul '07

31 Jul '07

Hello folks Haskell is considered good for embedded DSLs. I'm trying to implement some simple EDSL in a typeful manner and having a problem with looking up variable values. I've got an Expression GADT, which admits variables. The problem is with writing compute function which will lookup variable values in a type-safe manner. The exp. data type is like this data Exp a where Const a :: Val a -> Exp a Var :: a -> String -> Exp a -- where the first comp. isn't used,only for type info. .... So, obviously, I have to perform lookups in some 'scope' to compute the expression. By scope I mean the list of (name,value) pairs. How do I represent the scope? Well, I haven't gone that far as to encode statically the information about the type of every variable in scope. Instead, I used existentials to hide their types and put'em all in a list. For that purpose I introduced pack/unpack. -- value with dynamic type annotation -- m here and below can be Val, Exp, etc. -- to represent Val Int, Exp Int, etc. data Type m = TInt (m Int) | TString (m String) | TDouble (m Double) class Typed a where typ :: m a -> Type m instance Typed Int where typ x = TInt x instance Typed String where typ x = TString x instance Typed Double where typ x = TDouble x data Opaque m = forall a. (Typed a) => Opaque (m a) -- extract to an annotated representation extract :: Opaque m -> Type m extract (Opaque a) = typ a How would you suggest, I write compute function? My try was compute :: Scope -> Exp t -> Val t compute scope (Const x) = x -- trivial compute scope (Var t name) = -- intereseting part let opq = lookup name scope val = case opq of Nothing -> error "not in scope" Just opq -> extract opq expType = aux t in case val `matches` expType of -- I'd like to make some 'matches' func. Nothing -> error "type error" -- which would either produce an error Just v -> v -- or return the value, based on run-time tags matches :: Typed m -> Typed m -> Maybe (m a) BUT of course this type is bad, there's no 'a' in the left side matches (TInt x) (TInt _) = Just x matches (TString x) (TString _) = Just x matches (TDouble x) (TDouble _) = Just x matches _ _ = Nothing So, clearly the problem is in that Type m has no evidence of a, which was its very purpose. Ok, so I made data FType m a where FInt :: m Int -> FType m Int FString :: m String -> FType m String FDouble :: m Double -> Aux m a class Typed a where typ :: m a -> Type m -- as before ftyp :: m a -> FType m a -- new one and again obvious instance instance Typed Int where ftyp x = FInt x ... And of course, I'd like to get that information somehow extract2 (Opaque a) = ftyp a I rewrote 'matches' accordingly but the problem is already in the type of extract2 its type Opaque m -> (forall a. (Typed a) => m a) is not good to ghc, less polymorphic than expected So, in principle it must be doable, since opaque data retains its dictionary, and by that I can get a dynamic tag, say FInt x, where x is proved to be Int. What would you suggest? Thank you

2 4

Re: Haskell-Cafe Digest, Vol 47, Issue 237
by Chad Scherrer 31 Jul '07

31 Jul '07

Maybe I'm going about this the wrong way, but using the State monad for random numbers was always leaky for me. Any time I use it, I have to go through and strategically place "seq"s to counter the excessive laziness. IO and ST have worked well, and seem to be faster as well (though that's purely self-anecdotal evidence). I'm stuck in IO anyway for a lot of this (reading data from files to build my lookup tables), so ST didn't seem worth the extra trouble either. Admittedly it would have been good practice, though. What monad do most people use for random numbers? If performance is an issue, do you still use State? Generating an infinite list of randoms seems like a good approach if you just use them in one place, but beyond that you end up passing around the tail of the list at each step, so then you may as well wrap the generator in State, I think. Thanks, Chad > Chad Scherrer wrote: > > I prefer the purely functional approach as well, but I've > > been bitten several times by laziness causing space leaks in this > > context. I'm on a bit of a time crunch for this, so I avoided the > > risk. > > Well, space leaks won't magically disappear if you use IO a . > > Regards, > apfelmus

1 0

RLE in Haskell: why does the type variable get instantiated?
by Chris Eidhof 31 Jul '07

31 Jul '07

Hey Haskell-Cafe, I was trying out the code in Dons's article [1], and I noticed a weird thing when doing it in GHCi. When binding the function composition to a variable, the type suddenly changes. I'm not completely sure why this happens. Is this because GHCi is in a monad and wants to find an instance for the type variable? Here's my GHCi session: Prelude> :m +Control.Arrow Prelude Control.Arrow> :m + List Prelude Control.Arrow List> :t map (length &&& head) . group map (length &&& head) . group :: (Eq a) => [a] -> [(Int, a)] Prelude Control.Arrow List> let encode = map (length &&& head) . group Prelude Control.Arrow List> :t encode encode :: [Integer] -> [(Int, Integer)] Thanks, -chris [1]: http://cgi.cse.unsw.edu.au/~dons/blog/2007/07/31

5 4