- Haskell-Cafe - Haskell.org

by MR K P SCHUPKE 14 May '04

14 May '04

>> correcting parser >I would think this is a rather specialized requirement. I certainly don't >want a "correcting" parser for my work. But I can see that some >applications might... Especially if you are aiming for a genarally applicable library. What's really needed is a 'Strictness' switch for the parser, so you can select validating, or non-validating. The parser I wrote uses heuristsics that specify how to fix mistakes (like missing close tags) - this enables the XML parser to parse HTML with the correct set of rules. >This seems reasonable, and I'd expect a reasonable implementation (of a >filter) to stream via lazy evaluation where that matches the final usage >pattern. The outline I sketched (copied below) was intended to be built >upon something like HaXML's filter idea, so that streaming processing would >(in principle) be possible. If you don't use a list based representation, the only other way to get 'lazy' behaviour is to use the 'event' model - which is a lot more complex, but possible using one thread to do the parsing, and a Channel to pass the events through. I think you misunderstand what the parser and renderer do, the parser takes String input and outputs a stream of elements based on the BNF specification for XML... It looks like: data XmlElement = XMLDecl [XmlAttribute] | DocType XmlTagName XmlSystemLiteral XmlPubidLiteral | EmptyTag XmlTagName [XmlAttribute] | STag XmlTagName [XmlAttribute] | ETag XmlTagName | Text [XmlElement] | CharData String | CharRef Int | EntityRef XmlTagName | PERef XmlTagName | CDSect String | PI XmlTagName String | Comment String | Flush | Undefined | Unparsed String deriving (Show,Eq) The renderer takes a stream of these elements and converts to a String. All the filtering/reading/writing is done on streams of these elements. For example a filter could select only <Person ...> records from an XML data source, the person specific reader would then convert to a specific representation of a Person... myReadey :: [(XmlTreeDepth,XmlElement)] -> [Person] a writer does the opposite. Regards, Keean.

2 1

Re: [Haskell-cafe] Programming style and XML processing in Haskell
by MR K P SCHUPKE 14 May '04

14 May '04

Just sticking in my two pence worth... I am not sure what application you intend this for, but I find most XML parsers completely useless. With my application programmers hat on, I do not want to validate against a DTD, I want to extract as much information as possible from bad XML... what I would like is a correcting parser - one which outputs XML in compliance, but will accept any old rubbish and make a best guess attempt to fix it up (based on a set of configurable heuristic rules)... Secondly I deal with very large documents, the tree form of which won't fit in memory, so I would see an XML parser doin the following... parser :: String -> [XmlElements] filter :: [XmlElements] -> [XmlElements] reader :: [XmlElements] -> ... output data types ... writer :: ... input data types ... -> [XmlElements] render :: [XmlElements] -> String In order to keep track of the tree structure the tree-depth of each element is encoded within the XmlElement type... thus allowing the data to be streamed through the filters/readers etc. This means the parser can output the first element as soon as it encounters the second element (lazy list == stream in Haskell) rather than having to wait until the last element as would happen with a DOM tree (it is a tree not a graph as XML elements can only contain sub-elements)... As I said the above is just my opinion, and as it happens I have written a parser that does the above... I guess that is why there are several parsers for XML available (different requirements) and there will probably be many more ... Regards, Keean.

3 2

push/enter vs eval/apply question
by 7253146＠informatica.alumnos.uma.es 14 May '04

14 May '04

Hi. I have read part of the paper "Making a fast curry. Push/enter vs eval/apply for higher-order languages" (Simon Marlow ans Simon Peyton Jones, http://research.microsoft.com/Users/simonpj/papers/eval-apply/eval-apply.ps) where the tradeoffs of both currying models are discused. The paper takes the STG machine as design model. Just as an exercise, I tried to find the curying models for the G and TIM machines as described in "Implementing Functional Languages: a tutorial" (Simon Peyton Jones and David R. Lester, http://research.microsoft.com/Users/simonpj/Papers/pj-lester- book/student.pdf.gz). It was easy to find out that the fourth proposed implementation of the TIM machine was push/enter-oriented ("UpdateMarkers" instruction checks inside a function how many arguments it has been taken). But I have not find anything about for the G machine. It seems to not care about the number of arguments of a supercombinator: when one is evaluated, always have sufficient arguments, and partial applications are simple subgraphs with a mini spine of applications. I guess that only makes sense to talk about the two currying models push/enter and eval/apply when the considered machine is spineless, because on "spineful" or "spine-based" machines the graph of the lambda-calculus expression to evaluate is explicitly represented in memory, so we can see currying as lambda- application over generic lambda-variables. I am very interested on this matter. Please confirm my guess or explain why I am wrong, whoever knows it. Thanks in advance. Regards, Jose David --------------------------------------------- Este mensaje lo ha enviado un Alumno de la Universidad de Malaga. http://www.alumnos.uma.es/

1 0

How to hold common data
by scott west 13 May '04

13 May '04

Hello all, I'm new to haskell and was just wondering if there was any efficient or standard way to store and modify some sort of state data. The functional nature of haskell has me confused in this respect! Basically what I want to achieve is an interactive program that allows you to edit some tables, and thus hold some data. I dont' need to be spoonfed an answer, but a general guideline would be very helpful :) Thanks for any help you could provide! Regards, Scott

