August 2002 - Haskell

RE: ugliness with state parameter in ST stuff
by Simon Peyton-Jones 28 Aug '02

28 Aug '02

I don't know what you are trying to do, but I do know why your program is rejected. The *whole point* of a value of type (STArray s Int Int) is that it can only be read by a state thread with the same type parameter 's' as the array. Given your decls > class Foo a where > foo :: a -> IO Int > > data Bar s = Bar (STArray s Int Int) > > instance Foo (Bar s) where ... it is absolutely right that you are going to fail. To implement the instance decl, you need to make foo :: forall s. Bar s -> IO Int But you can read an STArray parameterised by an *arbitrary* state type s using the IO monad! Of course not! There is even a theorem in 'State in Haskell' that makes just this point: separate state threads really are separate, and you can't read a reference from one in another. No, no, no! Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 06 August 2002 19:20 | To: Haskell Mailing List | Subject: ugliness with state parameter in ST stuff | | | Sorry for the flood of emails this morning, but I've got | something which has really got me scratching my head. | | Suppose I have a class: | | > class Foo a where | > foo :: a -> IO Int | | and a datatype with a single function: | | > data Bar s = Bar (STArray s Int Int) | > | > getFirst :: Bar s -> ST s Int | > getFirst (Bar arr) = readArray arr 0 | | Now, I want to make (Bar s) and instance of Foo. But I can't | seem to do this. If I use: | | > instance Foo (Bar s) where | > foo = stToIO . getFirst | | GHC complains: | | Cannot unify the type-signature variable `s' | with the type `RealWorld' | Expected type: Bar s -> IO Int | Inferred type: Bar RealWorld -> IO Int | In the expression: stToIO . getFirst | In the definition of `foo': stToIO . getFirst | | and if I use: | | > instance Foo (Bar s) where | > foo = return . runST . getFirst | | GHC complains: | | Inferred type is less polymorphic than expected | Quantified type variable `s' escapes | Expected type: ST s a -> c | Inferred type: (forall s1. ST s1 a) -> a | In the first argument of `(.)', namely `runST' | In the second argument of `(.)', namely `runST . getFirst' | | Is there no way to do this? I can change the definition of Foo to: | | > class Foo2 a where | > foo2 :: (forall s . a s) -> IO Int | | I can define: | | > instance Foo2 Bar where | > foo2 = stToIO . getFirst | | Which I suppose works, but the problem is that in real life, | "Foo" is "Binary" and I can't really change it. | | Suggestions? (Other than simply moving all my ST stuff over to the IO | monad?) | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

RE: GHC bug,or Hugs feature?
by Simon Peyton-Jones 28 Aug '02

28 Aug '02

There are two things going on. 1. Hugs deals with mutual recursion in a more sophisticated way than GHC. Mark T is absolutely right, and the THIH paper explains. 2. Furthermore,GHC implements the H98 requirement that the context of all functions in a mutually recursive groups must be the same. So f :: Eq a => ... g :: Ord a => ... is illegal if f and g are mutually recursive. Both these things arise from the way GHC translates mutually recursive overloaded defns. Consider f :: Ord a => a -> a -> a f x y = ...(x==y)...(x>y)...(f y x)... GHC translates it thus: f ord_dict = let gr = select_gr ord_dict eq_dict = select_eq ord_dict eq = select_eq eq_dict fm x y = ...(eq x y)...(ord x y) ...(fm y x)... in fm Note that all the dictionary selection (and sometimes construction) is done outside the loop, implemented by 'fm'. Matters get more complicated when there is mutual recursion; suffice it it say that in order to pull the dictionary manipuation outside the loop, all the contexts must be the same. Arguably, H98 and GHC are wrong, and the restrictions should be lifted. GHC usually errs on the side of lifting restrictions (with -fglasgow-exts) but on this occasion the benefit seemed slight, while it turns out that the cost of changing the way let/where is dealt with is not inconsiderable. So I've let sleeping dogs lie. I think it's a corner case that seldom matters. Counter examples to this claim would be interesting. At least I hope this explains what's happening. Simon | -----Original Message----- | From: Mark Tullsen [mailto:mtullsen@cse.ogi.edu] | Sent: 09 August 2002 20:31 | To: haskell(a)haskell.org | Cc: Arthur Baars | Subject: Re: GHC bug,or Hugs feature? | | | I believe the incompatibilities are explained thus: | | In section 4.5.1 of the Haskell Report it only states that | "A dependency analysis transformation is first performed | to increase | polymorphism" | | But hugs appears to be using a more refined version of the | dependency | analysis as explained in section 11.6.3 of Mark Jones' paper Typing | Haskell in Haskell. Read that section. | | - Mark | | | Arthur Baars wrote: | > In Mark Jones' paper Typing Haskell in Haskell, I found the | following | > example(in the section on binding-groups): | > | > f :: Eq a => a -> Bool | > f x = x==x || g True | > g y = y<=y || f True | > | > According to the paper the inferred type of g should be: | g::Ord a => | > a -> Bool | > | > Hugs infers this type but GHC infers the following | *ambiguous* type: | > *Main> :i g | > -- g is a variable, defined at Test.hs:25 | > g :: forall a. (Eq a) => Bool -> Bool | > | > When adding an explicit type signature for g, Hugs happily | accepts the | > code, but GHC gives the following error: | > | > f :: Eq a => a -> Bool | > f x = x==x || g True | > g :: Ord a => a -> Bool | > g y = y<=y || f True | > | > Test.hs:24: | > Couldn't match `{Ord a}' against `{Eq a1}' | > When matching the contexts of the signatures for | > g :: forall a. (Ord a) => a -> Bool | > f :: forall a. (Eq a) => a -> Bool | > The signature contexts in a mutually recursive group | should all be | > identical | > When generalising the type(s) for g, f | > Failed, modules loaded: none. | > | > I think the problems are caused by differences in the binding group | > analysis in Hugs and GHC. | > | > Malcolm, could you check what NHC says about the examples above? | > | > Cheers, | > Arthur | > | > _______________________________________________ | > Haskell mailing list | > Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell | > | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

