- Haskell-Cafe - Haskell.org

RE: [Haskell] line-based interactive program
by Simon Marlow 13 Jul '05

13 Jul '05

On 08 July 2005 18:22, Olaf Chitil wrote: > In fact, unsafeInterleaveIO shows up limitations of the IO monad. > Without this strange primitive (what is actually unsafe about it?) Just picking up on this point: unsafeInterleaveIO is so named because it lets you write programs that don't obey the usual laws. For example: main = do r <- newIORef 0 a <- unsafeInterleaveIO $ readIORef r b <- unsafeInterleaveIO $ do writeIORef r 42; return 0 print (a + b) if you change (a + b) to (b + a), you get a different answer. Cheers, Simon

1 0

Confused about Cyclic struture
by Dinh Tien Tuan Anh 12 Jul '05

12 Jul '05

Hi, Im a newbie to Haskell and the concept of "cyclic strutures" has confused me a lot For example (taken from Richard Bird's book): ones = 1:ones Its clear that it involves a cyclic structure But: ones = repeat 1 repeat x = x:repeat x I dont really understand what the differences between these two and why the latter does not have a cyclic structure ? Why does changing : repeat x = xs where xs = x:xs create a cyclic stucture ? Thank you Anh _________________________________________________________________ Winks & nudges are here - download MSN Messenger 7.0 today! http://messenger.msn.co.uk

10 21

Overlapping Instances with Functional Dependencies
by Daniel Brown 12 Jul '05

12 Jul '05

I have the following three programs: class Foo a b instance Foo (a -> b) (a -> [b]) instance Foo a a class Bar a b | a -> b instance Bar (a -> b) (a -> b) instance Bar a a class Baz a b | a -> b instance Baz (a -> b) (a -> [b]) instance Baz a a When compiled in ghc 6.4 (with -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances) Foo and Bar compile fine, but Baz fails with this error: Baz.hs:2:0: Functional dependencies conflict between instance declarations: Baz.hs:2:0: instance Baz (a -> b) (a -> [b]) Baz.hs:3:0: instance Baz a a This is how I interpret the error: The fundep says "a uniquely determines b", but if you have `Baz (Int -> Int) b`, b is `Int -> [Int]` according to the first instance and `Int -> Int` according to the second instance. b isn't uniquely determined by a, so the functional dependency isn't functional -- thus the conflict. When confronted with overlapping instances, the compiler chooses the most specific one (if it is unique), e.g. `Baz (a -> b) (a -> [b])` is more specific than `Baz a a`. But it seems that the combination of the two features is broken: if the most specific instance is chosen before checking the functional dependency, then the fundep is satisfied; if the fundep is checked before choosing the most specific instance, then it isn't. Is this a bug, or am I confused? Dan

3 3

cabal --user question
by Frederik Eaton 11 Jul '05

11 Jul '05

Hi, How do I install a package in the user package.conf with cabal? It is not clear to me how to do this, looking at the output of 'configure --help'. There is an option "--user" to get dependencies from the user cabal file but this still, somewhat counterintuitively, tries to install the package in the global location (why would one want such behavior?). Specifying '--with-hc-pkg="ghc-pkg --user"' doesn't seem to work either, when I do this then 'install' and 'unregister' complete without error but apparently have no effect. Thanks in advance, Frederik

3 5

Re: matrix computations based on the GSL
by Keean Schupke 08 Jul '05

08 Jul '05

Is a matrix is a linear operation on a vector, does it not make sense to define matrix applicaion: mapply :: Matrix -> Vector -> Vector Then you can define say: rotate90 = mapply rotationMatrix90 v' = rotate90 v Keean.

2 3

RE: [Haskell-cafe] Overlapping Instances with Functional Dependencies
by Simon Peyton-Jones 08 Jul '05

08 Jul '05

Martin's dead right. GHC uses a less sophisticated mechanism to do matching when it's thinking about functional dependencies than when it's doing straight instance matching. Maybe something cleverer for fundeps would make sense, as you point out. I hadn't thought of that before; it's a good point. Nowadays, whenever a fundep question comes up I think "how would it show up if we had associated type synonyms instead of fundeps?" (see the paper on my home page). In this case I think the answer is "GHC's current instance-matching mechanism would work unchanged"; or to put it another way, what ever mechanism is used for instance matching, the same would be used for type dependencies. Simon | I wouldn't call this a bug, overlapping instances | and in particular the combination with functional dependencies | are something which is not well studied yet. | Hence, GHC is very conservative here. | | I feel like you, this program should work. | As you correctly point out, there's a conflict among the | two improvement rules (resulting from the instances and FD). | A sensible decision is to apply the same "ad-hoc" | mechanism to improvement rules that is currently | applied to overlapping instances. Of course, we need some | formal system to express such conditions precisely. | You find some hints how to achieve this in | | G. J. Duck, S. Peyton-Jones, P. J. Stuckey, and M. Sulzmann. | Sound and decidable type inference for functional dependencies. | In Proc. of ESOP'04 | | Martin | | | Daniel Brown writes: | > I have the following three programs: | > | > class Foo a b | > instance Foo (a -> b) (a -> [b]) | > instance Foo a a | > | > class Bar a b | a -> b | > instance Bar (a -> b) (a -> b) | > instance Bar a a | > | > class Baz a b | a -> b | > instance Baz (a -> b) (a -> [b]) | > instance Baz a a | > | > When compiled in ghc 6.4 (with -fglasgow-exts | > -fallow-overlapping-instances -fallow-undecidable-instances) Foo | > and Bar compile fine, but Baz fails with this error: | > | > Baz.hs:2:0: | > Functional dependencies conflict between instance declarations: | > Baz.hs:2:0: instance Baz (a -> b) (a -> [b]) | > Baz.hs:3:0: instance Baz a a | > | > This is how I interpret the error: The fundep says "a uniquely | > determines b", but if you have `Baz (Int -> Int) b`, b is `Int -> [Int]` | > according to the first instance and `Int -> Int` according to the second | > instance. b isn't uniquely determined by a, so the functional dependency | > isn't functional -- thus the conflict. | > | > When confronted with overlapping instances, the compiler chooses the | > most specific one (if it is unique), e.g. `Baz (a -> b) (a -> [b])` is | > more specific than `Baz a a`. | > | > But it seems that the combination of the two features is broken: if the | > most specific instance is chosen before checking the functional | > dependency, then the fundep is satisfied; if the fundep is checked | > before choosing the most specific instance, then it isn't. | > | > Is this a bug, or am I confused? | > | > Dan | > _______________________________________________ | > Haskell-Cafe mailing list | > Haskell-Cafe(a)haskell.org | > http://www.haskell.org/mailman/listinfo/haskell-cafe | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

RE: [Haskell-cafe] Re: [Haskell] ANNOUNCE: GHC survey results
by Simon Peyton-Jones 06 Jul '05

06 Jul '05

| If anything I would like to see the Haskell community produce a Haskell | front end which was compiler neutral. That would facilitate many | interesting projects, and that might even help with the need to support | new extensions as they come along. There are already some candidates | floating around, but it seems they are not widely adopted. Well, "ghc -c -fext-core Foo.hs" is a Haskell front end that produces System F code ("External Core"), in a file Foo.hcr. I'm not sure whether that was what you meant. However, External Core doesn't seem to have really caught on. Only 5% said it was essential, with another 16% saying "nice to have". I'm sure there's room to improve the ExtCore route. Simon

6 5

polymorphic type
by wenduan 06 Jul '05

06 Jul '05

Dear all, Suppose we have defined two functions as below: case :: (a -> c,b -> c) -> Either a b -> c case (f, g) (Left x) = f x case (f, g) (Right x) = g x plus :: (a -> b, c -> d) -> Either a b -> Either c d plus (f, g) = case(Left.f, Right.g) My question is regarding to the function signature of 'plus' , in its signature, does the 'a' in 'a -> b' and in 'Either a b', must be instantiated to the same object when the function is applied?E.g.,Either a b is instantiated to 'Either Char b', will the 'a' in 'a -> b' be instantiated to 'Either Char b'?Furthermore, are the two bs in 'a -> b' and 'Either a b' not conflicting?What I thought at first the signature of plus should be: plus :: (a -> c, b -> d) -> Either a b -> Either c d?Anyone know where I was wrong? -- X.W.D

3 2

Cabal with Alex and and Happy
by Brian Smith 06 Jul '05

06 Jul '05

Is there an example of how to build a Cabal package that has a lexer generated with Alex and a parser generated with Happy? As far as I can tell, the way to do this is to add "Other-Modules: Module.Name.Of.Parser.y Module.Name.Of.Lexer.x" to each executable/library stanza. But, when I try this, I get: Could not find module `GHC.Exts': it is a member of package base-1.0, which is hidden The generated parser code contains: #if __GLASGOW_HASKELL__ >= 503 import GHC.Exts #else import GlaExts #endif Also, I don't see any way of passing options to preprocessors using Cabal. In particular, how do you pass options to Happy? I am using GHC and Cabal from the CVS head, built about two weeks ago. Thanks, Brian

4 4

can't build module with ffi 'wrapper' by cabal (or ghc): unknown symbol
by Evgeny Chukreev 06 Jul '05

06 Jul '05

Hello! http://toril.ru/hmhash/hmhash-0.1.tar.bz2 ###### ./Setup.hs clean; ./Setup.hs configure; ./Setup.hs build -v5 Configuring HMhash-0.1... configure: searching for ghc in path. configure: found ghc at /usr/bin/ghc configure: looking for package tool: ghc-pkg near compiler in /usr/bin/ghc configure: found package tool in /usr/bin/ghc-pkg configure: Using install prefix: /usr/local configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4 configure: Using package tool: /usr/bin/ghc-pkg configure: Using haddock: /usr/bin/haddock configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: Using cpphs: /usr/bin/cpphs configure: Reading installed packages... configure: Dependency base-any: using base-1.0 Preprocessing library HMhash-0.1... /usr/bin/hsc2hs -osrc/Codec/Mhash.hs src/Codec/Mhash.hsc Building HMhash-0.1... /usr/bin/ghc -package-name HMhash -odir dist/build/src -hidir dist/build/src --make -isrc -ffi -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances -fallow-incoherent-instances -Wall -O0 -package base-1.0 Codec.Mhash -v Glasgow Haskell Compiler, Version 6.4, for Haskell 98, compiled by GHC version 6.2.2 Using package config file: /usr/lib/ghc-6.4/package.conf Using package config file: /home/akshaal/.ghc/i386-linux-6.4/package.conf Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Codec.Mhash Stable modules: *** Compiling Codec.Mhash ( src/Codec/Mhash.hs, interpreted ): compile: input file src/Codec/Mhash.hs *** Checking old interface for Codec.Mhash: Compiling Codec.Mhash ( src/Codec/Mhash.hs, dist/build/src/Codec/Mhash.o ) *** Parser: *** Renamer/typechecker: <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' <no location info>: Warning: Defined but not used: `k' *** Desugar: Result size = 6135 *** Simplify: Result size = 6847 Result size = 5654 Result size = 5564 *** Tidy Core: Result size = 5564 *** CorePrep: Result size = 6911 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** C Compiler gcc src/Codec/Mhash_stub.c -o /tmp/ghc29101.s -DDONT_WANT_WIN32_DLL_SUPPORT -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=604 -ffloat-store -I src/Codec -I /usr/lib/ghc-6.4/include Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.5 (Debian 1:3.3.5-8) /usr/lib/gcc-lib/i486-linux/3.3.5/cc1 -quiet -v -I src/Codec -I /usr/lib/ghc-6.4/include -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=5 -DDONT_WANT_WIN32_DLL_SUPPORT -D__GLASGOW_HASKELL__=604 src/Codec/Mhash_stub.c -quiet -dumpbase Mhash_stub.c -auxbase-strip /tmp/ghc29101.s -O -Wimplicit -version -ffloat-store -o /tmp/ghc29101.s GNU C version 3.3.5 (Debian 1:3.3.5-8) (i486-linux) compiled by GNU C version 3.3.5 (Debian 1:3.3.5-8). GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95593 ignoring nonexistent directory "/usr/i486-linux/include" #include "..." search starts here: #include <...> search starts here: src/Codec /usr/lib/ghc-6.4/include /usr/local/include /usr/lib/gcc-lib/i486-linux/3.3.5/include /usr/include End of search list. *** Assembler gcc -Isrc/Codec -c /tmp/ghc29101.s -o dist/build/src/Mhash_stub.o *** Assembler gcc -Isrc/Codec -c /tmp/ghc29100.s -o dist/build/src/Codec/Mhash.o *** Deleting temp files Deleting: /tmp/ghc29101.s /tmp/ghc29100.s Upsweep completely successful. *** Deleting temp files Deleting: link(batch): upsweep (partially) failed OR Main.main not exported; not linking. *** Deleting temp files Deleting: /usr/bin/ar qv dist/build/libHSHMhash-0.1.a dist/build/src/Codec/Mhash.o /usr/bin/ar: creating dist/build/libHSHMhash-0.1.a a - dist/build/src/Codec/Mhash.o ###### ./Setup.hs install Installing: /usr/local/lib/HMhash-0.1 & /usr/local/bin HMhash-0.1... Registering HMhash-0.1... Reading package info from ".installed-pkg-config" done. building GHCi library /usr/local/lib/HMhash-0.1/HSHMhash-0.1.o... done. Saving old package config file... done. Writing new package config file... done. ###### ghci -package HMhash ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base-1.0 ... linking ... done. Loading package HMhash-0.1 ... linking ... ghc-6.4: /usr/local/lib/HMhash-0.1/HSHMhash-0.1.o: unknown symbol `CodecziMhash_d7Ew' ghc-6.4: unable to load package `HMhash-0.1' ------------------ I know how to fix it by hands: rm dist/build/libHSHMhash-0.1.a /usr/bin/ar qv dist/build/libHSHMhash-0.1.a dist/build/src/Codec/Mhash.o dist/build/src/Mhash_stub.o But, how to do it with cabal? -- ... WBR, Evgeny Chukreev ...

3 3

Fork & execve
by yin 05 Jul '05

05 Jul '05

Hello! Is there some way how to fork a process in haskell? And excuting an another proces, waiting until it exit and colecting his stdout? Matej 'Yin' Gagyi PS: I'm sorry for my English!

2 1

New-bee question about seq in Parsec.Pos
by Christoph Bauer 04 Jul '05

04 Jul '05

Hi, I try to understand, how Parsec works. In Pos.hs I found these definition of SourcePos: data SourcePos = SourcePos SourceName !Line !Column deriving (Eq,Ord) My poor haskell knowledge says me, that Line and Column is always strict. So, what does the following function? forcePos :: SourcePos -> SourcePos forcePos pos@(SourcePos name line column) = seq line (seq column (pos)) thanks for an enlightenment, Christoph Bauer -- let () = let rec f a w i j = Printf.printf "%.20f\r" a; let a1 = a *. i /. j in if w then f a1 false (i +. 2.0) j else f a1 true i (j +. 2.0) in f 2.0 false 2.0 1.0

2 1

haskell parser for java bytecode?
by Kimberley Burchett 03 Jul '05

03 Jul '05

I'm interested in using haskell to do static analysis of java bytecode. To my surprise, I wasn't able to find any existing haskell libraries for parsing java .class files. Is anyone aware of such a library? I've already started writing my own implementation, which I intend to make available as a reusable library once it's ready, but if someone else has already done the work then I'd love to avoid having to repeat it. Kimberley Burchett http://www.kimbly.com/

4 4

pair (f,g) x = (f x, g x)?
by wenduan 02 Jul '05

02 Jul '05

I came across a haskell function on a book defined as following: pair :: (a -> b,a -> c) -> a -> (b,c) pair (f,g) x = (f x,g x) I thought x would only math a single argument like 'a', 1, etc....,but it turned out that it would match something else, for example, a pair as below: square x = x*x pair (square.fst,Char.toUpper.snd) (2,'a') (4,'A') The type declaration of pair is what confused me, pair :: (a -> b,a -> c) -> a -> (b,c),it says this function will take a pair of functions which have types of a->b,a->c,which I would take as these two functions must have argument of the same type, which is a,and I didn't think it would work on pairs as in the above instance,but surprisingly it did,can anybody enlighten me? -- X.W.D

4 4

Re: haskell parser for java bytecode?
by Frank-Andre Riess 01 Jul '05

01 Jul '05

Hi there, keeping out of the previous tiff, I'd just like to mention that I, too, am interested in such a project - I don't require a parser for Java bytecode, but I think I'd be a good experience and at least it would get me to know the JVM a bit better... maybe :) By the way, there once was some discussion about having Haskell actually -target- the JVM (I think, it was on the Glasgow Haskell Users list). That might as well be an interesting thing to do. Best regards, Frank-Andre Riess

1 0

Conversion between MonadPlus instances
by Gracjan Polak 01 Jul '05

01 Jul '05

Hi all, A simple question for advanced Haskellers, but I still have some problems bending my mind over it. Example: I have some function, that can return multiple results. Currently I need only the first one, but in the spirit of NotJustMaybe, I try to be as general as possible. If I code it like this: reduction :: (MonadPlus m) => [Rule] -> Expr -> m Expr reduction expr = do rule <- rules reduction rule expr Variable m gets unified with []. But I want m to stay as general as possible here. This version works, but I somehow do not like the "smell" of it reduction expr = do let listmonad = do rule <- rules reduction rule expr msum (map return listmonad) Is there a better way how to "embed" MonadPlus in other "MonadPlus"? -- Gracjan

2 1

RE: ANNOUNCE: GHC survey results
by Simon Marlow 01 Jul '05

01 Jul '05

On 28 June 2005 14:11, Bulat Ziganshin wrote: > Tuesday, June 28, 2005, 1:58:13 PM, you wrote: > >> http://www.haskell.org/ghc/survey2005-summary.html >> There's a lot to take in, but it's an interesting read. Enjoy! > > thank you all, processing all the 600 answers was not easy work :) > > i have several comments regarding results of this survey: > > 1) GHCi compiles to bytecode several times faster than GHC makes > unoptimized compilation. can unoptimized GHC compilation just create > bytecode (as Ocaml does)? Do you really mean "several times faster"? My impression is that it's a few percent faster, if at all. Some measurements would be good. We've thought about compiling to persistent byte code in the past, but the gains never seemed to be worth the effort: we'd need a byte-code serialiser and loader. > 2) is your plans to support x86-64 platform includes Windows (and all > other sorts of Unix), or it's for Linux only? Definitely Windows too. I hear the cygwin/mingw tools are still unstable on Windows x64, though. > 3) many users complaining about non-compatibility between GHC > versions. if they mean library interfaces changes then how about using > Pesco's library versioning scheme? (see > http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory) I've read that article, and I think it's an interesting idea. I can't disagree with the arguments put forward, but somehow, the cure seems a bit painful. Cheers, Simon

4 3

Re: [Haskell] best way to do generic programming?
by Thomas Jäger 01 Jul '05

01 Jul '05

Arka, as you already mentioned, you want to have a look at the "Scrap your Boilerplate" approach. > import Data.Generics > ... > data Expr = Const Int | Var String | Add Expr Expr deriving (Typeable, Data) will derive the necessary Data instance and allow you to define > optimizeDeep :: Data a => a -> a > optimizeDeep = everywhere (mkT optimize) On 7/1/05, Arka al Eel <arkaaleel(a)gmail.com> wrote: > Hi, > > I'm playing with generic programming. At the moment I'm interested in > reusable transformations on data types. Provided for example a toy > datatype Expr like this: > > data Expr = Const Int | Var String | Add Expr Expr > > Plus a function "optimize" that optimizes a pattern "x + 0" into "x": > > optimize (Add x (Const 0)) = x > > You would now want this to be this generic, so the function should be > recursive for all other constructors *and* other data types. For > example, suppose that Expr is included in other datatype: > > data Stm = Assign String Expr | Seq Stm Stm > > I now want the "optimize" transformation to work on Stm, like > this: > > x = optimize (Seq (Assign (Add (Var "x") (Const 0))) blah blah) > with a sensible solution in an hour, while I can do this in two > minutes in Scheme. After all, writing compilers is supposed to be a > *strong* point of Haskell. Real world is knocking on your door, guys! Thomas

1 0

RE: [Haskell-cafe] Re: [Haskell] Dynamic binding
by Ralf Lammel 01 Jul '05

01 Jul '05

> > But note that "same functionality" is one thing, > > having "separate compilation" and "program extensibility" too > > is another one. > > As I said, and as is well-known, "extensibility" is a red herring in > this context - you merely trade one dimension of extensibility for > another one. I am not going to fight for extensibility. It's just that I believe that there is a value in a direct correspondence as opposed to a transcription. I cite from the OOHaskell abstract: "The [...] code [...] demonstrates that OO code translates into OOHaskell in an intuition-preserving way: essentially expression-by-expression, without requiring global transformations." I would like to add a peer-reviewed clear reference to the OOHaskell paper about the red herring that you mention. I don't have such a reference. May I kindly ask you to offer a few for selection? Thanks, Ralf

4 4

Re: haskell parser for java bytecode?
by Kimberley Burchett 30 Jun '05

30 Jun '05

Jerzy Karczmarczuk asked: > > Why for goodness' sake, people interested in Haskell *should* worry > about parsing of Java bytecode chunks? Are you asking why I'm interested in bytecode instead of source code, or are you asking why I'm interested in Java at all? One answer to the first question is: because java bytecode is a simpler problem domain than java source. For example, name resolution is trivial when working with bytecode (there's no ambiguity between package/class/variable names, inherited names are already resolved, overloaded functions are already resolved, etc). Also, many of the newer features of java disappear at the bytecode level: inner classes, generics, the new foreach statement, etc. Another answer to the first question is: because java bytecode can be used as a target for several languages these days, and by working with it directly, I can work with any language that compiles to the jvm, rather than restricting myself just to java. The answer to the second question is: because the rest of the world matters to some people. Kimberley Burchett http://www.kimbly.com/

4 4

Unicode.hs (was: RE: Re[2]: ANNOUNCE: GHC survey results)
by Dimitry Golubovsky 30 Jun '05

30 Jun '05

Hi, Vadim Konovalov wrote: === that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC? === Clarifying on Unicode stuff in GHC I contributed: It is in CVS now, and I believe will be in 6.4.1 At least it shows up at: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/GHC/Unicod… (MAIN branch) But this module is just an interface to another module, WCsubst.c: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/cbits/WCsu… which in turn was produced from UnicodeData.txt (? I believe this is correct name of the file from www.unicode.org) by the shell script: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/cbits/ubco… This API handles simple case conversions (Char -> Char), and categorization of characters according to what is in the UnicodeData.txt file. Before (i. e. up to and including 6.4), Unicode stuff was handled through wc* locale based functions for wide chars conversion. Since not every installation of Unix (or some other OS) has this set up properly (mine was not: personal itch), this code was proposed for GHC and finally made it there. Hope this explains everything. In fact, Unicode.hs itself is not completely mine ;) PS: Autrijus (the guy who develops Pugs) included those files on his own because 6.4 was just out, and Unicode stuff was not there yet. -- Dimitry Golubovsky Anywhere on the Web

1 0

RE: Re[2]: ANNOUNCE: GHC survey results
by Konovalov, Vadim 30 Jun '05

30 Jun '05

> btw, in Pugs sources > (http://search.cpan.org/CPAN/authors/id/A/AU/AUTRIJUS/Perl6-Pugs-6.2.7.tar.g z) > there is Unicode.hs module wich can classify and convert full range of > Unicode symbols under any OS. i don't understand - is this module > already included in GHC 6.5? if not, it would be good addition that file reads: -- Based on the GHC.Unicode library, Copyright 2005, Dimitry Golubovsky. -- See GHC's LICENSE file for the full license text. That said, it is part of GHC?

1 0

Re: [Haskell] ANNOUNCE: GHC survey results
by Bernard Pope 30 Jun '05

30 Jun '05

[moved to haskell-cafe] On Tue, 2005-06-28 at 14:46 -0700, John Meacham wrote: > Unfortunatly hat suffers from the same problem that pretty much every > non-trivial preprocessor does, as soon as you start using ghc's special > or experimental features that have not been added to hat yet, they stop > working. I agree this is a problem. [snip] > I am not sure what the general solution would be. perhaps > hat being integrated with ghc? I think it is preferable to keep them separate. Already a big effort was put into making hat independent of nhc98. There will always be more tools that Haskell could use, which must transform the source code one way or another. I'd rather not see them all be pushed inside ghc, or whatever other compiler was popular at the time. It's probably better for ghc's maintainability to keep these tools out of its source tree (pure speculation on my part though). > or better yet would be a standard > interface for ghc to call a preprocessor but at some intermediate level > where most of the extensions have been sugared away but most of the > original source structure still exists... the nice thing about a > standard interface would be that jhc and other compilers could support > it too. It wouldn't even need to be a plugin based thing, but rather an > executable that ghc can run and pass commands to it on stdin and read > results on stdout. Sounds nicer. Perhaps GHC-as-a-library might be close to what is needed. There is a danger that we won't be able to settle upon what is the right core language to use, and some tools will be left out, thus reverting to the solution employed by hat at the moment. > Being able to just work on any unmodified program the > compiler supports is a huge feature. Yes. The problem is that Haskell is being torn in two directions. One direction is a research vehicle. The other direction is a work-horse. GHC sits somewhere in the middle, and does an amazing job too. The trouble is that it has become a fast moving target. Overall I think Hat's solution is a reasonable compromise between the competing needs of the tool. If anything I would like to see the Haskell community produce a Haskell front end which was compiler neutral. That would facilitate many interesting projects, and that might even help with the need to support new extensions as they come along. There are already some candidates floating around, but it seems they are not widely adopted. Cheers, Bernie.

1 0

Commerical Users of Functional Programming Workshop 2005
by Andy Moran 29 Jun '05

29 Jun '05

[ Apologies for multiple postings; please forward to potentially interested parties ] CUFP 2005 THE SECOND COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING WORKSHOP Talinn, Estonia September 24th 2005 Co-located with ICFP Functional languages have been under academic development for over 25 years, and are still proving to be very fertile ground for programming language research. Consequently, most of the development focus of these languages is driven by academic and theoretical questions. More recently, however, functional languages have been very successfully used in commercial, industrial, and government settings, where their advantages have been able to be leveraged dramatically. The goal of CUFP is to act as a voice for commercial users of functional programming languages and technology. It aims to help functional programming become increasingly viable as a technology for use in the commercial, industrial, and government space, by providing a forum for FP professionals to share their experiences and ideas, whether business, management or engineering. It also aims to enable the formation and cementing of relationships and alliances that further the commercial use of functional languages. Providing user feedback to language designers and implementors is not a primary goal of the workshop, though it will be welcome if it occurs. Program plans ------------- The meeting will last a full day, with a mix of invited and submitted presentations, plus discussion sessions. Topics will range over a wide area, including: * Case studies both of successful and unsuccessful uses of functional programming; * Business opportunities and risks from using functional languages; * Enablers for functional language use in a commercial setting; * Barriers to the adoption of functional languages, and * Mitigation strategies for overcoming limitations of FP. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. A full report of last year's workshop will appear in the Functional Programming column of SIGPLAN Notices. See http://www.galois.com/cufp/ for more information, including last year's schedule and a report describing last year's workshop. This year's schedule will also be available there soon. Submissions ----------- Submissions by prospective speakers or suggestions for speakers are welcome! Just send an e-mail to cufp at galois.com with an outline of what you'd like to talk about or what you think your suggestee should give a talk about. Program Committee ----------------- Mike Ashley: Mike.Ashley at sagian.com Jim Grundy: Jim_Grundy at ichips.intel.com Xavier Leroy: Xavier.Leroy at inria.fr Simon Peyton Jones: simonpj at microsoft.com Ulf Wiger: ulf.wiger at ericsson.com Andy Moran: moran at galois.com John Launchbury: john at galois.com (Chair) -- Andy Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran(a)galois.com

1 0

Compiling an extremely large Haskell file (in GHC)
by Arjun Guha 29 Jun '05

29 Jun '05

I have an extremely large source file of about 11 MB. It's the all-pairs shortest paths data for a map of the Hyde Park area of Chicago (no real reason, really). I generated information in Scheme and printed the result to a Haskell source file as a list. I then edited the file to initialized an array with the data. GHC, with a 200MB stack, took up 1 hour and 1.3 GB of memory before getting killed by the system. How would I compile something of this size? I need to have the array of all-pairs shortest paths pre-computed. Any suggestions? Thanks. -Arjun

6 7

Announce: Yet Another Tool to Generate FFI Bindings: hsffig
by Dimitry Golubovsky 29 Jun '05

29 Jun '05

I am pleased to announce the very first alpha release of the (yet another) FFI binding autogeneration tool. Some time ago, I asked the list subscribers about available bindings to Berkeley DB. Several people kindly shared their code with me. One thing I noticed in all bindings: they required manually-written wrappers to accomodate for Berkeley DB indirect style of calling functions. Considering large number of such functions in BDB, I attempted to write a tool which would automatically parse the BDB include file, and extract function prototypes to generate FFI declarations. Soon it became clear that an almost full C syntax parser would be necessary. Finally it resulted in what I am presenting to the Haskell community with hope that this utility will be useful to many developers. Of course there are many omissions and shortcuts, but before I move forward, I would like to get some feedback from potential users of this tool. There is no detailed documentation. I have written a brief README file. More detailed documentation will follow. I haven't created a homepage for this project yet: the only way to get it so far is the darcs repo: darcs get http://www.golubovsky.org/repos/hsffig Files in the repository may be browsed at: http://www.golubovsky.org/repos/hsffig/ I will appreciate any feedback. Dimitry Golubovsky Middletown, CT

2 1

Re: ANNOUNCE: GHC survey results
by Bulat Ziganshin 28 Jun '05

28 Jun '05

Hello Simon, Tuesday, June 28, 2005, 1:58:13 PM, you wrote: SM> http://www.haskell.org/ghc/survey2005-summary.html SM> There's a lot to take in, but it's an interesting read. Enjoy! thank you all, processing all the 600 answers was not easy work :) i have several comments regarding results of this survey: 1) GHCi compiles to bytecode several times faster than GHC makes unoptimized compilation. can unoptimized GHC compilation just create bytecode (as Ocaml does)? 2) is your plans to support x86-64 platform includes Windows (and all other sorts of Unix), or it's for Linux only? 3) many users complaining about non-compatibility between GHC versions. if they mean library interfaces changes then how about using Pesco's library versioning scheme? (see http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory) 4) i definitely will poll for nightly snapshot build for Windows (if it's possible) and frequent releases of stable versions i think there is a plans to move toward the "real world". but it encounter the chicken&egg problem - the commercial programmers don't want to use Haskell because it's too far-from-earth, and you cannot make movements toward "real world" because there is almost no voices from non-academic world. of course i can't monopolize the right to say over all these programmers. but from my point of view several things can be done to be closer to commercial programs and programmers: 1) adding OO-like features in O'Haskell style. for readers that don't know it's about adding new variants to ADT types: type Figure = Circle ... type Figure |= Box ... and adding new fields to existing records: type Point = {x,y::Int} type ColoredPoint = Point extended with {c::Color} imho these extensions are great because it's both in Haskell and C++ style 2) adding "real-world" libraries. i think about libraries for string processing, regular expression handling, command-line processing, serializing, ASCIIZ strings, working with filesystem and running external commands, networking, web-oriented libraries (http/ftp/smtp/pop3, constructing/deconstructing emails), DBMS access i enumerated here only working libraries which i seen in MissingH, or written by Pesco, John Meacham, or Peter Simons 3) may be it is time to include some FFI-generating tool in GHC? many newcomers have some C/C++ libraries they need to communicate 4) some newcomers wrote what they want to say example programs and even tutorials in the package. i think that at least links to such sources/texts can be provided so that a newcomer can easily get a TASTE of Haskell 5) of course, you must add words about Pugo and Darcs in readme :) anyway, ADT is a vehicle of progress ;) -- Best regards, Bulat mailto:bulatz@HotPOP.com

4 6

Noob error: Type b -> c b Does not match IO a
by kynn＠panix.com 28 Jun '05

28 Jun '05

--text follows this line-- I'm trying to learn Haskell from YAHT. My attempt at a solution of Exercise 3.10 is failing with a "Type does not match" error. The exercise is to write a function that will read numbers (one per line) from the command line, until the number 0 is entered. At this point the program is supposed to print out the sum of the numbers, their product, and for each number, the factorial. The interaction should resemble this: Give me a number (or 0 to stop): 5 Give me a number (or 0 to stop): 8 Give me a number (or 0 to stop): 2 Give me a number (or 0 to stop): 0 The sum is 15 The product is 80 5 factorial is 120 8 factorial is 40320 2 factorial is 2 The code I have for this is given next (the line that fails is indicated by a comment): module Main where import IO main = do hSetBuffering stdin LineBuffering numberList <- getList let s = sumList numberList let p = prodList numberList putStrLn ("The sum is " ++ s) putStrLn ("The product is " ++ p) printFact numberList fact 0 = 1 fact 1 = 1 fact x = x * fact x - 1 sumList [] = 0 sumList (x:xs) = x + sumList xs prodList [] = 1 prodList (0:xs) = 0 prodList (x:xs) = x * prodList xs printFact [] = return printFact (x:xs) = do -- triggers error message putStrLn (x ++ " factorial is " ++ fact x) printFact xs return getList = do putStrLn "Give me a number (or 0 to stop):" numString <- getLine let num = read numString if num == 0 then return [] else return (num:getList) Here's the full error I get (from HUGS): IO> :l Ex3_10 ERROR "./Ex3_10.hs":28 - Type error in generator *** Term : printFact xs *** Type : b -> c b *** Does not match : IO a If anyone can explain to me how to fix this error I'd appreciate it. Also, what is the difference between <- and let? Lastly, any comments on any other detail of the code, particularly coding, style are most welcome. Thanks! kj

5 5

Why I Love Haskell In One Simple Example
by John Goerzen 28 Jun '05

28 Jun '05

I posted this on my blog at http://changelog.complete.org/node/339 but I thought there may be some here that would find it of use. I recently implemented some new Haskell numeric types that, instead of performing calculations, can generate a rendering of the requested calculation or store units with it. Here you see a transcript of my session with a Haskell interpreter. The mathematical statements I am entering after the ">" are standard Haskell expressions, and, as I demonstrate, normally evaluate to a single result. Once I get a more powerful simplifier, I will probably write a LaTeX exporting function as well. The entire implementation of this, BTW, is less than 200 lines. NumTest> 5 + 1 * 3 8 NumTest> prettyShow $ 5 + 1 * 3 "5+(1*3)" NumTest> rpnShow $ 5 + 1 * 3 "5 1 3 * +" NumTest> prettyShow $ 5 + 1 * 3 "5+(1*3)" NumTest> prettyShow $ simplify $ 5 + 1 * 3 "5+3" NumTest> prettyShow $ 5 * (Symbol "x") + 3 "(5*x)+3" NumTest> 5 / 2 2.5 NumTest> (units 5 "m") / (units 2 "s") 2.5_m/s NumTest> (units 5 "m") / 2 2.5_m NumTest> 10 * (units 5 "m") / (units 2 "s") 25.0_m/s NumTest> sin (pi/2) 1.0 NumTest> sin (units (pi/2) "rad") 1.0_1.0 NumTest> sin (units 90 "deg") 1.0_1.0 NumTest> (units 50 "m") * sin (units 90 "deg") 50.0_m NumTest> ((units 50 "m") * sin (units 90 "deg")) :: Units (SymbolicManip Double) 50.0*sin(((2.0*pi)*90.0)/360.0)_m NumTest> rpnShow $ dropUnits $ ((units 50 "m") * sin (units 90 "deg")) "50.0 2.0 pi * 90.0 * 360.0 / sin *" NumTest> (units (Symbol "x") "m") * sin (units 90 "deg") x*sin(((2.0*pi)*90.0)/360.0)_m Also, I defined this in my source file: test :: forall a. (Num a) => a test = 2 * 5 + 3 Now, it can be used: NumTest> test 13 NumTest> rpnShow test "2 5 * 3 +" NumTest> prettyShow test "(2*5)+3" NumTest> test + 5 18 NumTest> prettyShow (test + 5) "((2*5)+3)+5" NumTest> rpnShow $ test + 5 "2 5 * 3 + 5 +" You can grab the very early experimental code with darcs get http://darcs.complete.org/num. Haskell has no built-in support for numeric types with units, arbitrary symbols carried through computations, etc. But it was trivial to add it. This kind of extensibility is a key part of why Haskell is so amazing.

5 6

RE: [Haskell-cafe] Compiling an extremely large Haskell file (in GHC)
by Simon Marlow 27 Jun '05

27 Jun '05

On 27 June 2005 19:24, Arjun Guha wrote: > I have an extremely large source file of about 11 MB. It's the > all-pairs shortest paths data for a map of the Hyde Park area of > Chicago (no real reason, really). I generated information in Scheme > and printed the result to a Haskell source file as a list. I then > edited the file to initialized an array with the data. > > GHC, with a 200MB stack, took up 1 hour and 1.3 GB of memory before > getting killed by the system. How would I compile something of this > size? I need to have the array of all-pairs shortest paths > pre-computed. Any suggestions? GHC doesn't have a good way to compile large amounts of static data. Either: (a) put the data into a static array in a C file, compile it with a C compiler, and access it via the FFI, or (b) encode it as a string, and access it using GHC's primitives, or (c) read it from a file at runtime. (Happy and Alex use (b) for encoding parse tables, BTW). Cheers, Simon

1 0

Why distinct tyvars in instance declarations?
by Josh Hoyt 27 Jun '05

27 Jun '05

Hello, I'm a new Haskeller, and I'm running into a problem attempting to declare certain types as instances. I was attempting something that's effectively equivalent to: > class Foo a > > instance Foo (Either b b) but GHC complains: > Illegal instance declaration for `Foo (Either b b)' > (The instance type must be of form (T a b c) > where T is not a synonym, and a,b,c are distinct type variables) > In the instance declaration for `Foo (Either b b)' and so I looked in the report (http://www.haskell.org/onlinereport/decls.html#sect4.3.2) and found: > The general form of the corresponding instance declaration is: > > instance cx' => C (T u1 ... uk) where { d } > > where k>=0. The type (T u1 ... uk) must take the form of a type constructor T applied to simple type variables u1, ... uk; furthermore, T must not be a type synonym, and *the ui must all be distinct*. (emphasis mine) My question is, why this restriction that the types must be distinct? In particular, I'd like to declare a very specific type (Either String String) as an instance. What techniques can I use to accomplish this? Josh Hoyt

3 3

Re: [Haskell-cafe] Why distinct tyvars in instance declarations?
by Frank-Andre Riess 27 Jun '05

27 Jun '05

Hi there, > but GHC complains: > > Illegal instance declaration for `Foo (Either b b)' > > (The instance type must be of form (T a b c) > > where T is not a synonym, and a,b,c are distinct type variables) > > In the instance declaration for `Foo (Either b b)' unless I'm totally mistaken, your problem isn't the distinction thingy, but rather an error like supplying an Int for where you need (Int -> Int -> Int). That is, you're trying make (Either String String) an instance of Foo, (Either String String) already being a fully constructed type; Foo, on the other hand, seems to require a type constructor that is yet to parameterize over three more types (e.g. StateT). Greets, Frank-Andre Riess

3 2

Re: [Haskell-cafe] Noob error: Type b -> c b Does not match IO a
by kynn＠panix.com 27 Jun '05

27 Jun '05

Some simplifications might help you here... > prodList [] = 1 > prodList (0:xs) = 0 > prodList (x:xs) = x * prodList xs Simplified: prodList xs = foldl (*) 1 xs But my original at least made some provision for short circuiting the whole operation if the list contained a 0. As far as I can figure, fold, map, etc., are not suitable for any situation in which short-circuiting would be desirable (e.g. and, or, etc.). Am I wrong? (I realize that, given that the function product is already available, there is no point in defining my function prodList above, but my question is a more general one, having to do with how best to implement short-circuiting.) Thanks! kj

6 8

type inference and named fields
by Malcolm Wallace 27 Jun '05

27 Jun '05

I have discovered something I believe to be a problem in Haskell'98, although it is not a simple bug as such - it has more of the flavour of an unintended mismatch in the interaction of two separate features. Since Haskell is deeply principled language, a feature conflict is extremely rare, and so worthy of note. So here it is: Some attempts to use named field updates are prohibited by type inference, even though the code is perfectly type safe. Here is an example. > module Fieldbug where > data Fields a = > VariantWithTwo { field1 :: a > , field2 :: a } > | VariantWithOne { field1 :: a } The key point here is that the data structure with named fields has more than one constructor, and some fields are omitted in one of the variants. Now let's try to write a simple conversion function over values of this type, using only the named-field update style: > data Void = Void > > voidcast :: Fields a -> Fields Void > voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void } > voidcast v@(VariantWithOne{}) = v { field1 = Void } It looks simple enough doesn't it? But none of the widely available Haskell implementations will accept this code. Hugs: ERROR "Fieldbug.hs":11 - Inferred type is not general enough *** Expression : voidcast *** Expected type : Fields a -> Fields Void *** Inferred type : Fields Void -> Fields Void ghc: Fieldbug.hs:11:32: Couldn't match the rigid variable `a' against `Void' `a' is bound by the type signature for `voidcast' Expected type: Fields Void Inferred type: Fields a In the record update: v {field1 = Void} In the definition of `voidcast': voidcast (v@(VariantWithOne {})) = v {field1 = Void} nhc98: ====== Errors after type inference/checking: Derived type for Fieldbug.voidcast at 10:1-11:42 does not match due to: given free variable a is bound to Void Derived:((Fields Void) -> (Fields Void)) Given :((Fields a) -> (Fields Void)) As far as I can tell, the problem is that in the final line, the expression v { field1 = Void } is interpreted by the type inference algorithm as if the variable v could contain either constructor VariantWithOne or VariantWithTwo. Obviously in the latter case the expression would indeed be incomplete because it casts only one of the fields, not both. But we know that can never be the case! By pattern-matching, this particular v /must/ be the former constructor. Unfortunately we cannot pass that knowledge into the type inference algorithm. It turns out that it is in fact /impossible/ to write this conversion function using only named field updates. It can only be written by using an explicit constructor on the rhs, which thus forces you to initialise all its fields explicitly. This negates any value from using named fields in the first place. Regards, Malcolm

10 32

RE: [Haskell-cafe] Re: [Haskell] Dynamic binding
by Ralf Lammel 24 Jun '05

24 Jun '05

> Off-hand, I recall a paper by Martin Odersky and the Scala people > discussing their approach to the Expression Problem, So ... http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200433.pdf ... I guess The key innovative idea there is composition of mixins while replacing formal superclasses of mixins by the actual base class for mixin composition. I quote: "In a mixin composition A with B with C, class A acts as actual superclass of mixins B and C, replacing the declared superclasses of B and C. To maintain type soundness, A must be a subclass of the declared superclasses of B and C. A super reference in either B or C will refer to a member of class A. As is the case for trait composition, Scala's mixin composition is commutative in the mixins - A with B with C is equivalent to A with C with B." In OOHaskell, you would parameterize in the superclass and that's it. DISCLAIMER: we haven't tried this. Thanks for the inspiration. > and a related paper by Jacques Garrigue, > where he proposes to solve it using OCaml's polymorphic variants. I am not sure. Is this referring to "Objective Label"? Which paper exactly? > Hope this helps, It's interesting but I don't see how we make progress with the original (by now perhaps trivial) question regarding the transportation of an OO design into Haskell. The shapes problem doesn't call for Odersky's new contribution: I quote: "We add to this list the following criterion: * Independent extensibility: It should be possible to combine independently developed extensions so that they can be used jointly [21]." The shapes problem rather calls for silly subtyping polymorphism. So we are beating a dead horse (or a red herring) by detouring to Scala unless I don't get you were hinting at. BTW, I just notice that Oderksy's list of partial solutions isn't complete: - Visitor combinators (Joost Visser) complementing Palsberg et al. - Many forms of generic functional programming (Hinze etc.) - Haskell type classes allow for extension in both type and processor extension. It's getting late here. Ralf

2 1

RE: [Haskell-cafe] Re: [Haskell] Dynamic binding
by Ralf Lammel 24 Jun '05

24 Jun '05

Bulat wrote: > if you require several operations, you can pack them in tuple or > structure (really, tuple is a structure without field names) How are we going to anticipate all possible bodies of a for-loop? By comparison, when we build a normal Haskell list, does the construction precisely mirror what we are going to *do* with each element? Fold the map then!!! > if you need fields/interfaces inheritance, then this method will not > work. but in 90% of cases it's enough. What to do for the other 10%? > in C++, creating classes is the > most useful method of structuring program, so it is used for any > problem - from very simple to most complex. when you translate such > thing to Haskell, it's better to see which concrete problem are solved > with help of classes, and not to emulate the classes itself (because > in this case you will write many unneeded code) Yes, but we ought to solve the shapes problem. The shapes example is in Bulat's 10% region. > only because it's C-like :) you just can't believe that Haskell > program can be 3-10 times smaller while keeping the same functionality > :))) But note that "same functionality" is one thing, having "separate compilation" and "program extensibility" too is another one. Ralf

