Re: Lazy Parsing
There's a combinator which Phil Wadler called "guarantee" which makes a parser lazy -- guarantee p succeeds at once, with a result which will be produced, when demanded, by p. Many parsing libraries include it under one name or another... John ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Lazy Parsing
I'm wondering if there are any libraries out there for creating parsers that lazily build up their result. I know I could thread the remaining input through a parser by hand, but it seems like someone should have already done it. I'd like to be able to turn a stream of XML into a lazy tree of tags (probably Maybe tags, or Either errors tags), but I don't think HaXml and the like do that sort of thing. Branodn Moore ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: higher-kind deriving ... or not
Hi On Thu, 28 Feb 2002, Tom Pledger wrote: > C T McBride writes: > | > data Fix f = Fix (f (Fix f)) > | > | There's no equivalent first-order definition. This is where > | higher-kind parameters actually buy us extra stuff, and it's also the > | point at which the first-order constraint for show becomes hopeless. > > Did you see the technique Mark Tullsen posted last year, for making > instances in the presence of a fixpoint? I've found it useful. > > http://haskell.cs.yale.edu/pipermail/haskell/2001-May/003942.html Thanks for the pointer. Yes, that looks like a kind of hard-coding of the lifting to higher kinds that I'm after. If I understand things correctly, it would seem that for every type class C t, indexed by types, one can manufacture the constructor class FC f which asserts that f preserves C-ness. For each C-method m :: blah[t] one gives the FC method fm :: C t => blah[f t] One can lift further, by defining classes for constructors with higher-kind parameters which take FC-ness (or whatever) to C-ness. Requiring FC f (a first-order constraint on a higher-kind thing) is a plausible fake of requiring (forall a. C a => C (f a)) (a higher-order constraint on types). If I read correctly, automating this construction, effectively yielding computation of classes from kinds, is part of Simon PJ and Ralf Hinze's `Deriving Type Classes' proposal. The functionality is clearly desirable. It does, however, come at the cost of introducing a third and still separate programming language as a component of Haskell---the language of programming over kinds. It's no good asking when this will stop, because it doesn't. It is worth asking when the different layers of this hierarchy will acquire a greater uniformity. Cheers Conor ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Help
On Wed, 27 Feb 2002, Juan M. Duran wrote: > I got a function with type :: IO [[Double]], and what I want is write this > output in a file, how can I do it... I mean, I cannot doit by just using > writeFile (snip) Does something like this help at all? myfn :: IO [[Double]] myfn = return [[1.346, 4.144], [5.143, 2.453]] format_doubles :: [[Double]] -> String format_doubles x = foldr (++) "" (map format_line x) format_line :: [Double] -> String format_line [] = "\n" format_line x = foldr1 (\x y -> x ++ ", " ++ y) (map show x) ++ "\n" main = myfn >>= (\x -> return $ format_doubles x) >>= putStr Okay, it's not the most readable bit of code, but I'm guessing it covers the bit that's confusing you. All the best, Mark ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Help
I got a function with type :: IO [[Double]], and what I want is write this output in a file, how can I do it... I mean, I cannot doit by just using writeFile And one more thing: the Glasglow compiler doesn let me compile because I use the function readFloat (declare in the Prelude of Hugs 98), but Hugs lets me, why? How can I solve it? Thanks ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: higher-kind deriving ... or not
| > data Wonky f | > = Wonky | > | Manky (f (Wonky f)) | > deriving Show | | The trouble is that when I ask either hugs -98 or ghci | -fglasgow-exts to | | show (Wonky :: Wonky Copy) | | the poor compiler's brain explodes. I fixed this a few weeks ago. GHC (5.03) now says: Foo.hs:3: No instance for `Show (f (Wonky f))' When deriving the `Show' instance for type `Wonky' | I tried to guess the type of the show instance derived for | Wonky. Being a naive sort of chap, I thought it might be | | show :: (forall a. Show a => Show (f a)) => Wonky f -> String Not naive. That's exactly the right type. See Section 7 of "Derivable type classes". http://research.microsoft.com/~simonpj/Papers/derive.htm Havn't implemented this, yet, alas. | It's clear that with typing problems, inference becomes | unsustainable pretty soon after you leave the safe harbours | of the Hindley-Milner system. However, lots of lovely | programs have more interesting types: it would be very | frustrating if Haskell forbade these programs just because | their types were not inferrable---not least since, for these | jobs, we usually do think of the type first and the code | afterwards. Sensibly, Haskell allows us to write these types | down, so the machine's task is merely checking. This hybrid | approach preserves type inference for `old' code, whilst | promoting more adventurous programming by allowing us to say | what we mean when the machine is too dim to guess. I agree wholeheartedly with this; it's exactly the approach I'm trying to take with GHC. One obvious extension is to let the user specify the context for a derived instance decl, but still let the compiler generate the code. Havn't done this either! Simon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: higher-kind deriving ... or not
Hi again On Wed, 27 Feb 2002, Tom Pledger wrote: > Yes, there's a vicious circle in context reduction, between Wonky Copy > and Copy (Wonky Copy). > > | I don't want to start an argument about how to solve this problem. I > | do want to suggest that, for the time being, it would be better to > | reject `deriving Show' for type constructors like Wonky (ie those with > | higher-kind parameters) than to generate instances which break the > | compiler. > | > | Or am I just being a spoilsport? > > It depends on your definition of sport. ;-) > > > data Sport f > > = Sport > > | Association (f Bool) > > deriving Show > > > test = show (Sport :: Sport Maybe) Fair point, but this is just a thinly disguised first-order type constructor: type Sport f = Maybe (f Bool) Correspondingly, it's fine just to check Show for the actual instance which is used. In effect, some higher-kind parameters to datatypes are unnecessary because all their usages can abstracted as type parameters, and the corresponding applications of f passed in as arguments, just as above. However, once you introduce a fixpoint, this abstraction is no longer possible: > data Fix f = Fix (f (Fix f)) There's no equivalent first-order definition. This is where higher-kind parameters actually buy us extra stuff, and it's also the point at which the first-order constraint for show becomes hopeless. Perhaps banning such derivings for all higher-kind parametric datatypes is being a bit of a spoilsport: we can allow it exactly where it isn't necessary! Another interesting aspect of Tom's example is that the show instance exists in practice exactly because (i) Show Bool (ii) Show a => Show (f a) -- when f is Maybe These are the properties expressed by the relevant instance declarations. They are strictly stronger than Show (f Bool), but it takes a pretty bizarre f to make the distinction. Unfortunately, although we can express (ii) as a property, we can't demand it as a property, because constraints are first-order. If we could, the problem with fixpoints would go away, but instance inference would get even more complex than it already is in post 98 Haskell. There's a real question here: at what point does a problem become too complex for us to accept automation as the only means of its solution? It's clear that with typing problems, inference becomes unsustainable pretty soon after you leave the safe harbours of the Hindley-Milner system. However, lots of lovely programs have more interesting types: it would be very frustrating if Haskell forbade these programs just because their types were not inferrable---not least since, for these jobs, we usually do think of the type first and the code afterwards. Sensibly, Haskell allows us to write these types down, so the machine's task is merely checking. This hybrid approach preserves type inference for `old' code, whilst promoting more adventurous programming by allowing us to say what we mean when the machine is too dim to guess. Could there be a corresponding hybrid approach for instance inference? Conor ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
