July 2010 - Haskell-Cafe

bounded ranges
by Chad Scherrer 22 Jul '10

22 Jul '10

Hello cafe, I'm trying to do some things with bounded indices so I can carry around arrays (well, Vectors, really) without needing to refer to the bounds. For example, if I know my indices are Bool values, I can do > rangeSize (minBound, maxBound :: Bool) 2 I'd like to be able to do this in general, but... > :t rangeSize (minBound, maxBound) <interactive>:1:11: Ambiguous type variable `a' in the constraints: `Bounded a' arising from a use of `minBound' at <interactive>:1:11-18 `Ix a' arising from a use of `rangeSize' at <interactive>:1:0-29 Probable fix: add a type signature that fixes these type variable(s) I thought it might help to put it into a module and do a better job with the type, like this: bdRangeSize :: (Ix i, Bounded i) => i -> Int bdRangeSize _ = rangeSize (minBound, maxBound :: i) but I still have problems: MyArray.hs:22:36: Could not deduce (Bounded i1) from the context () arising from a use of `maxBound' at MyArray.hs:22:36-43 Possible fix: add (Bounded i1) to the context of an expression type signature In the expression: maxBound :: i In the first argument of `rangeSize', namely `(minBound, maxBound :: i)' In the expression: rangeSize (minBound, maxBound :: i) I thought maybe it's an existential types problem or something, but I don't understand why it would be coming up here. Any thoughts? Oh yes, and I'm using GHC version 6.12.1. Thanks, Chad

4 6

gd on Win32
by Jason Felice 22 Jul '10

22 Jul '10

Howdy, The listed maintainer for gd is no longer maintaining it. I'm wondering if anyone else is, if there is a version control URL, and how I can send patches. I need to get it working for Win32. Thanks

6 9

Regular Expression to Determinate Finite Automata translator
by Aaron Gray 22 Jul '10

22 Jul '10

Hi, I am a Haskell newbie. I have coded a Regular Expression to Determinate Finite Automata translator. Algorithm from the Dragon Book. Would someone eyeball the code and give me suggestions please. I have not done anything on character classes yet though. And the parsing is a bit of a hack. What I am not sure about is having to have multiple versions of similar datatype, each with variations in order to enumerate and generate followPos set. Is there a better way of implementing this ? Many thanks in advance, Aaron

3 2

music-related problem
by Michael Mossey 22 Jul '10

22 Jul '10

