May 2008 - Haskell-Cafe

Re: [Haskell-cafe] Induction (help!)
by PR Stanley 08 May '08

08 May '08

After you grok induction over the naturals, you can start to think about structural induction, which is usually what we use in programming. They are related, and understanding one will help you understand the other (structural induction actually made more sense to me when I was learning, because I started as a programmer and then became a mathematician, so I thought in terms of data structures). Paul: I was hoping that understanding the classic mathematical concept would help me appreciate the structural computer science) variation better. I don't know what it is about induction that I'm not seeing. It's so frustrating! Deduction in spite of the complexity in some parts makes perfect sense. This, however, is a different beast! So let's say you have a tree, and we want to count the number of leaves in the tree. data Tree = Leaf Int | Branch Tree Tree countLeaves :: Tree -> Int countLeaves (Leaf _) = 1 countLeaves (Branch l r) = countLeaves l + countLeaves r We want to prove that countLeaves is correct. So P(x) means "countLeaves x == the number of leaves in x". Paul: By 'correct' presumably you mean sound. First we prove P(Leaf i), since leaves are the trees that have no subtrees. This is analogous to proving P(0) over the naturals. Paul: I'd presume 'proof' here means applying the function to one leaf to see if it returns 1. If I'm not mistaken this is establishing the base case. countLeaves (Leaf i) = 1, by definition of countLeaves. "Leaf i" has exactly one leaf, obviously. So countLeaves (Leaf i) is correct. Now to prove P(Branch l r), we get to assume that P holds for all of its subtrees, namely we get to assume P(l) and P(r). Paul: How did you arrive at this decision? Why can we assume that P holds fr all its subtrees? You can think of this as constructing an algorithm to prove P for any tree, and we have "already proved" it for l and r in our algorithm. Paul: Is this the function definition for countLeaves? This is analogous to proving P(n) => P(n+1) in the case of naturals. Paul:I thought P(n) was the induction hypothesis and P(n+1) was the proof that the formula/property holds for the subsequent element in the sequence if P(n) is true. I don't see how countLeaves l and countLeaves r are analogous to P(n) and P(n+1). So: Assume P(l) and P(r). P(l) means "countLeaves l == the number of leaves in l" P(r) means "countLeaves r == the number of leaves in r" countLeaves (Branch l r) = countLeaves l + countLeaves r, by definition. And that is the number of leaves in "Branch l r", the sum of the number of leaves in its two subtress. Therefore P(Branch l r). Now that we have those two cases, we are done; P holds for any Tree whatsoever. In general you will have to do one such proof for each case of your data structure in order to prove a property for the whole thing. At each case you get to assume the property holds for all substructures. Generally not so many steps are written down. In fact in this example, most people who do this kind of thing a lot would write "straightforward induction", and that would be the whole proof :-) The analogy between structural induction and induction over the naturals is very strong; in fact induction over the naturals is just induction over this data structure: data Nat = Zero | Succ Nat Hope this helps. Luke

7 9

who maintains the POSIX/Unix Unistd.hs?
by Galchin, Vasili 07 May '08

07 May '08

Hello, I am trying to find the definition for the data type "TimeSpec"/"CTimeSpec". thanks, Vasili

2 1

Figuring out if an algebraic type is enumerated through Data.Generics?
by Alfonso Acosta 07 May '08

07 May '08