RE: ambiguous type variables in existential classes
by Simon Peyton-Jones 28 Aug '02

28 Aug '02

Hal I don't quite understand the intuitions behind your program, but the bug is easy enough: | instance (Eq e, Foo p) => Foo (Wrap p) where | foo (Bar p) e q = foo p e q This instance declaration is guaranteed to give problems if it is ever used, and GHC should probably bleat about it. Suppose you have the constraint Foo (Wrap T) where T is some type. Using the instance declaration we can simplify this to the constraints Eq e Foo T where e is a fresh type variable. But we are never going to learn any thing more about 'e', and so it is correctly reported as ambiguous. It's like writing reverse :: Eq x => [a] -> [a] Any call to this 'reverse' will give a constraint (Eq x) that is ambiguous. Really, GHC should reject the instance declaration. Simon

1 0

Evaluation order, ghc versus hugs, lazy vs. strict
by Jan Kybic 28 Aug '02

28 Aug '02

Hello, I am wrestling with having Haskell (using ghc(i) version 5.02.2) evaluate things in good order and to garbage collect what he no longer needs. I could simplify the problem to this simple example: main = print $ sum [0..1000000] When you use a sufficiently large number (perhaps 10000000 instead of 1000000), both ghci and ghc terminate with "Stack space overflow". On the other hand, Hugs (dated December 2001) runs the example OK and produces the result of 500000500000. I have the following questions: 1. Why does this happen? Why does not ghc Haskell generate the list lazily, summing as he goes and forgetting what he no longer needs? 2. How can I find out what happens? The normal profiling ( -prof -auto-all ) does not seem to be very helpful. Could not we get some kind of tracing, printing out what is being evaluated? 3. How can I tell Haskell what I want ? a) that the (+) in sum is strict. It is in this case but in other more complex, like "foldl1 f [0..1000000]" I end up with closures f ( f ( f ( f ( ....)))) which are not evaluated until the end. b) that the list [0..1000000] should be lazy, e.g. evaluated only as needed I will be very grateful for any help. I am trying to use Haskell for numerical calculations but so far I am not very satisfied: the code is very elegant but runs of the order of many magnitudes slower than the corresponding C implementation. Please help me avoid going to C again. Thanks, Jan -- ------------------------------------------------------------------------- Jan Kybic <kybic(a)ieee.org> Odyssee, INRIA, Sophia-Antipolis, France or <Jan.Kybic(a)sophia.inria.fr>,tel. work +33 492 38 7589, fax 7845 http://www-sop.inria.fr/robotvis/personnel/Jan.Kybic/

8 16

Re: Pretty printing (was: Standard Library for text formatting?)
by Zdenek Dvorak 26 Aug '02

26 Aug '02

