May 2010 - Haskell-Cafe

Tools to make tidy HTML
by Dmitri O.Kondratiev 21 May '10

21 May '10

Hello! Please advise haskell libraries similar to convert real-world HTML to well-formed XML. I need something similat to "HTML Tidy" library: http://tidy.sourceforge.net/ Thanks! Dmitri

1 0

Register now for: Haskell in Leipzig (Germany), June 4.
by Johannes Waldmann 21 May '10

21 May '10

Schedule and registration for the "Haskell in Leipzig" meeting on June 4 are now on-line: http://www.iba-cg.de/hal5.html It's our fifth meeting, and here are five good reasons to go: * learn Haskell: attend tutorials for beginners * get first-hand information: authors of Leksah, HXT, Hawk give tutorials/talks * share your expert knowledge: at lambda camp * see beyond Haskell: learn dependently typed programming in Agda * relax at BBQ party and listen to strange sounds: unsafePerformance The meeting is presented by http://www.fit-leipzig.de/ , in co-operation with http://www.imn.htwk-leipzig.de/ , http://www.leipziger-medienstiftung.de/, http://www.iba-cg.de/ Best regards, Johannes Waldmann (for the Hal5 program committee)

1 0

Недвижимость во Франции, аренда и продажа вилл
by moreletto 21 May '10

21 May '10

Офис нашей компании находится в Ницце - в самом сердце Французской Ривьеры, что дает нам непосредственную возможность предложить виллы для аренды и продажи во всем их многообразии, а также сориентировать наших клиентов на самые интересные и значимые мероприятия в богатой культурной и светской жизни Лазурного берега. Мы предоставляем нашим клиентам широкий выбор вилл класса люкс по всей протяжённости Лазурного берега Франции - от Сан Тропе до Монако, оказываем визовую поддержку, а также организуем визиты на приглянувшиеся Вам объекты при заключении контрактов по аренде или покупке вилл и другой недвижимости <http://www.property-serviceazur.com/> средиземноморского побережья. Уважаемые партнеры, мы предлагаем Вам сотрудничество в приобретении Вашими клиентами *недвижимости во Франции, на Лазурном берегу *, который всегда ценился поклонниками искусства, знатоками истории, любителями изысканной кухни и живописных пейзажей.

2 1

String rewriting
by Roly Perera 21 May '10

21 May '10

Hi, I'm looking for a simple way to rewrite strings according to simple composable rules like: replace "_" by "\$\\hole\$" replace "-n" where n matches an integer by "^{n}" so that I can import some pretty-printed output into a LaTeX alltt environment. I'm guessing that this nice functional stream transformation problem has been solved thousands of times. Could anyone point me to a simple package that would do this for me? many thanks, Roly

5 4

Intuitive function given type signature
by R J 21 May '10

21 May '10

What are some simple functions that would naturally have the following type signatures: f :: (Integer -> Integer) -> Integer g :: (Integer -> Integer) -> (Integer -> Integer) (Bird problem 1.4.5) _________________________________________________________________ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:…

6 8

Type famillies & Lifting IO
by oleg＠okmij.org 21 May '10

21 May '10

