August 2005 - Haskell-Cafe

Creating a Haskell section in Autoconf Macro Archive
by Peter Simons 12 Aug '05

12 Aug '05

Fellow Haskell'ers, I've been maintaining the site <http://autoconf-archive.cryp.to/> for a while now, and I can't help but notice that there is no Haskell section. I know that GHC comes with a lot of useful Haskell-related Autoconf macros, so does Darcs, and so do a lot of other projects too. Thus, I was wondering whether the respective macro authors would be willing to submit their macros to the archive for distribution, so that other software developers around the world can find them, and re-use them. To have a macro added to the archive, all you need to do is to e-mail it to me in the proper mark-up format, so that the software which generates the archive can extract the necessary meta information and documentation. I'll use one of David Roundy's macros as an example to show what that looks like. Hope you don't mind, David. ;-) Here it is: | dnl @synopsis AX_TRY_COMPILE_GHC(PROGRAM, [ACTION-IF-TRUE], [ACTION-IF-FALSE]) | dnl | dnl AX_TRY_COMPILE_GHC tries to compile and link the given | dnl program using $GHC for the compiler, and $GHCFLAGS as | dnl flags passed to the compiler. | dnl | dnl @category Haskell | dnl @author David Roundy <droundy(a)abridgegame.org> | dnl @version 2005-08-12 | dnl @license AllPermissive | | AC_DEFUN([AX_TRY_COMPILE_GHC],[ | cat << \EOF > conftest.hs | -- [#]line __oline__ "configure" | [$1] | EOF | rm -f Main.hi Main.o | if AC_TRY_COMMAND($GHC $GHCFLAGS -o conftest conftest.hs) && test -s conftest | then | dnl Don't remove the temporary files here, so they can be examined. | ifelse([$2], , :, [$2]) | else | echo "configure: failed program was:" >&AC_FD_CC | cat conftest.hs >&AC_FD_CC | echo "end of failed program." >&AC_FD_CC | ifelse([$3], , , [ rm -f Main.hi Main.o | $3 | ])dnl | fi]) One of the more interesting keywords is @license, obviously. The license recommended by the Free Software Foundation for Autoconf macros is the all-permissive license, which reads like this: | Copying and distribution of this file, with or without | modification, are permitted in any medium without royalty | provided the copyright notice and this notice are preserved. Other valid choices are "GPL2", "GPLWithACException", and "BSD". A more thorough description of the keywords is available on the archive's homepage. Peter

2 2

Re: [Haskell] pros and cons of static typing and side effects ?
by Bernard Pope 12 Aug '05

12 Aug '05

[Moved to the Haskell cafe] It's Friday afternoon here so I thought I'd join in the fun. On Thu, 2005-08-11 at 23:01 -0400, ajb(a)spamcop.net wrote: > While you can't be certain that once your code typechecks, it's bug-free > (though that does often happen), you can be almost guaranteed that if > your code typechecks after a refactoring, the refactoring didn't > introduce any bugs. (I tend to agree with ajb's sentiment, but I'll play the devil's advocate anyway). Perhaps we can reach a fixed point of violent agreement? I'm a bit concerned with "can't be certain" on the one hand, and "_almost_ guaranteed", on the other. I guess there are nuances to be explored here, and it is all about degree of confidence. Sometimes I have high confidence in my refactoring, like introducing a state monad. Other times I have much less confidence, like swapping the order of arguments in numerical calculations. However, if it weren't for static type checking then I would be much less game to even _try_ introducing a state monad in my code in the first place. (Maybe that's just me). Another colleague of mine gave the opinion that one of the reasons higher-order code is less common in Prolog than Haskell is that in Prolog does not have static type checking (it's just one factor out of many). It seems to me like static type checking has the capacity to make some refactorings much less heroic than they would be in the non-static setting. That's my "log on the fire" for today. Bernie.

1 0

Re: [Haskell-cafe] Creating a Haskell app to do crosstabs
by Andy Elvey 11 Aug '05

11 Aug '05