3 2

Re: [Haskell-cafe] How to hold common data
by MR K P SCHUPKE 13 May '04

13 May '04

simplest way... use a recursive function that feeds itself the state as one of its arguments...

3 2

Surprising bugs
by Mark Carroll 13 May '04

13 May '04

I clearly don't understand Haskell very deeply yet because I dealt with a couple of interesting types of bug this week. One sort was where, if I have, f :: SomeType -> Stuff ... f = whatever g :: Stuff ... g = f someValue ...then I can get an error that suggests that maybe I'm violating the monomorphism restriction if I put in f's type but not g's. If I put both in, it becomes happy. Another sort was where, if I had an algebraic parametric type (is that the name? Ord a => Foo a b c, etc.) then I couldn't have, say, a Maybe (Foo a b c), where sometimes I called it with a (Just foo) and sometimes with a Nothing, because with the Nothings it would complain about, erm, some ambiguity to do with Ord a. However, it would be fixed if I made the Maybe X argument into two arguments, Bool -> X, the Bool indicating if the X was meant to have been a Nothing or a Just X. I hope both (or either!) of those made sense. I don't have the code immediately to hand to reproduce the details, but I just thought I'd try to recall what they were because I found these compiler complaints interesting. I don't fully understand what's happening, and I'm sure a newbie would be quite bewildered. (-: -- Mark

1 0

Monadic Composition
by Jorge Adriano Aires 12 May '04

12 May '04

Hello, I needed to compose monadic functions, since I couldn't find anything in Control.Monad so I defined my own. I first came up with a left associative version: compLM [f1,..., fn] a = (f1 a >>= f2) >>= ... >>= fn > compLM :: Monad m => [a->m a] -> (a->m a) > compLM mfs a = foldl (>>=) (return a) mfs Later a right associative version, which I believe to be more efficient, particularly when some computation returns fail: compRM [f1,..., fn] a = \x->f1 x >>= (\x->f2 x >>= ... >>= \x->fn x) a > compRM :: Monad m => [a->m a] -> (a->m a) > compRM = foldr (\f g-> (\x ->f x >>= g)) return This higher order function seems quite useful to me and not trivial, so I expected it to be available. When this happens I wonder if I'm missing something. Am I complicating things? Is it actually available (or some other that does the trick) ? Or is it just me who finds this usefull enough to be in the libs? J.A.

2 2

Cyclic Dependencies
by Georg Martius 12 May '04

12 May '04

Hi, I have some problems with cyclic dependencies. Module Foo: data Foo = Foo { bar :: Bar } Module Bar: class BarClass b where barfun :: b -> Foo -> Foo data Bar = forall b . (BarClass b) => Bar b Obviously I have to import both modules mutually. My workaround was to add a further type variable to BarClass. class BarClass' b f where barfun :: b -> f -> f data Bar' f = forall b . (BarClass' b f) => Bar b This seams to be fine, but in my case it is a bit more compicated. I need a Read instance of Foo. Therefor I have to implement the Read instance for the existential type Bar by my own and need to know about the instanced of BarClass. Unfortunately, the instances of BarClass need Foo and I have a cycle again. Thanks, Georg

1 0

Visualising a type class hierarchy
by Andre Pang 12 May '04

12 May '04

Hey all, Does anyone know of a good way to visualise ("graph") a type class hierarchy, including one with multiple-parameter type classes? The traditional "inherits from" arrows used in graphs of object-oriented classes doesn't deal very well with type classes. A simple case, such as: class Super a class Super a => Sub a instance Super SuperType instance Super SubType instance Sub SubType works fine, but once you get into situations such as: class SuperMulti a b class SubMulti a b c | a b -> c instance SuperMulti a Foo => SubMulti a Bar c I haven't found elegant ways of visualising this at all: how do you draw arrows from SuperMulti to SubMulti, for instance? Has anyone else had a go at this? -- % Andre Pang : trust.in.love.to.save

1 0

Re: [Haskell-cafe] Toy application advice wanted
by John Hughes 10 May '04

10 May '04

> But Scheme lets you change things if you want to! (The Haskell > afficianados gasp). Let's face it...in most long-running applications, > data changes a lot during the lifetime of a program. So somehow, you have > to manage the repercussions of state changes. Haskell does this with > monads. (I'm still wrapping my brain around them, but...) Apparently > monads plus some syntactic sugar are like functions that return a value > and the next function, which in turn returns a value and the next > function, etc. so that referential transparency is maintained. This is a > heckuva lot of work to do (set! foo 'bar). I hope I'm not far off base > with this. Gosh, this sounds complicated! I think there's a much simpler way to see it. In almost any language, some expressions have side-effects, and some don't. Use expressions with side-effects carelessly, in the wrong place, and you can screw up. In Haskell, expressions with side-effects have a type that says so (IO <type>), and that in turn lets the type-checker restrict where you use them (hence the many questions "How do I get an <alpha> from an IO <alpha>?" -- the point is, you can't). So you avoid screwing up. Not particularly complicated, not particularly costly. writeIORef foo Bar :: IO () -- empty result, with a side-effect. OK, there's more to it than this, once you start using other monads than IO or ST, and especially once you start overloading code on the underlying monad. But as an initial understanding this is enough. John Hughes

1 0