[GHC] #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable
#3413: configure fails when generated with debian's autoconf 2.64-1 from
unstable
-+--
Reporter: explicitcall | Owner:
Type: bug | Status: new
Priority: normal| Component: Build System
Version: 6.11 | Severity: normal
Keywords:| Testcase:
Os: Linux | Architecture: Unknown/Multiple
-+--
when doing `sh boot./configure` on ghc-HEAD with latest patches with
debian's autoconf 2.64-1 from unstable installed, I get this:
{{{
checking for ghc-pkg matching /home/user/local/bin/ghc...
/home/user/local/bin/ghc-pkg
./configure: line 6156: syntax error near unexpected token
`indResVersion=$fptools_cv_windres_version'
./configure: line 6156: `fiindResVersion=$fptools_cv_windres_version;'
}}}
after that configure script stops
when I downgrade to autoconf 2.63-3 from testing, configure runs normally
generated buggy configure script is attached
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3413
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] #3374: Profiling libraries are not installed
#3374: Profiling libraries are not installed ---+ Reporter: scsibug |Owner: Type: bug | Status: new Priority: normal |Milestone: Component: Build System| Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ---+ Changes (by akiel): * difficulty: = Unknown * os: MacOS X = Linux Comment: I can confirm this. I have version ghc-6.11.20090803. The *_p.a files are inside the build dirs but wouldn't be installed. I'm on Linux (Ubuntu 9.04) amd64 GHC 6.10.4 as base. -- Ticket URL: http://hackage.haskell.org/trac/ghc-test/ticket/3374#comment:1 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] #3381: PROPOSAL: Remove Control.OldException
#3381: PROPOSAL: Remove Control.OldException -+-- Reporter: igloo |Owner: Type: proposal | Status: closed Priority: normal|Milestone: Not GHC Component: libraries/base| Version: 6.10.4 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Some people thought it is too soon to remove `Control.OldException`, so it has been marked deprecated instead. If we do a `base4-compat` in GHC 6.12 then we will remove it from base 5. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3381#comment:2 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
Data.List permutations
A friend mine, new to functional programming, was entertaining himself by writing different combinatorial algorithms in Haskell. He asked me for some help so I sent him my quick and dirty solutions for generating variations and permutations: inter x [] = [[x]] inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) perm [] = [[]] perm (x:xs) = concatMap (inter x) (perm xs) vari 0 _ = [[]] vari _ [] = [] vari k (x:xs) = concatMap (inter x) (vari (k-1) xs) ++ vari k xs After that I found out that nowadays there is a permutation function in the Data.List module: permutations:: [a] - [[a]] permutations xs0= xs0 : perms xs0 [] where perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where interleavexs r = let (_,zs) = interleave' id xs r in zs interleave' _ [] r = (ts, r) interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r in (y:us, f (t:y:us) : zs) I was surprised to find that not only my version is much simpler from the one in Data.List but it also performs better. Here are some numbers from my rather old ghc 6.8.1 running ubuntu on my box: *Main length $ permutations [1..10] 3628800 (10.80 secs, 2391647384 bytes) *Main length $ perm [1..10] 3628800 (8.58 secs, 3156902672 bytes) I would like to suggest to change the current implementation in Data.List with the simpler one. Also, it would be nice to add variations and combinations in the Data.List module. Cheers. -- Slavomir Kaslev ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Data.List permutations
On Tue, Aug 4, 2009 at 8:42 PM, Slavomir Kaslevslavomir.kas...@gmail.com wrote: A friend mine, new to functional programming, was entertaining himself by writing different combinatorial algorithms in Haskell. He asked me for some help so I sent him my quick and dirty solutions for generating variations and permutations: inter x [] = [[x]] inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) perm [] = [[]] perm (x:xs) = concatMap (inter x) (perm xs) vari 0 _ = [[]] vari _ [] = [] vari k (x:xs) = concatMap (inter x) (vari (k-1) xs) ++ vari k xs After that I found out that nowadays there is a permutation function in the Data.List module: permutations :: [a] - [[a]] permutations xs0 = xs0 : perms xs0 [] where perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where interleave xs r = let (_,zs) = interleave' id xs r in zs interleave' _ [] r = (ts, r) interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r in (y:us, f (t:y:us) : zs) I was surprised to find that not only my version is much simpler from the one in Data.List but it also performs better. Here are some numbers from my rather old ghc 6.8.1 running ubuntu on my box: *Main length $ permutations [1..10] 3628800 (10.80 secs, 2391647384 bytes) *Main length $ perm [1..10] 3628800 (8.58 secs, 3156902672 bytes) I would like to suggest to change the current implementation in Data.List with the simpler one. Also, it would be nice to add variations and combinations in the Data.List module. Cheers. -- Slavomir Kaslev Oops. It seems I should have used the glasgow-haskell-users mailing list. FIXED -- Slavomir Kaslev ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Current GHC core documentation.
On 03/08/2009 15:54, Richard Kelsall wrote: This page http://www.haskell.org/ghc/documentation.html has a link to the September 2001 (Draft for GHC 5.02) document describing GHC Core (in what is for me user-hostile .ps.gz format.) And this page http://www.haskell.org/ghc/docs/latest/html/users_guide/ext-core.html promises an easier format PDF document, but the link is broken. I did eventually find the 1st April 2009 GHC 6.10 document here http://www.haskell.org/ghc/docs/6.10.2/html/ext-core/core.pdf and a bit on this page http://www.haskell.org/ghc/docs/latest/html/users_guide/options-debugging.html#id468571 about GHC core. I haven't read these yet, but could I ask whether they constitute the complete current documentation for GHC core? (I'm just curious to get a flavour of what core does.) There's also the commentary page: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/CoreSynType which is supposed to be the canonical place for documentation about GHC's internal Core datatype. External Core is slightly different: it refers to the external representation of Core that you get from the -fext-core flag. Round-tripping via External Core is supposed to be non-lossy, though, so External Core retains everything in the original Core. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling large source files
I suggest not using Haskell for your list. Put the data in a file and read it at runtime, or put it in a static C array and link it in. Cheers, Simon On 03/08/2009 22:09, Günther Schmidt wrote: Hi Thomas, yes, a source file with a single literal list with 85k elements. Günther Am 03.08.2009, 22:20 Uhr, schrieb Thomas DuBuisson thomas.dubuis...@gmail.com: Can you define very large and compiler? I know an old version of GHC (6.6?) would eat lots of memory when there were absurd numbers of let statements. Thomas 2009/8/3 Günther Schmidt red...@fedoms.com: Hi all, I'm having trouble compiling very large source files, the compiler eats 2GB and then dies. Is there a way around it? Günther ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
use gtar and not tar under solaris
Hi, I've just been informed that unpacking the binary (i386) solaris distribution using bunzip2 and tar: bunzip2 -c ghc-6.10.4-i386-unknown-solaris2.tar.bz2 | tar xvf - does not work properly! Use instead: gtar jxvf ghc-6.10.4-i386-unknown-solaris2.tar.bz2 File names longer than a hundred characters are cut off, i.e. ghc-6.10.4/libraries/dph/dph-prim-seq/dist/build/Data/Array/Parallel/Unlifted/Sequential/Flat/UArr.hi is wrongly extracted as: ghc-6.10.4/libraries/dph/dph-prim-seq/dist/build/Data/Array/Parallel/Unlifted/Sequential/Flat/UArr.h leading to an installation failure: installPackage: Error: Could not find module: Data.Array.Parallel.Unlifted.Sequential.Flat.UArr with any suffix: [hi] gmake[1]: *** [install.library.dph/dph-prim-seq] Error 1 Ian, could you place a note about using gtar for unpacking solaris binary-dists? Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling large source files
On Tue, Aug 04, 2009 at 09:12:37AM +0100, Simon Marlow wrote: I suggest not using Haskell for your list. Put the data in a file and read it at runtime, or put it in a static C array and link it in. On 03/08/2009 22:09, G?nther Schmidt wrote: Hi Thomas, yes, a source file with a single literal list with 85k elements. People, when a program only defines and returns a String constant of n literals, how much memory needs ghc-6.10.4 to compile it ? O(n), or may be O(n^2), or ... Regards, - Serge Mechveliani mech...@botik.ru ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.List permutations
Your function is not equivalent: perm _|_ = _|_ permutations _|_ = _|_ : _|_ On 8/4/09, Slavomir Kaslev slavomir.kas...@gmail.com wrote: A friend mine, new to functional programming, was entertaining himself by writing different combinatorial algorithms in Haskell. He asked me for some help so I sent him my quick and dirty solutions for generating variations and permutations: inter x [] = [[x]] inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) perm [] = [[]] perm (x:xs) = concatMap (inter x) (perm xs) vari 0 _ = [[]] vari _ [] = [] vari k (x:xs) = concatMap (inter x) (vari (k-1) xs) ++ vari k xs After that I found out that nowadays there is a permutation function in the Data.List module: permutations:: [a] - [[a]] permutations xs0= xs0 : perms xs0 [] where perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where interleavexs r = let (_,zs) = interleave' id xs r in zs interleave' _ [] r = (ts, r) interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r in (y:us, f (t:y:us) : zs) I was surprised to find that not only my version is much simpler from the one in Data.List but it also performs better. Here are some numbers from my rather old ghc 6.8.1 running ubuntu on my box: *Main length $ permutations [1..10] 3628800 (10.80 secs, 2391647384 bytes) *Main length $ perm [1..10] 3628800 (8.58 secs, 3156902672 bytes) I would like to suggest to change the current implementation in Data.List with the simpler one. Also, it would be nice to add variations and combinations in the Data.List module. Cheers. -- Slavomir Kaslev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.List permutations
On Tue, Aug 4, 2009 at 8:53 PM, Krasimir Angelovkr.ange...@gmail.com wrote: Your function is not equivalent: perm _|_ = _|_ permutations _|_ = _|_ : _|_ Nice catch. One can use the same trick as in permutations: perm2 [] = [[]] perm2 xxs@(x:xs) = xxs : tail (concatMap (inter x) (perm2 xs)) I've just noticed that permutations and perm enumerate the permutations in different order. On 8/4/09, Slavomir Kaslev slavomir.kas...@gmail.com wrote: A friend mine, new to functional programming, was entertaining himself by writing different combinatorial algorithms in Haskell. He asked me for some help so I sent him my quick and dirty solutions for generating variations and permutations: inter x [] = [[x]] inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) perm [] = [[]] perm (x:xs) = concatMap (inter x) (perm xs) vari 0 _ = [[]] vari _ [] = [] vari k (x:xs) = concatMap (inter x) (vari (k-1) xs) ++ vari k xs After that I found out that nowadays there is a permutation function in the Data.List module: permutations :: [a] - [[a]] permutations xs0 = xs0 : perms xs0 [] where perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where interleave xs r = let (_,zs) = interleave' id xs r in zs interleave' _ [] r = (ts, r) interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r in (y:us, f (t:y:us) : zs) I was surprised to find that not only my version is much simpler from the one in Data.List but it also performs better. Here are some numbers from my rather old ghc 6.8.1 running ubuntu on my box: *Main length $ permutations [1..10] 3628800 (10.80 secs, 2391647384 bytes) *Main length $ perm [1..10] 3628800 (8.58 secs, 3156902672 bytes) I would like to suggest to change the current implementation in Data.List with the simpler one. Also, it would be nice to add variations and combinations in the Data.List module. Cheers. -- Slavomir Kaslev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Slavomir Kaslev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.List permutations
Am Dienstag 04 August 2009 19:48:25 schrieb Slavomir Kaslev: A friend mine, new to functional programming, was entertaining himself by writing different combinatorial algorithms in Haskell. He asked me for some help so I sent him my quick and dirty solutions for generating variations and permutations: inter x [] = [[x]] inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) perm [] = [[]] perm (x:xs) = concatMap (inter x) (perm xs) vari 0 _ = [[]] vari _ [] = [] vari k (x:xs) = concatMap (inter x) (vari (k-1) xs) ++ vari k xs After that I found out that nowadays there is a permutation function in the Data.List module: permutations:: [a] - [[a]] permutations xs0= xs0 : perms xs0 [] where perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where interleavexs r = let (_,zs) = interleave' id xs r in zs interleave' _ [] r = (ts, r) interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r in (y:us, f (t:y:us) : zs) I was surprised to find that not only my version is much simpler from the one in Data.List but it also performs better. Here are some numbers from my rather old ghc 6.8.1 running ubuntu on my box: *Main length $ permutations [1..10] 3628800 (10.80 secs, 2391647384 bytes) *Main length $ perm [1..10] 3628800 (8.58 secs, 3156902672 bytes) But you compare *interpreted* code here, that's not what counts. Prelude Perms length $ perm [1 .. 10] 3628800 (1.20 secs, 1259105892 bytes) Prelude Perms length $ permutations [1 .. 10] 3628800 (0.56 secs, 551532668 bytes) Prelude Perms length $ perm [1 .. 11] 39916800 (13.18 secs, 14651808004 bytes) Prelude Perms length $ permutations [1 .. 11] 39916800 (4.30 secs, 5953485728 bytes) Apparently the library code is more amenable to the optimiser (note that the actual library is faster still: Prelude Data.List length $ permutations [1 .. 10] 3628800 (0.49 secs, 551532812 bytes) Prelude Data.List length $ permutations [1 .. 11] 39916800 (3.73 secs, 5953485816 bytes) I have no idea why). I would like to suggest to change the current implementation in Data.List with the simpler one. Also, it would be nice to add variations and combinations in the Data.List module. Cheers. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.List permutations
On Tue, Aug 4, 2009 at 9:23 PM, Daniel Fischerdaniel.is.fisc...@web.de wrote: Am Dienstag 04 August 2009 19:48:25 schrieb Slavomir Kaslev: A friend mine, new to functional programming, was entertaining himself by writing different combinatorial algorithms in Haskell. He asked me for some help so I sent him my quick and dirty solutions for generating variations and permutations: inter x [] = [[x]] inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) perm [] = [[]] perm (x:xs) = concatMap (inter x) (perm xs) vari 0 _ = [[]] vari _ [] = [] vari k (x:xs) = concatMap (inter x) (vari (k-1) xs) ++ vari k xs After that I found out that nowadays there is a permutation function in the Data.List module: permutations :: [a] - [[a]] permutations xs0 = xs0 : perms xs0 [] where perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where interleave xs r = let (_,zs) = interleave' id xs r in zs interleave' _ [] r = (ts, r) interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r in (y:us, f (t:y:us) : zs) I was surprised to find that not only my version is much simpler from the one in Data.List but it also performs better. Here are some numbers from my rather old ghc 6.8.1 running ubuntu on my box: *Main length $ permutations [1..10] 3628800 (10.80 secs, 2391647384 bytes) *Main length $ perm [1..10] 3628800 (8.58 secs, 3156902672 bytes) But you compare *interpreted* code here, that's not what counts. Prelude Perms length $ perm [1 .. 10] 3628800 (1.20 secs, 1259105892 bytes) Prelude Perms length $ permutations [1 .. 10] 3628800 (0.56 secs, 551532668 bytes) Prelude Perms length $ perm [1 .. 11] 39916800 (13.18 secs, 14651808004 bytes) Prelude Perms length $ permutations [1 .. 11] 39916800 (4.30 secs, 5953485728 bytes) Which version of ghc are you testing on? I guess, it's more recent than mine. Apparently the library code is more amenable to the optimiser (note that the actual library is faster still: Prelude Data.List length $ permutations [1 .. 10] 3628800 (0.49 secs, 551532812 bytes) Prelude Data.List length $ permutations [1 .. 11] 39916800 (3.73 secs, 5953485816 bytes) I have no idea why). Probably because it's compiled (and not interpreted) in this case. -- Slavomir Kaslev ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.List permutations
Am Dienstag 04 August 2009 20:30:58 schrieb Slavomir Kaslev: On Tue, Aug 4, 2009 at 9:23 PM, Daniel Fischerdaniel.is.fisc...@web.de wrote: Which version of ghc are you testing on? I guess, it's more recent than mine. 6.10.3. But I think if you compiled it with 6.8.*, the library code would still be faster, perhaps by a smaller margin. Apparently the library code is more amenable to the optimiser (note that the actual library is faster still: Prelude Data.List length $ permutations [1 .. 10] 3628800 (0.49 secs, 551532812 bytes) Prelude Data.List length $ permutations [1 .. 11] 39916800 (3.73 secs, 5953485816 bytes) I have no idea why). Probably because it's compiled (and not interpreted) in this case. All my times were from compiled (with -O2) code. The question is, why does the same source code produce slower object code in module Perms than in Data.List? I suppose it's because Data.List was compiled with different command line options, but I've no idea which. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Working with GHC HEAD
On Sun, Aug 2, 2009 at 8:32 PM, Bertram Felgenhauer bertram.felgenha...@googlemail.com wrote: Antoine Latter wrote: - Does anyone have a version of 'network' which builds against GHC head? I could bludgeon in the new GHC.IO.FD.FD type myself, but I'd thought I'd ask around first. http://int-e.home.tlink.de/haskell/network-ghc-6.11.dpatch works for me. I've applied this to the network HEAD. Thanks for the patch. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Data.List permutations
Your function is not equivalent: perm _|_ = _|_ permutations _|_ = _|_ : _|_ I have a vague memory that the library version diagonalises properly, so that if you give it a lazy infinite input, it still generates sensible output lazily. If so, this important property should be noted in the haddocks. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] memory management
Nathan, I'm interested in research relating to memory management in Haskell. I'm at the point where I don't know enough to have very specific questions, but I'm especially interested in garbage collection in Haskell, and any available statistics (such as, how long does a thunk typically live before its evaluated, after its evaluated?), or tools that would let me get that sort of information more easily. If any one could be so kind as to point me to relevant research papers or other documentation, it would be very much appreciated. In the early to mid '90s we built various heap-profiling tools to examine the characteristics of heap data in lazy functional programs. You can find papers describing this work by Googling heap profiling. You may be particularly interested in the investigation of heap lag and heap drag -- see for example the ICFP'96 paper. Others have worked on similar tools since, but I'm not sure how extensive heap profiling facilities are in ghc, the most widely used implementation of Haskell. Regards Colin R ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] memory management
I'm not quite sure how to describe this, but are you aware of any
research into converting heap allocations into frames on a stack?
For example, many C functions follow this kind of pattern:
void doSomeStuff(..)
{
// allocate required resources
int a,b,c; // finite amount of temp allocations on stack
int* buffer = malloc(..); // larger (finite) allocation on heap
// free resources
free(buffer); // free heap allocations
// stack allocs popped by compiler.
}
They key aspect is the amount of memory required is calculatable in
advance and allocated/removed in a lump rather than a series of
requests. No pointer-tracking/garbage collection is required.
I can picture similar situations arising in Haskell where for suitable
expressions the compiler could in theory determine that garbage
collection would be unnecessary for a lump of temporary data and simply
allocate/deallocate when starting/finishing evaluating the thunk. The
goal being to simplify garbage collection for this kind of temporary
allocation.
Any thoughts?
Ta,
Sam
-Original Message-
From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org]
On Behalf Of Colin Runciman
Sent: 04 August 2009 12:06
To: Nathan Ricci
Cc: Haskell@haskell.org
Subject: Re: [Haskell] memory management
Nathan,
I'm interested in research relating to memory management in
Haskell. I'm at the point where I don't know enough to have very
specific questions, but I'm especially interested in garbage
collection
in Haskell, and any available statistics (such as, how long does a
thunk
typically live before its evaluated, after its evaluated?), or tools
that would let me get that sort of information more easily. If any one
could be so kind as to point me to relevant research papers or other
documentation, it would be very much appreciated.
In the early to mid '90s we built various heap-profiling tools to
examine the characteristics of heap data in lazy functional programs.
You can find papers describing this work by Googling heap profiling.
You may be particularly interested in the investigation of heap lag
and heap drag -- see for example the ICFP'96 paper. Others have
worked on similar tools since, but I'm not sure how extensive heap
profiling facilities are in ghc, the most widely used implementation of
Haskell.
Regards
Colin R
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] memory management
On Tue, Aug 4, 2009 at 7:30 AM, Sam Martinsam.mar...@geomerics.com wrote: I can picture similar situations arising in Haskell where for suitable expressions the compiler could in theory determine that garbage collection would be unnecessary for a lump of temporary data and simply allocate/deallocate when starting/finishing evaluating the thunk. The goal being to simplify garbage collection for this kind of temporary allocation. Any thoughts? Ta, Sam Sounds like region inference to me. (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) -- gwern signature.asc Description: OpenPGP digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] memory management
Sounds like region inference to me. (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) Thanks, yes, that's exactly what I had in mind. Is anything like this is done in GHC? Ta, Sam ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] memory management
On 04/08/2009 13:33, Sam Martin wrote: Sounds like region inference to me. (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) Thanks, yes, that's exactly what I had in mind. Is anything like this is done in GHC? Not at the moment, no. Bear in mind that with generational GC, allocating memory that quickly becomes garbage is quite cheap. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] memory management
Hi, staying in the realm of the explicit and pragmatic, various libraries in Haskell do provide safeexplicit region/alloca/stack allocation actions, e.g., Foreign.Marshal.Alloc.allocaBytes :: Int - (Ptr a - IO b) - IO b with the promise that the pointer doesn't escape here (you could constrain this using the type system, if you so wish..) I don't know if the GHC RTS still(?) provides hooks for allocating alloca objects specially. There's been some work on monadic regions too; worth looking at. hth --sigbjorn On 8/4/2009 15:49, Simon Marlow wrote: On 04/08/2009 13:33, Sam Martin wrote: Sounds like region inference to me. (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) Thanks, yes, that's exactly what I had in mind. Is anything like this is done in GHC? Not at the moment, no. Bear in mind that with generational GC, allocating memory that quickly becomes garbage is quite cheap. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] memory management
On Tue, Aug 4, 2009 at 2:49 PM, Simon Marlow marlo...@gmail.com wrote: On 04/08/2009 13:33, Sam Martin wrote: Sounds like region inference to me. (https://secure.wikimedia.org/wikipedia/en/wiki/Region_inference) Thanks, yes, that's exactly what I had in mind. Is anything like this is done in GHC? Not at the moment, no. Bear in mind that with generational GC, allocating memory that quickly becomes garbage is quite cheap. Speculation time... I have no real basis for this, and I'm quite possibly overlooking a lot of details... There may be other benefits to doing this kind of escape-analysis, aside from making short-lived allocations cheaper (which are indeed already quite cheap)... If you can associate a bunch of allocations with a point in the stack, even if it's very low in the stack (and thus long-lived), there's a lot less work that the GC needs to do to track all the other allocations (in the global heap), since there's just fewer of them. Also, each stack is associated with a specific thread, so it sort of brings you half-way to per-thread GC, in the sense that all the stack-based resource management is per-thread. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re[2]: [Haskell] memory management
Hello Sigbjorn, Tuesday, August 4, 2009, 6:11:09 PM, you wrote: this using the type system, if you so wish..) I don't know if the GHC RTS still(?) provides hooks for allocating alloca objects specially. it's allocated as usual object, these are cheap anyway as far as it freed before minor GC occurs (which is called after each 512kb allocated, by default) afair, jhc uses region inference -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: Simple quirk in behavior of `mod`
That how I was taught to round in school, so it doesn't seem at all unusual to me. 2009/7/23 Matthias Görgens matthias.goerg...@googlemail.com: Round-to-even means x.5 gets rounded to x if x is even and x+1 if x is odd. This is sometimes known as banker's rounding. OK. That's slightly unusual indeed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FFI: Problem with Signal Handler Interruptions
Dear list members,
In February this year there was a posting Why does sleep not work?
(http://www.haskell.org/pipermail/haskell-cafe/2009-February/055400.html).
The problem was apparently caused by signal handler interruptions. I
noticed the same (not with sleep though) when doing some FFI work and
compiled the following test program:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign.C.Types
import Control.Concurrent
sleep :: IO ()
sleep = c_sleep 3 = print
fails :: IO ()
fails = sleep
works :: IO ()
works = forkIO sleep return ()
main :: IO ()
main = fails works threadDelay 300
foreign import ccall unsafe unistd.h sleep
c_sleep :: CUInt - IO CUInt
When compiled with GHC (using --make -threaded), it will print 3
immediately (from the fails function) and after 3 seconds 0 (from
works), before it finally exits. man sleep(3) tells me that sleep
returns 0 on success and if interrupted by a signal the number of
seconds left to sleep. Clearly fails is interrupted by a signal
(which seems to be SIGVTALRM). This was mentioned in the discussion
from February.
I would like to know why fails fails and works works, i.e. why is
sleep not interrupted when run in a separate thread? And what can be
done to make sleep work in the main thread? It wouldn't be wise to
block SIGVTALRM, wouldn't it?
Many thanks,
Levi
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Proposal: TypeDirectedNameResolution
Henning Thielemann wrote: Heinrich Apfelmus schrieb: Note that there are alternative solution for this particular problem. For instance, a version of qualified with different semantics will do; something like this import Data.List import sometimes qualified Data.Map as Map Isn't that quite the same as import Data.Map as Map ? Not quite. The intended difference is that ambiguous names default to the module that imports them unqualified. I.e. import Data.List import sometimes qualified Data.Map as Map map -- Data.List.map or Data.Map.map ? will silently default to Data.List.map . But you risk breaking packages when new qualifiers are added to imported modules. Yeah, that's kinda unavoidable if you don't want to qualify so many names. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Cyclic data declarations
Job Vranish wrote: I think that in an ideal world haskell would have some way of allowing infinite types if you asked for them explicitly (say in the type signature somehow) and then just automatically wrap/unwrap everything with newtypes behind the scenes (well maybe in an ideal world it wouldn't have to do this either). This wouldn't change the underlying semantics, but would get rid of alot of messyness. Infinite types are possible, My toy language infers infinite types just fine :) and I think Ocaml has an option for them, but niether of those have type classes so I'm not sure how compatable the idea is with haskell in general. There was a thread with a compelling reason against vanilla infinite types some time ago: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/17103 Of course, you can have all the recursion you want by using newtype , it's just that you need to annotate them with the extraneous constructor. In fact, that's exactly the purpose of the constructor; think of it as an aid for the type checker. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: The Haskell Platform 2009.2.0.2
Don Stewart wrote: andrewcoppin: Maybe I'm being dense... Is there somewhere which lists what's changed from the last release? Oh, sorry, that will be in the web announcement tomorrow. No problem. ;-) Given the Platform's aims, I think it would be a good idea to make it blindingly obvious how to find a complete changelog for every version of the platform yet released (plus a release date for each). Essentially, * GHC 6.10.4 * network upgraded to 2.2.1.4 * Improvements to the MacOSX installer * Improvements to crazy popular Windows installer * Significant improvements in Debian support for Haskell * Gentoo now has full support for the Haskell Platform So... mostly just improvements to the installer then? ;-) (Oh, and new GHC - which AFAIK is mostly a bugfix update anyway...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] funct.prog. vs logic prog., practical Haskell
On Sun, Aug 2, 2009 at 12:25 PM, Petr Pudlak d...@pudlak.name wrote:
I'd like to convince people at our university to pay more attention to
functional languages, especially Haskell. Their arguments were that
(1) Functional programming is more academic than practical.
(2) They are using logic programming already (Prolog); why is Haskell
better than Prolog (or generally a functional language better than a
logic programming language)?
Regarding (1), today it's common to do functional programming in
industrially accepted languages, at least if you want to be productive :)
Take for example the following C# code, taken from production code:
var graphs = selection.SelectMany(
e = e.SelfAndIntraGraphAncestors()
.OfTypeIGraphContainer()
.Take(1)
.SelectMany(gc = gc.ChildGraphs));
Each of these C# methods work on lazy streams, so this even lazy functional
programming in a sense :) (albeit with potential side effects)
I could write this in imperative style, something like this (but it's not
the same, the code below is strict, a lazy version would be much longer,
unless I cheat and use C#'s yield statement)
var graphContainers = new ListIGraphContainer();
foreach( var entity in selection )
{
foreach( var ancestor in entity.SelfAndIntraGraphAncestors() )
{
var graphContainer = ancestor as IGraphContainer;
if( graphContainer != null )
{
foreach( var childGraph in graphContainer.ChildGraphs )
{
graphContainers.Add(childGraph);
}
break;
}
}
}
Obviously the second one is much less declarative and more difficult to read
(and maintain).
So really, any good industrial programmer should master at least the basics
of functional programming. Haskell might be one of the most beautiful and
elegant languages to use for learning functional programming.
Also IMHO any experienced programmer should understand that although popular
imperative programming languages like C++, C#, Java, Python, etc are more
powerful than pure functional languages (in these sense that you can peek
and poke around without restrictions like a crazy chicken), in practice this
power is so difficult to control that it's a bit like giving everybody the
right to carry a gun in public so people would feel safer ;-)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell interface files: Why used? What about same data in object files?
I am trying to understand the design of the Haskell interface files. Why are they a separate file rather than having the same data in the object file generated by the compiler? (Naively, it seems to me this would work also. Am I missing something?) Placing interface information into object files would be a perfectly reasonable design decision for a compiler. The language standard itself does not mandate the use of interface files (although it did once, around Haskell 1.2), nor any particular format, so a compiler is free to use whatever strategy it wishes. Some good reasons for having a separate interface are: they can be human-readable and human-writable (ghc's do not fulfill this criterion); they can be used to bootstrap mutually recursive modules in the absence of any object files (ghc uses .hs-boot files instead); other tools can extract information about modules without having to understand either the full Haskell syntax or the object language. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: yst 0.2.1
This sounds great! I really like using yaml for web development. However, my last use case was for a non-techie, so I created a little desktop application for editing the yamlbase, if you excuse the neologism. I think it worked quite well, because the user was then presented with a friendly looking system ( I even wrote a little calendar widget :) without having to spend the precious moneys on dynamic hosting. In the end, everyone was very happy. Actually, it was written in Ruby, and Shoes, and the data part was a lot less powerful than the yst query language there - but I think that an analogous tool would be useful; a GUI which creates yst scripts, would make yst a very powerful tool for non-techies. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell interface files: Why used? What about same data in object files?
Hi Some good reasons for having a separate interface are: they can be human-readable and human-writable (ghc's do not fulfill this criterion); they can be used to bootstrap mutually recursive modules in the absence of any object files (ghc uses .hs-boot files instead); other tools can extract information about modules without having to understand either the full Haskell syntax or the object language. An additional reason is that for some changes of .hs file (where just the implementation changes) the .o file can be regenerated without touching the .hi file. This allows more accurate build dependencies and less recompilation. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Cyclic data declarations
In a lot of cases though annotating all the recursive aspects with newtypes is a _royal_ pain, and is even worse if you want the datatypes to be instances of common type classes like Functor, Applicative, etc... (try it sometime) I don't advocate allowing infinite types wholesale, just in specific cases with a special annotation (like a type signature specifying the allowed infinite type). I think this would be the best of both worlds. - Job On Tue, Aug 4, 2009 at 4:23 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Job Vranish wrote: I think that in an ideal world haskell would have some way of allowing infinite types if you asked for them explicitly (say in the type signature somehow) and then just automatically wrap/unwrap everything with newtypes behind the scenes (well maybe in an ideal world it wouldn't have to do this either). This wouldn't change the underlying semantics, but would get rid of alot of messyness. Infinite types are possible, My toy language infers infinite types just fine :) and I think Ocaml has an option for them, but niether of those have type classes so I'm not sure how compatable the idea is with haskell in general. There was a thread with a compelling reason against vanilla infinite types some time ago: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/17103 Of course, you can have all the recursion you want by using newtype , it's just that you need to annotate them with the extraneous constructor. In fact, that's exactly the purpose of the constructor; think of it as an aid for the type checker. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Thinking about what's missing in our library coverage
+++ Don Stewart [Aug 03 09 22:53 ]: alexander.dunlap: o pandoc — markdown, reStructuredText, HTML, LaTeX, ConTeXt, Docbook, OpenDocument, ODT, RTF, MediaWiki, groff No. Pandoc is too actively developed to go into the HP. It's also much more of an end-user application than a standard library - it's applications are not general enough to be included in the standard distribution. One comment on your thoughtful post. What role does having unique capabilities for the Haskell Platform play? Our base library is already notable for having OpenGL support out of the box. Maybe markup/markdown formats (for example) would also help Haskell stand out from the crowd. A similar case would be gtk2hs out of the box (Python supplied Tcl guis). On the other hand, maybe the HP should be aiming to be comprehensive enough to /support/ pandoc without additional dependencies. I agree that pandoc shouldn't be in the HP. Also, although we ought to have a zip encoding package, I'm not sure it should be zip-archive (I'm the author). zip-archive is not complete; there are some kinds of zip files it can't parse. Quoting the documentation: there is no support for encryption, zip files that span multiple disks, ZIP64, OS-specific file attributes, or compression methods other than Deflate. A better solution, perhaps, would be a binding to libzip. In this connection, I want to make a general point about the HP: In a way, it doesn't matter so much which additional pure Haskell libraries it includes, because once you have cabal install, you can get anything easily. For bindings to C libraries, it's another story. pcre-light is a good example. If I want to tell someone how to install pandoc with syntax highlighting, I can't just say, Get the HP and then cabal install pandoc -fhighlighting. I have to say: First, install the pcre library, if it's not already on your system... -- and you lose a lot of users at this step. Havig high-quality, high-level bindings to standard libraries like pcre, libzip, etc., together with the C libraries themselves, in HP would be very useful. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Split package organization (AntTweakBar, Cabal, darcs)
I'm working on a Haskell binding for AntTweakBar, a light user interface for OpenGL applications (http://www.antisphere.com/Wiki/tools:anttweakbar). I have three questions about how to organize it as a Haskell package or packages, Cabal, and darcs. First, since AntTweakBar provides support for handling events from GLUT, GLFW, and SDL, as well as customizable event handling from other sources, would it be best to divide it into four packages -- AntTweakBar (core), AntTweakBar-GLUT, AntTweakBar-GLFW, and AntTweakBar-SDL? A few other package groups on Hackage have taken this approach of splitting according to the user interface: for example, grapefruit-ui-gtk, reactive-glut, though not on such a large scale as I am proposing. Advantages of four packages rather than one: -- Fewer build dependencies, for example, for users who want to use just SDL and not have to install GLUT or GLFW. -- If one of the build dependencies is broken (as for example GLFW is just at the moment with the latest OpenGL), users could still build the other AntTweakBar-* packages. Disadvantages: -- More packages to install, for those who want it all. -- I might seem to be grabbing an undue share of the package namespace. And it could get way out of hand if I further split the examples from the library, making AntTweakBar-(base|GLUT|GLFW|SDL)-(lib|examples) = 8 packages! Would that be a problem? -- Possible inconvenience for the developer (see second question). Second question, assuming the four-way split is the best way to package this: my impression is that a directory can have only one cabal package file and one Setup.hs file. (http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html, Creating a Package) So for example I could not have, in the same directory, AntTweakBar.cabal, AntTweakBar-GLUT.cabal, etc. That means the four packages would each have to have their own directories, and it is sometimes inconvenient to be jumping back and forth between them. Any good way around that? Third question, assuming four separate directories for the four Cabal package files. Putting all four into one darcs repo (i.e., the darcs repo would have one main directory and a subdirectory for each package) seems to make it easier to coordinate development of the related packages -- for example, a single 'darcs rec -a' takes care of recording the related changes in all four subdirectories. Any reason not to do it that way? -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \/\_/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Tue, Aug 4, 2009 at 4:54 PM, John MacFarlanej...@berkeley.edu wrote: [..] In this connection, I want to make a general point about the HP: In a way, it doesn't matter so much which additional pure Haskell libraries it includes, because once you have cabal install, you can get anything easily. For bindings to C libraries, it's another story. AFAIU the plan is to separate GHC and its platform packages, so in the future it might not be that easy to get to the point where you _can_ run 'cabal install'. pcre-light is a good example. If I want to tell someone how to install pandoc with syntax highlighting, I can't just say, Get the HP and then cabal install pandoc -fhighlighting. I have to say: First, install the pcre library, if it's not already on your system... -- and you lose a lot of users at this step. This is a good point, but to some extent this brings us back to a discussion that's specific to systems with broken or non-existing package managers. Wouldn't it be better to deal with _that_ outside of HP? /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Tue, Aug 4, 2009 at 6:13 PM, Magnus Therningmag...@therning.org wrote: AFAIU the plan is to separate GHC and its platform packages, so in the future it might not be that easy to get to the point where you _can_ run 'cabal install'. Absolutely not. The point of HP is to make the path from bare OS to complete Haskell installation including cabal-install consist of a single step: 1. Install Haskell Platform This is a good point, but to some extent this brings us back to a discussion that's specific to systems with broken or non-existing package managers. Wouldn't it be better to deal with _that_ outside of HP? AIUI, on systems with working package managers, HP will be a metapackage which depends on the appropriate real packages. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
Hello John, Tuesday, August 4, 2009, 7:54:14 PM, you wrote: methods other than Deflate. A better solution, perhaps, would be a binding to libzip. it's hard to find feature list for libzip, but i suggest to look into 7zip library support. it supports lot of archive formats, including zip, rar, 7z, and for zip supports zip64, unicode filenames, aes encryption, bzip2/lzma. license is lgpl, API is COM-like that may be a hard part -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Mon, Aug 3, 2009 at 10:40 PM, Alexander Dunlap alexander.dun...@gmail.com wrote: o unicode text [text] [text-icu] — packed, unicode text This is essential, although I don't know if it is stable enough for the platform (?). I'm doing some cleaning up of the APIs at the moment for usability purposes, but it would be really, really nice to have some help with testing, performance measurement, and tuning. The code is very clean and easy to understand :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cyclic data declarations
There are a number of ways to fix this of various complexity, depending on
how many kinds of statements you have in your language and how adverse you
are to code duplication.
One option is to remove the recursion from your statement type and to make a
'base functor' like you've proposed with your link based ADT.
data Stmt a = Slf Test [a] [a] | ...
and then make that recursive by using a newtype to make the folding
explicit.
newtype Mu f = In { out :: f (Mu f) }
Now you can work on Mu Stmt which is a fixed point of your statement data
type and get your original meaning, or work with Stmt Int and have a
statement type that indexes statements by # and can look them up in a
control flow graph or some such.
You can even attach annotations at every level by using a different ADT to
wrap yourself up. (For the category-theory inclined, this gives rise to
something known as the cofree comonad of your base functor)
newtype Ann f e = Ann e (f (Ann f e))
So now you can have something like:
Ann 2 (SIf ... (Ann 1 (Var X)) (Ann 1 (Var Y))
if you wanted to count the number of variable references in a subtree for
instance.
On the other hand, rarely does a programming language consist solely of
statements. You often have expressions and other types floating around and
tying with an explicit Mu can sometimes get in the way of that.
Forgetting those definitions for a moment, we can try to fix the one
statement type problem.
You can use some interesting GADT based solutions to fix that, but another
approach that I've been using recently is to use explicit recursion in a
slightly different place.
type (v : f) = f (v f)
data Var (f :: * - *) = V String
data Exp f
= App (Exp : f) (Exp : f)
| Lam (Var : f) (Exp : f)
| Var (Var : f)
data Stmt f
= If (Exp : f) [Stmt : f] [Stmt : f]
| ...
Now we can have a lot of different kinds of expressions based on what we
substitute in for f.
data Ann a e = Ann a e
newtype Mu e = Mu e
data Free a e = Return a | Free e
newtype Base a e = Base a
now:
Stmt (Base Int) -- is a statement wrapped around integers
Stmt (Ann Int) -- is a statement wrapped around subtrees of various types
annotated with integers
Stmt Mu -- is your old statement type with newtype Mu wrappers on its
children.
Stmt (Free Int) is your old statement data type, with occasional integer
place holders for unexpanded portions of the tree, they can act as standins
for Exps, Vars, etc.
You can then borrow a trick from a recent post of mine:
http://comonad.com/reader/2009/incremental-folds/
with some minor modifications to extract data incrementally or return
results as you grow the syntax tree.
The design space is large and there are a lot of options to explore around
here, so don't take any of this as the one and only way to implement a
syntax ADT. =)
-Edward Kmett
On Sun, Aug 2, 2009 at 1:25 AM, Michal D. michal.dobrog...@gmail.comwrote:
I'm in the process of writing a toy compiler but I'm having some
trouble trying to make my datatypes general. For example, using parsec
I parse statements as:
data Stmt = SIf Test [Stmt] [Stmt] | ...
However, when it's time to create a control flow graph it would be
nice to represent statements as (the Int's signify the node id's for
either case of the if statement):
data Stmt = SIf Test Int Int | ...
So, in a eureka moment I decided that this should be allowable with
the following declaration:
data Stmt link = SIf Test link link | ...
Ofcourse, the problem is trying to declare the resulting type for
parsing: parse - Stmt [Stmt [Stmt ]]. Any hints on whether
there is a way to accomplish what I'm trying to do or do I have to
bite the bullet and declare two seperate datatypes? I tried being
clever and declaring a 'helper' type as type StmtRec = Stmt [StmtRec]
but to no avail... GHC won't let it slide: Cycle in type synonym
declarations!
Cheers,
Michal
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
Max Rabkin wrote: On Tue, Aug 4, 2009 at 6:13 PM, Magnus Therningmag...@therning.org wrote: AFAIU the plan is to separate GHC and its platform packages, so in the future it might not be that easy to get to the point where you _can_ run 'cabal install'. Absolutely not. The point of HP is to make the path from bare OS to complete Haskell installation including cabal-install consist of a single step: 1. Install Haskell Platform Yes, indeed, if there exists a pre-compiled, binary version of HP for your platform. Also, note that you _didn't_ say that the goal of HP is to limit the pain of installing bindings to C libraries. This is a good point, but to some extent this brings us back to a discussion that's specific to systems with broken or non-existing package managers. Wouldn't it be better to deal with _that_ outside of HP? AIUI, on systems with working package managers, HP will be a metapackage which depends on the appropriate real packages. Yes, but again, the role of HP shouldn't be to limit the pain of installing bindings to C libraries. What I'm saying is that it's a worthwhile goal to limit that pain, but it should be handled outside of HP. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
On Tue, Aug 4, 2009 at 11:56 PM, Magnus Therningmag...@therning.org wrote: AIUI, on systems with working package managers, HP will be a metapackage which depends on the appropriate real packages. Yes, but again, the role of HP shouldn't be to limit the pain of installing bindings to C libraries. What I'm saying is that it's a worthwhile goal to limit that pain, but it should be handled outside of HP. How could one do that? On systems with package managers, the platform won't bundle C libraries, but depend on them (this is correct: if software does in fact depend on a C library, it should declare that dependency). On systems without package managers, we could provide some form of sub-platform containing C libraries or a system for installing them, but then installing a Haskell system is no longer a one-step process. It's been a while since I was a regular Windows user, but it seemed then that bundling dependencies was the most common (only?) solution. /M --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage Download Rankings August 2009
Total package downloads on Hackage, by August 1 2009, http://www.galois.com/~dons/hackage/august-2009/popularity-august-2009.html All packages by month: http://www.galois.com/~dons/hackage/august-2009/hackage-august-2009.html Raw data: http://www.galois.com/~dons/hackage/august-2009/hackage-downloads-august-2009.csv Enjoy. -- Don P.S. For reference, here's the data from March, http://www.galois.com/~dons/hackage/popularity.html and analysis at the time http://www.galois.com/blog/2009/03/23/one-million-haskell-downloads/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A problem with bytestring 0.9.1.4 hGetBuf: invalid argument
Hi all,
I've recently came across a problem when processing a large text file
(around 2G in size).
I wrote a Haskell program to count the number of lines in the file.
module Main where
import System
import qualified Data.ByteString.Char8 as S
-- import Prelude as S
main :: IO ()
main = do { args - getArgs
; case args of
{ [ filename ] -
do { content - S.readFile filename
; let lns = S.lines content
; putStrLn (show $ length lns)
}
; _ - error Usage : Wc file
}
}
I get this error, if I use the ByteString module,
./Wc a.out
Wc: {handle: a.out}: hGetBuf: invalid argument (illegal buffer size
(-1909953139))
Otherwise, it returns me the result.
Another observation is that if I reduce the size of the file, the ByteString
version works too.
Is it a known limitation?
Regards,
Kenny
A generator program that generate large file. (Warning, it is very slow, I
don't know how to speed it up)
-- generate a file
module Main where
import System
import qualified Data.ByteString.Char8 as S
l :: S.ByteString
l = S.pack All work, no fun, make Kenny a dull boy.
main :: IO ()
main = do { args - getArgs
; case args of
{ [ n, fn ] - do { let i = read n
; mapM_ (\s - S.appendFile fn s) (take i $
repeat l)
}
; _ - return ()
}
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A problem with bytestring 0.9.1.4 hGetBuf: invalid argument
haskellmail:
Hi all,
I've recently came across a problem when processing a large text file (around
2G in size).
I wrote a Haskell program to count the number of lines in the file.
module Main where
import System
import qualified Data.ByteString.Char8 as S
-- import Prelude as S
main :: IO ()
main = do { args - getArgs
; case args of
{ [ filename ] -
do { content - S.readFile filename
; let lns = S.lines content
; putStrLn (show $ length lns)
}
; _ - error Usage : Wc file
}
}
I get this error, if I use the ByteString module,
./Wc a.out
Wc: {handle: a.out}: hGetBuf: invalid argument (illegal buffer size
(-1909953139))
Otherwise, it returns me the result.
Another observation is that if I reduce the size of the file, the ByteString
version works too.
Is it a known limitation?
Yes, you need to use Data.ByteString.Lazy.Char8 to process files larger
than this on a 32 bit machine (you'll have more space on a 64 bit
machine).
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A problem with bytestring 0.9.1.4 hGetBuf: invalid argument
Oh right. Thanks for pointing out. :)
On Wed, Aug 5, 2009 at 10:06 AM, Don Stewart d...@galois.com wrote:
haskellmail:
Hi all,
I've recently came across a problem when processing a large text file
(around
2G in size).
I wrote a Haskell program to count the number of lines in the file.
module Main where
import System
import qualified Data.ByteString.Char8 as S
-- import Prelude as S
main :: IO ()
main = do { args - getArgs
; case args of
{ [ filename ] -
do { content - S.readFile filename
; let lns = S.lines content
; putStrLn (show $ length lns)
}
; _ - error Usage : Wc file
}
}
I get this error, if I use the ByteString module,
./Wc a.out
Wc: {handle: a.out}: hGetBuf: invalid argument (illegal buffer size
(-1909953139))
Otherwise, it returns me the result.
Another observation is that if I reduce the size of the file, the
ByteString
version works too.
Is it a known limitation?
Yes, you need to use Data.ByteString.Lazy.Char8 to process files larger
than this on a 32 bit machine (you'll have more space on a 64 bit
machine).
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