Wondering if I could get some suggestions for coding this problem. A musical document (or "score") consists primarily of a list of measures. A measure consists primarily of lists of "items". We'll consider only one kind of item: a note. Items have a location within the measure. A note's location indicates both where it goes on the page (i.e. a visual representation of the score) and what moment in time it begins sounding (i.e. rendering the score in sound). My concern here is sound. data Doc = [Measure] data Loc = ... (represents a location within the musical document including measure number) data Measure = Measure [(Loc,Item)] -- In the Meausre, we can assume (Loc,Item) are in -- ascending order Notes also have an end, when indicates when in time they stop sounding. See the 'end' field below. Also note the 'soundedEnd' 'tieStart' and 'tieStop' fields which I will explain. data Item = Note { pitch :: Pitch , end :: Loc , soundedEnd :: Maybe Loc , tieNext :: Bool , tiePrior :: Bool } There is a concept of "tied notes". When two notes are tied together, their durations are summed and they are sounded continuously as if one note. Ties have several uses, but one important one is to make a sound that begins in one measure and ends in a later measure, by tying notes across measures. The 'tieNext' field indicates if a note is tied to the following note (that is, the next note of the same pitch). 'tiePrior' indicates if tied to immediately prior note of same pitch. A chain of notes can be tied. Notes in the middle with have both tieNext and tiePrior set. In the event a note is within a chain of ties, its 'soundedEnd' field needs to be computed as Just e where e is the end of the last note in the chain. This information is useful when rendering the document as sound. My problem is: - given a Doc in which all fields have been set EXCEPT soundedEnd (all soundedEnd's are given a default value of Nothing) - update those notes in the Doc which need to have soundedEnd set. This involves chasing down the chain of ties. I can solve a simpler problem which is -- Given a note with tieNext set, and a list of notes, find -- the end Loc of the last note in the chain. Only notes -- with the same pitch as 'firstNote' are considered when looking -- for the chain of notes. computeSoundedEnd :: Item -> [Item] -> Loc computeSoundedEnd firstNote notes = compSndEnd (pitch firstNote) notes compSndEnd :: Pitch -> [Item] -> Loc compSndEnd _ [] = error "tie chain doesn't come to completion" compSndEnd p (n:ns) = if pitch n == p then if tieNext n then if tiePrior n then compSndEnd p ns else error "illegal tie chain" else if tiePrior n then end n else error "illegal tie chain" else compSndEnd p ns The thing that is hard for me to understand is how, in a functional paradigm, to update the entire Doc by chasing down every tie and making all necessary updates. Thanks, Mike

6 13

Re: [Haskell] ANNOUNCE: vorbiscomment 0.0.1
by Antoine Latter 21 Jul '10

21 Jul '10

On Wed, Jul 21, 2010 at 10:16 AM, Chris Wagner <christopher.t.wagner(a)gmail.com> wrote: > I'm happy to announce that I have packaged up my first Haskell library, > vorbiscomment, which allows for reading of "Vorbis comments" from Ogg > Vorbis files. The code is rugged and surely buggy, but any feedback, > patches, etc. are more than welcome. > > I do have a specific question in releasing this, and you can respond to > my personal email address if this mailing list is not appropriate for > discussion, but I'm wondering where my library's functionality should > live within the module hierarchy. At present, I have simply placed it > in a top-level "Vorbis" module, but this is surely not the proper place > for it. > Hi Chris, I have 5 packages which populate under the Codec.* hierarchy, so I would try to stake something out underneath Codec.Audio.*. Are these comments unique to Vorbis, or are they for anything contained in Ogg? Antoine (also, moving discussion to -cafe)

1 0

Problem with reloading modules in GHC API
by Hongmin Fan 21 Jul '10

21 Jul '10

Hi, I'm using GHC API to dynamically load some module, and evaluate it; and later change the content of the module, and re-evaluate it. But I found unless I delete the object file created by previous compilation, the module seems not reloaded. I have set ghcLink = LinkInMemory as an older post suggested To illustrate what I'm saying, here is a piece of code (sorry for any naivety in the code, new to Haskell too) import System.IO (IOMode(..),hClose,hPutStr,openFile) import Directory (removeFile) import GHC import GHC.Paths import DynFlags import Unsafe.Coerce src_file = "Target.hs" obj_file = "Target.o" main = do writeTarget "arg" func0 <- compileTarget putStrLn $ show $ func0 2 writeTarget "arg*2" func1 <- compileTarget putStrLn $ show $ func1 2 writeTarget input = do -- removeFile obj_file `catch` (const $ return ()) -- uncomment this line to have correct results h <- openFile src_file WriteMode hPutStr h "module Target (Target.target) where\n" hPutStr h "target::Double -> Double\n" hPutStr h "target arg = \n " hPutStr h input hClose h compileTarget = defaultErrorHandler defaultDynFlags $ do func <- runGhc (Just libdir) $ do -- setup dynflags dflags <- getSessionDynFlags setSessionDynFlags dflags { ghcLink = LinkInMemory } -- load target module target <- guessTarget src_file Nothing setTargets [target] r <- load LoadAllTargets case r of Failed -> error "Compilation failed" Succeeded -> do m <- findModule (mkModuleName "Target") Nothing -- set context and compile setContext [] [m] value <- compileExpr ("Target.target") do let value' = (unsafeCoerce value) :: Double -> Double return value' return func The code basically write to a Haskell source file twice with different content, and hoping to get different results, but unless I uncomment the line with removeFile, the output of 2 runs are the same; using 'touch' to touch the source file being written between 2 runs also gives the correct results. So maybe caused by some caching mechanism? I'm using GHC 6.12.1 in Ubuntu 10.04. I have this workaround of deleting the obj file, but I'm wondering the "correct" way of doing it. Did some search on GHC API, but never got something relevant. Thanks, Hongmin

3 6

Re: [Haskell] ANNOUNCE: vorbiscomment 0.0.1
by Henk-Jan van Tuyl 21 Jul '10

21 Jul '10

Redirecting to Haskell-café On Wed, 21 Jul 2010 19:16:16 +0200, Chris Wagner <christopher.t.wagner(a)gmail.com> wrote: > I'm happy to announce that I have packaged up my first Haskell library, > vorbiscomment, which allows for reading of "Vorbis comments" from Ogg > Vorbis files. The code is rugged and surely buggy, but any feedback, > patches, etc. are more than welcome. > > I do have a specific question in releasing this, and you can respond to > my personal email address if this mailing list is not appropriate for > discussion, but I'm wondering where my library's functionality should > live within the module hierarchy. The "Hierarchical module names" page [1] on the HaskellWiki gives some guidelines; I suppose the name Sound.Vorbis.Comment would be a good one. Regards, Henk-Jan van Tuyl [1] http://www.haskell.org/haskellwiki/Hierarchical_module_names -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

1 0

Data types a la carte
by Victor Nazarov 21 Jul '10

21 Jul '10

I've been experimenting with type level programming and open recursion. My aim this far is to implement very modular interpreter for lambda calculi and combinatory logic powerful enough to demonstrate steps of some term's reduction to normal form. I'd like to be able to setup the set of combinators and reduction rules and to express the set in type signature. I'd like to achieve maximum modularity of the code by all possible means. Below is the beginning of this effort. Show instances are defined completely modular. Show instance for Lambda and show instance for Combinator reuse the very same code of Show instance of ApplicativeF. However, there are problems with this code, and I'd like to receive some suggestions to cope with them. 1) UndecidableInstances are required for this code to compile. Is it possible to avoid this language extension? What is the reason for it to be required? 2) app, var, abs functions. app function is defined differently for every example. Is it possible to perform some automatic lifting so that app will work for any combination of ApplicativeF? Can I use Functor class or should I define my own type-class for this purpose? Is it possible at all? 3) The code below uses technique similar to Data Type a la Carte. Is it possible to achieve the same modularity using Finally Tagless technique? > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE UndecidableInstances #-} Some type level combinators first > newtype (:.) f g a = O (unO :: f (g a)) > newtype (:<*>) f g a = S {unS :: f a (g a)} > newtype Flip f x y = Flip {unFlip :: f y x} > newtype Mu f = Mu {unMu :: f (Mu f)} Their show instances doesn't affect representation of underlying type > instance Show (f (Mu f)) => Show (Mu f) > where showsPrec d (Mu f) = showsPrec d f > instance Show (f (g a)) => Show ((f :. g) a) > where showsPrec d (O f) = showsPrec d f > instance Show (f a (g a)) => Show ((f :<*> g) a) > where showsPrec d (S f) = showsPrec d f > instance Show (f y x) => Show (Flip f x y) > where showsPrec d (Flip f) = showsPrec d f Applicative is some structure that permits application of some objects. We use open recursion here. ApplicativeF o is a functor that represent this structure. And Mu (Flip ApplicativeF o) is a fix-point of this functor. > data ApplicativeF a o = App a a | Obj o > type Applicative o = Mu (Flip ApplicativeF o) Pareses are left associative in applicative structure > instance (Show o, Show a) => Show (ApplicativeF o a) > where showsPrec d (Obj o) = showsPrec d o > showsPrec d (App a b) = > showParen (d > 4) $ showsPrec 4 a . (' ':) . showsPrec 5 b Here is an example of applicative structure of strings > test1 :: Applicative String > test1 = obj "x" `app` obj "y" `app` obj "z" `app` (obj "w" `app` obj "v") > where obj = Mu . Obj > app a b = Mu $ App a b Lambda calculi is a calculi of some objects with applicative structure. This object may represent a variable or an abstraction of variable. LambdaObjF encodes this fact. We use all combinators defined above to define objects of lambda calculi. > data LambdaObjF name a = Var Name | Abs Name a > type Lambda name = Mu (ApplicativeF :<*> LambdaObjF name) > instance (Show a) => Show (LambdaObjF String a) > where showsPrec d (Var s) = showParen (d > 5) (showString s) > showsPrec d (Abs s a) = > showParen (d > 3) $ > ('\\':) . showString s . showString ". " . showsPrec 3 a Lets try to build an object of lambda calculi > type Name = String > test2 :: Lambda Name > -- test2 = (\x. \y. x) a b > test2 = (abs "x" (abs "y" (var "x")) `app` var "a") `app` var "b" > where var = Mu . S . Flip . Obj . Var > abs x b = Mu . S . Flip . Obj $ Abs x b > app a b = Mu . S . Flip $ App a b Combinatory logic defines some basic combinators > data CombinatorObjF a = CK | CS > type Cominator = Mu (ApplicativeF :<*> CombinatorObjF) > instance Show (CombinatorObjF a) > where showsPrec d CK = showString "K" > showsPrec d CS = showString "S" > test3 = s `app` k `app` k `app` (k `app` s) > where s = Mu . S . Flip . Obj $ CS > k = Mu . S . Flip . Obj $ CK > app a b = Mu . S . Flip $ App a b -- Victor Nazarov

2 1

[Ann] New version of parser combinator library uu-parsinglib-2.4.0
by S. Doaitse Swierstra 21 Jul '10

21 Jul '10

I have uploaded a new version of the package uu-parsinglib, te collection of online, error-correcting parser combinators, with both an applicative and a monadic interface. * The new version behaves better when more than three corrective steps have to be taken at a specific position. In order ro do so we have added a form of abstract interpretation which computes the minimal length of each alternative, so the shortest one can be chosen (and not one of the recursive alternatives!). * Furthermore we compute for each parser whether it can recognise the empty string. This is used to provide error messages when such parsers are used in list-like constructs, on of the most commonly made mistakes by innocent parser writers. * a combinator <?> was added which can be used to label productions, and which label is used to report what was expected * some further overloadings of pSym have been added which function at a lower level, thus leading to much faster parsers, especially when using the combinator to construct scanner like parsers: e.g. spaces = pMunch (==' ') makes sure that all spaces are skipped in a single go, instead of dealing with each recognised ' ' by itself. I hope you like the extensions, and would be happy to hear from you, both if you use them successfully, or if you have any reason for not using them. Doaitse Swierstra

1 0

The where-clause and guards
by Eitan Goldshtrom 21 Jul '10

21 Jul '10

I'm trying to fit a where clause to some guards I'm using. I have the following f a b | c > 1 = ... | c < 1 = ... | otherwise = ... where c = a+b yet I'm getting a parsing error. Is this not the correct way to combine "where" with "guards"? -Eitan

2 5