2 1

RE: [Haskell] Dynamic binding
by Ralf Lammel 24 Jun '05

24 Jun '05

Andreas Rossberg said: > [Followups to Haskell Cafe] > as far as I read it, "dynamic" or "late binding" is orthogonal to > subtyping, or typing in general. It is just that most typed OO languages > lump these concepts together. Absolutely agreed. > Often a simple first-class function, or a record thereof, > is enough (in fact, "dynamic binding" is just the OOO way > of saying "calling a first-class function"). In typical > functional programming style, you need the general > thing only rarely. Can you just tell how *you* would favor encoding the shapes example that was posed by poster? (It might just be that your code would be very close to Lennart's proposal?) Thanks, Ralf

2 1

RE: [Haskell-cafe] RE: Re[4]: [Haskell] Dynamic binding
by Ralf Lammel 24 Jun '05

24 Jun '05

I guess we just need to agree that we disagree. Of course, you are right that I am just a newbie when it comes to Haskell. How did you know that I am actually a Cobol programmer? Did you google? http://www.google.com/search?biw=1003&hl=en&q=Ralf+Cobol Seriously (?): 1. I never intended to impose any particular OO style on Haskeller's. Its more about the *intellectual* question whether we can take C++/C#/Java code and do a structure-preserving conversion to Haskell without starting to argue on paradigm conversion. Or as Alistair Bayley argues (Alistair, thanks for helping out!) http://www.haskell.org/tmrwiki/FpVsOo "... it might be that you need to interface with external OO code, or you are porting an existing program and need to remain faithful to the original design, if only because you don't understand it well enough to convert it to a functional design. ..." Bulat, why not read all of this? Also see the end of that Wiki page, where a reference to a paper is given, which seems to solve all these problems, but my brain is to small to really be sure. ;-) 2. No matter how much you try, the code that you showed was not very close to a faithful Shapes implementation. If you dare to read the spec: http://onestepback.org/articles/poly/ http://www.angelfire.com/tx4/cus/shapes/ You made two proposals that don't solve the problem no matter of *style*: 1st proposal of Bulat: > just create list of draw functions itself: > > [drawCircle (10,10) 5, drawSquare (20,20) 10] > > you are not expected that this problem can be solved with one line of code? :) My reply: you are not building a list of objects. You are not organizing a loop whose body iterates over a list and executes functionality. 2nd proposal of Bulat: > for more complex tasks - declare interface as a structure: > > data ShapeInterface = Shape { draw :: IO (), > moveTo :: Point -> IO (), > calcArea :: Float > } > > > and return this structures from "constructor" functions: > > circle x y r = Shape { draw = drawCircle center r, > moveTo newCenter = ...., > calcArea = pi*r*r > } > where center = Point x y > > square x y size = Shape { draw = ...., > moveTo newCenter = ...., > calcArea = size*szie > } > > figures = [circle 1 2 3, square 4 5 6, circle 7 8 9] The tragedy here is that this stops to work once circles and squares do have different interfaces. You solution does not scale. Subtyping allows for interface extension, and the actual benchmark exploits this, but your code avoids it. Anyway the solution is trivial: ex. quantification, you didn't propose that. Cheers, Ralf (back to Cobol) > -----Original Message----- > From: Bulat Ziganshin [mailto:bulatz@HotPOP.com] > Sent: Thursday, June 23, 2005 11:37 PM > To: Ralf Lammel > Cc: Pal-Kristian Engstad; haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] RE: Re[4]: [Haskell] Dynamic binding > > Hello Ralf, > > Thursday, June 23, 2005, 11:40:13 PM, you wrote: > > RL> a) building (i) a list of data is fundamentally different > RL> from building (ii) a list of anticipated results of each datum. > RL> I would be surprised to hear that this counts as a valid technique. > RL> BTW, you can do the *same* in a lazy OO language. (No lazy OO language > RL> at hand -- well lazyness can be simulated.) > > sorry, "valid" technique is technique that work :) i use in my own > program all the three ways i mentioned to solve problems of different > complexity > > afair, you are relatively new to Haskell (relatively to my 1-year > experience :) and, i think, you are not share FP thinking style. when > programming in Haskell, i think in terms "what thing i will need in > this point of program?". if i need, for example, a possibility to check > string against regular expression, then i will pass a function which > does this check, not original RE. if i need a possibility to > draw a shape, i will pass action which draws this shape. if i need > several functions, i just combine them in a tuple > > there is one interesting example in my program. i have a list of > wildcards and list of filenames and for each filename i need to know > number of first wildcard to which this filename matched. in early > stages of my program development i just passed list of wildcards to > file-finding routine (as [Wildcard]). then, i changed list of wildcards > to list of functions which check match against each wildcard > ([Filename->Bool]). and after that, i changed this to one function which > just finds first True answer (Filename->Int). it was also more > effective to compute this function only one time (it was something > compiled > on moment of computing and worked as fast as hand-written analyzer for > given set of wildcards) > > as you see, i slowly migrated from traditional way of solving this > problem to perfectly functional way and it was required several months > > RL> a) building (i) a list of data is fundamentally different > RL> from building (ii) a list of anticipated results of each datum. > > i think that you don't have "Haskell brain" ;) and therefore don't > "trust" functions, which are passed as parameters, collected in lists, > saved in data structures and so on. you are prefer to "put hands on" > some data, preferably an object, which can be manipulated with any > method declared in his interface. i'm right? ;) > > FP encourage another way - passing functions which will then be applied to > some additional arguments, as in my program, where file-finding > function absolutely don't need list of wildcards. it just need to map > filename to wildcard number, so a Filename->Int parameter is just > enough > > in the draw example, each elment in a list was an action (having type > IO() ), so i don't create list of anticipated results, i created list > of actions which can be performed, for example, by sequence_ > > > RL> Anyway, even if people end up coding as you propose, > RL> it won't work in general. Think of mutation methods that > RL> change the state but preserve the type. Then your list will > RL> still be heterogonous. NO? > > my second example was just of this type. it uses IORefs to hold > current state, but this IORefs don't need to appear in interface > > see method moveTo, which changes state variable center, and method > draw, which uses this variable > > >> this state is just don't need to appear in interface definition :) > >> circle x y r > > RL> You are not talking about state but constructor arguments. > > "interface definition" is a structure ShapeInterface, which have only > fields for exposed object methods. so it supports any figures in > universe :) > > RL> In OO, mutable state tends to leak to the interface, > RL> perhaps not as public fields, perhaps not even as public > > only in C++ and other languages which need to calculate object size :) > declaration of _non-public_ fields in _interface_ is something strange > ;) > > >> this state is just don't need to appear in interface definition :) > >> > >> if you need to maintain mutable state, this is also not a problem: > >> > >> data ShapeInterface = Shape { draw :: IO (), > >> moveTo :: (Int,Int) -> IO (), > >> calcArea :: Float > >> } > >> circle x y r = do > >> center <- ref (x,y) > >> return Shape { draw = val center >>= drawCircle r > >> , moveTo = (center=:) > >> , calcArea = pi*r*r > >> } > >> main = do > >> figures <- sequence [circle 1 2 3, square 4 5 6, circle 7 8 9] > >> mapM_ draw figures > >> mapM_ (moveTo (0,0)) figures > >> mapM_ draw figures > >> > >> ref=newIORef > >> val=readIORef > >> (=:)=writeIORef > > > > -- > Best regards, > Bulat mailto:bulatz@HotPOP.com > >

1 0

Re: [Haskell] Dynamic binding
by Andrew Ward 24 Jun '05

24 Jun '05

Jan-Willem Maessen wrote: > > On Jun 22, 2005, at 9:38 PM, Andrew Ward wrote: > >> Pal-Kristian Engstad wrote: >> >>> On Wednesday 22 June 2005 05:38 pm, Andrew Ward wrote: >>> >>>> What would be the normal way for a Haskell programmer to handle the >>>> typical shape example in beginner OO tutorials? >>>> >>> >>> By not doing OO. You have to ask yourself, what is the purpose >>> and/or benefit of using OO? In C++, OO is _useful_ because you >>> restrict the problems of mutable data (by enclosing it in C++ classes). >>> >>> ML type languages have other methods of doing things, and guess >>> what, OO is not that needed for these languages. Sum-types, >>> pattern-matching and data constructors make half of the need for OO >>> go away. Higher order functions and make it even less needed. For >>> the rest, there's always work-arounds. >>> >>> PKE. >>> >> To handle the problem of drawing all shapes, in c++, I would have a >> list of shape pointers: >> >> struct shape{ virtual void draw(...);}; >> struct circle : public shape {...}; >> struct square : public shape {...}; >> std::list<shape *> shapes; >> for(std::list<shape *>::iterator it = shapes.begin();it != >> shapes.end();++it) >> { (*it)->draw(...); } >> >> This general pattern of dynamic binding I use over and over again. >> Could you give me some example code of this type of thing handled in >> Haskell's way? Assuming that the number of classes deriving from >> shape might get quite large. > > > It seems to me that if this is the specific problem being addressed, a > list of higher-order functions is exactly the right solution in any > ML-like language, and this is why there have been several responses to > that effect. > > I do think it's fair to say "consider changing the way you think" to > OO programmers trying to learn Haskell. If we were on an OOP mailing > list, I could ask for days how to simulate pattern matching and > algebraic types---and get a nonsensical runaround involving the > visitor pattern and huge swaths of unreadable code. > > Ralf, I think it's incumbent on you, having said several times "that > isn't solving the problem", to more clearly explain what problem you > think exists and cannot be solved gracefully (I suspect it has to do > with extensible down-casting---which is indeed hard in Haskell, but > many reasonable people might consider irrelevant or even overtly bad). > > Andrew, if this isn't the problem you're actually trying to solve, can > you explain why a simple list of functions doesn't help you? > I think I will need to learn a little more Haskell before I can appreciate all the different responses. However I will try to answer your question. Assuming I have a list of shapes somewhere in my program. The list would be heterogeneous, or at least contain data constructed using various different type constructors. The list would also be changing all the time, for example in a drawing program. So, using the suggestion of a list of drawing functions, would this not mean I would have to alter the list of drawing functions each time I alter the list of shapes? It does not seem an extensible solution. When it comes to adding new types or new functionality for existing types would it not be easy to miss updating a part of the program source that needed updating? The example I have found the simplest is the one given by Lennart, however this to me seems equivalent to the way people use switch statements in C to mimic dynamic binding. As I said before, I will have to learn more haskell and investigate OOHaskell properly. Thanks for all your responses. > -Jan-Willem Maessen > > >> Andrew Ward. >> >> >> _______________________________________________ >> Haskell mailing list >> Haskell(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell > > >

2 1

RE: Re[4]: [Haskell] Dynamic binding
by Ralf Lammel 24 Jun '05

24 Jun '05

Bulat, a) building (i) a list of data is fundamentally different from building (ii) a list of anticipated results of each datum. I would be surprised to hear that this counts as a valid technique. BTW, you can do the *same* in a lazy OO language. (No lazy OO language at hand -- well lazyness can be simulated.) Anyway, even if people end up coding as you propose, it won't work in general. Think of mutation methods that change the state but preserve the type. Then your list will still be heterogonous. NO? b) You wrote: > this state is just don't need to appear in interface definition :) > circle x y r You are not talking about state but constructor arguments. Please have a look here: http://www.angelfire.com/tx4/cus/shapes/cpp.html Circle Interface (Circle.h) class Circle: public Shape { public: Circle(int newx, int newy, int newradius); int getRadius(); void setRadius(int newradius); void draw(); private: int radius; }; [See getRadius and setRadius) In OO, mutable state tends to leak to the interface, perhaps not as public fields, perhaps not even as public proxy properties (but in the shapes example, it *does*), but then still as sublcass-specific interface member. Anyway, I am happy to add your and Lennart's proposals as appendices to the OOHaskell saga. And finally, Bulat, I agree with your point that > original exercise was about OO way to solve some problem. i want > to say that in Haskell it's better in most cases to use another, > functional way Thanks, Ralf (returning to his VB problem) > -----Original Message----- > From: Bulat Ziganshin [mailto:bulatz@HotPOP.com] > Sent: Thursday, June 23, 2005 4:55 AM > To: Ralf Lammel > Cc: Andrew Ward; Pal-Kristian Engstad; haskell-cafe(a)haskell.org > Subject: Re[4]: [Haskell] Dynamic binding > > Hello Ralf, > > Thursday, June 23, 2005, 11:36:20 AM, you wrote: > > >> just create list of draw functions itself: > >> > >> [drawCircle (10,10) 5, drawSquare (20,20) 10] > > RL> No! the exercise is about lists of shapes > RL> not lists of results of drawing shapes. > RL> This is clearly a major difference. > > in cases where you need to call only one function on created objects, > you can just insert in list calls to this functions (not their results! i > suppose > that drawXXX functions has "... -> IO ()" type) > > in cases where you need to call several functions for this object, you > can insert in list tuple or structure for each object, as i do in next > example. original exercise was about OO way to solve some problem. i want > to say that in Haskell it's better in most cases to use another, > functional way > > RL> Bulat wrote: > > >> for more complex tasks - declare interface as a structure: > >> > >> data ShapeInterface = Shape { draw :: IO (), > >> moveTo :: Point -> IO (), > >> calcArea :: Float > >> } > > RL> No! You miss the point that the different shapes > RL> differ regarding state types. > RL> You don't have a chance when you use one datatype. > > this state is just don't need to appear in interface definition :) > > see for example: > > data ShapeInterface = Shape { draw :: IO (), > calcArea :: Float > } > > circle x y r = Shape { draw = drawCircle x y r, > calcArea = pi*r*r > } > > square x y size = Shape { draw = drawSquare x y size, > calcArea = size*szie > } > > figures = [circle 1 2 3, square 4 5 6, circle 7 8 9] > > > > > > if you need to maintain mutable state, this is also not a problem: > > data ShapeInterface = Shape { draw :: IO (), > moveTo :: (Int,Int) -> IO (), > calcArea :: Float > } > circle x y r = do > center <- ref (x,y) > return Shape { draw = val center >>= drawCircle r > , moveTo = (center=:) > , calcArea = pi*r*r > } > main = do > figures <- sequence [circle 1 2 3, square 4 5 6, circle 7 8 9] > mapM_ draw figures > mapM_ (moveTo (0,0)) figures > mapM_ draw figures > > ref=newIORef > val=readIORef > (=:)=writeIORef > > > RL> haskell-cafe? > > as you wish :) > > -- > Best regards, > Bulat mailto:bulatz@HotPOP.com > >

