July 2005 - Haskell-Cafe

Re: [Haskell-cafe] IO platform for testing
by Frank-Andre Riess 17 Jul '05

17 Jul '05

Hi there, > There are some other, minor problems -- for indexing you need ss!!0, the > name m01_mod, and you may need an 'import' to make getArgs visible. yup, and you have to get rid of the two "do"s in the application of putStrLn. Regards, Frank-Andre Riess

1 0

RE: [Haskell-cafe] Unicode.hs (was: RE: Re[2]: ANNOUNCE: GHC surveyresults)
by Simon Marlow 17 Jul '05

17 Jul '05

On 30 June 2005 14:36, Dimitry Golubovsky wrote: > It is in CVS now, and I believe will be in 6.4.1 Not planned for 6.4.1, but definitely in 6.6. Cheers, Simon

2 1

O'Haskell
by Monique Louise 16 Jul '05

16 Jul '05

Is there any project for extending GHC or any other Haskell compiler with support to O'Haskell / any object-oriented Haskell extesion? That could be very useful for improving Haskell interoperability with OO languages. Thanks in advance, Monique Monteiro -- ________________________________ Monique Louise B.Monteiro Msc Student in Computer Science Center of Informatics Federal University of Pernambuco

1 0

weired
by wenduan 16 Jul '05

16 Jul '05

The following function which converts a number represents a sum of money in pence didn't work as expected and the result didn't make any sense to me: penceToString :: Price -> String penceToString p = let str = show p len = length str in if len ==1 then "0.0" ++ str else if len ==2 then "0." ++ str else (take (len-2) str) ++ "." ++ (drop (len - 2) str ) *Main> penceToString 234566666667899999999786 "-6710990.94" ?!?! -- X.W.D

2 1

Problem linking against Data.Graph
by Andy Gimblett 16 Jul '05

16 Jul '05

Hi all, I'm something of a Haskell newbie, and this is my first post to this list. I'm trying to do some very basic things with graphs, but can't get started with Data.Graph. In particular, linking fails - I'm wondering if something's wrong with my install. (For the record: ghc-6.4 compiled/installed fresh today on gentoo linux - it _looks_ OK to my Haskell-untrained eyes). Here follows a small example which I believe should compile just fine: ---- Code begins "Main.hs" module Main where import Data.Graph.Inductive import System.IO main :: IO () main = putStrLn "Hello, world!" ---- Code ends As you can see, this basically does nothing! Unfortunately, here's what happens: [csandy@cspcag spa_haskell] ghc -o Main Main.hs Main.o(.text+0x145): In function `__stginit_Main_': : undefined reference to `__stginit_DataziGraphziInductive_' collect2: ld returned 1 exit status I get similar errors whatever I try to do with Data.Graph. Trying to compile ghc-6.4/libraries/fgl/test/test.hs (from the source tree) gives me multiple errors of the above type (though not identical). If anyone can shed any light on this, or tell me what stupid thing I'm doing wrong, I'd really appreciate it. Many thanks, -Andy -- Andy Gimblett Computer Science Department University of Wales Swansea http://www.cs.swan.ac.uk/~csandy/

4 4

weird
by wenduan 15 Jul '05

15 Jul '05

The following function which converts a number represents a sum of money in pence didn't work as expected and the result didn't make any sense to me: penceToString :: Price -> String penceToString p = let str = show p len = length str in if len ==1 then "0.0" ++ str else if len ==2 then "0." ++ str else (take (len-2) str) ++ "." ++ (drop (len - 2) str ) *Main> penceToString 234566666667899999999786 "-6710990.94" ?!?! -- X.W.D

1 0

Functional dependencies and type inference
by Einar Karttunen 15 Jul '05

15 Jul '05

Hello I am having problems with GHC infering functional dependencies related types in a too conservative fashion. > class Imp2 a b | a -> b > instance Imp2 (Foo a) (Wrap a) > > > newtype Wrap a = Wrap { unWrap :: a } > data Foo a = Foo > data Proxy (cxt :: * -> *) > > foo :: Imp2 (ctx c) d => Proxy ctx -> (forall a b. (Imp2 (ctx a) b) => a -> b) -> c -> d > foo p f x = f x The type of "foo (undefined :: Proxy Foo)" is inferred as "forall c. (forall a b. (Imp2 (Foo a) b) => a -> b) -> c -> Wrap c" which shows the outmost functional dependence is working fine. ctx is carried to the inner Imp2. However "foo (undefined :: Proxy Foo) Wrap" will fail complaining that Couldn't match the rigid variable `b' against `Wrap a' `b' is bound by the polymorphic type `forall a b. (Imp2 (ctx a) b) => a -> b' at <interactive>:1:0-32 Expected type: a -> b Inferred type: a -> Wrap a In the second argument of `foo', namely `Wrap' My guess is that GHC cannot see that the functional dependency guarantees that there are no instances which make the inferred type invalid. Any solutions to this problem? - Einar Karttunen

1 0

RE: [Haskell-cafe] Re: Module.T naming style
by Simon Marlow 15 Jul '05

15 Jul '05

On 15 July 2005 09:48, Henning Thielemann wrote: > On Thu, 14 Jul 2005, Andrew Pimlott wrote: >> 2) enshrining one-type-per-module in the naming convention is not IMO >> justified, and may prove limiting; > > Other languages like Modula-3 and Oberon do it with great success. The > limit in Haskell is that most compilers don't conform to the Haskell > 98 report which allows mutually recursive modules. But I think the > compilers should allow them instead of forcing users to put many type > and class definitions into one module. I hope you weren't including GHC in "most compilers" :-) GHC's implementation of mutually recursive modules is conformant with Haskell 98 (see Section 5.7). Cheers, Simon

3 2

RE: [Haskell-cafe] Module.T naming style
by Simon Marlow 15 Jul '05

15 Jul '05

On 15 July 2005 11:24, Henning Thielemann wrote: > On Fri, 15 Jul 2005, Simon Marlow wrote: > >> On 15 July 2005 09:48, Henning Thielemann wrote: >> >>> The limit in Haskell is that most compilers don't conform to the >>> Haskell 98 report which allows mutually recursive modules. But I >>> think the compilers should allow them instead of forcing users to >>> put many type and class definitions into one module. >> >> I hope you weren't including GHC in "most compilers" :-) GHC's >> implementation of mutually recursive modules is conformant with >> Haskell 98 (see Section 5.7). > > But there are unresolved problems with class definitions. > http://www.haskell.org/pipermail/haskell-cafe/2005-May/009873.html > > Is this covered by the statement "Modules may be mutually recursive."? > http://www.haskell.org/onlinereport/modules.html Ok, mututal recursion between classes in separate modules isn't currently supported (I'd forgotten about that). But it's a bit harsh to say that because of this missing feature GHC doesn't support mutually recursive modules - we've been using mutually recursive modules in GHC itself for nearly a decade! Cheers, Simon

1 0

Re: Coin changing algorithm
by Okasaki, C. DR EECS 15 Jul '05

15 Jul '05

ChrisK wrote: > During a single evaluation the recursive calls never "collide", so > unless this overlap is optimized, then the subproblem memoizing won't do > anything... Actually, the recursive calls can collide. For example, if you are trying to make 87 cents with 7 coins, you can make the first 80 cents with four coins using either 50-10-10-10 or 20-20-20-20. Either way, you'll end up making a recursive call on 7 cents and 3 coins. Admittedly, however, with this choice of coin denominations, you don't get very many such collisions... -- Chris

1 0