Re: [Haskell-cafe] Web application interface
Absolutely; the goals I have are minimal dependencies and no warnings for compilation ;). On Sat, Jan 16, 2010 at 9:35 PM, Nicolas Pouillard < nicolas.pouill...@gmail.com> wrote: > Excerpts from Michael Snoyman's message of Wed Jan 13 15:46:12 +0100 2010: > > Hi, > > > > I recently read (again) the wiki page on a web application interface[1] > for > > Haskell. It seems like this basically works out to Hack[2], but using an > > enumerator instead of lazy bytestring in the response type. Is anyone > > working on implementing this? If not, I would like to create the package, > > though I wouldn't mind some community input on some design decisions: > > Wai seems to lightly rely on ImpredicativeTypes which becomes deprecated > in GHC 6.12 and could be removed in 6.14. This seems to be due to the > response tuple. > > Is there any plan to change this to a more forward compatible solution? > > -- > Nicolas Pouillard > http://nicolaspouillard.fr > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC bug? Cabal bug? Haddock bug?
AHA! > Note that after running "cabal haddock" we re-build all of our .hi and > .o files EXCEPT ./dist/build/HSsyb-with-class-0.6.1.o > > And now, since TH generates random symbols, we have symbols in the new > .hi files that aren't in the old (and only) HSsyb-with-class-0.6.1.o. So, this leaves us with two questions: 1) Why does "cabal haddock" rebuild the .hi and .o files? On the face of it, this seems odd: Build documentation and your library gets rebuilt? 2) Why doesn't Instances.o get rebuilt? Surely this has something to do with the fact that Instances.hs contains only orphan instances. But any answer here just leads to a raft of other questions: Surely this problem would plague other modules have have similar source files? What is Haddock doing? If Haddock needs the .hi files, why not just use them? If it just "builds them to be sure", why in the dist tree and not some place temporary? If is going to build .o files, why not all? Curiouser. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Data.Ring -- Pre-announce
One other name I've heard used, pretty much ever since the dos days when the 16 character fixed sized keyboard buffer was the first instance of such a structure I'd seen, was a 'ring buffer'. Data.RingBuffer perhaps? I agree that Data.Ring is a terrible name, partially because I already have a Data.Ring in the monoids package! -Edward Kmett On Sat, Jan 16, 2010 at 1:40 PM, Henning Thielemann < schlepp...@henning-thielemann.de> wrote: > wren ng thornton schrieb: > > Tom Tobin wrote: >> >>> - Heinrich Apfelmus wrote: >>> Since the name Ring is already taken by an ubiquitous mathematical structure, and thus already in hackage for example as Algebra.Ring in the numeric-prelude , I suggest to call the data structure Necklace instead. >>> >>> Is Necklace a known name for this data structure? If not Ring, I was >>> thinking Circular might be an appropriate name. >>> >> >> I'm not sure if there's a canonical name, except perhaps "circular queue". >> Necklace is cute, though Circular or CircleQueue might be better. I'd also >> advise strongly against using Ring in order to avoid confusing nomenclature. >> (Loop should be avoided for similar reasons.) >> > When reading "Ring" first time in the e-mail subject, I also thought it > would be about the algebraic structure with that name. > > CircularList seems fine to me. Necklace is nice but might be missed when > someone searches for that data structure on Hackage. > > > ___ > 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] What's going on here?
Dumb! I've been hacking Lisp and just slipped over to Haskell to check on something. Thanks, Michael --- On Sat, 1/16/10, VoidPrayer wrote: From: VoidPrayer Subject: Re: [Haskell-cafe] What's going on here? To: haskell-cafe@haskell.org Date: Saturday, January 16, 2010, 10:05 PM 在 2010年 1月 17日 星期日 11:02:59，michael rice 寫道: > I don't see anything wrong with this function, which just subtracts 1 from > the first element of an Int list (if there is a first element). > > Michael > > My function: > > dropFirst :: [Int] -> [Int] > dropFirst [] = [] > dropFirst (x:xs) = (x-1) : xs > > My output: > > :l dropfirst > > [1 of 1] Compiling Main ( dropfirst.hs, interpreted ) > Ok, modules loaded: Main. > *Main> dropFirst [3 4 5 6] Use dropFirst [3,4,5,6], I think. > > :1:11: > No instance for (Num (t -> t1 -> t2 -> Int)) > arising from the literal `3' at :1:11-17 > Possible fix: > add an instance declaration for (Num (t -> t1 -> t2 -> Int)) > In the expression: 3 4 5 6 > In the first argument of `dropFirst', namely `[3 4 5 6]' > In the expression: dropFirst [3 4 5 6] > *Main> > ___ 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] What's going on here?
>>*Main> dropFirst [3 4 5 6] List members are separated by commas. Space in Haskell denotes function application. Hence the error message: Hence t > No instance for (Num (t -> t1 -> t2 -> Int)) > arising from the literal `3' at :1:11-17 > Possible fix: > add an instance declaration for (Num (t -> t1 -> t2 -> Int)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: AlternativePrelude extension
On Sun, 2010-01-17 at 00:09 +0100, Sjur Gjøstein Karevoll wrote: > However, the option to set language extension globally is still > available, either as an option to the compiler when building, or in > the cabal file describing the package. Hmm. Since the extensions should be specified in Cabal anyway (at least I guess it does some detection if compiler supports them) shouldn't it be specified in one place? Regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's going on here?
在 2010年 1月 17日 星期日 11:02:59，michael rice 寫道: > I don't see anything wrong with this function, which just subtracts 1 from > the first element of an Int list (if there is a first element). > > Michael > > My function: > > dropFirst :: [Int] -> [Int] > dropFirst [] = [] > dropFirst (x:xs) = (x-1) : xs > > My output: > > :l dropfirst > > [1 of 1] Compiling Main ( dropfirst.hs, interpreted ) > Ok, modules loaded: Main. > *Main> dropFirst [3 4 5 6] Use dropFirst [3,4,5,6], I think. > > :1:11: > No instance for (Num (t -> t1 -> t2 -> Int)) > arising from the literal `3' at :1:11-17 > Possible fix: > add an instance declaration for (Num (t -> t1 -> t2 -> Int)) > In the expression: 3 4 5 6 > In the first argument of `dropFirst', namely `[3 4 5 6]' > In the expression: dropFirst [3 4 5 6] > *Main> > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What's going on here?
I don't see anything wrong with this function, which just subtracts 1 from the first element of an Int list (if there is a first element). Michael My function: dropFirst :: [Int] -> [Int] dropFirst [] = [] dropFirst (x:xs) = (x-1) : xs My output: > :l dropfirst [1 of 1] Compiling Main ( dropfirst.hs, interpreted ) Ok, modules loaded: Main. *Main> dropFirst [3 4 5 6] :1:11: No instance for (Num (t -> t1 -> t2 -> Int)) arising from the literal `3' at :1:11-17 Possible fix: add an instance declaration for (Num (t -> t1 -> t2 -> Int)) In the expression: 3 4 5 6 In the first argument of `dropFirst', namely `[3 4 5 6]' In the expression: dropFirst [3 4 5 6] *Main> ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC bug? Cabal bug? Haddock bug?
2010/1/16 Mark Lentczner : > Indeed - all those look exactly like the same issue. > >> And the workaround: >> http://groups.google.com/group/happs/msg/1e7761d421b0e5eb > > That doesn't fix the real issue: It causes happstack-data to not need the > thing that is built wrong in syb-with-class. I believe my work-around (build > syb-with-class w/o documentation) will be a more universal workaround, as at > that point the syb-with-class install is no longer broken. > >> Here's the GHC bug report: http://hackage.haskell.org/trac/ghc/ticket/3799 > > Registration for that trac is broken, so I couldn't update that ticket. I see > that you've added pointers to my post, thank you! Perhaps you can also add a > note that the issue seems to have to do with something that cabal does > differently when there is a documentation step enabled. > Here's the good stuff. First, I did a "cabal configure && cabal build" for syb-with-class. And then: > antoine-latters-macbook:syb-with-class-0.6.1 alatter$ find . | grep \\.o$ | xargs ls -l -rw-r--r-- 1 alatter staff 121496 Jan 16 20:04 ./dist/build/Data/Generics/SYB/WithClass/Basics.o -rw-r--r-- 1 alatter staff5888 Jan 16 20:04 ./dist/build/Data/Generics/SYB/WithClass/Context.o -rw-r--r-- 1 alatter staff 157220 Jan 16 20:04 ./dist/build/Data/Generics/SYB/WithClass/Derive.o -rw-r--r-- 1 alatter staff 403216 Jan 16 20:04 ./dist/build/Data/Generics/SYB/WithClass/Instances.o -rw-r--r-- 1 alatter staff 602752 Jan 16 20:04 ./dist/build/HSsyb-with-class-0.6.1.o antoine-latters-macbook:syb-with-class-0.6.1 alatter$ find . | grep \\.hi$ | xargs ls -l -rw-r--r-- 1 alatter staff 33600 Jan 16 20:04 ./dist/build/Data/Generics/SYB/WithClass/Basics.hi -rw-r--r-- 1 alatter staff2367 Jan 16 20:04 ./dist/build/Data/Generics/SYB/WithClass/Context.hi -rw-r--r-- 1 alatter staff 13960 Jan 16 20:04 ./dist/build/Data/Generics/SYB/WithClass/Derive.hi -rw-r--r-- 1 alatter staff 166039 Jan 16 20:04 ./dist/build/Data/Generics/SYB/WithClass/Instances.hi antoine-latters-macbook:syb-with-class-0.6.1 alatter$ cabal haddock Running Haddock for syb-with-class-0.6.1... Preprocessing library syb-with-class-0.6.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: ffi-1.0, rts-1.0 Documentation created: dist/doc/html/syb-with-class/index.html antoine-latters-macbook:syb-with-class-0.6.1 alatter$ find . | grep \\.o$ | xargs ls -l -rw-r--r-- 1 alatter staff 121496 Jan 16 20:05 ./dist/build/Data/Generics/SYB/WithClass/Basics.o -rw-r--r-- 1 alatter staff5896 Jan 16 20:05 ./dist/build/Data/Generics/SYB/WithClass/Context.o -rw-r--r-- 1 alatter staff 157220 Jan 16 20:05 ./dist/build/Data/Generics/SYB/WithClass/Derive.o -rw-r--r-- 1 alatter staff 403216 Jan 16 20:05 ./dist/build/Data/Generics/SYB/WithClass/Instances.o -rw-r--r-- 1 alatter staff 602752 Jan 16 20:04 ./dist/build/HSsyb-with-class-0.6.1.o antoine-latters-macbook:syb-with-class-0.6.1 alatter$ find . | grep \\.hi$ | xargs ls -l -rw-r--r-- 1 alatter staff 33600 Jan 16 20:05 ./dist/build/Data/Generics/SYB/WithClass/Basics.hi -rw-r--r-- 1 alatter staff2367 Jan 16 20:05 ./dist/build/Data/Generics/SYB/WithClass/Context.hi -rw-r--r-- 1 alatter staff 13960 Jan 16 20:05 ./dist/build/Data/Generics/SYB/WithClass/Derive.hi -rw-r--r-- 1 alatter staff 166039 Jan 16 20:05 ./dist/build/Data/Generics/SYB/WithClass/Instances.hi < Note that after running "cabal haddock" we re-build all of our .hi and .o files EXCEPT ./dist/build/HSsyb-with-class-0.6.1.o And now, since TH generates random symbols, we have symbols in the new .hi files that aren't in the old (and only) HSsyb-with-class-0.6.1.o. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: nntp 0.0.3
Rather a 'bug-fix' release. Intended to add additional symbols to group names. I'd like to add support for explicit fetching some headers only and giving the message a more MIME-like behaviour but I'm afraid there is nowhere written how XHDR/HDR would behave with multiline headers nor I found a suitable package (mime[1] seems to not include even parsing the headers only and mime-string[2] does not take into account comments which may or may not be a problem with Message-ID comparaison). Regards [1] http://hackage.haskell.org/package/mime [2] http://hackage.haskell.org/package/mime-string signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language simplicity
PL/I has keywords, they're just not reserved words. With as many keywords as PL/I has, there something to say for not making them reserved. :) On Wed, Jan 13, 2010 at 11:50 AM, Brandon S. Allbery KF8NH wrote: > On Jan 13, 2010, at 05:45 , Ketil Malde wrote: >> >> "Brandon S. Allbery KF8NH" writes: >>> >>> If we're going to go that far, FORTRAN and PL/1 have none. FORTRAN is >>> somewhat infamous for this: >> >> There's also the option (perhaps this was PL/1?) of writing constructs >> like: IF THEN THEN IF ELSE THEN etc. Having few reserved words isn't >> necessarily a benefit. :-) > > That'd be PL/I, and a prime example of why languages use keywords these days > (as if FORTRAN weren't enough). :) > > -- > brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com > system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu > electrical and computer engineering, carnegie mellon university KF8NH > > > > ___ > 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] GHC bug? Cabal bug? Haddock bug?
Indeed - all those look exactly like the same issue. > And the workaround: > http://groups.google.com/group/happs/msg/1e7761d421b0e5eb That doesn't fix the real issue: It causes happstack-data to not need the thing that is built wrong in syb-with-class. I believe my work-around (build syb-with-class w/o documentation) will be a more universal workaround, as at that point the syb-with-class install is no longer broken. > Here's the GHC bug report: http://hackage.haskell.org/trac/ghc/ticket/3799 Registration for that trac is broken, so I couldn't update that ticket. I see that you've added pointers to my post, thank you! Perhaps you can also add a note that the issue seems to have to do with something that cabal does differently when there is a documentation step enabled. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AlternativePrelude extension
Laurdag 16. januar 2010 22.40.17 skreiv Malcolm Wallace:
> > I'm thinking the syntax would be something like
> > AlternativePrelude="MyPrelude".
>
> There is a general principle that the semantics of a program should be
> completely described by the source code itself, and not dependent on
> options that may or may not be specified elsewhere. Hence, the idea
> of adding {-# LANGUAGE #-} pragmas, so that the source code is self-
> contained.
>
> Specifying {-# LANGUAGE NoImplicitPrelude #-} together with "import
> MyPrelude" satisfies this principle, as does {-# LANGUAGE
> AlternativePrelude="MyPrelude" #-} in all files where it matters. But
> the difference in usability is slight.
>
> If you are suggesting that {-# LANGUAGE AlternativePrelude="MyPrelude"
> #-} should somehow escape the scope of the module it appears in, then
> I think we heading for less firm ground.
>
> Regards,
> Malcolm
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
Having a LANGUAGE pragma, or indeed any pragma, escape the module it's used in
would be pretty silly, wouldn't it?
In principle I'm a fan of the LANGUAGE pragmas. Self-contained source is
usually much easier to read that source that depends on whatever command the
author used to build the thing.
However, the option to set language extension globally is still available,
either as an option to the compiler when building, or in the cabal file
describing the package. Allowing an alternative prelude in this fashion makes
it easier to switch out the standard for alternatives in existing projects
just to see what might happen, how things are changed or just for giggles. It
might not be advisable to do so in code you plan on unleashing on the world,
but it would make experimenting with alternatives cheaper than it currently
is.
--
Sjur Gjøstein Karevoll
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: Space-leak-free, efficient symbol table implementation.
Interesting code, it was nice to read, thanks! Just a few minor comments. On Thu, Jan 14, 2010 at 11:33:54PM +, Thomas Schilling wrote: > intern s = unsafePerformIO $ do > lnk <- newIORef Nothing > r <- newIORef $ SymInfo (hash s) lnk s > return (Symbol r) > > mkSymbolInfo :: String -> SymbolInfo > mkSymbolInfo s = unsafePerformIO $ do > lnk <- newIORef Nothing > return $ SymInfo (hash s) lnk s intern = fmap Symbol . newIORef . mkSymbolInfo > -- END OF COMMON CASE > -- > -- If the symbols have been built using the same symbol table > -- we will only reach this case if we have a hash collision or > -- the symbols were built from different symbol tables. -- END OF COMMON CASE -- -- We will only reach this case if we have a hash collision or -- the symbols were built from different symbol tables. Thanks for sharing, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AlternativePrelude extension
I'm thinking the syntax would be something like
AlternativePrelude="MyPrelude".
There is a general principle that the semantics of a program should be
completely described by the source code itself, and not dependent on
options that may or may not be specified elsewhere. Hence, the idea
of adding {-# LANGUAGE #-} pragmas, so that the source code is self-
contained.
Specifying {-# LANGUAGE NoImplicitPrelude #-} together with "import
MyPrelude" satisfies this principle, as does {-# LANGUAGE
AlternativePrelude="MyPrelude" #-} in all files where it matters. But
the difference in usability is slight.
If you are suggesting that {-# LANGUAGE AlternativePrelude="MyPrelude"
#-} should somehow escape the scope of the module it appears in, then
I think we heading for less firm ground.
Regards,
Malcolm
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: FASTER primes
Am Samstag 16 Januar 2010 18:53:33 schrieb Will Ness: > Daniel Fischer web.de> writes: > > Am Donnerstag 14 Januar 2010 08:25:48 schrieb Will Ness: > > > Daniel Fischer web.de> writes: > > > > Am Mittwoch 13 Januar 2010 10:43:42 schrieb Heinrich Apfelmus: > > > > > I wonder whether it's really the liveness of pair in > > > > > > > > > > mergeSP (a,b) pair > > > > > = let sm = spMerge b (fst pair) > > > > > in (a ++ fst sm, merge (snd sm) (snd pair)) > > > > > > > > > > that is responsible for the space leak, ... > > > > > > > > I think that is responsible. At least that's how I understand the > > > > core: > > > > > > > > mergeSP (a,b) ~(c,d) = (a ++ bc, merge b' d) > > > >where > > > > (bc, b') = spMerge b c > > > > spMerge ... > > > > > > That is equivalent to > > > > > > first (a++) . second (`merge`d) $ spMerge b c > > > > > > and Daniel's fix is equivalent to > > > > > > first (a++) $ spMerge b c d > > That should've been > > mergeSP (a,b) p = first(a++) . second(`merge`snd p) $ spMerge b (fst > p) > > and > > mergeSP (a,b) p = first(a++) $ spMerge b (fst p) (snd p) > > > The code fragments you've posted are essentially > > > mergeSP (a,b) p = let res = case p of (c,_) -> > case spMerge b c of (# x,y #) -> > (x,y) > in >(# (++) a (case res of (bc,_)-> bc) , > case res of (_,b') -> > case p of (_,d) -> merge b' d #) > > and > > mergeSP (a,b) p = let res = case p of (c,d) -> > case spMerge b c d of (# x,y #) -> > (x,y) > in >(# (++) a (case res of (bc,_)-> bc) , > case res of (_,b') -> b' #) > > > This looks like Haskell to me, with many detailes explicitely written > out, probaly serving as immediate input to the compiler - not its > output. So it can't say to us much about how this is actually > implemented on the lower level. (?) It's 'core', the intermediate language GHC uses and does its transformations upon. It's more or less a slimmed down version of Haskell. That came from -ddump-simpl, thus it's the output of the simplifier, after numerous transformation/optimisation passes. I think that is then fairly directly translated to assembly (via Cmm), the STG to STG and Cmm passes do not much optimisation anymore (I may be wrong, what know I about the compiler. However, I've found that the -ddump-simpl output corresponds well to the actual behaviour whenever I look.). I find that much more redable than the -fext-core output (http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/ext-core.html "GHC can dump its optimized intermediate code (said to be in “Core” format) to a file as a side-effect of compilation."), which says the same, only more verbose and less readable. Of course, if I could read assembly, that would exactly reveal what happens. > > Your theory would certainly hold if the translation was done one-to-one > without any further code rearrangements. But it could've been further > re-arranged by the compiler at some later stage (is there one?) into an > equivalent of, e.g. > > > mergeSP (a,b) p = let (bc,b') = case p of (c,_) -> > case spMerge b c of (x,y) -> > (x,y) > in >(# (++) a bc , > case p of (_,d) -> merge b' d #) > > > and further, > > > mergeSP (a,b) p = let (c,d) = case p of (x,y) -> (x,y) > (bc,b') = case spMerge b c of (x,y) -> > (x,y) > in >(# (++) a bc , merge b' d #) > > > could it? This would take hold on /d/ and /c/ at the same time, right? It would. But AFAICT, after the simplifier is done, no such rearrangements occur anymore. > > What is that code that you've shown exactly? At which stage is it > produced and is it subject to any further manipulation? I'm no GHC expert either, so I don't know what it does when exactly. But after parsing and desugaring, there come a few iterations of the simplifier, intermingled with specialising, demand-analysis, CSE, let- floating, worker-wrapper-split, ... . At the end of all that, the Tidy Core is generated (part of which I posted). What happens from then on, well ... > I apologise if > these are obvious questions, I don't know anything about GHC. I also > don't know what (# x,y #) means? Unboxed tuple (pair in this case). That means, have the components for themselves, don't wrap them in a (,) constructor. > > One thing seems certain - we should not hold explicit references to same > entities in different parts of our code, to avoid space leaks with more > confidence. Except when it's good to share ;) > To make code look as much tail-recursive as possible, so to speak. Tail recursion isn't really important (for GHC at least, I think for lazy languages in general), due to different evaluati
Re: [Haskell-cafe] Language simplicity
Eduard Sergeev schrieb: Andrew Coppin wrote: OK people, it's random statistics time! OK, my version of meaningless statistics: C++ (ISO/IEC 14882:1998(E)): 325 pages (712 including standard libraries) C# (ECMA-334): 505 pages (language only) Java: 450 pages (language only?) Scala (2.7): 125 pages (157 including standard library) Eiffel (ECMA-367): 160 pages (language only) ANSI SQL-92: 685 pages (language only) Haskell-98: 77 pages (247 including Prelude) Erlang (4.7.3) 162 pages (251 including builtin functions) Scheme (R5RS): 17 pages (45 including standard procedures) Modula-3 is advertised for needing only 60 pages for the language definition. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language simplicity
Niklas Broberg schrieb: Haskell '98 apparently features 25 reserved words. (Not counting "forall" and "mdo" and so on, which AFAIK are not in Haskell '98.) 21 actually. case, class, data, default, deriving, do, else, if, import, in, infix, infixl, infixr, instance, let, module, newtype, of, then, type, where. There's also three special words that can still be used as identifiers, so aren't reserved: as, qualified, hiding. Recently I added 'export' to my NEdit highlight patterns in order to support FFI statements more completely. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language simplicity
Andrew Coppin schrieb: Hmm, I wonder if there's some way to compare the size of the language specification documents? :-} PS. It comes as absolutely no surprise to me that C++ has the most keywords. But then, if I were to add AMOS Professional, that had well over 800 keywords at the last count... Because those BASIC dialects had a large set of built-in functions that would have been library functions in other languages. BlitzBasic II had many such functions defined as library functions. GFA-Basic provided many system library functions as built-in functions. There was a famous book about Murphy's law applied to computers where programming languages were advertised by the number of their built-in commands. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Poor man's generic programming
Is any of the existing Generics packages able to work without compiler
extensions, that is Haskell 98?
I mean, it is ok if the developer of the generic parts of a library
needs compiler extensions or extra tools, but the user who calls 'cabal
install' shall not need them and the developer, who does not touch
generic definitions, should not need them as well.
I think this could be done with pragmas in the following way:
class C a where
f :: a -> [Int]
{-# GENERICDEFAULT
f {| Unit |} Unit = []
#-}
{-# GENERATEDINSTANCEBEGIN Automatically generated - Do not edit! #-}
instance C () where
f () = []
{-# GENERATEDINSTANCEEND Automatically generated - Do not edit! #-}
Now, by running a tool, the part between the GENERATEDINSTANCE pragmas
can generated or updated.
Everything outside the pragmas can be Haskell 98.
It does not only avoid extensions of the building compiler, but also
extensions of a programmer's brain. Because for programmers it is often
easier to understand a set of instances and see the common patterns,
than to understand generic code that builds the instances.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC bug? Cabal bug? Haddock bug?
This sounds similar to an issue I was seeing over here: http://groups.google.com/group/happs/msg/04ecfe4fd6285c0d The module being compiled also includes TH top-level statements, and was only reproducible when building from Cabal. Here's another occurance on a different platform: http://groups.google.com/group/happs/msg/0f65ba6e4f7e822d And the workaround: http://groups.google.com/group/happs/msg/1e7761d421b0e5eb Here's the GHC bug report: http://hackage.haskell.org/trac/ghc/ticket/3799 Antoine 2010/1/16 Mark Lentczner : > === Short Story === > > If I build syb-with-class-0.6 via cabal (cabal configure; cabal build) in the > unpacked tar directory, it builds correctly. > > If I build it via "cabal install" (either from the unpacked directory, or by > letting cabal fetch it), then the resulting package is corrupted. In > particular, the .hi interface file for Data.Generics.SYB.WithClass.Instances > mentions symbols that aren't in the .a file. (Or rather, they have the wrong > names.) > > I compared verbose logs of both builds and the differ only in temporary file > names execpt that the "cabal install" version builds haddock, as my > .cabal/conf file has documentation: True. Turns out that if turn > documentation off, then then "cabal install" builds a .hi file that matches > the .a file... and all is well. > > Is this a bug in cabal? cabal-install? ghc? haddock? > > I have saved logs of all this if anyone wants. > > - Mark (MtnViewMark) Lentczner > ma...@glyphic.com > http://www.ozonehouse.com/mark/ > > === Versions === > > [2373] : cabal -V > cabal-install version 0.8.0 > using version 1.8.0.2 of the Cabal library > > [2374] : ghc -V > The Glorious Glasgow Haskell Compilation System, version 6.10.4 > > [2376] : ghc-pkg describe haddock | grep version > version: 2.4.2 > > === Background & Details === > > I was installing happstack on my Mac with my Haskell Platform (GHC 6.10.4) > installation. I have successfully installed dozens of other packages in this > environment before, and these results are annomalous. > > I kicked this off via: > cabal install --user happstack > > This installs many packages, including syb-with-class-0.6, which compiled and > installed just fine. > > When installing happstack-data, and compiling the file > Happstack/Data/Proxy.hs, during the Template Haskell step (where things get > loaded up in ghci), the build encounters this link error: > > [ 7 of 16] Compiling Happstack.Data.Proxy ( src/Happstack/Data/Proxy.hs, > dist/build/Happstack/Data/Proxy.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > Loading package syb ... linking ... done. > Loading package array-0.2.0.0 ... linking ... done. > Loading package bytestring-0.9.1.5 ... linking ... done. > Loading package containers-0.2.0.1 ... linking ... done. > Loading package packedstring-0.1.0.1 ... linking ... done. > Loading package pretty-1.0.1.0 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package syb-with-class-0.6 ... linking ... done. > (... many more loads elided...) > Loading package HaXml-1.13.3 ... linking ... done. > ghc: > unknown symbol > `_sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMabOQZN_closure' > > That symbol decodes to something referring to: > package: syb-with-class-0.6 > module: Data.Generics.SYB.WithClass.Instances > reference: dataType[abOQ] > > The reference turns out to be from Loading Happstack.Data.Default, which in > turn imports Data.Generics.SYB.WithClass.Instances. > > Poking around, I found that the interface (.hi) file for > Data.Generics.SYB.WithClass.Instances does indeed export such an object: > > [2324] : ghc --show-iface Data/Generics/SYB/WithClass/Instances.hi | fgrep > dataType[a > Data.Generics.SYB.WithClass.Instances.dataType[abOQ]) -} > Data.Generics.SYB.WithClass.Instances.dataType[abSm]) -} > dataType[abOQ] :: Data.Generics.SYB.WithClass.Basics.DataType > dataType[abSm] :: Data.Generics.SYB.WithClass.Basics.DataType > > But, the library doesn't export it: > > [2325] : nm libHSsyb-with-class-0.6.a | fgrep dataTypeZMa > 0001854c D > _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMaeuiZN_closure > 00018604 D > _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMaexTZN_closure > > These refer to dataType[aeui] and dataType[aexT], which don't exist in the > interface file. > > Something seems amiss here: The interface file is exporting generated names > that don't match what the library is exporting. > > If I do the same investigation with the profiling versions of this module, > they match: > > [2326] : ghc --show-iface Data/Generics/SYB/WithClass/Instances.p_hi |
Re: [Haskell-cafe] Web application interface
Excerpts from Michael Snoyman's message of Wed Jan 13 15:46:12 +0100 2010: > Hi, > > I recently read (again) the wiki page on a web application interface[1] for > Haskell. It seems like this basically works out to Hack[2], but using an > enumerator instead of lazy bytestring in the response type. Is anyone > working on implementing this? If not, I would like to create the package, > though I wouldn't mind some community input on some design decisions: Wai seems to lightly rely on ImpredicativeTypes which becomes deprecated in GHC 6.12 and could be removed in 6.14. This seems to be due to the response tuple. Is there any plan to change this to a more forward compatible solution? -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC bug? Cabal bug? Haddock bug?
=== Short Story === If I build syb-with-class-0.6 via cabal (cabal configure; cabal build) in the unpacked tar directory, it builds correctly. If I build it via "cabal install" (either from the unpacked directory, or by letting cabal fetch it), then the resulting package is corrupted. In particular, the .hi interface file for Data.Generics.SYB.WithClass.Instances mentions symbols that aren't in the .a file. (Or rather, they have the wrong names.) I compared verbose logs of both builds and the differ only in temporary file names execpt that the "cabal install" version builds haddock, as my .cabal/conf file has documentation: True. Turns out that if turn documentation off, then then "cabal install" builds a .hi file that matches the .a file... and all is well. Is this a bug in cabal? cabal-install? ghc? haddock? I have saved logs of all this if anyone wants. - Mark (MtnViewMark) Lentczner ma...@glyphic.com http://www.ozonehouse.com/mark/ === Versions === [2373] : cabal -V cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library [2374] : ghc -V The Glorious Glasgow Haskell Compilation System, version 6.10.4 [2376] : ghc-pkg describe haddock | grep version version: 2.4.2 === Background & Details === I was installing happstack on my Mac with my Haskell Platform (GHC 6.10.4) installation. I have successfully installed dozens of other packages in this environment before, and these results are annomalous. I kicked this off via: cabal install --user happstack This installs many packages, including syb-with-class-0.6, which compiled and installed just fine. When installing happstack-data, and compiling the file Happstack/Data/Proxy.hs, during the Template Haskell step (where things get loaded up in ghci), the build encounters this link error: [ 7 of 16] Compiling Happstack.Data.Proxy ( src/Happstack/Data/Proxy.hs, dist/build/Happstack/Data/Proxy.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-with-class-0.6 ... linking ... done. (... many more loads elided...) Loading package HaXml-1.13.3 ... linking ... done. ghc: unknown symbol `_sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMabOQZN_closure' That symbol decodes to something referring to: package: syb-with-class-0.6 module:Data.Generics.SYB.WithClass.Instances reference: dataType[abOQ] The reference turns out to be from Loading Happstack.Data.Default, which in turn imports Data.Generics.SYB.WithClass.Instances. Poking around, I found that the interface (.hi) file for Data.Generics.SYB.WithClass.Instances does indeed export such an object: [2324] : ghc --show-iface Data/Generics/SYB/WithClass/Instances.hi | fgrep dataType[a Data.Generics.SYB.WithClass.Instances.dataType[abOQ]) -} Data.Generics.SYB.WithClass.Instances.dataType[abSm]) -} dataType[abOQ] :: Data.Generics.SYB.WithClass.Basics.DataType dataType[abSm] :: Data.Generics.SYB.WithClass.Basics.DataType But, the library doesn't export it: [2325] : nm libHSsyb-with-class-0.6.a | fgrep dataTypeZMa 0001854c D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMaeuiZN_closure 00018604 D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZMaexTZN_closure These refer to dataType[aeui] and dataType[aexT], which don't exist in the interface file. Something seems amiss here: The interface file is exporting generated names that don't match what the library is exporting. If I do the same investigation with the profiling versions of this module, they match: [2326] : ghc --show-iface Data/Generics/SYB/WithClass/Instances.p_hi | fgrep dataType[a Data.Generics.SYB.WithClass.Instances.dataType[anmx]) -} Data.Generics.SYB.WithClass.Instances.dataType[anq8]) -} dataType[anmx] :: Data.Generics.SYB.WithClass.Basics.DataType dataType[anq8] :: Data.Generics.SYB.WithClass.Basics.DataType ma...@mtree ~/Library/Haskell/packages/syb-with-class-0.6/lib/ghc-6.10.4 [2327] : nm libHSsyb-with-class-0.6_p.a | fgrep dataTypeZMa 00032704 D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZManmxZN_closure 0003282c D _sybzmwithzmclasszm0zi6_DataziGenericsziSYBziWithClassziInstances_dataTypeZManq8ZN_closure
Re: [Haskell-cafe] Compilers
On Sat, Nov 29, 2008 at 8:02 PM, John Meacham wrote:
> On Sat, Nov 29, 2008 at 11:41:03PM +0100, Daniel Fischer wrote:
>> Great, nothing I don't already have, so download the source tarball, unpack
>> and
>> ./configure --prefix=$HOME
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> ... more configure output ...
>> checking for drift-ghc... no
>> configure: error: DrIFT not found get it from
>> http://repetae.net/computer/haskell/DrIFT/
>>
>> Huh?
>> da...@linux:~/jhc/jhc-0.5.20080307> which DrIFT
>> /home/dafis/.cabal/bin/DrIFT
>> da...@linux:~/jhc/jhc-0.5.20080307> DrIFT --version
>> Version DrIFT-2.2.3
>
> Oh golly. I never put DrIFT on cabal, apparently whomever tried to
> cabalize it didn't include the ghc driver script, and also appeared to
> just drop the documentation from the package altogether. It is things
> like that that make it very hard to get behind cabal, why was DrIFT
> crippled just so it can be put on cabal? If cabal wasn't powerful enough
> to compile DrIFT, and we already had a perfectly good way of compiling
> it, why the need to shoehorn it in and cause this problem? sigh.
...
> John
Thought I'd mention that
http://hackage.haskell.org/package/DrIFT-cabalized 2.2.3.1 includes a
drift-ghc.hs (compiles to /home/gwern/bin/bin/DrIFT-cabalized-ghc)
which is a clone of the drift-ghc.in shell script you allude to:
import Data.List (isInfixOf)
import System.Cmd (rawSystem)
import System.Environment (getArgs)
import System.Exit (ExitCode(ExitSuccess))
import Paths_DrIFT_cabalized (getBinDir)
main :: IO ExitCode
main = do args <- getArgs
case args of
(a:b:c:[]) -> conditional a b c
_ -> error "This is a driver script allowing DrIFT to be
used seamlessly with ghc.\n \
\ in order to use it, pass '-pgmF drift-ghc -F'
to ghc when compiling your programs."
conditional :: FilePath -> FilePath -> FilePath -> IO ExitCode
conditional orgnl inf outf = do prefix <- getBinDir
infile <- readFile inf
if "{-!" `isInfixOf` infile then do
putStrLn (prefix ++ "DriFT-cabalized " ++
inf ++ " -o " ++ outf)
rawSystem inf ["-o", outf]
else do writeFile outf ("{-# LINE 1
\"" ++ orgnl ++ " #-}")
readFile inf >>= appendFile outf
return ExitSuccess
{- GHC docs say: "-pgmF cmd
Use cmd as the pre-processor (with -F only).
Use -pgmF cmd to select the program to use as the preprocessor.
When invoked, the cmd pre-processor is given at least three arguments
on its command-line:
1. the first argument is the name of the original source file,
2. the second is the name of the file holding the input
3. third is the name of the file where cmd should write its output to." -}
John: I would appreciate you pointing out if I have made a mistake
anywhere in that and not actually replicated the functionality of the
shell script. (I think I have, but I didn't really understand what the
first echo was supposed to do and just copied its functionality.)
--
gwern
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Data.Ring -- Pre-announce
wren ng thornton schrieb: Tom Tobin wrote: - Heinrich Apfelmus wrote: Since the name Ring is already taken by an ubiquitous mathematical structure, and thus already in hackage for example as Algebra.Ring in the numeric-prelude , I suggest to call the data structure Necklace instead. Is Necklace a known name for this data structure? If not Ring, I was thinking Circular might be an appropriate name. I'm not sure if there's a canonical name, except perhaps "circular queue". Necklace is cute, though Circular or CircleQueue might be better. I'd also advise strongly against using Ring in order to avoid confusing nomenclature. (Loop should be avoided for similar reasons.) When reading "Ring" first time in the e-mail subject, I also thought it would be about the algebraic structure with that name. CircularList seems fine to me. Necklace is nice but might be missed when someone searches for that data structure on Hackage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] addFinalizer to which object?
The documentation of System.Mem.Weak.addFinalizer suggests to me, that
this function is very fragile, because the object we track, might be
optimized away.
In my case this applies. I have a resource that is needed for generating
chunks of a lazy byte string. If the byte string is created completely
or the byte string cannot be accessed anymore, this resource must be
freed. It must also be freed within Haskell code, thus
addForeignPtrFinalizer does not help.
To illustrate that I have attached a small example, where I use a
StablePtr as resource, that points to a list. This Haskell list is read
from C code and written to a chunk of a lazy ByteString. A Haskell
function creates the ByteString lazily and calls the C function for
every new chunk. I have added a finalizer to the StablePtr itself. That
works without optimization, but using optimization the finalizer is run
immediately and the program aborts with segmentation fault.
Thus my question: How to get reliable finalization?
#include "ProcessList_stub.h"
/*
The function copies elements from a Haskell list to a piece of memory
and returns the number of bytes that could be fetched.
*/
int copy_list_to_chunk (unsigned long int n, HsStablePtr list, char *p) {
unsigned long int k = n;
while (k>0) {
if (!get_next_element(list, p)) {break; }
p++;
k--;
}
return (n-k);
}
{-
# generate C stubs
ghc -c ProcessList.hs
# generate executable
ghc -O --make ProcessChunk.c ProcessList.hs
-}
{-
Use a C function for filling chunks of a lazy ByteString
with data from a Haskell list.
A StablePtr is needed to pass the list to C and back to Haskell.
Somehow we must assert that the StablePtr is deleted
and the list can be garbage collected,
once the ByteString is constructed.
We concatenate infinitely many such lists,
thus many StablePtrs and referenced lists must be freed.
Use addFinalizer? To which object shall I add the finalizer?
Without optimization adding the finalizer to the StablePtr works,
with optimization, its finalizer is run too early.
I also tried to add the finalizer to the end of the list,
which is not quite correct,
but then the finalizer is run never.
Whatever I tried: Finalizer is run immediately or never.
What is the right way?
-}
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import qualified Data.ByteString as B
import qualified Data.ByteString.Internal as BI
import qualified Data.ByteString.Lazy as BL
import qualified Data.ByteString.Lazy.Internal as BLI
import System.IO.Unsafe (unsafePerformIO, unsafeInterleaveIO, )
import System.Mem.Weak (addFinalizer, )
import Foreign.StablePtr (StablePtr, newStablePtr, freeStablePtr,
deRefStablePtr, )
import Foreign.Storable (poke, )
import Foreign.C.Types (CULong, )
import Foreign.Ptr (FunPtr, Ptr, nullPtr, castPtr, )
import Data.IORef (IORef, newIORef, readIORef, writeIORef, )
import Data.Word (Word8, Word32, )
import Control.Monad (liftM2, )
getNextElement ::
StablePtr (IORef [Word8]) -> Ptr Word8 -> IO Bool
getNextElement stable elemPtr = do
listRef <- deRefStablePtr stable
xt <- readIORef listRef
case xt of
[] -> return False
x:xs -> do
poke elemPtr x
writeIORef listRef xs
return True
foreign export ccall "get_next_element"
getNextElement :: StablePtr (IORef [Word8]) -> Ptr Word8 -> IO Bool
foreign import ccall "copy_list_to_chunk"
copyListToChunk :: CULong -> StablePtr (IORef [Word8]) -> Ptr Word8 -> IO
CULong
chunkSize :: Int
chunkSize = 13
byteStringFromList :: [Word8] -> BL.ByteString
byteStringFromList list = unsafePerformIO $ do
stable <- newStablePtr =<< newIORef list
addFinalizer stable
(putStrLn "free stable pointer" >> freeStablePtr stable)
let go =
unsafeInterleaveIO $ do
v <- BI.createAndTrim chunkSize $
fmap fromIntegral .
copyListToChunk (fromIntegral chunkSize) stable
fmap (BLI.chunk v) $
if B.length v < chunkSize
then return BL.empty
else go
go
main :: IO ()
main =
print $ BL.unpack $ -- BL.take 1000 $
BL.concat $
map
(BL.take 42 . byteStringFromList . iterate (1+))
(iterate (1+) 0)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: FASTER primes
Daniel Fischer web.de> writes: > > Am Donnerstag 14 Januar 2010 08:25:48 schrieb Will Ness: > > Daniel Fischer web.de> writes: > > > Am Mittwoch 13 Januar 2010 10:43:42 schrieb Heinrich Apfelmus: > > > > I wonder whether it's really the liveness of pair in > > > > > > > > mergeSP (a,b) pair > > > > = let sm = spMerge b (fst pair) > > > > in (a ++ fst sm, merge (snd sm) (snd pair)) > > > > > > > > that is responsible for the space leak, ... > > > > > > I think that is responsible. At least that's how I understand the > > > core: > > > > > > mergeSP (a,b) ~(c,d) = (a ++ bc, merge b' d) > > >where > > > (bc, b') = spMerge b c > > > spMerge ... > > > > That is equivalent to > > > > first (a++) . second (`merge`d) $ spMerge b c > > > > and Daniel's fix is equivalent to > > > > first (a++) $ spMerge b c d > > That should've been mergeSP (a,b) p = first(a++) . second(`merge`snd p) $ spMerge b (fst p) and mergeSP (a,b) p = first(a++) $ spMerge b (fst p) (snd p) The code fragments you've posted are essentially mergeSP (a,b) p = let res = case p of (c,_) -> case spMerge b c of (# x,y #) -> (x,y) in (# (++) a (case res of (bc,_)-> bc) , case res of (_,b') -> case p of (_,d) -> merge b' d #) and mergeSP (a,b) p = let res = case p of (c,d) -> case spMerge b c d of (# x,y #) -> (x,y) in (# (++) a (case res of (bc,_)-> bc) , case res of (_,b') -> b' #) This looks like Haskell to me, with many detailes explicitely written out, probaly serving as immediate input to the compiler - not its output. So it can't say to us much about how this is actually implemented on the lower level. (?) Your theory would certainly hold if the translation was done one-to-one without any further code rearrangements. But it could've been further re-arranged by the compiler at some later stage (is there one?) into an equivalent of, e.g. mergeSP (a,b) p = let (bc,b') = case p of (c,_) -> case spMerge b c of (x,y) -> (x,y) in (# (++) a bc , case p of (_,d) -> merge b' d #) and further, mergeSP (a,b) p = let (c,d) = case p of (x,y) -> (x,y) (bc,b') = case spMerge b c of (x,y) -> (x,y) in (# (++) a bc , merge b' d #) could it? This would take hold on /d/ and /c/ at the same time, right? What is that code that you've shown exactly? At which stage is it produced and is it subject to any further manipulation? I apologise if these are obvious questions, I don't know anything about GHC. I also don't know what (# x,y #) means? One thing seems certain - we should not hold explicit references to same entities in different parts of our code, to avoid space leaks with more confidence. To make code look as much tail-recursive as possible, so to speak. Does that make sense? Anyway that was a very educational (for me) and fruitful discussion, and I greatly appreciate your help, and fixing and improving of the code. Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Naïve Parallelization: C++ vs Haskell
I felt the previous comparison left a little to be desired so I have repeated the experiment on 8 cores using the original Haskell code and giving results for 9, 12 and 13 levels of spheres: http://flyingfrogblog.blogspot.com/2010/01/naive-parallelization-c-vs-haskell.html -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] From records to a type class
Excerpts from Stephen Tetley's message of Sat Jan 16 10:27:33 +0200 2010:
> If you haven't obviously got dispatch on type then records are certainly fine.
Yes, no dispatch on type.
I got a class based implementation compiling, but it seems overly
complex. Maybe the record approach is better after all.
This is a bit more complex than Parsec unfortunately. (an analogue
would be adding encodings to the types of Parsec parsers)
import Data.Word
data IsDir
data IsFile
type Ino = Word32
data Attr = Attr {}
data Proxy t
type family FT (fht :: ((* -> *) -> *)) (fd :: *)
class FH (t :: (* -> *) -> *) where
fhFre :: Proxy t -> Word64 -> IO ()
fhAllo :: forall any. FT t any -> IO Word64
fhRe :: forall any. Word64 -> IO (FT t any)
data UseRaw :: ((* -> *) -> *)
type instance FT UseRaw any = Word64
instance FH UseRaw where
fhFre _ _ = return ()
fhAllo= return
fhRe = return
data UseStablePtr :: (* -> *) -> (* -> *) -> *
type instance FT (UseStablePtr ty) fh = ty fh
instance FH (UseStablePtr ty) where -- omitted
class FH (FhImpl ty) => Fuse' ty where
type FhImpl ty :: (* -> *) -> *
open' :: ty -> Ino -> IO (FT (FhImpl ty) IsFile)
read' :: ty -> Ino -> FT (FhImpl ty) IsFile -> Word64 -> Word32
-> IO [Word8]
opendir' :: ty -> Ino -> IO (FT (FhImpl ty) IsDir)
getattr' :: forall fileOrDir. ty -> Ino -> FT (FhImpl ty) fileOrDir
-> IO Attr
data MyUserType = MyUserType
instance Fuse' MyUserType where
type FhImpl MyUserType = UseRaw
open' = \_ _ -> return 22
- Taru Karttunen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] From records to a type class
Hi Taru If you haven't obviously got dispatch on type then records are certainly fine. Some obigatory examples: http://www.cas.mcmaster.ca/~kahl/Publications/TR/2000-01/Kahl-Braun-Scheffczyk-2000a.pdf (see the Editor type page 13) http://www.cas.mcmaster.ca/~kahl/Publications/Conf/Kahl-1999a.pdf http://web.cecs.pdx.edu/~sheard/papers/JfpPearl.ps Parsec's Text.ParserCombinators.Parsec.Token module is an example that has seen widespread use. http://hackage.haskell.org/packages/archive/parsec/2.1.0.1/doc/html/Text-ParserCombinators-Parsec-Token.html Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
