- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Can it be proven there are no intermediate "useful" type classes between Applicative Functors & Monads?
by David Barbour 07 Jun '11

07 Jun '11

On Sun, Jun 5, 2011 at 12:51 PM, KC <kc1956(a)gmail.com> wrote: > If new intermediate classes crop up then there would be no point in fixing > > class (Applicative m) => Monad m where > > since it would have to be changed if new intermediate classes are found. > You might check out a few articles regarding Kleisli arrows [1][2] for possibilities that live between applicative and monad. Applicative itself is also a little on the strong side. I had to reject Applicative for one model of signal transformers because 'pure' was not a legal constructor, even though 'fmap . const' and '<*>' were okay. And even Functor is too strong if you want effective linearity. I've found Adam Megacz's Generalized Arrows [3] to be a suitable chassis for weaker models. [1] http://www.haskell.org/haskellwiki/Arrow_tutorial#Kleisli_Arrows [2] http://lambda-the-ultimate.org/node/4273 [3] http://www.cs.berkeley.edu/~megacz/garrows/

1 0

Re: [Haskell-cafe] Cons of -XUndecidableInstances
by oleg＠okmij.org 07 Jun '11

07 Jun '11

It seems that UndercidableInstances keep getting a bad rap. There are legitimate and decidable applications of UndercidableInstances. These applications have nothing to do with OOP, or HList for that matter. This topic is discussed at length in the article http://okmij.org/ftp/Haskell/types.html#undecidable-inst-defense Here are the conclusions: Thus there are patently decidable type programs that require UndecidableInstances. That extension should not be categorically stigmatized. In conclusion, UndecidableInstances is not a dangerous flag. It will never cause the type-checker to accept a program that `goes wrong.' The only bad consequence of using the flag is type checker's might be telling us that it cannot decide if our program is well-typed, given the context-stack--depth limit. We may ask the type-checker to try a bit harder (with a larger depth limit), or look through our program and find the problem. UndecidableInstances are quite like the primitive recursion criterion: all primitive recursion functions surely terminate; non-primitive recursion functions generally don't. Still there are many classes of non-primitive recursive functions that are total. To see their totality, one has to use more complex criteria.

3 2

Mysterious complaint about .hi files
by Josef Svenningsson 07 Jun '11

07 Jun '11

