August 2008 - Haskell-Cafe

ANN: zip-archive 0.0
by John MacFarlane 03 Sep '08

03 Sep '08

I've written a library, zip-archive, for dealing with zip archives. Haddock documentation (with links to source code): http://johnmacfarlane.net/zip-archive/ Darcs repository: http://johnmacfarlane.net/repos/zip-archive/ It comes with an example program that duplicates some of the functionality of 'zip' (configure with '-fexecutable' to build it). I intend to put it on HackageDB, but I thought I'd get some feedback first. Bug reports, patches, and suggestions on the API are all welcome. John

3 3

Arrow without `>>>'
by Valery V. Vorotyntsev 03 Sep '08

03 Sep '08

Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv

3 3

ANN: wavconvert 0.1.1
by Tim Chevalier 31 Aug '08

31 Aug '08

Hi all, I uploaded to Hackage a little program I wrote to organize my music file collection in the hopes that someone else might find it useful too: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wavconvert I had a directory tree full of .wav files that I ripped from CDs at times when I didn't want to wait for an .mp3 or .ogg encoder to run. The trouble is that .wav files don't have metadata (ID3 tags) that specify artist, album and track names. So, wavconvert takes a directory tree as an argument, and converts any .wav files in it to .ogg (using an external OGG encoder) while filling in the ID3 tags based on the directory names. The name is a bit misleading, since this is not an OGG encoder written in Haskell; it just handles invoking an existing encoder with the right flags to set the metadata. I'd welcome any patches to make this more generally useful (as it is, it assumes a particular file structure and OGG encoder.) Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "Research is what I'm doing when I don't know what I'm doing."--Wernher von Braun

18 35

Re: [Haskell] Compiler Construction course using Haskell?
by Krasimir Angelov 31 Aug '08

31 Aug '08

Hi Johannes, There is a similar course in Chalmers. The home page is here: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/progs/current/ There students were required to implement full parser, partial typechecker and partial interpreter for C++ in either C++, Java or Haskell. We used BNFC for the parser: http://www.cs.chalmers.se/Cs/Research/Language-technology/BNFC/ which was easier for most students I think. In any way I would recomend Happy+Alex or BNFC instead of Parsec but this is only my personal preference. Best Regards, Krasimir 2008/8/20 Johannes Waldmann <waldmann(a)imn.htwk-leipzig.de>: > Hello. > > I plan to give a course in compiler construction, > using Haskell as the implementation language > (not as source or target language). > > Something along these lines: > 1. combinator parsers (Parsec), > 2. simple interpreter (arithmetical expressions) > 3. add algebraic data types, functions > 4. type checker > 5. code generator. > Ideally, 2..5 would be using the very same tree traversal code > and just change the monad for evaluation. > > Any comments appreciated. Have you given such a course? Taken? > > If I really decide to do it, > then slides (in German) will be made available. > > Best regards, J.W. > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > >

5 4

Re: [Haskell-cafe] Re: [Haskell] Top Level <-
by Adrian Hey 31 Aug '08

31 Aug '08

Ganesh Sittampalam wrote: > On Sun, 31 Aug 2008, Adrian Hey wrote: > >> Thanks for taking the time to do this Dan. I think the safety >> requirement has been met, but I think it fails on the improved API. >> The main complaint would be what I see as loss of modularity, in that >> somehow what should be a small irrelevant detail of the implementation >> of some obscure module somewhere has propogated it's way all the way >> upto main. > > That's the key point, as I see it - they aren't "irrelevant details of > the implementation", they are requirements the implementation places on > its context in order for that implementation to be correct. So they > should be communicated appropriately. Eh? Please illustrate your point with Data.Unique. What requirements does it place on it's context? (whatever that might mean :-) It just does what it says on the tin AFAICS. There are no requirements it places on "clients" (to use an OO term), as should any halfway decent API IMO. >> To me this seems completely at odds with what I thought was generally >> accepted wisdom of how to write good maintainable, modular software. >> Namely hiding as much implemention detail possible and keeping APIs >> as simple and stable as they can be. I don't know if I'm alone in >> that view nowadays. > > It's no problem to hide implementation detail, but I don't think you > should hide the *requirement* of the implementation that it has > constraints on how it is called, namely that it requires once-only > initialisation or whatever. No decent API should require this. Data.Unique certainly doesn't. In fact is debatable whether any API should requre an initalisation call at all before other stuff should be called (the other stuff check initialisation has occured and do it itself if necessary). The real irony of your remark is that making APIs this robust is practically impossible *without* using global variables, and you're now saying that because they've done this work to eliminate these constraints they now have to be held to account for this with an absurd API. Seems like a clear case of "no good deed going unpunished" :-) Regards -- Adrian Hey

1 0

Calling Lockheed, Indra, Thales, Raytheon
by Paul Johnson 31 Aug '08

31 Aug '08

This is a strange question, I know, but is there anyone working in any of the above companies on this mailing list? Everyone will no doubt be wondering what they have in common. I'm afraid I can't discuss that. Paul.

6 6

idea: TH calculating type level function results / binary types?
by Marc Weber 31 Aug '08

31 Aug '08

Hi, Maybe you've noted that I've started writing an XML library which validates the generated XML against a given DTD at compile time. Not everything is implemented right now and it would be quite usable if it didn't take that much time. The problem: To see some details have look at my small announcement on haskellcafe. type checking 12 lines of XML code has taken > 3hourse using some TypeToNat type equality comparison > 35sec using an implementation proposed by Oleg > 30sec no longer using HLists to check wether an attribute may be added but an AttrOk tag attr class (proposed by Oleg) > ?sec after finishing a state transformation implementation propably generating thausands of intermediate state or a mixture of this and the parser like apporach. Even if the last approach works it's a pity because: * it took much time to write * hard to read code * no error messages.. In the 30sec apprach I've used some instances such as class Consume elType state state' | elType state -> state' class FailHelper state' state'' | state' -> state'' instance FailHelper (Fail a) => FailHelper (F a) () -- F indicating sub element could not be consumed, failure instance FailHelper a a -- So I got error messages telling me no instance for MoreElementsExpected (Or (E Html_T) (E Body_T)) or such.. that's nice and usable. I can't think of a nice way reporting errors when transforming a dtd line (a,b,c) (= tag sequence a b c) into data State1 data State2 data State3 instance Conseme State1 A_T State2 -- consume tag a instance Conseme State2 B_T State3 -- consume tag b instance Conseme State3 C_T ConsumedEnd -- consume tag c in a convinient way without adding much bloat. The XHMTL spec has about 150 ! tags.. So even if creating this kind of state transforming instances this will result in a lot of bloat. So if the compiler has to load a some MB large .hi file it will spend unnecessary time just loading them. an idea: (new?) solution: What about enhancing ghc so that a) you can define type level functions and calculate the result using template haskell functions: benefits: * speed (it can even be compiled! ) * nice error messages on failure * mantainable code * reusing known source (such as parser combinator libraries) syntax could look like this: class Bar a b c d | a b -> c, a b -> d instance (Maybe x) z $(calculateC) $(calculateD) calculateC :: Type -> Type -> Type calculateD :: Type -> Type -> Type an efficient implementation for TypeEq a b typebool | a b -> typebool could be done by everyone with ease without reading HList source or Olegs papers.. (you should do so anyway ..) b) add some binary serialization support so that you don't have to do expensive data -> type level -> data (de)serializations. .hi files wouldn't blow much this way as well. So a parse specification such as (1) could really be included within types and could become even more complex. Than an exisiting parser combinator library could be used and a validating XML library could be written within some hours.. I think ghc is already a superiour compiler because it allows such advanced technics thereby making users such as me even ask for more :-) I consider this a good sign. So has anyone thought about this before? Would someone help / guide me implementing this extension in the near future? Of course it will clash with some instance -X extensions.. but I think that in everyday use you'd probably use either this template haskell approach or use normal class instance declarations so it I guess it could be handled. Maybe this does already exist in one or the other way? Sincerly Marc Weber (1) (Seq (Elem Title_T) (Seq (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T)))))) (Query (Seq (Elem Base_T) (Star (Or (Elem Script_T) (Or (Elem Style_T) (Or (Elem Meta_T) (Or (Elem Link_T) (Elem Object_T))))))))))

1 0

Discussing FFI
by Maurício 30 Aug '08

30 Aug '08

Hi, I saw the (a?) page about FFI on Haskell: http://www.cse.unsw.edu.au/~chak/haskell/ffi It shows a link to a mailing list but, checking the list archives at: http://www.haskell.org/pipermail/ffi , it seems it's dead since 2007. Is there a new list about FFI? Where should I discuss my begginer issues about it? Thanks, Maurício

2 1

Parsec and network data
by brian 30 Aug '08

30 Aug '08

Hi, I've been struggling with this problem for days and I'm dying. Please help. I want to use Parsec to parse NNTP data coming to me from a handle I get from connectTo. One unworkable approach I tried is to get a lazy String from the handle with hGetContents. The problem: suppose the first message from the NNTP server is "200 OK\r\n". Parsec parses it beautifully. Now I need to discard the parsed part so that Parsec will parse whatever the server sends next, so I use Parsec's getInput to get the remaining data. But there isn't any, so it blocks. Deadlock: the client is inappropriately waiting for server data and the server is waiting for my first command. Another approach that doesn't quite work is to create an instance of Parsec's Stream with timeout functionality: instance Stream Handle IO Char where uncons h = do r <- hWaitForInput h ms if r then liftM (\c -> Just (c, h)) (hGetChar h) else return Nothing where ms = 5000 It's probably obvious to you why it doesn't work, but it wasn't to me at first. The problem: suppose you tell parsec you're looking for (many digit) followed by (string "\r\n"). "123\r\n" won't match; "123\n" will. My Stream has no backtracking. Even if you don't need 'try', it won't work for even basic stuff. Here's another way: http://www.mail-archive.com/haskell-cafe@haskell.org/msg22385.html The OP had the same problem I did, so he made a variant of hGetContents with timeout support. The problem: he used something from unsafe*. I came to Haskell for rigor and reliability and it would make me really sad to have to use a function with 'unsafe' in its name that has a lot of wacky caveats about inlining, etc. In that same thread, Bulat says a timeout-enabled Stream could help. But I can't tell what library that is. 'cabal list stream' shows me 3 libraries none of which seems to be the one in question. Is Streams a going concern? Should I be checking that out? I'm not doing anything with hGetLine because 1) there's no way to specify a maximum number of characters to read 2) what is meant by a "line" is not specified 3) there is no way to tell if it read a line or just got to the end of the data. Even using something like hGetLine that worked better would make the parsing more obscure. Thank you very very much for *any* help.

12 19

FunGEn
by Henk-Jan van Tuyl 30 Aug '08

30 Aug '08

L.S., I found the Functional Game Engine FunGEn on the web: http://www.cin.ufpe.br/~haskell/fungen/download.html It looks useful, but since it hasn't been maintained for a long time, it doesn't compile. Is there a newer version I can download? -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ --

3 2