Greg Buchholz wrote: >Andy Elvey wrote: > > >>a) Using Haskell to read a delimited file (with column-headings) into a >>columnar or tabular data-structure - >> >> >> Parsec (http://www.cs.uu.nl/~daan/parsec.html) is a great parsing >>library in Haskell. >> >> >>Greg Buchholz >> >> >> Hi Greg - thanks very much for this! I'll check Parsec out - thanks for the link - - Andy

1 0

Creating a Haskell app to do crosstabs
by Andy Elvey 11 Aug '05

11 Aug '05

Hi everyone - I'm a relative newcomer to Haskell, and am very much besotted with it - it's a great language! :-) At the moment, I'm in the early stages of putting together a little "Haskell-like" language using the Spirit parser framework (Spirit is part of the Boost C++ libraries). Spirit also has a functional-programming "sister" library (Phoenix), which includes lambdas, lazy functions and lots more. Phoenix is currently being merged with the Boost Lambda Library. ( Sorry for the off-topic digression - just giving the background to what I'm doing .... ;-) ) I've done a couple of "toy parsers" for Spirit already, but now I'm looking to do something that is more of a challenge - doing a small-ish Haskell-like language. The language is aimed at being able to read in a comma-delimited file (with column-headings), and putting the data into "columns". ( I envisage maybe a Haskell "pair". The first item being the column heading, the second being a list, with the data in it. ) Then, the user would select one of those "columns" for a "page" variable (that one would be optional), and one or more "columns" for the crosstab rows and columns. What I'm needing to do is to first put together the code in Haskell itself, and get it running. Then, that will give me a good feel as to how much of "core" Haskell I need to implement, in order to do the crosstab app. So, I was wondering - has anyone in the Haskell community used Haskell to do crosstabs? ( And if so, is there any code available? ). Any help in the two areas - a) Using Haskell to read a delimited file (with column-headings) into a columnar or tabular data-structure - b) Using Haskell to do crosstabs - - would be very welcome! I should also stress that full credit will be given to the writers of any code supplied. Very many thanks in advance for any help received! - - Andy

3 4

RE: [Haskell-cafe] Functional dependenices in class declarations
by Simon Peyton-Jones 11 Aug '05

11 Aug '05