Hello, > > After doing some searching, it seems that "pretty printing" is > > a prominant "Haskell way" of doing text output. I still am > > interested in finding a library of standard text formatting > > (String formatting) functions, but it seems like it might > > be worth my while investigating pretty printing. > >Pretty printing is not very suited for printf like formatting, I have looked for something simmilar some time ago, but unsuccesfully. Pretty printing libraries are not very useful for breaking paragraphs into lines, distributing spaces evenly, etc. (at least I was not able to persuade them to work like that). I have written following module that implements stupid first-fit algorithm for these purposes; the interface is simmilar to the pretty printing libraries. Zdenek Dvorak module ReportPrinter ( LowDoc,HighDoc, (<>),(<+>),($$),(<$>), int, lowText, text, empty, colon, comma, space, semi, period, brackets, parens, vcat, sep, punctuate, high, nest, par, render ) where data LowDoc=Text String | Join LowDoc LowDoc | Append LowDoc LowDoc | Empty deriving (Show) data HighDoc=HLowDoc LowDoc | Paragraph Int HighDoc | Nest Int HighDoc | Above HighDoc HighDoc | Beside HighDoc HighDoc deriving (Show) (<>)::LowDoc->LowDoc->LowDoc x <> Empty = x Empty <> x = x x <> y = Join x y (<+>)::LowDoc->LowDoc->LowDoc x <+> Empty = x Empty <+> x = x x <+> y = Append x y (<$>)::HighDoc->HighDoc->HighDoc x <$> HLowDoc Empty=x HLowDoc Empty <$> x=x x <$> y=Beside x y ($$)::HighDoc->HighDoc->HighDoc x $$ HLowDoc Empty=x HLowDoc Empty $$ x=x x $$ y=Above x y lowText::String->LowDoc lowText=Text text::String->LowDoc text str=sep $ map lowText $ words str int::Int->LowDoc int=text . show empty::LowDoc empty=Empty colon::LowDoc colon=lowText ":" comma::LowDoc comma=lowText "," space::LowDoc space=lowText " " semi::LowDoc semi=lowText ";" period::LowDoc period=lowText "." brackets::LowDoc->LowDoc brackets doc=lowText "[" <> doc <> lowText "]" parens::LowDoc->LowDoc parens doc=lowText "(" <> doc <> lowText ")" sep::[LowDoc]->LowDoc sep=foldl (<+>) empty high::LowDoc->HighDoc high=HLowDoc vcat::[HighDoc]->HighDoc vcat=foldl ($$) (high empty) punctuate::LowDoc->[LowDoc]->[LowDoc] punctuate _ [] = [] punctuate _ [x] = [x] punctuate pun (h:t) = (h <> pun) : punctuate pun t nest::Int->HighDoc->HighDoc nest=Nest par::Int->HighDoc->HighDoc par=Paragraph render::Int->HighDoc->String render width doc=highRender width 0 0 doc "" highRender::Int->Int->Int->HighDoc->String->String highRender width indFirst indRest doc rest= case doc of HLowDoc lowDoc -> lowRender width indFirst indRest lowDoc rest Paragraph ind pDoc -> highRender width indFirst (indRest+ind) pDoc rest Nest ind pDoc -> highRender width (indFirst+ind) (indRest+ind) pDoc rest Above doc1 doc2 -> highRender width indFirst indRest doc1 $ highRender width indRest indRest doc2 rest Beside doc1 doc2 -> error "Rendering two HighDocs beside not supported." lowRender::Int->Int->Int->LowDoc->String->String lowRender width indFirst indRest doc rest= stringRender width indFirst indRest strs rest where (strs,_) = stringify False doc [] stringify False (Text txt) rest = ((txt,length txt):rest,False) stringify True (Text txt) [] = ([(txt,length txt)],False) stringify True (Text txt) ((txt',len'):rest) = ((txt++txt',length txt+len'):rest,False) stringify join Empty rest = (rest,join) stringify join (Append doc1 doc2) rest = let (rest',join')=stringify join doc2 rest in stringify join' doc1 rest' stringify join (Join doc1 doc2) rest = let (rest',_)=stringify join doc2 rest in stringify True doc1 rest' stringRender::Int->Int->Int->[(String,Int)]->String->String stringRender width indFirst indRest [] rest=rest stringRender width indFirst indRest strs rest= let (lne,rst)=cutLine (width-indFirst) strs rest'=stringRender width indRest indRest rst rest in lineRender (rst==[]) width indFirst lne rest' cutLine tot ((txt,len):t)=(txt:lne',rst) where (lne',rst)=cutLine' (tot-len) t cutLine' ml []=([],[]) cutLine' ml r@((tx,ln):t') | ml>ln = let (lne'',rst')=cutLine' (ml-ln-1) t' in (tx:lne'',rst') | otherwise = ([],r) lineRender::Bool->Int->Int->[String]->String->String lineRender last width ind lne rest=indent ind rslt where totlen = sum $ map length lne words = length lne reqlen = totlen + words - 1 havelen = width - ind distsp = if havelen > reqlen && not last then havelen - reqlen else 0 count = words `div` 2 rslt = distribSpaces count distsp words lne rest indent n = (take n (cycle " ") ++) distribSpaces::Int->Int->Int->[String]->String->String distribSpaces _ _ _ [h] rest = h ++ '\n' : rest distribSpaces count minus plus (h:t) rest = h ++ ' ' : spaced where (spaced,count') = recount count rest' = distribSpaces (count'-minus) minus plus t rest recount cnt | cnt < 0 = let (spaced',cnt')=recount (cnt+plus) in (' ':spaced',cnt') | otherwise = (rest',cnt) _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

1 0

future business ��Ѻ�س!
by future＠businez.com 26 Aug '02

26 Aug '02

> >��蹵�� Ѻ�š��áԨ��Թ��絔 >��ǡѺ��¹�ŧ��˭� >��Ѻ�ٻẺ�ͧ�ҹ��͹Ҥ� ��ؤ�ͧ�š��ᴹ �ѹ�� >�ҹ��¹�ŧ͹Ҥ��ҧ��Թ�ͧ�س��ʹ� > �Ѻ�ҹ价��ѹ�� >��ö�� 8,000 � 50,000 �ҷ/��͹ > >�Ѻ��Ѥ÷�駼��ͧ�� ѹ�� 2-3 �� ͧ��Ш� > >��ԡ�� http://www.zthefuture.com/advanced >�� http://www.thaiworkathome.com/advanced > > > >��ҷ�ҹ��ͧ��â��Ţ��ù�� CLICK�� >http://www.thaiworkathome.com/unsubscribe.php

1 0

Haskell on FreeBSD
by Oliver Braun 26 Aug '02

26 Aug '02

Hi Haskellers on FreeBSD, I have committed a bunch of new Haskell ports to the FreeBSD ports tree. The FreeBSD ports tree contains now 18 Haskell related ports: devel/c2hs devel/drift devel/green-card devel/haddock devel/happy devel/hat devel/hmake devel/hpl devel/popenhs graphics/hgl lang/generic-haskell lang/ghc lang/ghc-doc lang/hugs lang/nhc98 textproc/haxml x11-toolkits/frantk x11-toolkits/gtk+hs Is any Haskeller on FreeBSD interested in giving me some feedback, working with me on more Haskell ports or on the improvement of the existing ports. Please feel free to drop me a note or file a PR. Regards, Olli [lets start a "Haskell on FreeBSD" project] -- «: IST & IIS _ INF _ UniBwM :: obraun(a)informatik.unibw-muenchen.de :» «: Tele-Consulting GmbH :: obraun(a)Tele-Consulting.com :» «: FreeBSD Commmitter :: obraun(a)FreeBSD.org :»

1 0

Standard Library for text formatting?
by Dr Mark H Phillips 26 Aug '02

26 Aug '02

Hi, Is there a standard haskell library for formatting text? Ie something with similar (or better) functionality to C's sprintf? I've done a bit of a search and haven't come up with much. In particular, I am looking for a routine that allow me to left or right justify text within a fixed column width. Presumably I could write this myself, but it would be better to use a standard library if there is such a thing. Cheers, Mark. -- Dr Mark H Phillips Research Analyst (Mathematician) AUSTRICS - smarter scheduling solutions - www.austrics.com Level 2, 50 Pirie Street, Adelaide SA 5000, Australia Phone +61 8 8226 9850 Fax +61 8 8231 4821 Email mark(a)austrics.com.au

2 2

Re: Java byte code library anyone?
by Ashley Yakeley 26 Aug '02

26 Aug '02

At 2002-08-23 07:44, Sven Panne wrote: >Has anybody already written a Haskell library for Java byte code manipulation >(reading/writing class files, editing byte codes, etc.)? Something in the >spirit of the Byte Code Engineering Library (http://jakarta.apache.org/bcel/) >or the Jikes Bytecode Toolkit (http://www.alphaworks.ibm.com/tech/jikesbt/) >would be extremely nice. It's not rocket science, but quite a bit of work. There's code in JVM-Bridge for assembling Java class files. It does things such as constant pooling, etc., for you. I use it to create "callback" classes at run-time that have Haskell functions for methods. <http://sourceforge.net/projects/jvm-bridge/> -- Ashley Yakeley, Seattle WA

2 1

Reklam Vermek ��in Servet �demeyin
by info 24 Aug '02

24 Aug '02

Reklam Vermek İçin Servet Ödemeyin · Artık çok daha ucuza ve masrafsız nasıl mı ? · 7 milyon Türk kullanıcısına şirketinizin tanıtımını yaparak · Arama motorlarına kayıt ettirerek · 400.000.000 milyon yabancı kullanıcıya kendinizi tanıtarak Şirket , Kurum , Kuruluş ve Web Sitenizi bu yolla çok daha ucuza tanıtabilirsiniz. - 7 milyon Türk Kullanıcı sadece 49 $ + KDV - 400.000.000 Yabancı Kullanıcı 99 $ + KDV İletişim : Necatibey caddesi 27/11 Sıhhıye – Ankara İcq : 131140541 e-mail : info(a)bulent.net

1 0