[GHC] #1287: SPECIALIZE causes panic
#1287: SPECIALIZE causes panic
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler | Version: 6.6
Severity: normal|Keywords: panic, SPECIALIZE
Difficulty: Unknown |Testcase:
Architecture: Unknown | Os: Unknown
-+--
the following code snippet makes GHC (6.6) panic:
{{{
delta' :: Eq a = a - a - b - b - b
delta' x y e f = if (x==y) then f else e
{-# SPECIALIZE delta' :: Num b = Int - Int - b - b - b #-}
delta :: (Eq a, Num b) = a - a - b
delta x y = delta' x y 0 1
{-# SPECIALIZE delta :: Num b = Int - Int - b #-}
}}}
the reply from GHC:
{{{
ghc-6.6: panic! (the 'impossible' happened)
(GHC version 6.6 for i386-apple-darwin):
Template variable unbound in rewrite rule $dNum{v a1bL} [lid]
}}}
it does not panic without the SPECIALIZE pragmas.
the version used is GHC 6.6, i386-apple-darwin.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1287
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1282: stg_uncheckedShift* not found: regression from ghc-6.6 to ghc-6.6.1 RC 6.6.20070415 (?)
#1282: stg_uncheckedShift* not found: regression from ghc-6.6 to ghc-6.6.1 RC 6.6.20070415 (?) --+- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: powerpc Os: Linux | --+- Comment (by Isaac Dupree): Problem also reproducible with 6.7.20070418 for me. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1282 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1282: stg_uncheckedShift* not found: regression from ghc-6.6 to ghc-6.6.1 RC 6.6.20070415 (?)
#1282: stg_uncheckedShift* not found: regression from ghc-6.6 to ghc-6.6.1 RC 6.6.20070415 (?) --+- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Architecture: powerpc Os: Linux | --+- Comment (by Isaac Dupree): Okay, looking at different versions of the GHC source-code, it looks like the problem is that the stg_* functions have been renamed hs_* (e.g. see foreign imports in libraries/base/GHC/Word.hs, or libraries/base/include/HsBase.h and libraries/base/cbits/longlong.c), and so the binary library is trying to import uncheckedShiftL64 and uncheckedShiftRL64 using the C-names that are used in any so-far-released version of GHC, that start with stg_. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1282 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Release naming - e.g. 6.8 vs. 6.8.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've gotten confused before between whether GHC 6.6 referred to the whole branch or the point release between 6.4.2 and 6.6.1. It makes it hard to distinguish which is being referred to (although, it also makes it easy to be vague when referring to an upcoming major release, which might be considered an advantage I suppose). I propose we switch to that X.Y.0-style major release naming as of 6.8.0 (a.k.a. 6.8). Comments or opinions? Isaac (P.S. GCC's having made this naming change inspired me to suggest this, but I don't actually know what their reasons were) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKOrZHgcxvIWYTTURAtykAJ4s/cSgmcHtGspk1LvNApq+N2SjQQCdFAqH UsNQIR2CXZ6en74MFwNi0HM= =ynkD -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc6.6 on ps3 - compile error in StgCRun
Hi, I'm trying to build ghc-6.6 on a sony ps3, but have hit a problem: == make all -r; in /home/tora/ghc/ghc-6.6/rts ../compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP -optc-fno-strict-aliasing -H16m -O -optc-O2 -optc-DNOSMP -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o /tmp/ghc12557_0/ghc12557_0.s: Assembler messages: /tmp/ghc12557_0/ghc12557_0.s:12:0: Error: junk at end of line, first unrecognized character is `@' /tmp/ghc12557_0/ghc12557_0.s:16:0: Error: junk at end of line, first unrecognized character is `@' make[1]: *** [StgCRun.o] Error 1 make: *** [stage1] Error 1 The ps3 is running YDL, and to bootstrap the ghc build I managed to install a powerpc ghc6.6 on the system (downloaded a deb from http://packages.debian.org/cgi-bin/download.pl?arch=powerpcfile=pool%2Fmain%2Fg%2Fghc6%2Fghc6_6.6-3_powerpc.debmd5sum=f8f23c269deeb0e6a513f8b5bb94801darch=powerpctype=main then alien'ed it to get an rpm which seems to work - though ghci is non-functioning) The sources I'm trying to build are the standard ghc http://www.haskell.org/ghc/dist/6.6/ghc-6.6-src.tar.bz2 (and extralibs) uname -a Linux ebony 2.6.16-20061110.ydl.2ps3 #1 SMP Tue Dec 5 12:35:42 EST 2006 ppc64 ppc64 ppc64 GNU/Linux Any tips / pointers / advice greatfully recieved; TIA, Tristan Allwood ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc6.6 on ps3 - compile error in StgCRun
Hi, Some more information that may be useful: (ghc -v compilation and gcc -v) Cheers, Tristan Allwood 17:54:26 - [EMAIL PROTECTED]:~/ghc/ghc-6.6/rts ../compiler/ghc-inplace -v -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-DNOSMP -optc-fno-strict-aliasing -H16m -O -optc-O2 -optc-DNOSMP -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: /home/tora/ghc/ghc-6.6/driver/package.conf.inplace wired-in package base not found. wired-in package rts mapped to rts-1.0 wired-in package haskell98 not found. wired-in package template-haskell not found. Hsc static flags: -static -static Created temporary directory: /tmp/ghc14351_0 *** C Compiler: gcc -x c StgCRun.c -o /tmp/ghc14351_0/ghc14351_0.s -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=606 -O -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Waggregate-return -Wbad-function-cast -I../includes -I. -Iparallel -DCOMPILING_RTS -fomit-frame-pointer -DNOSMP -fno-strict-aliasing -O2 -DNOSMP -I . -I /home/tora/ghc/ghc-6.6/includes Using built-in specs. Target: ppc64-yellowdog-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-secureplt --with-long-double-128 --host=ppc64-yellowdog-linux --build=ppc64-yellowdog-linux --target=ppc64-yellowdog-linux --with-cpu=default32 Thread model: posix gcc version 4.1.1 20060525 (Yellow Dog 4.1.1-1) /usr/libexec/gcc/ppc64-yellowdog-linux/4.1.1/cc1 -quiet -v -I../includes -I. -Iparallel -I . -I /home/tora/ghc/ghc-6.6/includes -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -D__GLASGOW_HASKELL__=606 -DCOMPILING_RTS -DNOSMP -DNOSMP StgCRun.c -msecure-plt -quiet -dumpbase StgCRun.c -auxbase-strip /tmp/ghc14351_0/ghc14351_0.s -O -O -O2 -Wimplicit -Wall -W -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Waggregate-return -Wbad-function-cast -version -fomit-frame-pointer -fno-strict-aliasing -o /tmp/ghc14351_0/ghc14351_0.s ignoring nonexistent directory /usr/lib/gcc/ppc64-yellowdog-linux/4.1.1/../../../../ppc64-yellowdog-linux/include ignoring duplicate directory . ignoring duplicate directory /home/tora/ghc/ghc-6.6/includes #include ... search starts here: #include ... search starts here: ../includes . parallel /usr/local/include /usr/lib/gcc/ppc64-yellowdog-linux/4.1.1/include /usr/include End of search list. GNU C version 4.1.1 20060525 (Yellow Dog 4.1.1-1) (ppc64-yellowdog-linux) compiled by GNU C version 4.1.1 20060525 (Yellow Dog 4.1.1-1). GGC heuristics: --param ggc-min-expand=43 --param ggc-min-heapsize=25193 Compiler executable checksum: bc16e0fa6c53100b191b9cb78b3c673d *** Assembler: gcc -I. -c /tmp/ghc14351_0/ghc14351_0.s -o StgCRun.o /tmp/ghc14351_0/ghc14351_0.s: Assembler messages: /tmp/ghc14351_0/ghc14351_0.s:12:0: Error: junk at end of line, first unrecognized character is `@' /tmp/ghc14351_0/ghc14351_0.s:16:0: Error: junk at end of line, first unrecognized character is `@' *** Deleting temp files: Deleting: /tmp/ghc14351_0/ghc14351_0.s *** Deleting temp dirs: Deleting: /tmp/ghc14351_0 17:54:59 - [EMAIL PROTECTED]:~/ghc/ghc-6.6/rts gcc -v Using built-in specs. Target: ppc64-yellowdog-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-secureplt --with-long-double-128 --host=ppc64-yellowdog-linux --build=ppc64-yellowdog-linux --target=ppc64-yellowdog-linux --with-cpu=default32 Thread model: posix gcc version 4.1.1 20060525 (Yellow Dog 4.1.1-1) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Vacancy for a PhD student
(Knowledge of Haskell is a big plus; implementation of most of the tools will be done in Haskell.) Vacancy: PhD student in the Strategy Feedback project 1+3 years, Open University the Netherlands, location: Heerlen (preference). The project: In many subjects students have to acquire procedural skills. Problems in mathematics are often solved using a standard procedure, such as for example solving a system of linear equations by subtracting equations from top to bottom, and then substituting variables from bottom to top. Problems in computer science, physics, chemistry, electrotechnics, and other subjects, often require procedural skills as well. Furthermore, procedural skills appear at any educational level. E-learning systems offer excellent possibilities for practicing procedural skills. The first explanations and motivation for a procedure that solves a particular kind of problems are probably best taught in a class room, or studied in a book, but the subsequent practice can often be done behind a computer. There exist many e-learning systems or intelligent tutoring systems that support practicing procedural skills. The tools vary widely in breadth, depth, user-interface, etc, but, unfortunately, almost all of them lack sophisticated techniques for providing immediate feedback. If feedback mechanisms are present, they are hard coded in the tools, often even with the exercises. This situation hampers the usage of e-learning systems for practicing procedural skills. This project aims to investigate techniques for providing flexible and immediate feedback in tools that support practicing procedural skills. We want to use advanced techniques from computer science, taken from fields such as term rewriting, strategies, error-correcting parsers, and generic programming to provide feedback at each intermediate step from the start towards the solution of an exercise. We want to further develop some of these techniques, and apply and experiment with them in the domain of e-learning systems. Our goal is to obtain e-learning systems that give immediate and useful feedback. We will cooperate on this project with the Software Technology group from Utrecht University. Requirements: University degree in Computer Science. Good knowledge of functional programming, and several advanced computer science techniques. Knowledge of parsing, rewriting, strategies, generic programming, etc. will be useful. More information about the project can be found on http://ideas.cs.uu.nl/wiki/index.php/IDEAS:StrategicFeedback or contact Johan Jeuring ([EMAIL PROTECTED], +31 6 40010053). To apply: send a letter and your curriculum vitae before May 5, 2007 to: Open Universiteit Nederland, afdeling Personele ondersteuning, Postbus 2960, 6401 DL Heerlen. U kunt ook or an e-mail to: [EMAIL PROTECTED] Mention vacancynr FAC/INF/07024 In both cases, please cc Johan Jeuring ([EMAIL PROTECTED]). ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] anyone interested in developing a Language.C library?
Hi all, If anyone is interested in developing a Language.C library, I've just completed a full C parser which we're using in c2hs. It covers all of C99 and all of the GNU C extensions that I have found used in practise, including the __attribute__ annotations. It can successfully parse the whole Linux kernel and all of the C files in all the system packages on my Gentoo installation. It's implemented as an alex lexer and a happy parser. The happy grammar has one shift/reduce conflict for the dangling if/then/else issue (which could be hidden by using precedence but it's clearer not to). So if someone is interested in developing a more widely usable Language.C library, I think this would be a good place to start. There's plenty to do however: * The c2hs C AST is ok but probably not enough for a general purpose library. * The parser currently uses some other c2hs infrastructure which would need disentangling to pull the parser out (mostly identifiers and unique name supply management). * It does not record everything into the parse tree, eg __attribute__s are parsed but ignored. * It does no semantic analysis after parsing (though other bits of c2hs to a very little) * In at least one place the parser is deliberately too liberal (to avoid ambiguities) which would require simple extra checks after parsing to detect. * The lexical syntax has not been checked against the spec fully, it is probably over-liberal in some cases. * I've not done much performance work, the lexer has not been seriously tuned, it still lexes via a String. Having said that, the performance is not at all bad, on a 3Ghz box it does ~20k lines/sec. * The parser error messages are terrible (it might be interesting to try porting from happy to frown for this purpose) There's probably more stuff, but that's what I can think of right now. So if anyone is interested then let me know, I can give some pointers (hopefully the useful kind, not the void * kind). You can get the code from the c2hs darcs repo: darcs get --partial http://darcs.haskell.org/c2hs/ The C parser bits are under c2hs/c/ Duncan Licensing: It's not 100% clear. At the moment it's marked as GPL, but it's derived from several sources so we need to be careful about that. Personally I'm happy to use LGPL. It derives from c2hs obviously, which is GPL, though we could enquire about re-licencing, especially since there is very little of c2hs stuff used in it any more. It also derives partly from James A. Roskind's C grammar (in particular the grammar of declarations). His copyright license is fairly liberal but this need double-checking. It also derives from the C99 spec and I read the comments in the gcc C parser as a guide to GNU C's extensions to the C grammar (no code or comments were copied however). Testing: I tested it thus far by writing a little gcc wrapper script, so you can build any ordinary bit of C software using this wrapper and it'll call gcc with the same args but it'll also try and parse the input file. It reports into a log file. I've not tried the gcc C parser testsuite. This approach is probably good for other tests like trying to see if parsing and pretty printing can round-trip correctly; if not identical token streams (since parsing drops redundant brackets etc) checking if gcc produces identical .S/.o files. Something that c2hs needs is to calculate sizes of types and structure member offsets correctly. This is also something that could be tested in this style, by comparing on thousands of example .c files with what gcc thinks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haskell question
Greg Meredith wrote:
The file compiles with ghc as is. If you uncomment the last
section, however, you see that to close the loop on the constraints for the
agent syntax we hit a typing error. i bithink/i/b this is a hard
constraint in Haskell that prevents this level of generality in the
specification, but maybe you can see a way around it.
I believe the Haskell typechecker is right
instance (Eq n, Eq p) =
CoreAgentSyntax (MinimalAgentSyntax n p) where
bind [] proc = Thunk (\() - proc)
data MinimalAgentSyntax n p =
Thunk (() - p)
| Abstraction ([n] - p)
| Concretion [n] p
The bind method has the signature
bind :: (CoreProcessSyntax p, CoreAgentSyntax x) = [n] - (p a x) - x
That is: for any agent x and for _any_ process p (regardless of x), we
should be able to perform the bind operation. The signature for bind
proclaims total independence between 'p' and 'x'. However, when we
define the instance
CoreAgentSyntax (MinimalAgentSyntax n p) where
bind [] proc = Thunk (\() - proc)
we see that process proc and the agent aren't totally independent: the
result of bind has the type 'MinimalAgentSyntax n process' and thus is
dependent on the 'process == p a x'. We have broken our previously
made independence proclamation, and so the typechecker rightfully
complaints.
The following is one solution. It works sans the line marked TODO. I'm
not sure that line is correct:
-- -- TODO : lgm : need to substitute m for n in proc
-- bind (name:names) proc = Abstraction (\m - bind names proc)
According to the type of Abstraction, 'bind names proc' should have
the type 'p', that is, the same type as proc. It should be a
process. OTH, bind returns an agent. Something is amiss here.
{-# OPTIONS -fglasgow-exts #-}
module Core where
-- What's in a name?
class Nominal n where
nominate :: i - n i
newtype Name i = Nominate i deriving Eq
instance Nominal Name where nominate i = Nominate i
-- Where are we?
class Locality a where
locate :: (Eq s, Nominal n) = s - (n i) - a s (n i)
name :: (Eq s, Nominal n) = a s (n i) - (n i)
data Location s n = Locate s n deriving Eq
instance Locality Location where
locate s n = Locate s n
name (Locate s n) = n
-- Constraints
class CoreProcessSyntax p a x | p - a x where
zero :: p
sequence :: a - x - p
compose :: [p] - p
class CoreAgentSyntax x p n | x - p n where
bind :: [n] - p - x
offer :: [n] - p - x
-- Freedom (as in freely generated)
data MinimalProcessSyntax l x =
Null
| Sequence l x
| Composition [MinimalProcessSyntax l x]
data MinimalAgentSyntax n p =
Thunk (() - p)
| Abstraction ([n] - p)
| Concretion [n] p
-- Constraining freedom
instance CoreProcessSyntax (MinimalProcessSyntax l x) l x where
zero = Null
sequence l a = Sequence l a
compose [] = zero
compose ps = Composition ps
instance CoreAgentSyntax (MinimalAgentSyntax n p) p n where
bind [] proc = Thunk (\() - proc)
-- -- TODO : lgm : need to substitute m for n in proc
-- bind (name:names) proc = Abstraction (\m - bind names proc)
-- here's the possible implementation. I don't know if it's right.
-- But at least it types
bind (name:names) proc = Abstraction (\m - comp $ bind names proc)
where comp (Thunk f) = f ()
-- comp (Concretion n p) = ...
offer names proc = Concretion names proc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] COM and Haskell
On Thu, Apr 19, 2007 at 08:59:17AM -0700, Justin Bailey wrote: All, I'm interested in automating Excel using Haskell. I'm Has any work been done on using Excel (or more generally, COM) from Haskell? There is only one library: hdirect. No-one remembers Krasimir's hscom announcement? It was only back in Jan: http://www.mail-archive.com/[EMAIL PROTECTED]/msg19723.html http://darcs.haskell.org/packages/hscom/ It's not complete but maybe it does enough for your needs. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] COM and Haskell
On Thu, Apr 19, 2007 at 05:45:18PM +0100, Neil Mitchell wrote: And I would recommend using VBA, I've done loads of Excel programming - VBA is perfectly easy enough, the hard bit is the Excel API which is quite big. If you move to Haskell you get a slightly better programming language, with the same huge API, at the cost of a painful translation layer to the API. Think about generating VBA code from Haskell. Some time ago I did something similar with OpenOffice.org and it's UNO API for Java. I think it was much more pleasant then writing Java code would be for me. All data shuffling and laying out the spreadsheet was done in Haskell. I even had a small DSL for spreadsheet layout. The only problem was the method size limit in Java - I had to split code into many methods. Pozdrawiam Tomek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Vacancy for a PhD student
(Knowledge of Haskell is a big plus; implementation of most of the tools will be done in Haskell.) Vacancy: PhD student in the Strategy Feedback project 1+3 years, Open University the Netherlands, location: Heerlen (preference). The project: In many subjects students have to acquire procedural skills. Problems in mathematics are often solved using a standard procedure, such as for example solving a system of linear equations by subtracting equations from top to bottom, and then substituting variables from bottom to top. Problems in computer science, physics, chemistry, electrotechnics, and other subjects, often require procedural skills as well. Furthermore, procedural skills appear at any educational level. E-learning systems offer excellent possibilities for practicing procedural skills. The first explanations and motivation for a procedure that solves a particular kind of problems are probably best taught in a class room, or studied in a book, but the subsequent practice can often be done behind a computer. There exist many e-learning systems or intelligent tutoring systems that support practicing procedural skills. The tools vary widely in breadth, depth, user-interface, etc, but, unfortunately, almost all of them lack sophisticated techniques for providing immediate feedback. If feedback mechanisms are present, they are hard coded in the tools, often even with the exercises. This situation hampers the usage of e-learning systems for practicing procedural skills. This project aims to investigate techniques for providing flexible and immediate feedback in tools that support practicing procedural skills. We want to use advanced techniques from computer science, taken from fields such as term rewriting, strategies, error-correcting parsers, and generic programming to provide feedback at each intermediate step from the start towards the solution of an exercise. We want to further develop some of these techniques, and apply and experiment with them in the domain of e-learning systems. Our goal is to obtain e-learning systems that give immediate and useful feedback. We will cooperate on this project with the Software Technology group from Utrecht University. Requirements: University degree in Computer Science. Good knowledge of functional programming, and several advanced computer science techniques. Knowledge of parsing, rewriting, strategies, generic programming, etc. will be useful. More information about the project can be found on http://ideas.cs.uu.nl/wiki/index.php/IDEAS:StrategicFeedback or contact Johan Jeuring ([EMAIL PROTECTED], +31 6 40010053). To apply: send a letter and your curriculum vitae before May 5, 2007 to: Open Universiteit Nederland, afdeling Personele ondersteuning, Postbus 2960, 6401 DL Heerlen. U kunt ook or an e-mail to: [EMAIL PROTECTED] Mention vacancynr FAC/INF/07024 In both cases, please cc Johan Jeuring ([EMAIL PROTECTED]). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How Albus Dumbledore would sell Haskell
Thanks for your answer, I think it emphasizes that my example matches the exclaimed conditions * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language It's easy to encode this in some object oriented language with generics, [some dozen lines of java] The haskell solution may be much shorter, but it is far from impossible to encode such things in a plain-and-boring mainstream language like java. The promotional value of this (and similar) examples shrinks down to haskell code is much shorter. Wich is true, and important, but may not be enough to consider learning some crazy programming language. Okay, nobody sayed its impossible. GHC compiles Haskell programs to some kind of C. But first: Shorter code has less chances for bugs and is easier to maintain... More important: Correct me, if I'm wrong, but as far as I understand java, it is still impossible in your solution to evaluate the equivalent of head $ mirror $ rel [ (i,i) | i - [0..] ] in finite time, that is, your MirrorRel is not lazy in the elements. You have to build this also by hand and your code becomes even longer and more complex. (Java developers who don't understand Java's advanced features like generics and anonymous classes may not be able to write or understand the above written Java solution; but do you expect them to understand Haskell?) Add 1: This statement contradicts your easyness claim!? Add 2: In contrast, the Haskell solution does'nt uses advanced Haskell features (whatever this might be), it consists of 6 lines of plain Haskell 98 only. Regards, -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ --- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: fftw bindings
Are you aware of Dan J. Bernstein's library?: http://cr.yp.to/djbfft.html According to his benchmarks (from 1999?) it is faster than FFTW. I don't know whether that's still the case, a quick search did turn up http://projects.scipy.org/pipermail/scipy-dev/2002-August/001107.html which suggests that this was still the case in 2002. Support for djbfft seems to have been integrated into scipy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: fftw bindings
On Thu, Apr 19, 2007 at 05:46:49PM -0400, Al Falloon wrote: For us less knowledgable, what's fftw? Fastest Fourier Transform in the West. http://www.fftw.org/ Its cool, they use generative programming: an OCaml program generates codlets in C that can be composed and tuned to the specifics of your machine, then compiled into a blazingly fast FFT/DFT library. But that's only the beginning of the coolness! fftw uses runtime timings to optimize each fourier transform based on the behavior of the computer on which it is being run--its cache, memory speed, CPU, etc. The result being that fftw using portable C can beat out most hand-optimized fftw libraries written in assembly! Steven (one of fftw's two authors) has done some incredible work on optimizations. The most unbelievable (to me) was that by eliminating negative constants from the generated code (using subtraction instead) they sped up the library on a particular architecture by some some significant margin (I think I recall 20%). -- David Roundy Oleg has some related work http://okmij.org/ftp/Computation/Generative.html#framework ... The papers discuss in detail the generation of a straight-line C, Fortran, etc. code for the power-of-two FFT. The papers show that with the help of Abstract Interpretation we can exactly match the quality of code generated by the well-known system FFTW. The second paper demonstrates that our generated power-of-two FFT code has exactly the same number of floating-point operations as that in codelets of FFTW. The significant difference from FFTW is that we do not do any intensional code analysis ... I don't know how useful this is. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: fftw bindings
Christian Jaeger wrote: Are you aware of Dan J. Bernstein's library?: http://cr.yp.to/djbfft.html According to his benchmarks (from 1999?) it is faster than FFTW. Quite possibly faster, but restricted to Intel and AMD CPUs. FFTW compiles and runs on anything with a C compiler. Erik -- +---+ Erik de Castro Lopo +---+ Every time an American goes to a gas station, he is sending money to America's enemies. -- http://www.meforum.org/article/653 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Installation of hs-plugins
Hello everybody, could somebody please tell me how hs-plugins has to be installed. I tried it with hs-plguin 1.0rc1 and I was unable to build it. I did runhaskell Setup.lhs configure runhaskell Setup.lhs build (Crash without any information) I tried it wiht GHC 6.4, 6.4.1 and 6.6. I am using Windows XP with SP2. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [C2hs] anyone interested in developing a Language.C library?
Duncan Coutts wrote: If anyone is interested in developing a Language.C library, I've just completed a full C parser which we're using in c2hs. It covers all of C99 and all of the GNU C extensions that I have found used in practise, including the __attribute__ annotations. It can successfully parse the whole Linux kernel and all of the C files in all the system packages on my Gentoo installation. Great work! Using this as a basis for a Language.C would be a really worthwile project. Licensing: It's not 100% clear. At the moment it's marked as GPL, but it's derived from several sources so we need to be careful about that. Personally I'm happy to use LGPL. It derives from c2hs obviously, which is GPL, though As far as I am concerned, LGPL is fine. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Installation of hs-plugins
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philipp Volgger could somebody please tell me how hs-plugins has to be installed. I tried it with hs-plguin 1.0rc1 and I was unable to build it. I did runhaskell Setup.lhs configure runhaskell Setup.lhs build (Crash without any information) I tried it wiht GHC 6.4, 6.4.1 and 6.6. I am using Windows XP with SP2. I'm pretty sure you need to install under some kind of bash shell. I used mingw on WinXP, but I think it can be done with cygwin. I'd recommend mingw if you don't have either installed. Note that hs-plugins doesn't work with ghc-6.6 yet on Windows, so stick with 6.4.1 if you can. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Writing guards shorthand
| # let infer = function | A | B | C - true; | D | E | F - false;; | val infer : foo - bool = fun | | | Yes, I appreciate what you want, and I know ocaml too :) | | I was just talking around the other ways you can achieve it. I don't | know if there is a strong reason why haskell doesn't support an | equivalent syntax. No, there's no strong reason. It's just one more feature... and (perhaps surprisingly) Joel is the first person to raise it that I can remember. Which is not to say that it's unimportant, but it helps to explain why it isn't in the language. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: fftw bindings
Erik de Castro Lopo wrote: but restricted to Intel and AMD CPUs. This is wrong. I've just successfully compiled and run it on a PPC G3. FFTW compiles and runs on anything with a C compiler. There is no PPC specific code in the sources, so djbfft did compile and run on PPC just by virtue of a C compiler. http://cr.yp.to/djbfft/install.html: The djbfft installation procedure assumes that you have a UNIX system with gcc. That probably means that it won't build on Windows without cygwin or maybe MinGW; but likely that's just an issue of the build process (which is depending on make and sh), which isn't a big deal. Possibly it doesn't run competitively on architectures he hasn't optimized for. If you have valuable information about this, please provide it. Christian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: fftw bindings
Thanks to everybody for the answers, For the moment I think that I will try to slightly expand http://ofb.net/~wnoise/haskell/FFTW/ that was pointed out to me by Patrik Sellin with respect to Dan J. Bernstein's library http://cr.yp.to/djbfft.html I was not aware of it, but I would like to have also non power of 2 grids... so FFTW. Fawzi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: fftw bindings
Christian Jaeger wrote: There is no PPC specific code in the sources, so djbfft did compile and run on PPC just by virtue of a C compiler. I stand corrected. I must admit it was many years ago that I last looked at djbfft. Erik -- +---+ Erik de Castro Lopo +---+ A mouse is a device used to point at the xterm you want to type in. -- Kim Alm, a.s.r ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How Albus Dumbledore would sell Haskell
Derek Elkins wrote: Game search is exactly an example use in Why Functional Programming Matters (http://www.math.chalmers.se/~rjmh/Papers/whyfp.html). That paper, 23 years later, is still pretty compelling. Perhaps, it should just be modernized and somewhat expanded. I'll echo Lennart's response to the theorem proving suggestion :-) Tom Moertel's parallel port scanner is much more the kind of thing that will get people's attention. It's practical; it's parallel; and it's short. And for Simon's convenience, it's already been written, so he can concentrate on presenting it, rather than writing it. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How Albus Dumbledore would sell Haskell
On 4/19/07, Simon Peyton-Jones [EMAIL PROTECTED] wrote: I have lots of *general* ideas. What I'm hoping is that I can steal working code for one or two compelling examples, so that I can spend my time thinking about how to present it, rather than on dreaming up the example and writing the code. Last night I thought writing a simple arithmetic calculator in Haskell would be pretty cool. Parsec makes it so easy to parse simple arithmetic expressions. Coming from a Ruby/C# background, that would really impress me - that kind of parsing isn't easy! Not sure how hard it would be - but extending the calculator to different units or to symbolic expressions (i.e. simple variable assignments) would be impressive. Sorry I don't have any code to provide :) Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How Albus Dumbledore would sell Haskell
Mirko Rahn wrote: More important: Correct me, if I'm wrong, but as far as I understand java, it is still impossible in your solution to evaluate the equivalent of head $ mirror $ rel [ (i,i) | i - [0..] ] in finite time, that is, your MirrorRel is not lazy in the elements. You have to build this also by hand and your code becomes even longer and more complex. Yes, that's true. Java is strict, and each bit of laziness has to be introduced by hand. Just as Haskell is lazy, and each bit of strictness has to be introduced by hand. It's not clear for a non-Haskell-programmer that the haskell aproach is better, and i don't think that it becomes clear by showing a single program wich uses laziness. (Java developers who don't understand Java's advanced features like generics and anonymous classes may not be able to write or understand the above written Java solution; but do you expect them to understand Haskell?) Add 1: This statement contradicts your easyness claim!? I don't think so. I was able to write a short (modulo syntactical overhad of the Java language) and modular Java solution without consulting reference manuals, drawing diagrams or something. Add 2: In contrast, the Haskell solution does'nt uses advanced Haskell features (whatever this might be), it consists of 6 lines of plain Haskell 98 only. The Haskell solution has no need for advanced Haskell features because Haskell is an advanced programming language. This can be good (no need to implement advanced features yourself) or bad (fear of what the advanced features do with your simple-looking code). Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fftw bindings
On Thu, 19 Apr 2007, Fawzi Mohamed wrote: Hi everybody, I was wondering if someone had fftw bindings for haskell, or if I should roll my own. I did a small search but found nothing. I have written FFTW wrappers for Modula-3 using SWIG. Maybe this can help you translating the weak C types to something more meaningful: http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/fftw/src/LongRealFFTW.i3?rev=1.4content-type=text/x-cvsweb-markup ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How Albus Dumbledore would sell Haskell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: G'day all. Quoting Isaac Dupree [EMAIL PROTECTED]: Okay, looking at that code: The comments before the type definitions are mostly good... now it looks like I'm going into critique mode :) BTW, for the record, I didn't try too hard with this. It is meant to be illustrative of what you can do with Haskell and not too much time to spare. I know, (but if you got it from somewhere, the code could really be improved where it came from? :) or did I misunderstand?) I didn't haddock-ise the comments because Diff isn't a library. The comments are meant to be more commentary (this is a tutorial, remember!) than developer documentation. Admittedly. Haddock standardizes what bit of the code a comment is meant to refer to, though, so I like using its syntax anyway. (And all code might be part of a library someday... Haskell lets you think of almost all your code as libraries! it is an excellent way to think about modularity that is far too cumbersome in many other languages!) I suppose Match is the same (inclusive), but I can't tell. And personally I don't know what the significance/meaning of a found match is. OK, this needs explanation. A Match is a match _between_ the two files being diffed. So (a,b) means that line a in file 1 matches line b in file 2. I'll note that, thanks. Ah, I see now. Comparing data Range = Range Line Line and type Match = (Line,Line), they are isomorphic, but declared differently (which is fine IMO) Yup. They only have to be different enough to cause a type error if you accidentally try to mix them. Tuples are always a bit risky though (every tuple matches every other tuple you introduce, as well as libraries using them) -- but undoubtedly convenient syntax (and certainly worth showing off to those whose languages don't contain native tuples) The only IO that displayDiff does is putStrLn. It should probably return a string instead [...] Possibly, or even use a Writer monad. I habitually use putStrLn, though, because I regularly program in multiple languages, and this way I don't have to remember how Haskell handles line termination on different platforms. Hmm, reasonable. (I hope haskell just uses '\n' in-program everywhere..) You could return a list of lines instead (and mapM_ putStrLn the result). Is there any way to make IO be an instance of MonadWriter? Not in a reasonable way, I think, given 'listen' etc... possibly a different class interface would be more useful, but we're certainly not into trying that here! Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKOjaHgcxvIWYTTURAj/tAKCF1NoAR/tsCk/2F90qrJqotEa+GACfbYzs uWYo+EFqlpZTnsdS1YTndl8= =IR0K -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Program optimisation
I have *no idea* if this is an appropriate place to put this, but here goes... I have a (presumably) common problem. I have a nice Haskell program. It's compute-bounded, and I'd like to make it go faster. To that end, I've been trying to optimise it. Without going into great detail, the program basically revolves around processing a list and dumping the results into a file. Notable things about this structure: it's *big*, and I only need to *map* over it. Anyway, here's what I did... I wrote a simplified, cut down version of the program so I would have a fixed test case. I compiled it with GHC 6.6 and ran it. It takes 40 seconds to complete. Next, I read the GHC manual. Apparently there's a command-line switch -O2 which makes GHC try harder to optimise the program. (I had stupidly assumed it always tries to make good code...) The result? The program now does the same job in 30 seconds. That's quite a big speedup just for typing 3 characters! (Gee... I wonder what it does differently? I did notice that the compilation time went from 5 seconds up to 20 seconds. And the *.exe got smaller.) Next I played with profiling. If I'm reading this correctly, the -s profile is telling me that my program spends 72% CPU time doing GC. o_O Er... that's really suboptimal. Also - and this is really weird - the -p profile tells me that 82% of the program's time is spent in the quant8 function. The source code for this function is precisely quant8 :: Double - Word8 quant8 x = floor $ x * 0xFF Why that should take 82% CPU when the program is also doing heavy-metal complex number arithmetic and trig functions I have no idea! (Since I took those measurements, I have come up with a theory. When I ask for all these computations to be done... Haskell doesn't actually *do* them. It just stores them up until needed. It just occurred to me that quant8 is the *last* thing I ask it to do before the code hits a strict ByteString... So is the profiler just misappropriating all the work to quant8 when it's really elsewhere?) OK, so to recap: currently my program takes 30 seconds to run. Next, I changed the 2D lists (i.e., [[x]]) into 1D lists (that is, [x]). The new runtime? 30 seconds. Right, that seems to be no-op. Next I replaced lists with immutable boxed arrays. New runtime: 33 seconds. Ooops. Now, I would have thought an array would make the GC's life *much* easier by replacing tens of thousands of cons cells with one nice big array. But, apparently, no. The profiler output says GC is almost identical. Hmm... weird! Next, I switched to IO-mutable boxed arrays. (With in-place updates.) New runtime: 35 seconds. Da hell...? The more I optimise this program, the slower it goes! :'( Finally, in a fit of desperation, I changed it to *unboxed* arrays. For some reason, you can't have an unboxed array of complex numbers. So I had to make *two* unboxed arrays of doubles, and manually split/join myself. Similar problems happened elsewhere too. Suffice it to say, my program is now vomit-inducingly ugly. It doesn't even *function* correctly any more! (There's a byte alignment issue somewhere... I can't track it down.) New runtime: 15 seconds. I say again: 15 seconds. Changing to an unboxed array has *doubled* the speed. Not only that, the GC report now shows GC as using 7% CPU time, and peak RAM usage has been reduced from 25 MB to 4 MB. The memory graph is now utterly flat, whereas even with IO-mutable arrays with in-place update, it was still fluctuating all over the place. I will mention that the ByteString module was the only thing I would find in all of Haskell for doing binary I/O. The final (fast) program uses an IOUArray Int Word8 to do the binary I/O instead. (What's the difference BTW? Is there one? Other than the name anyway.) Perhaps part of the speed was in avoiding an array type conversion? I don't know. Certainly this is the messiest part, and the part where I suspect my bug is hiding. Finally, in the fast version, quant8 uses way less CPU (more like 50%), and the complex number math uses much more. Really goes look like the profiler being counterintuitive to me... Personally, I find it quite worrying that I had to manually mutilate my program to unbox everything when the compiler is supposed to be able to do such things automatically. Does GHC know about the array types? Or are they just a bunch of FFI calls that some 3rd party wrote? When I talk to other people about Haskell, they all say immutable sucks; that must be SO slow! and I tell them yeah, but the compiler can strip almost all of it out automatically. Well, my experience with this program suggests very differently. I do wonder if the program went faster just because unboxed arrays are strict. I couldn't think of any way to make a boxed array be strict. (I tried for ages!) Next task: Attempt to make the program use both cores on my dual-core monster machine for even more speed... A short program synopsys: module Main where init_frame ::
Re: [Haskell-cafe] Program optimisation
On Fri, Apr 20, 2007 at 07:01:32PM +0100, Andrew Coppin wrote: I have *no idea* if this is an appropriate place to put this, but here goes... Sure. Next, I read the GHC manual. Apparently there's a command-line switch -O2 which makes GHC try harder to optimise the program. (I had stupidly assumed it always tries to make good code...) The result? The program now does the same job in 30 seconds. That's quite a big speedup just for typing 3 characters! (Gee... I wonder what it does differently? I did notice that the compilation time went from 5 seconds up to 20 seconds. And the *.exe got smaller.) This is standard behavior for compilers. Right, that seems to be no-op. Next I replaced lists with immutable boxed arrays. New runtime: 33 seconds. Ooops. Now, I would have thought an array would make the GC's life *much* easier by replacing tens of thousands of cons cells with one nice big array. But, apparently, no. The profiler output says GC is almost identical. Hmm... weird! The compiler is pretty smart about lists. As long as you're doing simple things with them (e.g. mapping), odds are pretty good there won't be any intermediate cons cells generated (this is called deforestation). In contrast, no such optimization is available (yet) for arrays. Every time you create a new array, it needs to actually be created. Finally, in a fit of desperation, I changed it to *unboxed* arrays. For some reason, you can't have an unboxed array of complex numbers. So I had to make *two* unboxed arrays of doubles, and manually split/join myself. Similar problems happened elsewhere too. Suffice it to say, my program is now vomit-inducingly ugly. It doesn't even *function* correctly any more! (There's a byte alignment issue somewhere... I can't track it down.) New runtime: 15 seconds. Indeed, unboxed arrays are much nicer, but the whole Array batch of the standard library is pretty useless, in my experience. You can roll your own relatively easily using ForeignPtr, similar to Data.ByteString, but that's a bit of a pain. I will mention that the ByteString module was the only thing I would find in all of Haskell for doing binary I/O. The final (fast) program uses an IOUArray Int Word8 to do the binary I/O instead. (What's the difference BTW? Is there one? Other than the name anyway.) Perhaps part of the speed was in avoiding an array type conversion? I don't know. Certainly this is the messiest part, and the part where I suspect my bug is hiding. Binary IO is definitely an issue with Haskell. Finally, in the fast version, quant8 uses way less CPU (more like 50%), and the complex number math uses much more. Really goes look like the profiler being counterintuitive to me... Profilers are always counterintuitive in any language. (Okay, not quite always, but pretty much whenever you actually need a profiler.) A short program synopsys: module Main where init_frame :: [[Complex Double]] next_frame :: [[Complex Double]] - [[Complex Double]] process :: [[Complex Double]] - [[Colour]] save_file :: FilePath - [[Colour]] - IO () main = do work 0 init_frame work n xss = do save_file (Frame ++ show n) (process xss) if n 500 then work (n+1) (next_frame xss) else return () If you want actual help, you'll have to supply something more than this. You could cut out the actual work, and just post some code that does the framework. My guess (and you should have tested this) is that the runtime won't decrease much if you cut out the actual work (or replace it by something simple, like taking a exponential of everything), and the result would be that we'd be able to do more than commiserate. What happens if you cut the save_file from the process? Far better than profiling is checking by hand the actual removal of code from the program, as profiling has a tendancy to disable optimizations. You did run your timings with profiling disabled? You've got three potentially expensive functions here (process, save_file and next_frame), and it'd certainly help to have some idea which is the bottleneck. Due to lazy evaluation (less of an issue with unboxed arrays), you do need to be careful when removing bits of code, as this could cause other bits of code to not actually be run (e.g. if you never print the output, it might be that the next_frame is never evaluated, so you might need to print just the last frame, or compute the sum of each frame and print that). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Program optimisation
On Fri, Apr 20, 2007 at 08:33:41PM +0100, Andrew Coppin wrote: Indeed, unboxed arrays are much nicer, but the whole Array batch of the standard library is pretty useless, in my experience. You can roll your own relatively easily using ForeignPtr, similar to Data.ByteString, but that's a bit of a pain. There is no *way* I'm playing with C. The entire point of Haskell is to allow mankind to eradicate C forever. :-) ForeignPtr doesn't have anything to do with C, it's just the data structure you need to use if you want to write your own unboxed array. I was more interested in seeing people's comments about the program changes. For example, why would an in-place update be slower than lots of dynamically-allocated lists? That's totally counterintuitive. Also, is there any way in hell I can make the program stricter without mutilating the entire thing to use unboxed arrays? I couldn't figure out a way to do this. (Would be nice if there was a compiler switch to just turn off all laziness - but as far as I can tell, there isn't.) The in-place update (without boxing) still dynamically allocates thunks, which are similar in cost to cons cells (for some definition of similar). Unboxed arrays are exactly what you want--except that the UArray type is limited, which is why I recommended rolling your own. Hopefully the PArr package will help reduce the pain of using arrays. In any case, in my opinion Haskell desperately needs more strict data types, as strict types can go a long way towards eliminating all sorts of pain. I remember once going through all sorts of pain trying to avoid stack overflows when using Data.Map to compute a histogram, which all would have been avoided if there were a strict version of Data.Map (or even just strict functions on the lazy Data.Map). I don't think eliminating all laziness is a good idea, but (optional) strict datatypes most certainly are, as they can go a very long ways towards eliminating memory leaks. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: how would Albus Dumbledore sell Haskell
Simon, Regarding Justin Bailey's idea of a calculator -- here's a twist. There is some sample Haskell code of Conway's account of numbers as games floating around the internet (http://www.dcs.ed.ac.uk/home/pgh/conway.html, http://www.dcs.ed.ac.uk/home/pgh/Conway.lhs). i can't vouch for the code as i have not read it in anger. However, i've always thought it would be fun to do the standard calculator example, but with Conway games on the back end for doing the arithemetic. Some of the attractions: - you could have another set of buttons for displaying the games respresentation of the numbers - you could really emphasize the polymorphism of the basic operations - you could emphasize the use of laziness for calculations involving infinitary entities - you could explain Conway games (which are an intellectual treat for those who never seen them and just get better and better the more you return to them) Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haskell question
Oleg,
Many thanks for your help! i notice that the code you sent requires
-fglasgow-exts to be syntactically correct. Is there documentation on the
multi-parameter type classes? i think i see what you've done, but i'd like
to read up on it to make sure that i understand.
Best wishes,
--greg
On 4/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Greg Meredith wrote:
The file compiles with ghc as is. If you uncomment the last
section, however, you see that to close the loop on the constraints for
the
agent syntax we hit a typing error. i bithink/i/b this is a hard
constraint in Haskell that prevents this level of generality in the
specification, but maybe you can see a way around it.
I believe the Haskell typechecker is right
instance (Eq n, Eq p) =
CoreAgentSyntax (MinimalAgentSyntax n p) where
bind [] proc = Thunk (\() - proc)
data MinimalAgentSyntax n p =
Thunk (() - p)
| Abstraction ([n] - p)
| Concretion [n] p
The bind method has the signature
bind :: (CoreProcessSyntax p, CoreAgentSyntax x) = [n] - (p a x) -
x
That is: for any agent x and for _any_ process p (regardless of x), we
should be able to perform the bind operation. The signature for bind
proclaims total independence between 'p' and 'x'. However, when we
define the instance
CoreAgentSyntax (MinimalAgentSyntax n p) where
bind [] proc = Thunk (\() - proc)
we see that process proc and the agent aren't totally independent: the
result of bind has the type 'MinimalAgentSyntax n process' and thus is
dependent on the 'process == p a x'. We have broken our previously
made independence proclamation, and so the typechecker rightfully
complaints.
The following is one solution. It works sans the line marked TODO. I'm
not sure that line is correct:
-- -- TODO : lgm : need to substitute m for n in proc
-- bind (name:names) proc = Abstraction (\m - bind names proc)
According to the type of Abstraction, 'bind names proc' should have
the type 'p', that is, the same type as proc. It should be a
process. OTH, bind returns an agent. Something is amiss here.
{-# OPTIONS -fglasgow-exts #-}
module Core where
-- What's in a name?
class Nominal n where
nominate :: i - n i
newtype Name i = Nominate i deriving Eq
instance Nominal Name where nominate i = Nominate i
-- Where are we?
class Locality a where
locate :: (Eq s, Nominal n) = s - (n i) - a s (n i)
name :: (Eq s, Nominal n) = a s (n i) - (n i)
data Location s n = Locate s n deriving Eq
instance Locality Location where
locate s n = Locate s n
name (Locate s n) = n
-- Constraints
class CoreProcessSyntax p a x | p - a x where
zero :: p
sequence :: a - x - p
compose :: [p] - p
class CoreAgentSyntax x p n | x - p n where
bind :: [n] - p - x
offer :: [n] - p - x
-- Freedom (as in freely generated)
data MinimalProcessSyntax l x =
Null
| Sequence l x
| Composition [MinimalProcessSyntax l x]
data MinimalAgentSyntax n p =
Thunk (() - p)
| Abstraction ([n] - p)
| Concretion [n] p
-- Constraining freedom
instance CoreProcessSyntax (MinimalProcessSyntax l x) l x where
zero = Null
sequence l a = Sequence l a
compose [] = zero
compose ps = Composition ps
instance CoreAgentSyntax (MinimalAgentSyntax n p) p n where
bind [] proc = Thunk (\() - proc)
-- -- TODO : lgm : need to substitute m for n in proc
-- bind (name:names) proc = Abstraction (\m - bind names proc)
-- here's the possible implementation. I don't know if it's right.
-- But at least it types
bind (name:names) proc = Abstraction (\m - comp $ bind names proc)
where comp (Thunk f) = f ()
-- comp (Concretion n p) = ...
offer names proc = Concretion names proc
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
505 N 72nd St
Seattle, WA 98103
+1 206.650.3740
http://biosimilarity.blogspot.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Gotta love Haskell
My wife has been put in charge of scheduling lectors and ministers at our
church, so of course she needs a Haskell program to do the schedules for
her! While I've been working on it, I wrote something that I thought was a
pretty cool trick.
Each Mass requires a variety of different type and number of participants,
so when defining the Mass data structure I put a function in which selects
participants for that type of Mass from a given list:
data MassTime = MassTime {
...
selectParticipants :: (Participants - Maybe Participants), -- Picks
participants for this mass
... }
Each mass has particular requirements. Notice the 'selectParticipants'
function does not take a mass definition as an argument.
Here's the trick I thought was neat. When creating the MassTime value, I
capture it in a closure and bind it to the selector function, as below:
makeMass :: Day - MassTime
makeMass day =
mass
where
-- Use trick here to capture mass defined and pass to our selection
function.
mass = MassTime ... (weekendMassSelector mass) ...
'weekendMassSelector' is defined elsewhere, and basically knows how to count
up the right number of participants based on the mass definition given. It's
signature is:
weekendMassSelector :: MassTime - Participants - Maybe Participants
So weekendMassSelector gets the MassTime value it needs, before it is even
constructed. Partial evaluation then gives a function with the (Participants
- Maybe Participants) signature required by the data constructor. I love
Haskell - this just seems too cool.
Since I really doubt this is something new - is this a technique that's
commonly used? Does it have a name? It looks a lot like passing a this
argument to a function - have I re-invented OOP encapsulation? :)
Justin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Program optimisation
David Roundy wrote: I remember once going through all sorts of pain trying to avoid stack overflows when using Data.Map to compute a histogram, which all would have been avoided if there were a strict version of Data.Map (or even just strict functions on the lazy Data.Map). Then what you need is the new Data.Map clone.. http://darcs.haskell.org/packages/collections-ghc6.6/Data/Map/AVL.hs which I believe has all the strictness control you could want. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How Albus Dumbledore would sell Haskell
Simon Peyton-Jones wrote:
Lots of interesting ideas on this thread, and Haskell-Cafe threads are
*supposed* to wander a bit. But, just to remind you all: I'm particularly
interested in
concrete examples (pref running code) of programs that are
* small
* useful
* demonstrate Haskell's power
* preferably something that might be a bit
tricky in another language
I have lots of *general* ideas. What I'm hoping is that I can steal working
code for one or two compelling examples, so that I can spend my time thinking
about how to present it, rather than on dreaming up the example and writing the
code.
Put up or shut up, huh? OK, I have attached my feeble contribution for
consideration. Not quite as trivial as a prime number generator.
Since many in the audience might be database people, it might be
instructive how some simple relational algebra (inner join, transitive
closure) can be done from scratch (and without looking first at how
others do it!). It's not quite point-free, but I was surprised how
easily the set-like list invariant (sorted, no duplicates) was preserved
through many of the operations, allowing me to junk the set datatype I
started out with. In a non-FP language, I would have likely overlooked
this. Also, I reminded me of how Haskell enables the easy and powerful
method of writing a correct by naive algorithm and continuously
transforming it into what you want. In C++, the code noise is so high
that this would be prohibitive and tedious.
Obviously, some QuickCheck is needed to round things off, but I ran out
of time for this week.
There are no monads, but I slipped the categorical product operator ***
in there, along with lots of higher-order functions and showed how
easily one-off utility functions are created when needed.
It all fits on one slide. Plus, the indentation is so visually
appealing! Code as art.
Dan
module TransitiveClosure(innerJoin,transitiveClosure) where
import Data.List(sort,nubBy)
import Control.Arrow((***))
--
-- RELATIONAL ALGEBRA
ifKeyMatchesAddValue seekKey (findKey,value) =
if seekKey === findKey then (:) value
else id
lookupAll seekKey = foldr (ifKeyMatchesAddValue seekKey) []
lookupAllIn keyValueDict = flip lookupAll keyValueDict
-- PRE : abDict and bcDict are set-like
-- POST: Returned acDict is set-like
innerJoin :: (Ord a, Ord b, Ord c) = [(a, b)] - [(b, c)] - [(a, c)]
innerJoin abDict bcDict = concatMap innerJoinFor joinKeys
where getKeys = map fst
`andThen` removeDupsFromSorted
joinKeys = getKeys abDict
joinedValues = lookupAllIn abDict
`andThen` concatMap (lookupAllIn bcDict)
`andThen` sortAndRemoveDups
innerJoinFor = dup -- key into (joinKey,seekKey)
`andThen` (repeat {- joinKey -} ***
joinedValues {- seekKey -})
`andThen` uncurry zip -- (joinKey,joinedValues)
-- PRE : Arg is set-like
-- POST: Returned is set-like, transitiveClosure is idempotent
transitiveClosure :: (Ord a) = [(a, a)] - [(a, a)]
transitiveClosure aaDict
| aaDict === aaDictNew = aaDictNew
| otherwise= transitiveClosure aaDictNew
where aaDictNew= mergeInSelfJoin aaDict
mergeInSelfJoin d= d `merge` innerJoin d d
--
-- USING LISTS AS SETS
-- DEF: A list is set-like if it is in strictly increasing order
-- Why is this not in Prelude?
dup x = (x,x)
-- I prefer reading function composition from left-to-right
andThen = flip (.)
-- Uses instead of == to preserve set-like structures
x === y = not (x y || y x)
-- PRE : Arg is sorted
-- POST: Result is set-like
removeDupsFromSorted :: Ord a = [a] - [a]
removeDupsFromSorted = nubBy (===)
-- POST: Result is set-like
sortAndRemoveDups :: Ord a = [a] - [a]
sortAndRemoveDups = sort
`andThen` removeDupsFromSorted
-- PRE : Args are set-like
-- POST: Result is set-like, the sorted union of args
merge as [] = as
merge [] bs = bs
merge aas@(a:as) bbs@(b:bs) | a b = a : merge as bbs
| b a = b : merge aas bs
| otherwise = a : merge as bs
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [C2hs] anyone interested in developing a Language.C library?
chak: Duncan Coutts wrote: If anyone is interested in developing a Language.C library, I've just completed a full C parser which we're using in c2hs. It covers all of C99 and all of the GNU C extensions that I have found used in practise, including the __attribute__ annotations. It can successfully parse the whole Linux kernel and all of the C files in all the system packages on my Gentoo installation. Great work! Using this as a basis for a Language.C would be a really worthwile project. I think people should be very interested in this. The ability to easily manipulate and generate C would quickly insert Haskell into another useful niche. There must *surely* be real money in writing nice Haskell programs that optimise/analyse/refactor/generate C code... -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Program optimisation
droundy: In any case, in my opinion Haskell desperately needs more strict data types, as strict types can go a long way towards eliminating all sorts of Yes! Haskell is a combined strict and lazy language, after all. In particular, the ability to precisely combine strictness and laziness in a single data structure (e.g. Data.ByteString.Lazy) leads to some really nice applications difficult to realise in a fully strict language. There's a small beginnings of a 'strict' Data.* here, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/strict-0.1 Some additions to that could be useful. pain. I remember once going through all sorts of pain trying to avoid stack overflows when using Data.Map to compute a histogram, which all would have been avoided if there were a strict version of Data.Map (or even just strict functions on the lazy Data.Map). I don't think eliminating all laziness is a good idea, but (optional) strict datatypes most certainly are, as they can go a very long ways towards eliminating memory leaks. Quite so. I can imagine some useful variants of Data.Map.Strict/Lazy/... -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Program optimisation
ahey: David Roundy wrote: I remember once going through all sorts of pain trying to avoid stack overflows when using Data.Map to compute a histogram, which all would have been avoided if there were a strict version of Data.Map (or even just strict functions on the lazy Data.Map). Then what you need is the new Data.Map clone.. http://darcs.haskell.org/packages/collections-ghc6.6/Data/Map/AVL.hs which I believe has all the strictness control you could want. Which is also on hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/collections-0.3 -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] QuickCheck subsumes unit testing
Just to walk the walk, and not just talk the talk, here's a quick unit
testing 'diff' driver I hacked up for QuickCheck.
When run, it 'diffs' (well, just prints ;-) the incorrect values from
the unit test:
$ runhaskell T.hs
sort unit test : Falsifiable after 0 tests:
- [1,2,3]
+ [1,3,2]
From a normal QC specification like:
prop0 = (sort [3,2,1], [1,3,2])
main = mapM_ (\(s,a) - printf %-25s: s a n) tests
where
n = 100
tests = [(sort unit test, mytest prop0)]
The full driver code is attached. It is just proof of concept, but you
can see how to extend it to be smarter/prettier.
Note that we actually probably want to use SmallCheck here, to prevent
bogus repetition of the test. (I.e. 500 tests all passed, for a unit test).
Note also, the driver would need further extending, since we've changed
the structure of the Testable values.
Cheers,
Don
import Data.List
import Text.Printf
import System.IO
import System.Random
import Test.QuickCheck
prop0 = (sort [3,2,1], [1,3,2])
main = mapM_ (\(s,a) - printf %-25s: s a n) tests
where
n = 100
tests = [(sort unit test, mytest prop0)]
-- And a custom driver that `diff's the output
mytest :: (Show a, Eq a) = (a,a) - Int - IO ()
mytest (a,b) n = mycheck defaultConfig
{ configMaxTest=n
, configEvery= \n args - [] } a b
mycheck :: (Show a , Eq a) = Config - a - a - IO ()
mycheck config a b =
do rnd - newStdGen
mytests config (evaluate (a == b)) a b rnd 0 0 []
mytests :: (Show a , Eq a)
= Config - Gen Result - a - a - StdGen - Int - Int - [[String]]
- IO ()
mytests config gen a b rnd0 ntest nfail stamps
| ntest == configMaxTest config = do done OK, ntest stamps
| nfail == configMaxFail config = do done Arguments exhausted after ntest
stamps
| otherwise =
do putStr (configEvery config ntest (arguments result)) hFlush stdout
case ok result of
Nothing-
mytests config gen a b rnd1 ntest (nfail+1) stamps
Just True -
mytests config gen a b rnd1 (ntest+1) nfail (stamp result:stamps)
Just False -
putStr ( Falsifiable after
++ show ntest
++ tests:\n
++ - ++ show a
++ \n
++ + ++ show b
++ \n
) hFlush stdout
where
result = generate (configSize config ntest) rnd2 gen
(rnd1,rnd2) = split rnd0
done :: String - Int - [[String]] - IO ()
done mesg ntest stamps =
do putStr ( mesg ++ ++ show ntest ++ tests ++ table )
where
table = display
. map entry
. reverse
. sort
. map pairLength
. group
. sort
. filter (not . null)
$ stamps
display [] = .\n
display [x] = ( ++ x ++ ).\n
display xs = .\n ++ unlines (map (++ .) xs)
pairLength xss@(xs:_) = (length xss, xs)
entry (n, xs) = percentage n ntest
++
++ concat (intersperse , xs)
percentage n m= show ((100 * n) `div` m) ++ %
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why Mathematical Soundness Matters.
Hi All, This is in regard to previous posts about mathematical preludes. class Set a class (Set s) = SemiGroup s o where semigroup_op :: o - (s,s) - s -- closure -- associative class (SemiGroup s o) = Monoid s o where identity :: o - s class (Monoid s o) = Group s o where inverse :: o - s - s class Optimisable a where cost :: Set b = a - b First, consider a semigroup, which is a set with an associative operation. Into this structure falls Matrices with multiplication. There is scope for optimisation of a series of multiplications. Inductively for each m1 * m2 * m3 compare the cost of m1 * m2 versus m2 * m3 which can be simply obtained from the size of the index of the matrix. Thus expressions like (14,3) x (3,15) x (15,2) can be computed as (14,3) x ((3,15) x (15,2)) and not in a more expensive way. Furthermore, if we tag identities with a phantom type, we can eliminate needless operations like 3 + 0. Not as much optimisation can be achieved with inverses (3 + -3) because it might be just as expensive to calculate that something is an inverse as to do actual calculation. So how can this optimisation be performed? Well this is a question that I put forward to you, Gentle Reader. Static: It seems to me that expressions the types of which are known at compile-time can be optimised by using type-level programming in combination with compiler rewrite rules, e.g. if we have a type class SizeLarger then the expression semigroup_op (semigroup_op m1 m2) m3 can be rewritten as semigroup_op m1 (semigroup_op m2 m3) depending upon the SizeLarger types of the various (semigroup_op _ _) function calls. Another method is to manipulate the expressions as ASTs and convert to the concrete using TH. But what about dynamic data? Dynamic: These are terms whose types are not known until run-time (such as would happen when loading an arbitrary matrix from a file). In this case we can't use compiler term-rewriting or TH, but what options are there? Depending upon the speed/complexity of type-checking versus computation would it not be feasible to use run-time type checking (a polymorphic Dynamic type) to achieve this optimisation? Yes there is a lot to said in favour of static type-checking, but there are cases in which it is not feasible, witness type-level bounds checking of run-time loaded matrices of unknown shape. In a program that used run-time typechecking (yes there would be a computational overhead) the dynamic stuff would be isolated from the 'trusted' statically checked program and values could only be injected through trusted entry points (e.g. get4SquareDoubleMatrix :: Dynamic - IO (Array ((D4 $ Sz),(D4 $ Sz)) Double). In any case, writing 'simple' arithmetic expressions would become more cumbersome because of the overhead of annotating types and possibly moving between ASTs and the concrete. But if we a had collection of mathematically sound classes like SemiGroup, Monoid, Group, Field, etc... then these optimisations could be built into the compiler and we could sugar the programmer-side just as it has been for Monads. In conclusion, I put this forward as a reason for Mathematically Meaningful Numeric Classes and in obiter I am putting forward support for polymorphic Dynamic types (run-time typechecking). Cheers, Vivian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Program optimisation
Donald Bruce Stewart wrote: ahey: David Roundy wrote: I remember once going through all sorts of pain trying to avoid stack overflows when using Data.Map to compute a histogram, which all would have been avoided if there were a strict version of Data.Map (or even just strict functions on the lazy Data.Map). Then what you need is the new Data.Map clone.. http://darcs.haskell.org/packages/collections-ghc6.6/Data/Map/AVL.hs which I believe has all the strictness control you could want. Which is also on hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/collections-0.3 Actually it isn't I'm afraid. That module has had a complete re-write since the package was last cabalised. Anybody who's interested should darcs get it from http://darcs.haskell.org/packages/collections-ghc6.6/ Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Program optimisation
ahey: Donald Bruce Stewart wrote: ahey: David Roundy wrote: I remember once going through all sorts of pain trying to avoid stack overflows when using Data.Map to compute a histogram, which all would have been avoided if there were a strict version of Data.Map (or even just strict functions on the lazy Data.Map). Then what you need is the new Data.Map clone.. http://darcs.haskell.org/packages/collections-ghc6.6/Data/Map/AVL.hs which I believe has all the strictness control you could want. Which is also on hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/collections-0.3 Actually it isn't I'm afraid. That module has had a complete re-write since the package was last cabalised. Anybody who's interested should darcs get it from http://darcs.haskell.org/packages/collections-ghc6.6/ Oh, what's remaining before the next release? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