Hi cafe! I'm hitting a very strange problem when using haskell-src-exts and haskell-src-exts-qq. Consider the following module: \begin{code} {-# Language QuasiQuotes #-} module TestBug where import Language.Haskell.Exts import Language.Haskell.Exts.QQ unit = TyTuple Boxed [] ty = [dec| quux :: (a,b) |] \end{code} This module doesn't load for me using ghc 7.0.3. I've pasted the full error message at the end of this email but the error message begins with the following lines: TestBug.hs:11:11: Can't find interface-file declaration for variable Language.Haskell.Exts.Syntax.Boxed Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error Using -ddump-if-trace didn't help me much. The funny thing is that if I comment out the last line (the definition of 'ty') then the module loads just fine even though it uses the Boxed type in the definition of 'unit'. So the problem only manifests itself when I use tuples from haskell-src-exts-qq. Everything else that I've used from haskell-src-exts-qq works fine, it's just when I try to use tuples that things go haywire. I've tried to remove the packages and reinstall them but it didn't help. Any clues? Josef TestBug.hs:11:11: Can't find interface-file declaration for variable Language.Haskell.Exts.Syntax.Boxed Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the first argument of `Language.Haskell.Exts.Syntax.TyTuple', namely `Language.Haskell.Exts.Syntax.Boxed' In the third argument of `Language.Haskell.Exts.Syntax.TypeSig', namely `Language.Haskell.Exts.Syntax.TyTuple Language.Haskell.Exts.Syntax.Boxed ((:) (Language.Haskell.Exts.Syntax.TyVar (Language.Haskell.Exts.Syntax.Ident ((:) 'a' []))) ((:) (Language.Haskell.Exts.Syntax.TyVar (Language.Haskell.Exts.Syntax.Ident ((:) 'b' []))) []))' In the expression: Language.Haskell.Exts.Syntax.TypeSig (SrcLoc ((:) '<' ((:) 'u' ((:) 'n' ((:) 'k' ((:) 'n' ((:) 'o' ((:) 'w' ((:) 'n' ((:) '>' ((:) '.' ((:) 'h' ((:) 's' [])))))))))))) 1 2) ((:) (Language.Haskell.Exts.Syntax.Ident ((:) 'q' ((:) 'u' ((:) 'u' ((:) 'x' []))))) []) (Language.Haskell.Exts.Syntax.TyTuple Language.Haskell.Exts.Syntax.Boxed ((:) (Language.Haskell.Exts.Syntax.TyVar (Language.Haskell.Exts.Syntax.Ident ((:) 'a' []))) ((:) (Language.Haskell.Exts.Syntax.TyVar (Language.Haskell.Exts.Syntax.Ident ((:) 'b' []))) []))) Failed, modules loaded: none.

1 0

Re: [Haskell-cafe] Maybe use advice
by John Lato 07 Jun '11

07 Jun '11

Is it necessary (helpful) to use 'rewrite'? Nearly every time I've tried it, in the end 'transform' has been a better choice. Then you wouldn't need the 'Just's at all, and it should work fine. John > From: Lyndon Maydwell <maydwell(a)gmail.com> > > (missed including cafe) > > f :: [Modification] -> Maybe [Modification] > and > f _ = Just $ f ... > are incompatible > > I managed to get the behaviour I'm after with the use of Either, but > this really is messy: > > > -- Sets of changes > o (Modifier (Changes []) i) = Just $ i > o (Modifier (Changes [c]) i) = Just $ Modifier c i > o (Modifier (Changes l) i) = g (f (Left l)) > where > g (Right l) = Just $ Modifier (Changes l) i > g (Left l) = Nothing > > f (Left (Scale x y : Scale x' y' : l)) = > f $ Right $ Scale (x*x') (y*y') : h (f $ Left l) > f (Left (Translate x y : Translate x' y' : l)) = > f $ Right $ Translate (x+x') (y+y') : h (f $ Left l) > f (Left (Rotate x : Rotate x' : l)) = > f $ Right $ Rotate (x+x') : h (f $ Left l) > f x = x > > h (Left l) = l > h (Right l) = l > > > On Tue, Jun 7, 2011 at 3:11 AM, Maciej Marcin Piechotka > <uzytkownik2(a)gmail.com> wrote: > > On Mon, 2011-06-06 at 23:38 +0800, Lyndon Maydwell wrote: > >> I'm writing an optimisation routine using Uniplate. Unfortunately, a > >> sub-function I'm writing is getting caught in an infinite loop because > >> it doesn't return Nothing when there are no optimisations left. > >> > >> I'd like a way to move the last Just into f, but this makes recursion > >> very messy. I was wondering if there was a nice way to use something > >> like the Monad or Applicative instance to help here. > >> > >> -- Sets of changes > >> o (Modifier (Changes []) ?i) = Just $ i > >> o (Modifier (Changes [c]) i) = Just $ Modifier c i > >> o (Modifier (Changes l) ? i) = Just $ Modifier (Changes (f l)) i > >> ? where > >> ? ? f (Scale ? ? x y : Scale ? ? x' y' : l) = f $ Scale ? ? (x*x') > (y*y') : f l > >> ? ? f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') > (y+y') : f l > >> ? ? f (Rotate ? ?x ? : Rotate ? ?x' ? ?: l) = f $ Rotate ? ?(x+x') ? ? ? > ?: f l > >> ? ? f l = l > >> > >> > >> Any ideas? > > > > Something like: > > > > ... > > f (Rotate ? ?x ? : Rotate ? ?x' ? ?: l) > > ? ?= Just $ f (Rotate (x+x') : fromMaybe l (f l)) > > f l = Nothing -- As far as I understend > > > > Regards > > > > _______________________________________________ >

2 3

Can it be proven there are no intermediate "useful" type classes between Applicative Functors & Monads?
by KC 07 Jun '11

07 Jun '11

If new intermediate classes crop up then there would be no point in fixing class (Applicative m) => Monad m where since it would have to be changed if new intermediate classes are found. I realize non-existence proofs are hard. -- -- Regards, KC

6 7

Regression moving to ghc7
by tsuraan 07 Jun '11

07 Jun '11

I'm trying to write a rolling window variation of the adler32 hash function (here: https://gist.github.com/1011151) and I got it to a nearly acceptable speed under ghc 6.12.3 (~35MB/s on my work machine), so I thought I'd see how the new ghc 7.0.3 treated it. The answer is "not good". I get about 270KB/s. The key difference that I'm seeing from looking at the ghc-core program is that ghc 7.0.3 isn't using primitive ops for anything (unless they are no longer annotated with "#"). Can anybody shed any light as to what's going on? I'd also welcome any optimization tips that people would like to share. I've been messing with the code so much over the past day or two that I'm not even sure if it computes an adler32 anymore, but I hope that any optimization tops that pertain to that code would also apply to a correct algorithm. Right now, I'd just like to have the code run quickly, and to figure out why I'm seeing such a terrible regression under ghc7.

2 4

How to install GhC on a Mac without registering?
by John D. Ramsdell 07 Jun '11

07 Jun '11

I rarely use a Mac because it is too cute, but I bought one for my wife. I'd like to install GHC on her Mac just to test Haskell Platform and cabal install. (I rarely use Windows too, but testing GHC & cabal install is completely painless.) To do a quick test, do I really have to register as an Apple developer, or is there a way to test the platform anonymously? Someone who some times worries about privacy, John

14 20

Maybe use advice
by Lyndon Maydwell 06 Jun '11

06 Jun '11

I'm writing an optimisation routine using Uniplate. Unfortunately, a sub-function I'm writing is getting caught in an infinite loop because it doesn't return Nothing when there are no optimisations left. I'd like a way to move the last Just into f, but this makes recursion very messy. I was wondering if there was a nice way to use something like the Monad or Applicative instance to help here. -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = Just $ Modifier (Changes (f l)) i where f (Scale x y : Scale x' y' : l) = f $ Scale (x*x') (y*y') : f l f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') (y+y') : f l f (Rotate x : Rotate x' : l) = f $ Rotate (x+x') : f l f l = l Any ideas?

4 5

ANN: dtd-text DTD parser, V0.1.0.0
by Yitzchak Gale 06 Jun '11

06 Jun '11

The dtd-text package[1] provides a parser for XML DTDs. It implements most of the parts of the W3C XML specification relating to DTDs, and is compatible with versions 1.0 and 1.1 of the specification.[2] The result of the parse is a Haskell DTD object from the dtd-types[3] package. This first preliminary version of dtd-text, version 0.1.0.0, requires at least version 0.3.0.1 of dtd-types. Synopsis: -- Parse a DTD from a Data.Text.Lazy: dtdParse :: L.Text -> DTD That should usually be all you need. -- Or, for advanced users, if the DTD contains external -- parameter entities and you want to supply their values: dtdParseWithExtern :: SymTable -> L.Text -> DTD -- where type SymTable = M.Map Text L.Text I really should have edited the Cabal description of this package before I uploaded it. It promises an attoparsec-text parser and blaze-builder renderer for DTDs. First of all, the renderer is vaporware - I haven't written it yet. Just the parser was quite a bit of work, so I decided to release it before even starting on the renderer. Second, although dtd-text does use attoparsec-text, and does export parsers for all of the significant components of a DTD, those parsers are of limited usefulness on their own. It turns out that in order to support the full algorithm specified in the spec for parameter entity resolution, which is rather imperative in nature, two layers of parsing are necessary. So the dtd-text package also has some internal plumbing so that it can present a simple interface. This is a very preliminary alpha release. All I can say so far is that it compiles on my machine (GHC 7.0.2 on 64 bit Linux), and that I tested it against a huge, extremely complicated DTD, and it seems to have done the RIght Thing. Since there are likely to be bugs that I will need to fix soon, I will wait until then to fix the package description. More about external parameter entities, for advanced users: As mentioned above, this parser does not attempt to go out and fetch the values of external references for you from files and URLs. If you need to extract information from the DTD before you fetch them yourself, such as system IDs and public IDs, you might be able to get them by applying parseDTD to all or part of the DTD as an initial parse. The parser tries very hard to give partial results when things are missing, while still doing its best to avoid problems like looping references. So if your DTD has many deeply intertwined external parameter entities, this parser may not be very practical for you; on the other hand, I personally have never seen such a DTD in the wild. A final caveat: this version of dtd-text does not yet support conditional sections. Enjoy, Yitz [1] http://hackage.haskell.org/package/dtd-text [2] http://www.w3.org/TR/2008/REC-xml-20081126/ [3] http://hackage.haskell.org/package/dtd-types

2 2

ANN: dtd-text DTD parser and renderer, V0.1.1.0
by Yitzchak Gale 06 Jun '11

06 Jun '11

The dtd-text package[1] provides a parser and renderer for XML DTDs. It implements most of the parts of the W3C XML specification relating to DTDs, and is compatible with versions 1.0 and 1.1 of the specification.[2] The parser and renderer operate on Haskell DTD objects from the dtd-types[3] package. The parser is based on the attoparsec-text[4] parser library. Version 0.1.1.0 adds the first preliminary version of the renderer, based on the blaze-builder[5] package. Synopsis: -- Parse a DTD without parameter entity resolution. -- See the attoparsec-text package for information -- about how to use this parser. dtd :: Parse DTD -- Parse a DTD from a Data.Text.Lazy while resolving -- references to internal parameter entities. If you -- are not sure which interface to use, use this one. dtdParse :: L.Text -> DTD -- Parse a DTD from a Data.Text.Lazy while resolving -- references to internal and external parameter entities. -- Supply the values of the external parameter references -- using a SymTable, where type SymTable = M.Map Text L.Text dtdParseWithExtern :: SymTable -> L.Text -> DTD -- Create a builder to render a DTD. -- See the blaze-builder package for information -- about how to use this builder. buildDTD :: DTD -> Builder Enjoy, Yitz [1] http://hackage.haskell.org/package/dtd-text [2] http://www.w3.org/TR/2008/REC-xml-20081126/ [3] http://hackage.haskell.org/package/dtd-types [4] http://hackage.haskell.org/package/attoparsec-text [5] http://hackage.haskell.org/package/blaze-builder

1 0