Hi all, <probably_unnnecesary_background> I'm writing a Hardware-oriented DSL deep-embedded in Haskell (similar to Lava, for those familiar with it). One of the goals of the language is to support polymorphic signals (i.e. we would like to allow signals to carry values of any type, including user-defined types) The embedded compiler has different backends: simulation, VHDL, graphical representation in GraphML ... The simulation backend manages to support polymorphic signals by forcing them to be Typeable. In that way, circuit functions, no matter what signals they process, can be transformed to Dynamic and included in the AST for later simulation. The situation is more complicated for the VHDL backend. The Typeable trick works just fine for translating a limited set of predefined types (e.g. tuples) but not for user-defined types, since the embedded-compiler doesn't have access to the user-defined type declarations. One possible solution to access the type-definition of signal values would be constraining them to instances of Data. Then, we could use dataTypeOf to get access to the type representation. (Another option would be using template Haskell's reify, but I would like to avoid that by now) It would certainly be difficult map any Haskell type to VHDL, so, by now we would be content to map enumerate algebraic types (i.e. algebraic types whose all data constructors have arity zero, e.g. data Colors = Green | Blue | Red) </probably_unnnecesary_background> So, the question is. Is there a way to figure out the arity of data constructors using Data.Generics ? I'm totally new to generics, but (tell me if I'm wrong) it seems that Constr doesn't hold any information about the data-constructor arguments. Why is it so? Do you think there is a workoaround for this problem? (maybe using some other function from Data.Generics different to dataTypeOf?) Thanks in advance, Alfonso Acosta

2 2

Haddock and upload questions?
by Galchin, Vasili 07 May '08

07 May '08

Hello, 1) Can I set up Haddock to run everytime I do a build? 2) http://hackage.haskell.org/packages/upload.html .... - do I have to set up my .cabal in a special way to run "dist"? - once I checked that my Cabal package is "compliant" on this page, how do I get a username and password? Kind regards, Vasili

2 1

license question
by Henrique Ferreiro García 07 May '08

07 May '08

Hello everybody, I have one question regarding a licensing issue. I am developing a library to parse and pretty-print the Core Erlang language and it is heavily based on the modules included in haskell-src. What I want to know is if I have to reproduce all of the LICENSE file included in that package with my name included in the copyright notice or what other thing do I have to do. Thanks in advance. -- Henrique Ferreiro García <hferreiro(a)udc.es>

2 1

Re: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics?
by Edward Kmett 07 May '08

07 May '08

On Tue, May 6, 2008 at 12:34 PM, Alfonso Acosta <alfonso.acosta(a)gmail.com> wrote: | So, the question is. Is there a way to figure out the arity of data | constructors using Data.Generics ? | I'm totally new to generics, but (tell me if I'm wrong) it seems that | Constr doesn't hold any information about the data-constructor | arguments. Why is it so? Hmrmm, Playing around with it, I was able to abuse gunfold and the reader comonad to answer the problem : fst $ (gunfold (\(i,_) -> (i+1,undefined)) (\r -> (0,r)) (toConstr "Hello") :: (Int,String)) returns 2, the arity of (:), the outermost constructor in "Hello" A longer version which does not depend on undefined would be to take and define a functor that discarded its contents like: > module Args where > import Data.Generics > newtype Args a = Args { runArgs :: Int } deriving (Read,Show) > tick :: Args (b -> r) -> Args r > tick (Args i) = Args (i + 1) > tock = const (Args 0) > argsInCons = runArgs $ (gunfold tick tock (toConstr "Hello") :: (Args String) Basically all I do is rely on the fact that gunfold takes the 'tick' argument and calls it repeatedly for each argument after a 'tock' base case. The use of the reader comonad or functor is to give gunfold a 'functor-like' argument to meet its type signature. -Edward Kmett

2 1

TimeSpec
by Galchin, Vasili 06 May '08

06 May '08

Hello, I checked Hoogle for the POSIX data type TimeSpec. Nada. Does anybody know where the definition is? Thanks, Vasili

1 0

Still no joy with parsec
by Ross Boylan 06 May '08

06 May '08