Maciej Piechotka wrote: > class (Monad m, Monad (IO' m)) => MonadIO m where > type IO' m :: * -> * > liftIO :: IO a -> IO' m a > liftM :: m a -> IO' m a The signature for liftIO betrays a problem. Since liftIO is a member of a type class, when liftIO is used in code, the type checker has to find the appropriate instance (i.e., resolve the overloading). Suppose we have this piece of code: tt :: FooIO () tt = liftIO (return () :: IO ()) How to find the appropriate instance of MonadIO and resolve the liftIO overloading? The argument type of liftIO does not mention the type class parameter m at all, and so it is of no guidance for overloading resolution. We know that the return type of liftIO in the tt code is FooIO (). Thus we have to find such instance of the MonadIO class that its associated type IO' m is equal to FooIO. In other words, we have to find m as a solution of the equation IO' m = FooIO Or, we have to invert the type function IO' m. Alas, type functions are not generally injective and hence not invertible. Indeed, nothing prevents the user from defining two instances of MonadIO, for types m1 and m2, such that IO' m1 = IO' m2 = FooIO.

1 0

ANN: threads-0.1.0.1
by Bas van Dijk 20 May '10

20 May '10

Dear all, I uploaded threads-0.1.0.1 to hackage. Threads is a small package that lets you fork threads and wait for their result. The basic interface is simply: module Control.Concurrent.Thread where data ThreadId α forkIO ∷ IO α → IO (ThreadId α) wait ∷ ThreadId α → IO (Either SomeException α) threadId ∷ ThreadId α → Control.Concurrent.ThreadId I hope the names and types speak for themselves. Additionally the following module is provided that lets you wait for a group of threads to terminate: module Control.Concurrent.Thread.Group where data ThreadGroup new ∷ IO ThreadGroup forkIO ∷ ThreadGroup → IO α → IO (ThreadId α) wait ∷ ThreadGroup → IO () Installation: $ cabal update $ cabal install threads API docs: http://hackage.haskell.org/package/threads-0.1.0.1 Development: darcs get http://code.haskell.org/~basvandijk/code/threads Regards, Bas

1 0

Retrospective type-class extension
by Tony Morris 20 May '10

20 May '10

We all know that "class (Functor f) => Monad f" is preferable but its absence is a historical mistake. We've all probably tried once: instance (Functor f) => Monad f where ... However, is there a type system extension (even proposed but not implemented) that allows me to retrospectively apply such a notion? Ideally something like this would be handy if it could somehow be retrospectively applied: Monad <- Applicative <- Pointed <- Functor -- Tony Morris http://tmorris.net/

7 9

RE: [Haskell-cafe] making the GHC Api not write to stderr
by Phyx 20 May '10

20 May '10

I've thought about that, but my specific problem is that I'm calling the Haskell code compiled to a shared lib and then hPutStr is failing, presumable because there is no valid stderr (and I would image also no stdin or out). So in order for me to use that method I would have to create a new file handle and direct stderr to that. Or somehow create a fake Handle and pass it that. Or another alternative is on the side where I call the lib, create and attach some hidden console to the process and have it write there. But that all seems like a hackish way out, It would be best if the API just allowed me to turn off this behavior of writing to stderr. From: Jean-Denis Koeck [mailto:jdkoeck@gmail.com] Sent: Thursday, May 20, 2010 21:59 To: Phyx Subject: Re: [Haskell-cafe] making the GHC Api not write to stderr Maybe this <http://nominolo.blogspot.com/2010/04/haskell-tip-redirect-stdout-in-haskell .html> could help you ? 2010/5/20 Phyx <lonetiger(a)gmail.com> I was wondering how to forcibly quiet down the API. I have a custom handler in place, but when I call the function on failure both my handler gets called and somewhere somehow errors get printed to the stderr, which I really need to avoid. My current code looks like getModInfo :: Bool -> String -> String -> IO (ApiResults ModuleInfo) getModInfo qual file path = handleSourceError processErrors $ runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags $ configureDynFlags dflags target <- guessTarget file Nothing addTarget target setSessionDynFlags $ dflags { importPaths = [path] } load LoadAllTargets graph <- depanal [] False let modifier = moduleName . ms_mod modName = modifier $ head graph includes = includePaths dflags imports = importPaths dflags dflags' <- Debug.trace (moduleNameString modName) getSessionDynFlags setSessionDynFlags $ dflags' { includePaths = path:includes , importPaths = path:imports } parsed <- parse modName checked <- typecheckModule parsed _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

No copy XML parser (rough idea only)
by Joachim Breitner 20 May '10

20 May '10

Hi, an idea recently crossed my mind that describes a (possibly?) useful way of accessing XML data from Haskell that is very memory efficient – at least as long as you only read the XML; for XML processing and generation, other existing libraries are probably well suited. Given a (possibly very large) XML file as a ByteString, a „normal“ XML parser would have an algebraic data type for node etc., parsing the ByteString into a tree of haskell values. Simplified a bit, the data structure could look like this: > data Node = Node String [Attrib] [Node] | CData String The in-memory representation of such a a data structure is presumably very large, compared to the XML ByteString. Additionally, all the content is copied in memory and I evaluated a part of the Node (e.g. the tag name), this is retained by the constructor as long as the Node, and thus the whole document tree, is retained. My idea is to copy as little as possible, and refer to the existing ByteString as much as possible. Remember that a substring of a ByteString points at the same memory region, just with a different offset and length. So, in my case, the datatype looks like > newtype Node = Node ByteString > newtype CData = CData ByteString > newtype Attrib = Attrib ByteString where the constructors would not be exported. Instead, accessor methods would be provided: > tagName :: Node -> String > tagAttribs :: Node -> [Attrib] > tagContent :: Node -> [Either Node CData] > cDataContent :: CData -> ByteString So when searching for a certain tag, the library would only have to generate (and retain) pointers to the ByteString, but the tag name themselves do not have to be retained after the comparision. If it turns out to be too expensive to parse the fragment that is referenced by Node on every invocation of tagContent, this could be made a field of the constructor. Due to lazy evaluation, it will only be evaluated when needed, but then kept in memory: > data Node = Node ByteString [Either Node CData] About cDataContent: This method cannot just return the fragment of the document unaltered, unfortunately, as XML entities will have to be replaced. But if it returns a lazy ByteString, everything between the entities can be a chunk refering to the original data, again avoiding the creation of a copy. Now this is just a quick idea I wanted to share. I have not tried it yet, so I might be overlooking something which prevents the whole thing from working. It might also be the case that, due to lazy evaluation, the “usual” approach is actually well enough (at least if it uses ByteString instead of String). I’m curious what you think, Joachim Breitner -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata(a)joachim-breitner.de

4 4