2 1

Re[4]: [Haskell] Dynamic binding
by Bulat Ziganshin 23 Jun '05

23 Jun '05

Hello Ralf, Thursday, June 23, 2005, 11:36:20 AM, you wrote: >> just create list of draw functions itself: >> >> [drawCircle (10,10) 5, drawSquare (20,20) 10] RL> No! the exercise is about lists of shapes RL> not lists of results of drawing shapes. RL> This is clearly a major difference. in cases where you need to call only one function on created objects, you can just insert in list calls to this functions (not their results! i suppose that drawXXX functions has "... -> IO ()" type) in cases where you need to call several functions for this object, you can insert in list tuple or structure for each object, as i do in next example. original exercise was about OO way to solve some problem. i want to say that in Haskell it's better in most cases to use another, functional way RL> Bulat wrote: >> for more complex tasks - declare interface as a structure: >> >> data ShapeInterface = Shape { draw :: IO (), >> moveTo :: Point -> IO (), >> calcArea :: Float >> } RL> No! You miss the point that the different shapes RL> differ regarding state types. RL> You don't have a chance when you use one datatype. this state is just don't need to appear in interface definition :) see for example: data ShapeInterface = Shape { draw :: IO (), calcArea :: Float } circle x y r = Shape { draw = drawCircle x y r, calcArea = pi*r*r } square x y size = Shape { draw = drawSquare x y size, calcArea = size*szie } figures = [circle 1 2 3, square 4 5 6, circle 7 8 9] if you need to maintain mutable state, this is also not a problem: data ShapeInterface = Shape { draw :: IO (), moveTo :: (Int,Int) -> IO (), calcArea :: Float } circle x y r = do center <- ref (x,y) return Shape { draw = val center >>= drawCircle r , moveTo = (center=:) , calcArea = pi*r*r } main = do figures <- sequence [circle 1 2 3, square 4 5 6, circle 7 8 9] mapM_ draw figures mapM_ (moveTo (0,0)) figures mapM_ draw figures ref=newIORef val=readIORef (=:)=writeIORef RL> haskell-cafe? as you wish :) -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 1