I kept getting parse failures when I ran my little Parsec TeX snippet on a sample code. Seeing that ghc6.8 had debugging, I upgraded to it, only to discover that I can't even get the code to compile. $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :load g [1 of 1] Compiling Main ( g.hs, interpreted ) g.hs:11:19: Couldn't match expected type `t1 -> GenParser Char () t' against inferred type `CharParser st ()' In the expression: reserved "\\begin" 1 In a 'do' expression: reserved "\\begin" 1 In the expression: do reserved "\\begin" 1 braces (many1 letter) Failed, modules loaded: none. Do parsec and 6.8 just not get along? More generally, how can I go about diagnosing such problems? Since I can't load it, I can't debug it or get :info on the types. It looks as if maybe it's expecting a Monad, but getting a parser. But I don't know why that would have changed vs using 6.6. More questions about the error messages. Where is the expected type, and where is the inferred type, coming from? I'm guessing the expected type is from the function signature and the position inside a do (or perhaps from the argument following the ; in the do?) and the inferred type is what I would just call the type of reserved "begin". And what is the 1 that appears after 'reserved "\\begin"'? An indicator that all occurrences of the text refer to the same spot in the program? Nesting level? Thanks. Ross P.S. There have been some issues with the Debian packaging of ghc6.8, so it's possible I'm bumping into them. I thought/hoped the problems were limited to non i386 architectures. Also, I'm pretty sure that the parsec code used by ghc6.6, ghc6.8, and hugs is all in different files. So conceivably the parsec source differs. I have ghc6 6.8.2-5 and libghc6-parsec-dev 2.1.0.0-2. Source: import Text.ParserCombinators.Parsec import qualified Text.ParserCombinators.Parsec.Token as P import Text.ParserCombinators.Parsec.Language(haskell) reserved = P.reserved haskell braces = P.braces haskell -- TeX example envBegin :: Parser String envBegin = do{ reserved "\\begin" 1 ; braces (many1 letter) }

3 4

Induction (help!)
by PR Stanley 06 May '08

06 May '08

Hi I don't know what it is that I'm not getting where mathematical induction is concerned. This is relevant to Haskell so I wonder if any of you gents could explain in unambiguous terms the concept please. The wikipedia article offers perhaps the least obfuscated definition I've found so far but I would still like more clarity. The idea is to move onto inductive proof in Haskell. First, however, I need to understand the general mathematical concept. Top marks for clarity and explanation of technical terms. Thanks Paul

6 9

ANNOUNCE: category-extras 0.44.2
by Edward Kmett 06 May '08

06 May '08

Dan Doel asked me to roll category-extras into my nascent comonad transformer library, and the result is category-extras 0.44.2! So since Dan's release a couple of weeks ago ( http://www.haskell.org/pipermail/haskell-cafe/2008-April/042240.html) we have added: * Comonad Transformers. Context/ContextT, Reader/ReaderT. * A suite of Bifunctors and combinators in Control.Bifunctor.* -- we attach most of the logic usually associated with a monoidal/comonoidal category to the individual Bifunctor since Hask is a rich category to begin with. * A suite of Functors and combinators in Control.Functor.* * Pointed and copointed functors. * Control.Recursion has been broken out into a Control.Morphism.* and recoded to use a simpler distributive law. * Type Indexed versions of Applicatives, Monads, and Comonads (including Diatchki's Indexed State and Wadler's Delimited Continuation Parameterized Monad) * Parameterized Monads a la Ghani and Johann's paper ICFP 07 paper, and their Applicative and comonadic dual. * Higher-order hylo-, cata- and ana- morphisms. * Higher-order Monads a la Ghani and Johann and their comonadic equivalents. * Kan extensions. * BiKleisli arrows as seen in Uustalu and Vene's Signals and Comonads and SIGFPE's recent posts * The Pointer comonad * Grabbed Iavor Diatchki's value-supply and rolled it in as Control.Comonad.Supply to make it clearer that it is a comonad, and pave the way towards a Supply comonad transformer * A richer set of compositions to allow for construction of comonads and monads not only from adjunctions, but also from pre-composition or post-composition of a monad with a pointed functor, and similarly pre-composition and post-composition of a comonad with a copointed functor. * Generic functor zapping, zipping, unzipping, and cozipping as mentioned recently on http://comonad.com/reader There is still a lot to do in terms of adding back a lot of the documentation from the original, documenting the extensions and fleshing out all of the definable instances as the concepts have grown exceptionally fine-grained. I definitely welcome feedback and additions. In particular if you were using a feature that was supported by the old library or is unnatural to program in the current one, let me know. My goal is to gather a lot of this esoterica into one place and integrate it into something cohesive. HEAD: haddock http://comonad.com/haskell/category-extras/dist/doc/html/category-extras/ darcs http://comonad.com/haskell/category-extras/ Release: package http://hackage.haskell.org/cgi-bin/hackage-scripts/package/category-extras-… -Edward Kmett

1 0