Re: [Haskell-cafe] Interesting effect of upgrading GHC
Neil Mitchell [EMAIL PROTECTED] writes: I just removed GHC 6.6.1 and installed 6.8.1, and I noticed something rather unexpected. I recompiled an existing program (with -O2), and instead of taking 30 seconds to compile, it took roughly 2 seconds. In previous releases, certain constructs took O(n^2) time to compile. One that was a particular issue for me was: I've noticed that largish data structures - in my case, ~20x20 matrices - embedded in code seems to take a surprisingly long time to compile. (I haven't noticed (nor looked for) any speedup with new releases, though.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
On Mon, 12 Nov 2007, Derek Elkins wrote: On Mon, 2007-11-12 at 15:51 -0800, Donn Cave wrote: On Nov 12, 2007, at 12:00 PM, Galchin Vasili wrote: I am looking for (objective.. i.e. not juts FPL cheerleading) opinions as to why Wall Street ( http://www.janestcapital.com/) and banking are now using OCaml and Haskell. I really want to understand what industrial markets are adopting FPLs and why in order to help push FPLs penetration into industry. I wouldn't know about that, but incidentally, the first I heard of a distinct Wall Street software world, in the 90's, they were looking for Smalltalk programmers. Who knows what those crazy guys will be doing next. Epigram? From a cooperation with a financial institution I got the impression, that they have just enough money to try various things. Those guys e.g. believe that if you throw enough mathematics (supported by their money, of course) on their curves you can predict everything. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
On Tue, 13 Nov 2007, Jon Harrop wrote: Penetration is highest in parts of industry where small groups of talented programmers get together, most notably startups. Look at XenSource, Wolfram Research, The MathWorks, ?? Mathematica and MatLab are just the opposite of statically safe programming. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Henning Thielemann writes: ?? Mathematica and MatLab are just the opposite of statically safe programming. Is this a religious statement, quite popular in our Church of Functionalism, or you mean something concrete by that, and if yes, then what? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Galchin Vasili wrote: I am looking for (objective.. i.e. not juts FPL cheerleading) opinions as to why Wall Street ( http://www.janestcapital.com/) For Jane St Capital read the article by Yaron Minsky in issue 7 of the Monad Reader: http://www.haskell.org/sitewiki/images/0/03/TMR-Issue7.pdf Erik -- - Erik de Castro Lopo - ... a discussion of C++'s strengths and flaws always sounds like an argument about whether one should face north or east when one is sacrificing one's goat to the rain god. -- Thant Tessman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using type-level programming to tag functions with time and space complexity
On Thu, 18 Oct 2007, Daniel McAllansmith [EMAIL PROTECTED] wrote: I was wondering if anyone had done work on tagging functions at the type level with their time or space complexity and, if it's even feasible, calculating the complexity of compound functions. Any pointers? I have done some work on this in the context of dependently typed languages. See Lightweight Semiformal Time Complexity Analysis for Purely Functional Data Structures (http://www.cs.chalmers.se/~nad/publications/danielsson-popl2008.html). The paper also lists some related work which may be useful to you. -- /NAD ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
On Tuesday 13 November 2007 08:41, Henning Thielemann wrote: On Tue, 13 Nov 2007, Jon Harrop wrote: Penetration is highest in parts of industry where small groups of talented programmers get together, most notably startups. Look at XenSource, Wolfram Research, The MathWorks, ?? Mathematica and MatLab are just the opposite of statically safe programming. Absolutely. I was referring to a prototype Mathematica JIT compiler (developed in OCaml), the FFT routines in MATLAB (FFTW: written in OCaml) and the SML software that The MathWorks sell. I was not referring to the Mathematica and MATLAB languages themselves. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
On Tue, 13 Nov 2007 [EMAIL PROTECTED] wrote: Henning Thielemann writes: ?? Mathematica and MatLab are just the opposite of statically safe programming. Is this a religious statement, quite popular in our Church of Functionalism, or you mean something concrete by that, and if yes, then what? I meant that these languages, which are the main products of Wolfram and MathWorks, respectively, are untyped or at least dynamically typed, and thus are certainly not the appropriate tools for reliable development and maintenance. However, I see that Jon Harrop claimed statical type safety only for OCaml and Haskell, and functional design and high productivity for Mathematica and MatLab et.al. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
On Tue, 13 Nov 2007, Jon Harrop wrote: On Tuesday 13 November 2007 08:41, Henning Thielemann wrote: On Tue, 13 Nov 2007, Jon Harrop wrote: Penetration is highest in parts of industry where small groups of talented programmers get together, most notably startups. Look at XenSource, Wolfram Research, The MathWorks, ?? Mathematica and MatLab are just the opposite of statically safe programming. Absolutely. I was referring to a prototype Mathematica JIT compiler (developed in OCaml), interesting the FFT routines in MATLAB (FFTW: written in OCaml) and the SML software that The MathWorks sell. I see, but FFTW was not developed by MathWorks, but by Matteo Frigo and Steven G. Johnson (says fftw.org), and MathWorks continues to ignore functional programming as such, isn't it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Henning Thielemann writes: [EMAIL PROTECTED] wrote: Henning Thielemann writes: ?? Mathematica and MatLab are just the opposite of statically safe programming. Is this a religious statement, quite popular in our Church of Functionalism, or you mean something concrete by that, and if yes, then what? I meant that these languages, which are the main products of Wolfram and MathWorks, respectively, are untyped or at least dynamically typed, and thus are certainly not the appropriate tools for reliable development and maintenance. However, I see that Jon Harrop claimed statical type safety only for OCaml and Haskell, and functional design and high productivity for Mathematica and MatLab et.al. Well, Henning, it is quite a statement: certainly not the appropriate tools for reliable development and maintenance. Tell that to those legions of people who made dozens of thousands of programs in Lisp (or Scheme), in Smalltalk, etc. And now in Erlang... I believe, and I teach that static typing is a good thing, but, please, you are too young yet for sectarism... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ray tracer benchmark: GHC 6.6 vs 6.8
Following Lennart Augustsson's improvements of the Haskell implementations of my ray tracer language comparison: http://augustss.blogspot.com/2007/11/benchmarking-ray-tracing-haskell-vs.html I thought I'd share the performance improvements offered by Lennart's new code with the latest release of GHC. Time in seconds to run the five versions on my Athlon64 X2 2.2GHz running 64-bit Debian Lenny: ghc-6.6.1 22.0715339184 16.5431628227 13.3524830341 11.1260569096 6.33169198036 ghc-6.8.1 16.654654026 12.3998670578 7.8039829731 7.31486296654 6.03285193443 So 6.8 is up to a third faster! The fastest implementations in other language run at around 4s, so Haskell has gone from being 3x slower in the previous implementations with GHC 6.6 to only 50% slower with the new implementations and new GHC. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Building Haskell stuff on Windows
Peter Hercek wrote: Simon Peyton-Jones wrote: | Windows and Haskell is not a well travelled route, but if you stray of | the cuddly installer packages, it gets even worse. | | But it shouldn't. Really it shouldn't. Even though Windows is not my | preferred platform, it is by no means different enough to warrant such | additional complexity. Plus, GHC is developed at Microsoft, and the | currently most featureful Haskell IDE is on Windows... We build GHC on Windows every day. I use MSYS with no trouble. Are there any reasons to use mingw+msys instead of mingw+cygwin? The GHC build system supports both. The Cygwin route is usually more likely to work, because that's what the nightly builds use. MSYS is much faster than Cygwin for development work, though. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Hello jerzy, Tuesday, November 13, 2007, 3:03:16 PM, you wrote: Well, Henning, it is quite a statement: certainly not the appropriate tools for reliable development and maintenance. Tell that to those legions of people who made dozens of thousands of programs in Lisp (or Scheme), in Smalltalk, etc. And now in Erlang... don't forget about million of assemblers programmers. this can't prove anything -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
On Tue, 13 Nov 2007 [EMAIL PROTECTED] wrote: Henning Thielemann writes: [EMAIL PROTECTED] wrote: Henning Thielemann writes: ?? Mathematica and MatLab are just the opposite of statically safe programming. Is this a religious statement, quite popular in our Church of Functionalism, or you mean something concrete by that, and if yes, then what? I meant that these languages, which are the main products of Wolfram and MathWorks, respectively, are untyped or at least dynamically typed, and thus are certainly not the appropriate tools for reliable development and maintenance. However, I see that Jon Harrop claimed statical type safety only for OCaml and Haskell, and functional design and high productivity for Mathematica and MatLab et.al. Well, Henning, it is quite a statement: certainly not the appropriate tools for reliable development and maintenance. Tell that to those legions of people who made dozens of thousands of programs in Lisp (or Scheme), in Smalltalk, etc. And now in Erlang... I think there is a difference between 'many people have done it this way' and 'it was an appropriate choice to do so'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Henning Thielemann wrote: On Tue, 13 Nov 2007, Jon Harrop wrote: On Tuesday 13 November 2007 08:41, Henning Thielemann wrote: On Tue, 13 Nov 2007, Jon Harrop wrote: Penetration is highest in parts of industry where small groups of talented programmers get together, most notably startups. Look at XenSource, Wolfram Research, The MathWorks, ?? Mathematica and MatLab are just the opposite of statically safe programming. Absolutely. I was referring to a prototype Mathematica JIT compiler (developed in OCaml), interesting the FFT routines in MATLAB (FFTW: written in OCaml) and the SML software that The MathWorks sell. I see, but FFTW was not developed by MathWorks, but by Matteo Frigo and Steven G. Johnson (says fftw.org), Right, and it is not written in OCaml but in C. The OCaml code _generates_ optimized C code for the arch where it matters. a+, ld. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Fwd: Trouble using HDBC-postgres on Windows - can'tfind libpq.dll
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Bailey Well, I answered my own question. Unlike UNIX, specifying a library without the leading lib causes the library to not be found. Not sure if that's a GHC linking problem or what. Changing the library requirement to libpq in the .cabal file did the trick tho. This seems to be a bit different from what I discovered when cabalising Takusen. ghc uses gnu ld, which seems to be smart enough to know that -lpq means find libpq.dll or pq.dll. ghci's linker/loader isn't so slick. If you say -lpq to ghci, it looks for pq.dll only. So I just copied libpq.dll to pq.dll, so that they both exist. You're using runghc, so I guess that must use ghci, or something equivalent. You may find, now that you've changed the cabal entry to libpq, that you can no longer build with ghc (the compiler). But my memory of this is hazy. I think it's better to stick with pq in the cabal file (and copy libpq.dll to pq.dll), because this works for Unix systems too. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Laurent Deniau wrote: Henning Thielemann wrote: On Tue, 13 Nov 2007, Jon Harrop wrote: On Tuesday 13 November 2007 08:41, Henning Thielemann wrote: On Tue, 13 Nov 2007, Jon Harrop wrote: Penetration is highest in parts of industry where small groups of talented programmers get together, most notably startups. Look at XenSource, Wolfram Research, The MathWorks, ?? Mathematica and MatLab are just the opposite of statically safe programming. Absolutely. I was referring to a prototype Mathematica JIT compiler (developed in OCaml), interesting the FFT routines in MATLAB (FFTW: written in OCaml) and the SML software that The MathWorks sell. I see, but FFTW was not developed by MathWorks, but by Matteo Frigo and Steven G. Johnson (says fftw.org), Right, and it is not written in OCaml but in C. The OCaml code _generates_ optimized C code for the arch where it matters. That sounds like 'written in ocaml' to me. That's no more written in C than java code is written in assembly, just because the JIT generates optimised assembly code... I would say it's written in the language which the authors wrote it. The fact that they wrote it to generate some C code and then compile it: well, they're just a clever bunch :-) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Henning Thielemann writes: On Tue, 13 Nov 2007 [EMAIL PROTECTED] wrote: Well, Henning, it is quite a statement: certainly not the appropriate tools for reliable development and maintenance. Tell that to those legions of people who made dozens of thousands of programs in Lisp (or Scheme), in Smalltalk, etc. And now in Erlang... I think there is a difference between 'many people have done it this way' and 'it was an appropriate choice to do so'. You are absolutely RIGHT. The point is that I don't acknowledge the right, I don't give myself either, to say that something is or is not *appropriate* - at the long term, in this context. The only absolute truth seems to be that *all* becomes obsolete sooner or later. We as well. So, I just appeal for a bit of modesty. You know what happens when people start to claim that all done until now, concerning, say, the interpretation of Bible, or our understanding of Democracy was inappropriate for reliable development, etc. The sectarism is the lesser evil. The bigger one is the totalitarism. The dynamic typing niche seems quite stable, and developed by serious people. They may become obsolete one day, but playing Cassandras with respect to them is, perhaps, not very promising. Well, I acknowledge to everybody the right - of course - to bear some religious beliefs. I have mine, sometimes very strong... But I have quite a mileage to go before I feel ready to issue prophecies. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Jules Bean wrote: Laurent Deniau wrote: Henning Thielemann wrote: On Tue, 13 Nov 2007, Jon Harrop wrote: the FFT routines in MATLAB (FFTW: written in OCaml) and the SML software that The MathWorks sell. I see, but FFTW was not developed by MathWorks, but by Matteo Frigo and Steven G. Johnson (says fftw.org), Right, and it is not written in OCaml but in C. The OCaml code _generates_ optimized C code for the arch where it matters. That sounds like 'written in ocaml' to me. OCaml was used to write a meta-program which applies heuristics to minimize the runtime of the critical C code (i.e. the butterflies). This has nothing to do with FFT computation and it is optional. FFTW doesn't need any OCaml compiler or lib to be compiled and installed. That's no more written in C than java code is written in assembly, just because the JIT generates optimised assembly code... If your program is written in Java (resp. C) but the JIT is written in C (resp. OCaml), in which language is your code? I would say it's written in the language which the authors wrote it. The fact that they wrote it to generate some C code and then compile it: well, they're just a clever bunch :-) Effectively, they have used the right language for the right thing. a+, ld. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Weird ghci behaviour?
| For technical reasons, GHCi can only support the *-form for modules | which are interpreted, so compiled modules and package modules can | only contribute their exports to the current scope. But it does mean | the interpreter isn't referentially transparent, which is weird for a | language that puts so much stress on referential transparency. Well it depends on what you mean by referential transparency -- but I'll agree 100% that the behaviour you described in your original message is surprising, and therefore unwelcome. Nevertheless, I think there's a good reason for it. The technical reasons are not just laziness on our part. By exporting only the functions named in the export list, GHC can inline everything else vigorously, and that can in turn give big performance improvements. We don't want to arrange that every top-level definition is treated as exported *just in case* someone wants to GHCi that module. This is behaviour that could be changed. E.g. we could say that the top-level scope remains available unless you optimise with -O2. Or something. But there has to be a surprise lurking somewhere. It's just another of those things on GHC's now-large surface area that could probably be improved if someone sat down and thought about it carefully. Meanwhile, though, the best we can do is improve the documentation: Dan, can you suggest any words we could add to the documentation that would have prevented you stumbling? Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Weird ghci behaviour?
On Tue, 13 Nov 2007, Simon Peyton-Jones wrote: Meanwhile, though, the best we can do is improve the documentation: Dan, can you suggest any words we could add to the documentation that would have prevented you stumbling? ... or even better - words that GHCi can say, when it loads modules? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: Trouble using HDBC-postgres on Windows - can'tfind libpq.dll
On Nov 13, 2007 7:09 AM, Bayley, Alistair [EMAIL PROTECTED] wrote: You're using runghc, so I guess that must use ghci, or something equivalent. You may find, now that you've changed the cabal entry to libpq, that you can no longer build with ghc (the compiler). But my memory of this is hazy. I think it's better to stick with pq in the cabal file (and copy libpq.dll to pq.dll), because this works for Unix systems too. Luckily, GHC doesn't break with this change. However, I agree the cabal file should remain unchanged. I fixed it locally and plan to send a patch to the README included with the library to the author. If you can't fix it in the code, there is always the documentation right? :) Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Annoying (windows only?) related GHCi problem?
When I start a windowed program (e.g. GLUT or GTK2Hs) from within GHCi, my application's window does not become the foreground window. Is this on purpose? Thanks, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
On Nov 13, 2007 3:00 AM, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Dan, can you suggest any words we could add to the documentation that would have prevented you stumbling? I guess the thing that would have helped best would have been an error message like 'x' not in scope, use -fforce-recomp to see all symbols when running interactively in ghci with a previously compiled top level module. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
On Nov 13, 2007, at 13:32 , Dan Piponi wrote: On Nov 13, 2007 3:00 AM, Simon Peyton-Jones [EMAIL PROTECTED] wrote: Dan, can you suggest any words we could add to the documentation that would have prevented you stumbling? I guess the thing that would have helped best would have been an error message like 'x' not in scope, use -fforce-recomp to see all symbols when running interactively in ghci with a previously compiled top level module. FWIW, I'm thinking the right thing to do is -fforce-recomp explicitly loaded (:l) modules by default, with documentation specifying to -fno- force-recomp if you don't want that for some reason. If you're using ghci, most of the time you *don't* want the normal ghc symbol behavior. (The above would still be useful, if you then switched to a module pulled in by the explicitly loaaded one and tried to work with a non- exported symbol. I do that a fair bit when developing/debugging.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Functional programming languages are now much more widely used in industry, primarily because they offer substantial productivity improvements (roughly 10x) over C++ and Java and, consequently, are much more cost effective. Do you have any references for this? Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
2007/11/13, Simon Peyton-Jones [EMAIL PROTECTED]: | For technical reasons, GHCi can only support the *-form for modules | which are interpreted, so compiled modules and package modules can | only contribute their exports to the current scope. But it does mean | the interpreter isn't referentially transparent, which is weird for a | language that puts so much stress on referential transparency. Well it depends on what you mean by referential transparency -- but I'll agree 100% that the behaviour you described in your original message is surprising, and therefore unwelcome. Plus, I just discovered, by reading this thread, WHY this happen. Meanwhile, though, the best we can do is improve the documentation: Dan, can you suggest any words we could add to the documentation that would have prevented you stumbling? Granted, I'm lazy. I read release notes only and only few first pages to see what's new. Couldn't GHCI be improved to at least give some hints? Cheers, Radek. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] let vs. where
Hello, I know there are several important differences between let-expressions and where-clauses regarding scoping and the restriction of where to a top-level definition. However, frequently I write code in which either one would be allowed, and I was wondering if there were any guidelines or preferences for one structure over the other. Currently my choice is guided by aesthetics more than anything else ( I prefer the look and ordering of a where clause). Is there anything else I should consider? What do veteran Haskell programmers prefer? Thank you, John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Annoying (windows only?) related GHCi problem?
Peter Verswyvelen wrote: When I start a windowed program (e.g. GLUT or GTK2Hs) from within GHCi, my application’s window does not become the foreground window. Is this on purpose? This is just a guess, I do not really know :-) Maybe your problem is focus stealing prevention, which is a feature of windows OS. well, provided that you have the problem on ms windows. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
On Tuesday 13 November 2007 16:03, Laurent Deniau wrote: OCaml was used to write a meta-program which applies heuristics to minimize the runtime of the critical C code (i.e. the butterflies). This has nothing to do with FFT computation No. The sole purpose of the OCaml code is to symbolically simplify the FFT computations and generate C code implementing the best results. FFTW doesn't need any OCaml compiler or lib to be compiled and installed. No. FFTW contains around 13,000 lines of OCaml source code and you need the OCaml compiler to compile that. If you don't believe me, perhaps you will believe Steven G. Johnson (one of the authors of FFTW) when someone tried to tell him that he hadn't written his software in OCaml: http://groups.google.co.uk/group/fa.caml/msg/cfd08423c22ccff5 That OCaml code has millions of industrial users worldwide and is one of the most widely used pieces of software written in a statically typed functional programming language. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
On Tuesday 13 November 2007 18:38, Tim Newsham wrote: Functional programming languages are now much more widely used in industry, primarily because they offer substantial productivity improvements (roughly 10x) over C++ and Java and, consequently, are much more cost effective. Do you have any references for this? I'm compiling dozens of detailed case studies for a business management report about the use of modern statically typed functional programming languages in industry, designed to inform key decision-makers in industry. If anyone using Haskell in industry would like some free publicity in this report, please e-mail me. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Nov 13, 2007 6:56 PM, John Lato [EMAIL PROTECTED] wrote: Hello, I know there are several important differences between let-expressions and where-clauses regarding scoping and the restriction of where to a top-level definition. However, frequently I write code in which either one would be allowed, and I was wondering if there were any guidelines or preferences for one structure over the other. Currently my choice is guided by aesthetics more than anything else ( I prefer the look and ordering of a where clause). Is there anything else I should consider? What do veteran Haskell programmers prefer? I use let in monadic code and in lambda expressions, and where clauses everywhere else, pretty much. It's pretty much entirely based on what I think looks nice. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
Granted, I'm lazy. I read release notes only and only few first pages to see what's new. Couldn't GHCI be improved to at least give some hints? it does!-) watch the prompt, which says '*M', if all of M's top-level is in scope, or 'M', if only M's exports are in scope. check here: http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#ghci-scope claus - notice how in this example session, the ghci prompt before compilation is '*Main', whereas it is 'Prelude Main' after compilation (ghci adds the Prelude because otherwise only 'main' would be in scope): - $ ghcii.sh u.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. [1 of 1] Compiling Main ( u.hs, interpreted ) Ok, modules loaded: Main. *Main :q Leaving GHCi. $ ghc --make u [1 of 1] Compiling Main ( u.hs, u.o ) Linking u.exe ... $ ghcii.sh u.hs ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6.1, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Ok, modules loaded: Main. Prelude Main :q Leaving GHCi. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell library documentation question
Hello, Is there anyway to get a .pdf version of http://www.haskell.org/ghc/docs/latest/html/libraries/? Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Nov 13, 2007 10:56 AM, John Lato [EMAIL PROTECTED] wrote: I know there are several important differences between let-expressions and where-clauses regarding scoping and the restriction of where to a top-level definition. However, frequently I write code in which One place I find it useful is when there is a common computed value that is used throughout a function definition. For example, imagine some function that uses the length of a list passed in: someFunction ls a b c = ... (length ls) where someAuxFunction x y = ... length ls .. someOtherFunction x y = ... length ls ... a where clause can capture that calculation, make sure it's only done once, and shared throughout the function definition: someFunction ls a b c = ... listLen ... where listLen = length ls someAuxFunction x y = ... listLen ... someOtherFunction x y = ... listLen ... Notice a let clause wouldn't do it above, because length ls is called inside other functions defined in the where clause. Of course everything could be moved to a let clause in the function body. At that point I think it's purely stylistic. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Tue, 13 Nov 2007, John Lato wrote: Hello, I know there are several important differences between let-expressions and where-clauses regarding scoping and the restriction of where to a top-level definition. However, frequently I write code in which either one would be allowed, and I was wondering if there were any guidelines or preferences for one structure over the other. Currently my choice is guided by aesthetics more than anything else ( I prefer the look and ordering of a where clause). Is there anything else I should consider? What do veteran Haskell programmers prefer? This depends on whether you are an expression style or declaration style programmer. http://www.haskell.org/haskellwiki/Declaration_vs._expression_style http://www.haskell.org/haskellwiki/Let_vs._Where ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell library documentation question
Hi Is there anyway to get a .pdf version of http://www.haskell.org/ghc/docs/latest/html/libraries/? Yes, you could print it to PDF using something like acrobat distiller. Otherwise you could modify haddock to generate Latex markup and compile that. My question is why you would want this. What possible advantage would PDF have over the current format? The only thing I can imagine you doing with a PDF is printing it, and I hope you don't, for the sake of the trees! Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
Hi This depends on whether you are an expression style or declaration style programmer. http://www.haskell.org/haskellwiki/Declaration_vs._expression_style http://www.haskell.org/haskellwiki/Let_vs._Where Reading the let vs where page I'm left with the strong impression that I should use let everywhere. I know that's not true, and in fact I much prefer where. Can we put a Wikipedia style NPOV (neutral point of view) tag on that page? Or can someone do some editing? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
I'd like to thank Henning for pointing out the wiki page, which describes one consequence I hadn't considered. I knew I couldn't have been the first person to have this question, but I somehow missed it before. I agree with Neil, though, that it doesn't seem very neutral. On Nov 13, 2007 1:58 PM, Neil Mitchell [EMAIL PROTECTED] wrote: Hi This depends on whether you are an expression style or declaration style programmer. http://www.haskell.org/haskellwiki/Declaration_vs._expression_style http://www.haskell.org/haskellwiki/Let_vs._Where Reading the let vs where page I'm left with the strong impression that I should use let everywhere. I know that's not true, and in fact I much prefer where. Can we put a Wikipedia style NPOV (neutral point of view) tag on that page? Or can someone do some editing? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Tue, 13 Nov 2007, John Lato wrote: I'd like to thank Henning for pointing out the wiki page, which describes one consequence I hadn't considered. I knew I couldn't have been the first person to have this question, but I somehow missed it before. I agree with Neil, though, that it doesn't seem very neutral. Add advantages of 'where' as you like. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
Hi Maybe it would be enough to represent the example where problem more fairly on its own terms. The non-working example has us writing f = State $ \ x - y where y = ... x ... I just don't think this example is representative of the typical decisions in the trade-off. There are reasons to use let, and reasons to use where, but refactoring the entire code into a state monad isn't one I would have ever come up with! A more balanced variant of the page could mention this as one particular case where a let might be preferred, but the fundamental question of let vs where should deal with things like expression vs statement, scoping, textual ordering, strictness, pattern matching, desugaring etc - but probably mainly focus on style. My personal view is to nearly always use a where, except in a monad, where a do-let is correct choice. I very occasionally use a let-in, but only for reasons of textual ordering. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Tue, 2007-11-13 at 13:08 -0800, Donn Cave wrote: On Tue, 13 Nov 2007, Neil Mitchell wrote: This depends on whether you are an expression style or declaration style programmer. http://www.haskell.org/haskellwiki/Declaration_vs._expression_style http://www.haskell.org/haskellwiki/Let_vs._Where Monadification is a refactoring. You want IDE support for this anyways, so I don't think one should prefer let over where solely for the purpose that one day you might do this transformation. I personally prefer where clauses, since code becomes very readable if you name your functions well. However, if you refer to variables bound inside monadic code, you simply have to use 'let'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
I tend to prefer where, but I think that guards function declarations are more readable than giant if-thens and case constructs. where can scope over multiple guards, and guards can access things declared in a where clause, both of which are important features: f xs | len 2 = y | len == 1 = 0 | otherwise = -y where len = length xs y = ... compare to f xs = let len = length xs y = ... in if len 2 then y else if len == 1 then 0 else -y The indenting hides the structure of the second function. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Nov 13, 2007 1:24 PM, Ryan Ingram [EMAIL PROTECTED] wrote: I tend to prefer where, but I think that guards function declarations are more readable than giant if-thens and case constructs. Up until yesterday I had presumed that guards only applied to functions. But I was poking about in the Random module and discovered that you can write things like a | x 1 = 1 | x -1 = -1 | otherwise = x where 'a' clearly isn't a function. Seems like a nice readable format to use. Probably everyone except me already knew this already though. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Performance help
I've been working on a program over the last few days to evolve
cellular automata rules using a genetic algorithm. Luckily, this email
has nothing to do with CAs but everything to do with Haskell
performance.
For those who don't know, a CA is represented as a row of cells, where
each can be either black (on/1) or white (off/0). A CA is run by
generating a new row from the previous row according to some rule.
Each cell is examined in turn and based on the state of it's neighbors
and itself, a new cell in the next row is generated that is either
black or white.
The function below is my step function that generates this new row.
It's at the heart of my program and where all the execution time is
spent. In this scenario it's executed around 800 million times. On my
relatively modest desktop using GHC 6.8.1, the program takes about 30
seconds to run. Here's the function, with some of the type
declarations:
data Rule = Rule { ruleWidth :: Int, rules :: UArray Int Bool }
data Ring = Ring { currIdx :: !Int, vals :: (UArray Int Bool), lower,
upper, size:: !Int }
type CA = Ring
currR :: Int - Ring - Bool
currR amt r@(Ring curr arr l u s) = unsafeAt arr ((curr + amt) `mod` s)
stepWithUArray :: Int - Rule - CA - CA
stepWithUArray rowLen rule@(Rule width rules) row =
let upper = rowLen - 1
getRule currIdx = pattern' start 0
where
start = currIdx - width
end = currIdx + width
pattern' cnt !result
| cnt end = result
| otherwise = if (currR cnt row)
then pattern' (cnt + 1) (result * 2 + 1)
else pattern' (cnt + 1) (result * 2)
makeNewRow :: ST s (ST.STUArray s Int Bool)
makeNewRow =
do
arr - ST.newArray_ (0, upper)
let fill idx
| idx upper = return ()
| otherwise = do
unsafeWrite arr idx (unsafeAt rules (getRule idx))
fill (idx + 1)
fill 0
return $! arr
in fromUArray (ST.runSTUArray makeNewRow)
fromUArray produces a new Ring (i.e. CA) from an array. 'makeNewRow'
iterates over every cell in the current row using getRule to get the
new value for each cell and returns the new row as an array. getRule
essentially treats the neighbors of the current cell as bits, with the
most significant to the left. An index into the rules array is
constructed based on the values around the cell being examined (which
wrap on the ends, thus the Ring construct). That index is used to get
the value of the new cell from the rules array.
Profiling shows that the following lines take up the most execution
and allocation:
makeNewRow = ... -- 20.5% execution, 26.7% allocation
if (currR cnt row) ... -- 14.7% execution, 26.6% allocation, in pattern'
currR ... -- 14.7% execution, 0% allocation
Any suggestions for improving this code? Thanks in advance!
Justin
p.s. The entire program is attached. Compile with ghc -O2
-funbox-strict-fields -fbang-patterns --make GA-CA.hs. It runs 25
rules on each of 25 initial CAs for 2 generations.
p.p.s. On the bright side, this program has excellent memory
performance. It uses a constant 2 - 7 MB depending on the initial
parameters for the entire run. Beautiful!
ca.zip.safe
Description: Binary data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Tue, Nov 13, 2007 at 11:41:20AM -0800, Justin Bailey wrote: On Nov 13, 2007 10:56 AM, John Lato [EMAIL PROTECTED] wrote: I know there are several important differences between let-expressions and where-clauses regarding scoping and the restriction of where to a top-level definition. However, frequently I write code in which One place I find it useful is when there is a common computed value that is used throughout a function definition. For example, imagine some function that uses the length of a list passed in: someFunction ls a b c = ... (length ls) where someAuxFunction x y = ... length ls .. someOtherFunction x y = ... length ls ... a where clause can capture that calculation, make sure it's only done once, and shared throughout the function definition: someFunction ls a b c = ... listLen ... where listLen = length ls someAuxFunction x y = ... listLen ... someOtherFunction x y = ... listLen ... Notice a let clause wouldn't do it above, because length ls is called inside other functions defined in the where clause. Of course everything could be moved to a let clause in the function body. At that point I think it's purely stylistic. A let clause would work fine here: someFunction ls a b c = let listLen = length ls someAuxFunction x y = ... listLen ... someOtherFunction x y = ... listLen ... in ... listLen ... it's just that you don't want to mix let and where clauses, because then things get confusing. Even if it worked with both, noone would know the binding rules. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
Simon Peyton-Jones wrote: | For technical reasons, GHCi can only support the *-form for modules | which are interpreted, so compiled modules and package modules can | only contribute their exports to the current scope. But it does mean | the interpreter isn't referentially transparent, which is weird for a | language that puts so much stress on referential transparency. Well it depends on what you mean by referential transparency -- but I'll agree 100% that the behaviour you described in your original message is surprising, and therefore unwelcome. Nevertheless, I think there's a good reason for it. The technical reasons are not just laziness on our part. By exporting only the functions named in the export list, GHC can inline everything else vigorously, and that can in turn give big performance improvements. We don't want to arrange that every top-level definition is treated as exported *just in case* someone wants to GHCi that module. This is behaviour that could be changed. E.g. we could say that the top-level scope remains available unless you optimise with -O2. Or something. But there has to be a surprise lurking somewhere. I don't suggest a change to your ABI or anything like that. I just suggest that the interpreter - ghci - should, by default, always load a .hs file in interpreted mode, ignoring the .hi and .o already present. After all, a .hs file contains source code and ghci is a source code interpreter; I submit this would be the least surprising thing to do. When it loads dependent modules, I think it can safely load the .o/.hi versions as it does now if they exist, since we don't expect full symbol table access there. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance help
One observation is that you're doing a lot of redundant Bool - Int
conversion.
As you iterate across the array in fillArray, the rule you are using for the
next cell is almost entirely determined by the rule you are using for the
current cell; lop off the top bit, shift left by one, and add the new bit.
Instead, you're recalculating the entire rule at that point.
Sadly, (at least as of GHC 6.6.1) the performance of the operations in
Data.Bits was horrendous, and any time I wanted to use them for
performance, I ended up going through the FFI and writing C code. I haven't
had a chance to test this on GHC 6.8.
In this case, that might not be so bad, however. You can probably write a
10-20 line C function that implements fill and call it via the FFI.
Alternatively, you could create a new rule table which maps a rule and a
bool into a new rule index. This would only be twice the size of the rule
table, and you can index that way.
Also, what stops getRule from going off the end of the array? I didn't see
anything that prevented that in the code, and you're using unsafeAt, which
seems like a potential bug.
-- ryan
On 11/13/07, Justin Bailey [EMAIL PROTECTED] wrote:
I've been working on a program over the last few days to evolve
cellular automata rules using a genetic algorithm. Luckily, this email
has nothing to do with CAs but everything to do with Haskell
performance.
For those who don't know, a CA is represented as a row of cells, where
each can be either black (on/1) or white (off/0). A CA is run by
generating a new row from the previous row according to some rule.
Each cell is examined in turn and based on the state of it's neighbors
and itself, a new cell in the next row is generated that is either
black or white.
The function below is my step function that generates this new row.
It's at the heart of my program and where all the execution time is
spent. In this scenario it's executed around 800 million times. On my
relatively modest desktop using GHC 6.8.1, the program takes about 30
seconds to run. Here's the function, with some of the type
declarations:
data Rule = Rule { ruleWidth :: Int, rules :: UArray Int Bool }
data Ring = Ring { currIdx :: !Int, vals :: (UArray Int Bool), lower,
upper, size:: !Int }
type CA = Ring
currR :: Int - Ring - Bool
currR amt r@(Ring curr arr l u s) = unsafeAt arr ((curr + amt) `mod` s)
stepWithUArray :: Int - Rule - CA - CA
stepWithUArray rowLen rule@(Rule width rules) row =
let upper = rowLen - 1
getRule currIdx = pattern' start 0
where
start = currIdx - width
end = currIdx + width
pattern' cnt !result
| cnt end = result
| otherwise = if (currR cnt row)
then pattern' (cnt + 1) (result * 2 + 1)
else pattern' (cnt + 1) (result * 2)
makeNewRow :: ST s (ST.STUArray s Int Bool)
makeNewRow =
do
arr - ST.newArray_ (0, upper)
let fill idx
| idx upper = return ()
| otherwise = do
unsafeWrite arr idx (unsafeAt rules (getRule idx))
fill (idx + 1)
fill 0
return $! arr
in fromUArray (ST.runSTUArray makeNewRow)
fromUArray produces a new Ring (i.e. CA) from an array. 'makeNewRow'
iterates over every cell in the current row using getRule to get the
new value for each cell and returns the new row as an array. getRule
essentially treats the neighbors of the current cell as bits, with the
most significant to the left. An index into the rules array is
constructed based on the values around the cell being examined (which
wrap on the ends, thus the Ring construct). That index is used to get
the value of the new cell from the rules array.
Profiling shows that the following lines take up the most execution
and allocation:
makeNewRow = ... -- 20.5% execution, 26.7% allocation
if (currR cnt row) ... -- 14.7% execution, 26.6% allocation, in pattern'
currR ... -- 14.7% execution, 0% allocation
Any suggestions for improving this code? Thanks in advance!
Justin
p.s. The entire program is attached. Compile with ghc -O2
-funbox-strict-fields -fbang-patterns --make GA-CA.hs. It runs 25
rules on each of 25 initial CAs for 2 generations.
p.p.s. On the bright side, this program has excellent memory
performance. It uses a constant 2 - 7 MB depending on the initial
parameters for the entire run. Beautiful!
___
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] Performance help
On 11/13/07, Ryan Ingram [EMAIL PROTECTED] wrote: Also, what stops getRule from going off the end of the array? I didn't see anything that prevented that in the code, and you're using unsafeAt, which seems like a potential bug. Never mind, I realized this is a ring buffer with `mod` s. That's another slow operation when you're doing code as tight as this. If you can guarantee the ring is a power of 2 in size you can use a mask instead, or use my original suggestion of deriving rules from the previous rule and the new bit; the initial state is determined by the last bits in the buffer and you never wrap. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Renaming constructors for readability
I wonder, is there an equivalent of the 'type' keyword for constructors? An example: -- create a pseudo-C pointer type -- which can point to a value or a -- null. type Pointer a = Maybe a -- int a = 3; -- int *pa = a; ampersand :: t - Pointer t ampersand a = Just a -- int b = *pa. star :: Pointer a - a star (Just a) = a -- note this function behaves -- in an 'authentic' fashion ;-) To really complete the illusion it would be nice to replace the names Just and Nothing with PointerTo and Null. Then the constructors would really mean something. Is there a solution? -- Dougal Stanton [EMAIL PROTECTED] // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Renaming constructors for readability
On Tue, 13 Nov 2007, Dougal Stanton wrote: -- int a = 3; -- int *pa = a; ampersand :: t - Pointer t ampersand a = Just a What's bad about using 'ampersand' function as replacement for the constructor 'Just'? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance help
On Nov 13, 2007 2:21 PM, Ryan Ingram [EMAIL PROTECTED] wrote: Never mind, I realized this is a ring buffer with `mod` s. That's another slow operation when you're doing code as tight as this. If you can guarantee the ring is a power of 2 in size you can use a mask instead, or use my original suggestion of deriving rules from the previous rule and the new bit; the initial state is determined by the last bits in the buffer and you never wrap. I can't guarantee the ring is a power of 2 but do you feel like explaining the mask suggestion anyways? Thanks for the bits suggestion - I'll see if that helps performance at all. It looks like you have to be very careful in which concrete type you choose or you'll get a lot of conversion going on. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance help
On Tue, Nov 13, 2007 at 02:45:33PM -0800, Justin Bailey wrote: On Nov 13, 2007 2:21 PM, Ryan Ingram [EMAIL PROTECTED] wrote: Never mind, I realized this is a ring buffer with `mod` s. That's another slow operation when you're doing code as tight as this. If you can guarantee the ring is a power of 2 in size you can use a mask instead, or use my original suggestion of deriving rules from the previous rule and the new bit; the initial state is determined by the last bits in the buffer and you never wrap. I can't guarantee the ring is a power of 2 but do you feel like explaining the mask suggestion anyways? Thanks for the bits suggestion - I'll see if that helps performance at all. It looks like you have to be very careful in which concrete type you choose or you'll get a lot of conversion going on. About how wide are your rules usually? Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance help
Sure, if the ring size is a power of two, and a is greater than or equal to 0, then a `mod` ringSize == a .. (ringSize - 1) that is: a `mod` 8 == a .. 7 a `mod` 256 == a .. 255 etc. On 11/13/07, Justin Bailey [EMAIL PROTECTED] wrote: On Nov 13, 2007 2:21 PM, Ryan Ingram [EMAIL PROTECTED] wrote: Never mind, I realized this is a ring buffer with `mod` s. That's another slow operation when you're doing code as tight as this. If you can guarantee the ring is a power of 2 in size you can use a mask instead, or use my original suggestion of deriving rules from the previous rule and the new bit; the initial state is determined by the last bits in the buffer and you never wrap. I can't guarantee the ring is a power of 2 but do you feel like explaining the mask suggestion anyways? Thanks for the bits suggestion - I'll see if that helps performance at all. It looks like you have to be very careful in which concrete type you choose or you'll get a lot of conversion going on. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Renaming constructors for readability
On 13/11/2007, Henning Thielemann [EMAIL PROTECTED] wrote: On Tue, 13 Nov 2007, Dougal Stanton wrote: -- int a = 3; -- int *pa = a; ampersand :: t - Pointer t ampersand a = Just a What's bad about using 'ampersand' function as replacement for the constructor 'Just'? I also wanted to use it in pattern matching but have the advantage of all the stuff already written for Maybe. (Note this was an example I made up on the spur of the moment anyway.) I'd often thought it would be nice when adapting standard data structures for specific programs. Like, data Tree a = Leaf a | Branch a [Tree a] data FS a = File a | Folder a [FS a] Once you've got one it would be nice to repurpose it with more appropriate names. Just an idea! :-) D. -- Dougal Stanton [EMAIL PROTECTED] // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance help
On Nov 13, 2007 2:49 PM, Stefan O'Rear [EMAIL PROTECTED] wrote: About how wide are your rules usually? 7 bits (3 neighbors on each side plus the current cell). Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Renaming constructors for readability
On Tue, Nov 13, 2007 at 11:44:30PM +0100, Henning Thielemann wrote: On Tue, 13 Nov 2007, Dougal Stanton wrote: -- int a = 3; -- int *pa = a; ampersand :: t - Pointer t ampersand a = Just a What's bad about using 'ampersand' function as replacement for the constructor 'Just'? It wouldn't work in pattern matching. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance help
I implement bit shifting to get the next rule, as you suggested, and that cut my run time by 75%. It went from 200 seconds to do 100 rules on 100 CAs to 50 seconds. Amazing. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Renaming constructors for readability
On Tue, 13 Nov 2007, Dougal Stanton wrote: On 13/11/2007, Henning Thielemann [EMAIL PROTECTED] wrote: On Tue, 13 Nov 2007, Dougal Stanton wrote: -- int a = 3; -- int *pa = a; ampersand :: t - Pointer t ampersand a = Just a What's bad about using 'ampersand' function as replacement for the constructor 'Just'? I also wanted to use it in pattern matching but have the advantage of all the stuff already written for Maybe. No problem, write a function like 'maybe' to inspect the data. Instead of 'f m' with f :: Maybe T - S f (Just x) = g x f Nothing = h you write maybe h g m ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: let vs. where
Dan Piponi wrote: On Nov 13, 2007 1:24 PM, Ryan Ingram [EMAIL PROTECTED] wrote: I tend to prefer where, but I think that guards function declarations are more readable than giant if-thens and case constructs. Up until yesterday I had presumed that guards only applied to functions. But I was poking about in the Random module and discovered that you can write things like a | x 1 = 1 | x -1 = -1 | otherwise = x where 'a' clearly isn't a function. Seems like a nice readable format to use. Probably everyone except me already knew this already though. -- Dan I recalled having used this trick in the regex-tdfa regular expression matching engine. There is an option for single-line vs multi-line matching that changes whether ^ and $ get tested against '\n'. By using this trick I was able to decide which matching to use once and that decision gets cached: matchHere regexIn offsetIn prevIn inputIn = ans where ans = if subCapture then runHerePure else noCap where subCapture = captureGroups (regex_execOptions regexIn) (1=rangeSize (bounds (regex_groups regexIn))) [...snip...] -- Select which style of ^ $ tests are performed. test | multiline (regex_compOptions regexIn) = test_multiline | otherwise = test_singleline where test_multiline Test_BOL _off prev _input = prev == '\n' test_multiline Test_EOL _off _prev input = case input of [] - True (next:_) - next == '\n' test_singleline Test_BOL off _prev _input = off == 0 test_singleline Test_EOL _off _prev input = null input -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] More good performance results for ghc 6.8
Trying out some of the great language shootout programs with ghc 6.8 is producing nice results. For example, our classic cache-hammering, bitwise sieve benchmark is out of the box 10% faster with the new compiler. The (already rather good) benchmark is here (the same speed as the OCaml version under ghc 6.6): http://shootout.alioth.debian.org/gp4/benchmark.php?test=nsievebitslang=all And timing with old and new ghc: ghc 6.6.1 Primes up to 8192 4774995 Primes up to 4096 2488465 Primes up to 2048 1299069 ./A66 13 4.50s user 0.02s system 100% cpu 4.515 total ghc 6.8.1 Primes up to 8192 4774995 Primes up to 4096 2488465 Primes up to 2048 1299069 ./A68 13 4.13s user 0.01s system 99% cpu 4.142 total Lovely work GHC HQ, when low level, highly tuned code like this gets magically faster! Once 6.8 is in Gentoo (or earlier...) we should see similar improvements across a range of shootout programs. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Weird ghci behaviour?
On 2007-11-13, Jules Bean [EMAIL PROTECTED] wrote: Simon Peyton-Jones wrote: | For technical reasons, GHCi can only support the *-form for modules | which are interpreted, so compiled modules and package modules can | only contribute their exports to the current scope. But it does mean | the interpreter isn't referentially transparent, which is weird for a | language that puts so much stress on referential transparency. Well it depends on what you mean by referential transparency -- but I'll agree 100% that the behaviour you described in your original message is surprising, and therefore unwelcome. Nevertheless, I think there's a good reason for it. The technical reasons are not just laziness on our part. By exporting only the functions named in the export list, GHC can inline everything else vigorously, and that can in turn give big performance improvements. We don't want to arrange that every top-level definition is treated as exported *just in case* someone wants to GHCi that module. This is behaviour that could be changed. E.g. we could say that the top-level scope remains available unless you optimise with -O2. Or something. But there has to be a surprise lurking somewhere. I don't suggest a change to your ABI or anything like that. I just suggest that the interpreter - ghci - should, by default, always load a .hs file in interpreted mode, ignoring the .hi and .o already present. After all, a .hs file contains source code and ghci is a source code interpreter; I submit this would be the least surprising thing to do. When it loads dependent modules, I think it can safely load the .o/.hi versions as it does now if they exist, since we don't expect full symbol table access there. I _like_ being able to interactively apply bits of code, whether compiled or not, and I like being able to compile them and get it to go faster. This would be a step back, for me. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Tue, 13 Nov 2007 13:51:13 -0800 Dan Piponi [EMAIL PROTECTED] wrote: Up until yesterday I had presumed that guards only applied to functions. But I was poking about in the Random module and discovered that you can write things like a | x 1 = 1 | x -1 = -1 | otherwise = x where 'a' clearly isn't a function. Isn't it a function taking zero arguments? -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Somewhat random history question - chicken and egg
[EMAIL PROTECTED] wrote: But... tell me please, ANYONE, who takes part in this inspiring exchange: How many COBOL programs have you written in your life? How many programs in Cobol have you actually SEEN? Shudder. In '86, I had to modify a COBOL code generator, *written in COBOL*. The generated program read some data from a database and printed out zillions of reports; the generated program took more than 24 hours to run, so rarely ever completed successfully, as the machines they ran it on was not all that reliable. So I had to modify the generator to generate 'check-pointing' code, so the reporting program could be restarted from the last checkpoint rather than from the start. Report generation was something that COBOL was rather good at; code generation was an entirely different matter! That first exposure to (untyped) code-generation probably explains why I'm such a big fan of metaocaml these days... That year, I had way more fun figuring out how call-by-name worked in Algol 60, by starting at the generated thunks in the Burroughs 6800 assembly. Nice thing about that machine was that it was a pure stack machine - kind of like the JVM, as a matter of fact. The other nice thing about that machine is that they had completely bootstrapped it, so that there was only an Algol compiler for it, no user-level assembler at all [but a disassembler for debugging]. It had been bootstrapped several years back, or so I was told. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance help
On Tue, 2007-11-13 at 14:21 -0800, Ryan Ingram wrote: On 11/13/07, Ryan Ingram [EMAIL PROTECTED] wrote: Also, what stops getRule from going off the end of the array? I didn't see anything that prevented that in the code, and you're using unsafeAt, which seems like a potential bug. Never mind, I realized this is a ring buffer with `mod` s. That's another slow operation when you're doing code as tight as this. If you can guarantee the ring is a power of 2 in size you can use a mask instead, or use my original suggestion of deriving rules from the previous rule and the new bit; the initial state is determined by the last bits in the buffer and you never wrap. rem is faster than mod and equivalent if everything is positive. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let vs. where
On Tue, 2007-11-13 at 13:51 -0800, Dan Piponi wrote:
On Nov 13, 2007 1:24 PM, Ryan Ingram [EMAIL PROTECTED] wrote:
I tend to prefer where, but I think that guards function declarations are
more readable than giant if-thens and case constructs.
Up until yesterday I had presumed that guards only applied to
functions. But I was poking about in the Random module and discovered
that you can write things like
a | x 1 = 1
| x -1 = -1
| otherwise = x
where 'a' clearly isn't a function. Seems like a nice readable format
to use. Probably everyone except me already knew this already though.
Yep.
Haskell and Haskell code very often avoids special/corner cases.
There's no reason that shouldn't work so it does. Other examples are:
nullary fundeps, class Foo a | - a where ... ; non/record syntax for
pattern matching, case x of App {} - ... ; guards pretty much
everywhere
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] how does ghci and hugs handle redirecting of stdin/stdout?
Thanks, Vasya ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
Aaron Denney wrote: On 2007-11-13, Jules Bean [EMAIL PROTECTED] wrote: Simon Peyton-Jones wrote: | For technical reasons, GHCi can only support the *-form for modules | which are interpreted, so compiled modules and package modules can | only contribute their exports to the current scope. But it does mean | the interpreter isn't referentially transparent, which is weird for a | language that puts so much stress on referential transparency. Well it depends on what you mean by referential transparency -- but I'll agree 100% that the behaviour you described in your original message is surprising, and therefore unwelcome. Nevertheless, I think there's a good reason for it. The technical reasons are not just laziness on our part. By exporting only the functions named in the export list, GHC can inline everything else vigorously, and that can in turn give big performance improvements. We don't want to arrange that every top-level definition is treated as exported *just in case* someone wants to GHCi that module. This is behaviour that could be changed. E.g. we could say that the top-level scope remains available unless you optimise with -O2. Or something. But there has to be a surprise lurking somewhere. I don't suggest a change to your ABI or anything like that. I just suggest that the interpreter - ghci - should, by default, always load a .hs file in interpreted mode, ignoring the .hi and .o already present. After all, a .hs file contains source code and ghci is a source code interpreter; I submit this would be the least surprising thing to do. When it loads dependent modules, I think it can safely load the .o/.hi versions as it does now if they exist, since we don't expect full symbol table access there. I _like_ being able to interactively apply bits of code, whether compiled or not, and I like being able to compile them and get it to go faster. This would be a step back, for me. Just to be clear: my proposal is that if you want it to go faster you do ghci foo.hi or ghci foo.o ... so you still have the option to run on compiled code. My suggestion is simply that ghci foo.hs is an instruction to load source code (similarly :load); while ghci foo.o is obviously an instruction to load compiled code. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Weird ghci behaviour?
On 13 Nov 2007, at 11:03 PM, Jules Bean wrote: Just to be clear: my proposal is that if you want it to go faster you do ghci foo.hi or ghci foo.o ... so you still have the option to run on compiled code. My suggestion is simply that ghci foo.hs is an instruction to load source code (similarly :load); while ghci foo.o is obviously an instruction to load compiled code. Even just having :m + *Foo always interpret Foo (giving an error only if the source isn't installed) would be an improvement. And wouldn't alter any /non-error/ behavior that exists now. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