RE: [Haskell-cafe] Re: Using type classes for polymorphism of dataconstructors
by Ralf Lammel 23 Jun '05

23 Jun '05

Thomas Sutton wrote: > Main> :t (Impl (Prop "p") (Poss (Prop "p"))) -- "p -> <>p" > Impl (Prop "p") (Poss (Prop "p")) :: PC So the type says that this is a formula in the predicate calculus? (Even though you combine two formulae of modal logics.) Are you happy with that? Just wondering? Also, are you fine to take the conjunction of a PC and Modal formula, which is admitted by your types? (If not, you may want to use phantom types.) So it seems like the type doesn't carry a lot of information. Then we could also use different types. In particular, we could do without existentials. The types we get will (additionally) record the arity of the outermost constructor. (In your model, the type records the kind of logic of the outermost constructor.) class (Show f) => Formula f data PC0 = Prop String data Formula x => PC1 x = Neg x data (Formula x, Formula y) => PC2 x y = Conj x y | Disj x y | Impl x y instance Formula PC0 instance Formula x => Formula (PC1 x) instance (Formula x, Formula y) => Formula (PC2 x y) instance Show PC0 where show (Prop s) = s instance Formula x => Show (PC1 x) where show (Neg x) = "~" ++ show x instance (Formula x, Formula y) => Show (PC2 x y) where show (Conj a b) = (show a) ++ " /\\ " ++ (show b) show (Disj a b) = (show a) ++ " \\/ " ++ (show b) show (Impl a b) = (show a) ++ " -> " ++ (show b) data Formula x => Modal1 x = Poss x | Necc x instance Formula x => Formula (Modal1 x) instance Formula x => Show (Modal1 x) where show (Poss a) = "<>" ++ (show a) show (Necc a) = "[]" ++ (show a) main = do print (Prop "p") print (Poss (Prop "p")) print (Impl (Prop "p") (Poss (Prop "p"))) (Again, just wondering whether this might be an Ok solution.) Thomas Sutton wrote: > > In Java (C#, Python, etc) I'd do this ... Please post your Java code. I might want to add it to the OOHaskell demo suite. Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Thomas Sutton > Sent: Thursday, June 23, 2005 3:27 AM > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] Re: Using type classes for polymorphism of > dataconstructors > > On 11/06/2005, at 11:18 PM, Thomas Sutton wrote: > > In Java (C#, Python, etc) I'd do this by writing an interface > > Formula and have a bunch of abstract classes (PropositionalFormula, > > ModalFormula, PredicateFormula, etc) implement this interface, then > > extend them into the connective classes Conjunction, Disjunction, > > etc. The constructors for these connective classes would take a > > number of Formula values (as appropriate for their arity). > > > > I've tried to implement this sort of polymorphism in Haskell using > > a type class, but I have not been able to get it to work and have > > begun to work on implementing this "composition" of logics in the > > DSL compiler, rather than the generated Haskell code. As solutions > > go, this is far from optimal. > > > > Can anyone set me on the right path to getting this type of > > polymorphism working in Haskell? Ought I be looking at dependant > > types? > > I've finally managed to find a way to get this to work using > existentially quantified type variables and am posting it here for > the benefit of the archives (and those novices like myself who will > look to them in the future). My solution looks something like the > following: > > A type class over which the constructors ought to be polymorphic: > > > class (Show f) => Formula f where > > language :: f -> String > > A type exhibiting such polymorphism: > > > data PC > > = Prop String > > | forall a. (Formula a) => Neg a > > | forall a b. (Formula a, Formula b) => Conj a b > > | forall a b. (Formula a, Formula b) => Disj a b > > | forall a b. (Formula a, Formula b) => Impl a b > > instance Formula PC where > > language _ = "Propositional Calculus" > > instance Show PC where > > show (Prop s) = s > > show (Neg s) = "~" ++ (show s) > > show (Conj a b) = (show a) ++ " /\\ " ++ (show b) > > show (Disj a b) = (show a) ++ " \\/ " ++ (show b) > > show (Impl a b) = (show a) ++ " -> " ++ (show b) > > Another such type: > > > data Modal > > = forall a. (Formula a) => Poss a > > | forall b. (Formula b) => Necc b > > instance Formula Modal where > > language _ = "Modal Logic" > > instance Show Modal where > > show (Poss a) = "<>" ++ (show a) > > show (Necc a) = "[]" ++ (show a) > > Some example values of those types: > > Main> :t (Prop "p") -- "p" > Prop "p" :: PC > > Main> :t (Poss (Prop "p")) -- "<>p" > Poss (Prop "p") :: Modal > > Main> :t (Impl (Prop "p") (Poss (Prop "p"))) -- "p -> <>p" > Impl (Prop "p") (Poss (Prop "p")) :: PC > > I also have a sneaking suspicion I'd also be able to solve this > problem using dependant types, but I have not investigated that > approach. > > Cheers, > Thomas Sutton > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Using type classes for polymorphism of data constructors
by Thomas Sutton 23 Jun '05

23 Jun '05

Hi all, I've just started working on a theorem prover (labelled tableaux in case anyone cares) in Haskell. In preparation, I've been attempting to define some data types to represent logical formulae. As one of the requirements of my project is generality (i.e. it must be easily extendible to support additional logics), I've been attempting to build these data types modularly. The end goal in all of this is that the user (perhaps a logician rather than a computer scientist) will describe the calculus they wish to use in a simple DSL. This DSL will then be translated into Haskell and linked against some infrastructure implementing general tableaux bits and pieces. These logic implementations ought to be composable such that we can define modal logic to be propositional calculus with the addition of [] and <>. In Java (C#, Python, etc) I'd do this by writing an interface Formula and have a bunch of abstract classes (PropositionalFormula, ModalFormula, PredicateFormula, etc) implement this interface, then extend them into the connective classes Conjunction, Disjunction, etc. The constructors for these connective classes would take a number of Formula values (as appropriate for their arity). I've tried to implement this sort of polymorphism in Haskell using a type class, but I have not been able to get it to work and have begun to work on implementing this "composition" of logics in the DSL compiler, rather than the generated Haskell code. As solutions go, this is far from optimal. Can anyone set me on the right path to getting this type of polymorphism working in Haskell? Ought I be looking at dependant types? Thanks in advance, Thomas Sutton

2 3

Compiling ghc with openal
by Ron 22 Jun '05

22 Jun '05

Hi, I am configuring ghc from source(no Ports(since that is broken for this purpose too)) on freebsd 5.4: CPPFLAGS="-I/usr/X11R6/include/ -I/usr/local/include/ -L/usr/local/lib/ " ./configure I had issues with opengl, which were resolved by adding the first dir to CPPFLAGS, but it seems impossible to get ghc to recongize OpenAL, while I have it in /usr/local/lib libogg.a libogg.so libopenal.a libopenal.so.0 liborbit-c-backend.a libogg.la libogg.so.5 libopenal.so libopenal.so.0.0.8 In /usr/local/include/AL, I have al.h alc.h alctypes.h alext.h alexttypes.h altypes.h alut.h aluttypes.h I get this: checking for library containing alGenSources... no configure: WARNING: no OpenAL library found, so this package will not be built So, basically the question is: how do I tell ghc to "find" OpenAL? Regards, Ron

1 0

Buddha and GHC 6.4
by Jim Apple 21 Jun '05

21 Jun '05

Has anyone gotten Buddha (now called "plargleflarp" http://www.cs.mu.oz.au/~bjpop/buddha/) do work with GHC 6.4? I'm getting ghc-6.4: unknown package: buddha Jim P.S. What happened to the old name?

4 6

Announcing cross-platform implementation of Pan
by Sean Seefried 19 Jun '05

19 Jun '05

Hi all, I'd like to announce a new cross-platform implementation of Conal Elliott's image synthesis language - Pan. For more information see: http://www.cse.unsw.edu.au/~sseefried/pan/ This is very much an alpha release of the software. I have only built and tested it on Mac OS X and Linux, although it has been tested on Windows by another. Features: * Uses Don Stewart's hs-plugins library to dynamically load and display effects. * Cross-platform. Uses Daan Leijen's wxHaskell and Sven Panne's HOpenGL libraries. * Uses the Haskell Cabal libraries. Builds with version released in GHC 6.4. Drawbacks: * Not as fully featured as the original. * Not as fast. Implemented directly in Haskell instead of generating C code. Sean

1 0

Functional Programming lecture on video
by Carsten Otto 17 Jun '05

17 Jun '05

Hello! I am student at the RWTH Aachen (Germany) and this semester professor Giesl is lecturing "Functional Programming". In the first part of this lecture Haskell is presented and all basic concepts are explained (recursion, pattern matching, lambda expressions, user declared data types, ...). Later in this lecture the theoretical background is the main topic (semantics, lambda calculus, ...). If you are interested, you can watch this lecture on video: http://video.s-inf.de/#FP.2005-SS-Giesl.(COt).HD_Videoaufzeichnung The lecture of course is being held in English. The video is encoded with XviD 1250 KBit and 64 KBit Mono-MP3. The download-server is connected with about 100 MBit, so your download should be quite fast. Have fun, -- Carsten Otto carsten.otto(a)gmail.com www.c-otto.de

1 0

Hugs parse error in library file
by james pentland 16 Jun '05

16 Jun '05

i am working on ch 15, School of Expression. unfortunately, import Memo causes an Hugs error (see below). also, memoB in ch 15 calls memo1, but there is no memo1 in h:\Program Files\Hugs98\libraries\Hugs\Memo.hs this module contains memoN :: Int -> (a -> b) -> (a -> b) memoN = mkMemo eql hash of course, it should be easy enough to write memo1 :: (a -> b) -> (a -> b) memo1 = memoN 1 Memo.hs imports ST, which is where Hugs reports a parse error. h:\Program Files\Hugs98\libraries\Hugs\ST.hs contains at line 50 newtype ST s a = ST (forall r. (a -> r) -> r) what is the workaround? pentland@thetis /ntd/lo $ hugs Hugs session for: H:\Program Files\Hugs98\libraries\Hugs\Prelude.hs H:\Program Files\Hugs98\libraries\Prelude.hs H:\Program Files\Hugs98\libraries\Hugs\Base.hs Type :? for help Hugs.Base> :v -- Hugs Version 20050113 Hugs.Base> :load xva ERROR "H:\Program Files\Hugs98\libraries\Hugs\ST.hs":50 - Syntax error in type expression (unexpected `.') Animation> pentland@thetis /ntd/lo $ cat xva.hs import Animation (picToGraphic) import Shape import Picture import Memo import SOEGraphics hiding (Region, Event) import qualified SOEGraphics as G (Region, Event) import Draw (xWin,yWin,intToFloat) import Win32Misc (timeGetTime) -- import Word (word32ToInt) import Channel type Time = Float type UserAction = G.Event newtype Behavior a = Behavior (([Maybe UserAction],[Time]) -> [a]) newtype Event a = Event (([Maybe UserAction],[Time]) -> [Maybe a]) time :: Behavior Time time = Behavior (\(_,ts) -> ts) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

(small) code review request
by Radu Grigore 16 Jun '05

16 Jun '05

The programming language I know best is C++. Wait, don't close the message. I also know OCaml and a couple of days ago I read "A Gentle Introduction to Haskell". In order to practice what I've learned a bit above "hello world" programs I chose to solve some easy tasks from SPOJ. They have automatic testing so I know if I got it right or not and I can also look at submission statistics (number and accuracy) to choose easy problems. Aside from "easiness" I've chosen at random these: https://spoj.sphere.pl/problems/ADDREV/ https://spoj.sphere.pl/problems/CRSCNTRY/ So these are my first two Haskell "programs" and I'd appreciate any comments you might have, especially better ways of solving the problems. The first one asks you to print rev(rev a + rev b) for two numbers a and b where rev is a function that transforms an integer into an integer you get by reversing the digits. --- BEGIN addrev.hs --- rev :: Int -> Int rev = read . reverse . show solve :: Int -> IO () solve 0 = do return () solve n = do line <- getLine let a:b:_ = words line an = read a bn = read b in (putStrLn . show . rev) (rev an + rev bn) solve (n-1) main = do hSetBuffering stdin LineBuffering line <- getLine solve (read line) --- END addrev.hs --- The second problem happens to be the Longest Common Subsequence problem, which is a classical DP problem. After searching a bit how to do memoisation/dp in Haskell I've found two resources: http://www.haskell.org/hawiki/MemoisingCafs http://portal.acm.org/citation.cfm?id=871896&coll=Portal&dl=ACM&CFID=461433… I chose to try the approach in the Bird&Hinze article. The result is my second Haskell program: --- BEGIN crscntry.lhs --- One of the problems at SPOJ, namely CRSCNTRY, asks you to implement the classical (DP) algorithm for finding the length of the longest common subsequence. The reccurence relation is: lcs [] _ = 0 lcs _ [] = 0 lcs (x:xs) (y:ys) = | x == y = 1 + lcs xs ys | otherwise = lcs (x:xs) ys `max` lcs xs (y:ys) There are of course only mn distinct calls to lcs, where m = 1 + length xs, n = 1 + length ys. I will try here a memoisation approach about which I have read in "Trouble shared is trouble halved", by Bird and Hinze. The basic idea is to explicitly construct the call tree and store in it the result of computing the function. First, note that the reccurence relation above makes either one or two calls. I think we can get by with a binary tree that has this invariant: left . right n = right . left n Let's define the tree. > data Tree a = Empty | Node { left :: Tree a, info :: a, right :: Tree a } > leaf :: a -> Tree a > leaf x = Node Empty x Empty Now imagine the tree nodes put into a matrix l l x <--- x <--- x ^ ^ ^ |r l |r l |r x <--- x <--- x We use two memoisation functions. One of them constructs all the rows above (memo_lcs), while the other reuses the nodes above and constructs only one row to the left (memo_lcs'). We also pass around the lists so that we can constructs nodes correctly. > memo_lcs :: Eq a => [a] -> [a] -> Tree Integer > memo_lcs [] _ = Empty > memo_lcs _ [] = Empty > memo_lcs (x:xs) (y:ys) = > node x y (memo_lcs' t xs (y:ys)) t > where t = memo_lcs (x:xs) ys > memo_lcs' :: Eq a => Tree Integer -> [a] -> [a] -> Tree Integer > memo_lcs' _ [] _ = Empty > memo_lcs' _ _ [] = Empty > memo_lcs' z (x:xs) (y:ys) = > node x y (memo_lcs' l xs (y:ys)) l > where l = tree_left z Both of these functions use a smart constructor. It takes the left and right branches and constructs a new node while also computing the correct value the function must have. > node :: Eq a => a -> a -> Tree Integer -> Tree Integer -> Tree Integer > node x y l r > | x == y = Node l (1 + (value . tree_left) r) r > | otherwise = Node l (value l `max` value r) r The inspection of the value returns 0 for empty nodes. > value :: Tree Integer -> Integer > value Empty = 0 > value (Node _ r _) = r You might be wondering by now what is the function tree_left. > tree_left :: Tree a -> Tree a > tree_left Empty = Empty > tree_left (Node l _ _) = l (I wonder if all this would be simpler if I'd use a border of 0-valued leafs instead of the functions tree_left and value. I'll try soon.) Now the definition of lcs is simple. > lcs :: Eq a => [a] -> [a] -> Integer > lcs x y = value (memo_lcs x y) This is the basic solution of the problem CRSCNTRY. A testcase is just a bit more complicated. > testcase :: [[Integer]] -> Integer > testcase (x:xs) = foldl max 0 (map (lcs x) xs) In order to finish we just need to take care of the IO. > myReadList :: String -> [Integer] > myReadList s = > let (a, t) = head (lex s) in > case read a of > 0 -> [] > n -> n : (myReadList t) > readTest :: IO [[Integer]] > readTest = do > line <- getLine > case myReadList line of > [] -> do return [] > lst -> do > rest <- readTest > return (lst : rest) The solve function reads n tests and solves each of them. > solve :: Integer -> IO () > solve 0 = return () > solve (n+1) = do > test <- readTest > putStrLn (show (testcase test)) > solve n In the main function we read the number of tests we should handle and then solve them > main = do > line <- getLine > solve (read line) That's it. I hope it works (fast enough). --- END crscntry.lhs --- It worked fast enough. Anyway, I was wondering if the O(n) space and O(n^2) time solution can be implemented in Haskell. Another way to ask this. Consider the classic fibonacci example. Can one compute the n-th fibonacci number in O(n) time and O(1) space, i.e. remember only the "last" two values during computation? -- regards, radu http://rgrig.blogspot.com/

2 3

RE: [Haskell-cafe] Garbage collection and finalizer thread priority
by Simon Marlow 16 Jun '05

16 Jun '05

On 13 June 2005 14:32, Gracjan Polak wrote: > Simon Marlow wrote: >> >> I presume you're running GHC. There's no way to increase the >> priority of a thread - GHC's scheduler doesn't have a concept of >> priorities. >> > > Yes, I forgot to state it explicitly. > >> I would look into whether you can use mallocForeignPtr: this is much >> faster than using newForeignPtr with finalizerFree, because the >> memory is garbage collected directly and there's no need for a >> finalizer. > > I use mallocBytes + reallocBytes + addForeignPtrFinalizer > finalizerFree. I wouldn't think this is any different, thanks for > your suggestion. > > May I ask where that difference comes from? mallocBytes allocates memory using C's malloc(), which is expensive. Also, the finalizer to free the memory is also expensive. mallocForeignPtr on the other hand allocates memory directly in GHC's heap (much faster than malloc()), and the memory is garbage collected when it is no longer referenced, so there's no need for the finalizer. Still, ForeignPtr is quite a bit slower than Ptr. We have some ideas for improving it, which I'll hopefully get round to implementing sometime. Cheers, Simon

1 0