It's intentional. Consider this data type declaration data B b = MkT (A a b) Should that be accepted? The only thing it could possibly mean would be data B b = MkT (forall a. A a b) and I suppose that might possibly be useful. But in this case you're also saying that "a" determines "b". But you can hardly say *forall* a, if the choice of a determines the (fixed by context) b. These functional dependencies are tricky things. Martin Sulzmann and I wrote a paper about some of the trickiness (http://research.microsoft.com/%7Esimonpj/Papers/fd-chr/index.htm) and we're working on a journal version. My wild guess is that you are trying to convert an O-O idiom into Haskell, and that's led you to a rather strange program. Maybe there's another way to do it. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Frank | Sent: 08 August 2005 18:17 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] Functional dependenices in class declarations | | In ghc 6.4 (fine work - many gratulations to all who did it!) it is | permitted | to have type parameters which are reachable (7.4.3.1 context of type | signatures). | I tried the following: | | module TypeDependencies where | | class A a b | a -> b | | class (A a b) => B b where | op :: a -> a | | x :: A a b => a -> a | x = id | | Which compiles fine for the function x, but does complain | "not in scope: type variable 'a' " for the class (A a b) => B b. | | Is this an intentional restriction that 'reachable' type variables are only | permitted in type definitions, but not in classes? or do I misunderstand | something? | | Any help appreciated! | Andrew Frank | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] Internal error: scavenge_one
by Simon Marlow 09 Aug '05

09 Aug '05

On 08 August 2005 20:22, Dinh Tien Tuan Anh wrote: > i have the following error when running my program: > > <interactive>: internal error: scavenge_one: strange object 47 > > does anyone know what it is ? Yes, it's probably a bug. Please report it to glasgow-haskell-bugs(a)haskell.org, giving your GHC version, platform, the program that produces the bug, and any other relevant options that we need to reproduce it. Cheers, Simon

1 0

RE: [Haskell] unsafePerformIO and optimizations
by Simon Marlow 09 Aug '05

09 Aug '05

On 06 August 2005 15:24, Wolfgang Jeltsch wrote: > First, what is the problem with inlining a function call? Say, I > have a function f defined as follows: > > f :: Char -> () > f c = unsafePerformIO (putChar c) > > If inlining is allowed, the expression f '*' becomes > > unsafePerformIO (putChar '*'). > > Is this a problem? Or is inlining dangerous in other situations? > > On the other hand, I can see that inlining non-functions could cause > harm. Say I have something like this: > > u :: () > u = unsafePerformIO (putChar '*') > > Now, inlining u would transform (u,u) to > > (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) > > which could result in putChar '*' being executed multiple times. So > why does the library documentation only talk about disabling inlining > of functions? Well, you're right - it's all about sharing of redexes of the form (unsafePerformIO e). When you write an unsafePerformIO with a side effect, you probably have an intuition about when you expect that redex to be reduced. In your example above, you're probably thinking "it'll be executed whenever f is called". However, optimisations can invalidate your intuition in many ways, by increasing (or reducing) sharing of the unsafePerformIO redex. Inlining 'f' itself isn't a problem, because that doesn't change sharing, as you pointed out. However, it might expose potential for *reducing* sharing, because (unsafePerformIO (putChar '*')) is now a visibly constant expression, it only needs to be evaluated once per run of the program. > I understand that common subexpression elimination could cause harm. > It could transform the expression > > (unsafePerformIO (putChar '*),unsafePerformIO (putChar '*')) > > to > > let > u = unsafePerformIO (putChar '*') > in > (u,u), > > couldn't it? This would result in the I/O action be performed at > most once which is not what was intended. But couldn't the same > thing also happen if I use the expression (f '*',f '*'), probably in > a different module? Well, quite. > Does this mean that I have to use -fno-cse not > only in the module which contains the unsafePerformIO application but > also in every other module which uses unsafePerformIO indirectly via > f or functions using f? This way leads to madness - GHC's optimisations are simply not designed to provide any kind of guarantee about maintaining sharing properties. The guidelines we've given for unsafePerformIO are enough to cover simple uses like global variables. We should probably amend the documentation to say this. Cheers, Simon

2 1

Functional dependenices in class declarations
by Frank 08 Aug '05

08 Aug '05

In ghc 6.4 (fine work - many gratulations to all who did it!) it is permitted to have type parameters which are reachable (7.4.3.1 context of type signatures). I tried the following: module TypeDependencies where class A a b | a -> b class (A a b) => B b where op :: a -> a x :: A a b => a -> a x = id Which compiles fine for the function x, but does complain "not in scope: type variable 'a' " for the class (A a b) => B b. Is this an intentional restriction that 'reachable' type variables are only permitted in type definitions, but not in classes? or do I misunderstand something? Any help appreciated! Andrew Frank

2 1

RE: [Haskell-cafe] subRegex bug?
by Simon Marlow 04 Aug '05

04 Aug '05

On 11 May 2005 22:22, S. Alexander Jacobson wrote: > Am I misunderstanding the regex docs? > > *MyMod> subRegex (mkRegex "\\." ) "foo.bar" "blah" > "foo*** Exception: Text.Regex.Posix.regcomp: error in pattern Fixed now, thanks. Simon

1 0

RE: [Haskell-cafe] Problem type checking class-method implementation
by Ralf Lammel 03 Aug '05

03 Aug '05

Stefan, the problem can be spotted in the following erased version of your program. data Identity a instance Monad Identity class (Monad m) => IsItem m i where processItem :: i -> m () class (Monad m) => IsProcessor p m | m -> p where process :: (IsItem m i) => i -> m () newtype Item m = Item {processItemImpl :: m ()} newtype ProcessorT p m a = ProcessorT {runProcessorT :: m a} instance (Monad m) => Monad (ProcessorT p m) instance (Monad m) => IsProcessor p (ProcessorT p m) newtype Processor p a = Processor {unwrap :: ProcessorT p Identity a} instance Monad (Processor p) where castItem :: (IsItem (Processor p) i) => i -> Item (ProcessorT p Identity) castItem = undefined instance IsProcessor p (Processor p) where process = Processor . process . castItem Recall the type error: Could not deduce (IsItem (Processor p1) i) from the context (IsProcessor p (Processor p), Monad (Processor p), IsItem (Processor p) i) The problem is basically in here: instance IsProcessor p (Processor p) where process = Processor . process . castItem By specializing function signatures according to the instance head, and by applying type checking constraints for functional composition, we get these types: Processor :: ProcessorT p Identity () -> Processor p () process :: process :: ( IsProcessor p (ProcessorT p Identity) , IsItem (ProcessorT p1 Identity) () ) => Item (ProcessorT p1 Identity) -> ProcessorT p Identity () castItem :: (IsItem (Processor p1) i) => i -> Item (ProcessorT p1 Identity) The problem is the type-scheme polymorphic result type of castItem which is consumed by a type-variable polymorphic but type-class bounded argument type of process. The constraint of this application process, i.e., IsItem (Processor p1) i is the one GHC asks for. (Do the hugs test :-)) Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Stefan Holdermans > Sent: Wednesday, August 03, 2005 1:01 AM > To: haskell-cafe > Subject: [Haskell-cafe] Problem type checking class-method implementation > > Dear Haskellers, > > Yesterday I stumbled upon a problem type checking a program involving > multi-parameter type classes. GHC rejected the program; still, I was > not immediately convinced it contained a type error. Having given it > some more thoughts, I start to suspect that the type checker is in err > and that the program is well-typed after all. But, well, I might be > overlooking something obvious... > > I have reduced my code to a small but hopelessly contrived example > program exposing the problem. Please hang on. > > Because we employ multi-parameter type classes, we need the Glasgow > extensions: > > {-# OPTIONS -fglasgow-exts #-} > > Let's start easy and define the identity monad: > > newtype Identity a = Identity {runIdentity :: a} > > instance Monad Identity where > return = Identity > Identity a >>= f = f a > > Then, let's introduce the foundations for the (contrived) example: > > class (Monad m) => IsItem m i where > processItem :: i -> m () > > class (Monad m) => IsProcessor p m | m -> p where > process :: (IsItem m i) => i -> m () > -- ...some more methods, possibly involving p... > > So, an item is something that can be processed within the context of a > certain monad, and a processor is something that can process an item of > an appropriate type. Note the functional dependency from m to p: a > processor type m uniquely determines the type of the processing context > p. > > Before we move on, consider this canonical item type, which is just a > one-field record representing an implementation of the IsItem class: > > newtype Item m = Item {processItemImpl :: m ()} > > The corresponding instance declaration is obvious: > > instance (Monad m) => IsItem m (Item m) where > processItem = processItemImpl > > Furthermore values of every type that is an instance of IsItem can be > converted to corresponding Item values: > > toItem :: (IsItem m i) => i -> Item m > toItem = Item . processItem > > Please stick with me, for we are now going to implement a monad > transformer for processors (which, for this example, is really just the > identity monad transformer): > > newtype ProcessorT p m a = ProcessorT {runProcessorT :: m a} > > instance (Monad m) => Monad (ProcessorT p m) where > return = ProcessorT . return > ProcessorT m >>= f = ProcessorT (m >>= runProcessorT . f) > > instance (Monad m) => IsProcessor p (ProcessorT p m) where > process = processItem > > Then, finally, we use this transformer to derive a processor monad: > > newtype Processor p a = Processor {unwrap :: ProcessorT p Identity a} > > runProcessor :: Processor p a -> a > runProcessor = runIdentity . runProcessorT . unwrap > > So, we just make sure that Processor is a monad: > > instance Monad (Processor p) where > return = Processor . return > Processor m >>= f = Processor (m >>= unwrap . f) > > Now all what is left to do is declare Processor an instance of > IsProcessor. To this end, we need to be able to cast items for > Processor p to items for ProcessorT p Identity (for all p). The > following function takes care of that: > > castItem :: (IsItem (Processor p) i) => i -> Item (ProcessorT p > Identity) > castItem = Item . unwrap . processItem > > Note that up 'til now everything is fine: GHC is happy, I am happy. But > then, > when all the hard work is done, and we just only have to connect things > properly, it just breaks: > > instance IsProcessor p (Processor p) where > process = Processor . process . castItem > > After adding this last instance declaration, GHC happily reports: > > Processor.hs:56:24: > Could not deduce (IsItem (ProcessorT p Identity) > (Item (ProcessorT p1 Identity))) > from the context (IsProcessor p (Processor p), > Monad (Processor p), > IsItem (Processor p) i) > arising from use of `process' at Processor.hs:56:24-30 > Probable fix: > add (IsItem (ProcessorT p Identity) (Item (ProcessorT p1 > Identity))) > to the class or instance method `process' > or add an instance declaration for > (IsItem (ProcessorT p Identity) > (Item (ProcessorT p1 Identity))) > In the first argument of `(.)', namely `process' > In the second argument of `(.)', namely `process . castItem' > In the definition of `process': process = Processor . (process . > castItem) > > Processor.hs:56:34: > Could not deduce (IsItem (Processor p1) i) > from the context (IsProcessor p (Processor p), > Monad (Processor p), > IsItem (Processor p) i) > arising from use of `castItem' at Processor.hs:56:34-41 > Probable fix: > add (IsItem (Processor p1) i) to the class or instance method > `process' > or add an instance declaration for (IsItem (Processor p1) i) > In the second argument of `(.)', namely `castItem' > In the second argument of `(.)', namely `process . castItem' > In the definition of `process': process = Processor . (process . > castItem) > > It seems to me that the type checker fails to unify p and p1 where it > really should. But once again: I may be wrong here. So, could you > either explain to me what I'm missing here and why this program is > indeed ill-typed, or confirm that it's really just GHC that should be > accepting this program. > > I have attached a file Processor.hs containing the example program.

2 1