Re: [Haskell-cafe] On to applicative
On 29 August 2010 02:06, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/28/10 20:43 , michael rice wrote: Historical accident, to wit: Haskell 98 minimally defined Either in the Prelude, so in practice we get the basic definitions (Either itself and its Functor and Monad instances) from the Prelude and other utility functions from Data.Either. One might also say its a historical accident that Either isn't an instance of Bifunctor - Equal rights for Lefts!, but that's another story... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
On 29 August 2010 16:51, Stephen Tetley stephen.tet...@gmail.com wrote: One might also say its a historical accident that Either isn't an instance of Bifunctor - Equal rights for Lefts!, but that's another story... One might also say that that's because there is no BiFunctor in the report, standard library, etc. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
On 29 August 2010 07:58, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: One might also say that that's because there is no BiFunctor in the report, standard library, etc. Yep - that's where the historical accident comes in. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Support for lock-free/wait-free programming?
On Sat, 28 Aug 2010 21:22:57 -0400, Gregory Collins wrote: On OSX libgcc_s is only supplied as a dynamic library, which GHC doesn't seem to be able to link with. Any ideas would be appreciated. It works with this patch: -CC-Options: -fomit-frame-pointer -march=native -Wall - Hello Gregory, thanks for your patch. I have just uploaded bits-extras-0.1.1 [1] with tweaked CC-Options to only include -Wall on non-linux systems (plus minor documentation tweaks). Could you check if this compiles on OSX? I would prefer to keep -Wall enabled if possible. Gabriel [1] http://hackage.haskell.org/package/bits-extras-0.1.1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode pretty-printing
Thanks for getting back to me. I was imprecise, by UTF8 characters I mean Unicode. My source files are UTF8-encoded, and Haskell reads them fine, it only has problems outputting them in a readable way. At this point I'm not talking of any I/O besides plain console output. Not using Show is not that of a choice, since I'm using HUnit which uses Show and prints the test results via the standard output functions. I've tried to wrap my strings and redefine Show so that it doesn't escape anything, but the standard output functions don't accept that, and HUnit doesn't know anything about System.IO.UTF8: import System.IO.UTF8 import qualified System.IO import Test.HUnit newtype UString = UString String instance Show UString where show (UString s) = s instance Eq UString where (==) (UString s1) (UString s2) = s1 == s2 test1 = TestCase (assertEqual fail (UString абв) (UString где)) main = System.IO.hSetBinaryMode System.IO.stdout True System.IO.UTF8.putStrLn это тест - Prelude :load utest.hs [1 of 1] Compiling Main ( utest.hs, interpreted ) Ok, modules loaded: Main. *Main main это тест *Main runTestTT test1 ### Failure: fail expected: *** Exception: stderr: hPutChar: invalid argument (Illegal byte sequence) - I've tried replacing UString X in the test with Data.Text.pack X and even desperately with Data.Text.Encoding.encodeUtf8 (Data.Text.pack X), but no dice. Though this time instead of crashes I get the good old escapes. On 29 August 2010 00:09, Yitzchak Gale g...@sefer.org wrote: Peter Gromov wrote: Unfortunately, Haskell escapes UTF8 characters. What do you mean by UTF8 characters? Each element of the Char type represents a single Unicode character, not encoded in UTF-8 or any other encoding. When you read a text file using the traditional IO functions, recent versions of GHC will use the encoding of the current locale (whatever that means on your system) to decode the input into Unicode, unless you specify otherwise. The same is true for writing to the console or to a file. As Don pointed out, you may be interested in using the newer Data.Text instead, especially when encodings matter to you. It will usually be faster than traditional IO, and it is designed to be the new standard for representing text in Haskell. A third option would be to read the data as raw binary bytes, without any decoding, using Data.ByteString. Then it is totally up to you to do any decoding or encoding. In any case, the standard Show instances will not be able to do a very good job of displaying non-ASCII characters; Show cannot make very many assumptions about your data or your environment. As Don suggested, you may want to define your own type class similar to Show that does what you want. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode pretty-printing
2010/8/29 Peter Gromov gromop...@gmail.com: Thanks for getting back to me. I was imprecise, by UTF8 characters I mean Unicode. My source files are UTF8-encoded, and Haskell reads them fine, it only has problems outputting them in a readable way. At this point I'm not talking of any I/O besides plain console output. How are you outputting them? Unless you use a textual String I/O function with GHC 6.12, then by default showing a String will print it with escape characters for non-latin characters. Prelude :load utest.hs [1 of 1] Compiling Main ( utest.hs, interpreted ) Ok, modules loaded: Main. *Main main это тест *Main runTestTT test1 ### Failure: fail expected: *** Exception: stderr: hPutChar: invalid argument (Illegal byte sequence) Hmmm... if you are using GHC 6.12, what's your locale? I've only seen error messages like that when using something with a different encoding than your locale. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode pretty-printing
Yes, it's GHC 6.12.3. Character escapes are the least I want to see. As for the locale: $ locale LANG= LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LC_ALL= Unfortunately, I'm completely lame with locales and googling doesn't help very much to change C to something like UTF-8 (Mac, Snow Leopard). But the terminal does support UTF-8 anyway, as the output from my previous message shows (the main function output). On 29 August 2010 11:49, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: 2010/8/29 Peter Gromov gromop...@gmail.com: Thanks for getting back to me. I was imprecise, by UTF8 characters I mean Unicode. My source files are UTF8-encoded, and Haskell reads them fine, it only has problems outputting them in a readable way. At this point I'm not talking of any I/O besides plain console output. How are you outputting them? Unless you use a textual String I/O function with GHC 6.12, then by default showing a String will print it with escape characters for non-latin characters. Prelude :load utest.hs [1 of 1] Compiling Main ( utest.hs, interpreted ) Ok, modules loaded: Main. *Main main это тест *Main runTestTT test1 ### Failure: fail expected: *** Exception: stderr: hPutChar: invalid argument (Illegal byte sequence) Hmmm... if you are using GHC 6.12, what's your locale? I've only seen error messages like that when using something with a different encoding than your locale. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode pretty-printing
On 29 August 2010 21:24, Peter Gromov gromop...@gmail.com wrote: Yes, it's GHC 6.12.3. Character escapes are the least I want to see. *sigh* that could be because HUnit is calling print ( = putStrLn . show) on the String rather than putStrLn; unfortunately unless it decides to have a special case for Strings you probably won't be able to get around this. One option, though, is rather than returning a String, return a newtype wrapped around a String such that it's show instance is the String it contains... As for the locale: $ locale LANG= LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LC_ALL= Unfortunately, I'm completely lame with locales and googling doesn't help very much to change C to something like UTF-8 (Mac, Snow Leopard). But the terminal does support UTF-8 anyway, as the output from my previous message shows (the main function output). No idea about dealing with Macs, sorry. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
Erik de Castro Lopo wrote: Andrew Coppin wrote: On Linux, if I do, say, cabal install zlib, it falls over and tells me it can't find the zlib headers. So I go install them, rerun the command, and it works. On Windows, I issue the same command and it falls over and says that autoconf doesn't exist. It doesn't even *get* to the part where it looks for header files! You are trying to build code that is designed on and for Linux. As such it will probably work on all variants of Linux, Mac OSX and a majority of Unix variants (after installation of the required GNU tools). Unsurprisingly it does work on windows because windows because windows does just about everything differently to the Linux and the rest of the world does it. The C zlib library itself works just fine on just about every platform I'm aware of (including Windows). What doesn't work is the Haskell binding to it. (And even that does work if you can get it to build - e.g., IIRC zlib is now in HP.) Interestingly, even though everybody claims that it's impossible to support C bindings on Windows, gtk2hs has managed it somehow. The reason that works is probably because whoever released it had a windows machine available and took the time to make it work. In general, code written on and for Linux/Unix is not going compile with little problem on most Unix-style OSes and close to zero chance of compiling without siginficant work on windows. Much like the chance of OSS written for Windows working under Unix without a lot of work. (Yes, people write OSS for Windows too.) The problems I claim windows has with respect to compiling and installing FOSS: a) No standard place to find C include files. b) No standard place to find libraries. c) No standard way to find if common open source libraries are installed and where. As best as I can tell, the Unix Standard Way(tm) to do this kind of thing is to put files into well known locations so that they can be easily found. (The fact that tools like autoconf need to exist tells you something about how tricky this can be.) The Windows Standard Way(tm) is to install your stuff wherever you like, and then record its location in the Registry. Generally this applies more to run-time resources; I'll grant you that compile-time resources are more tricky. I think the expectation is that you'll use some kind of IDE, configure it to say where the header files and so forth are, and it will generate the appropriate command strings to build and link everything. For whatever reason, developers not native to Windows tend to avoid the Registry, so libraries ported to Windows (rather than native to it) tend not to register themselves in the Registry. So that's still perhaps not much help here. Regardless, you'd think Cabal could provide some way to make it easy to state where the files it needs actually are. Currently it does not. d) Missing common unix tools like bash. awk, sed, grep, make, autoconf, automake, libtool, pkg-config etc. If all you're trying to do is compile some Haskell files that include a few C headers, arguably you couldn't need any of these things (except perhaps for discovering where your files are). If you were trying to build the underlying C library itself... well *that* is another task entirely. C tends to be highly non-portable. Fortunately, most interesting C libraries have already been ported by some kind soul; it's just a question of building the Haskell bindings. Ideally for installing open source libraries the tools used should be the same as the ones used on Linux/Unix where they originated. Not all open source libraries originate on Unix. Some of them are actually native to Windows. But anyway, that's tangental to this discussion... My obviously all desktops are Windows was not meant to be entirely serious. But it's not exactly a revelation to state that Windows has much greater penetration in the desktop market than either Linux or indeed Mac OS. Your assessment is valid for user desktops but highly questionable for developer desktops. I can go along with that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On 29 August 2010 21:46, Andrew Coppin andrewcop...@btinternet.com wrote: The problems I claim windows has with respect to compiling and installing FOSS: a) No standard place to find C include files. b) No standard place to find libraries. c) No standard way to find if common open source libraries are installed and where. As best as I can tell, the Unix Standard Way(tm) to do this kind of thing is to put files into well known locations so that they can be easily found. (The fact that tools like autoconf need to exist tells you something about how tricky this can be.) No, autoconf has nothing to do with where the well known locations are. It's having to deal with different versions, etc. of libraries. The Windows Standard Way(tm) is to install your stuff wherever you like, and then record its location in the Registry. Generally this applies more to run-time resources; I'll grant you that compile-time resources are more tricky. I think the expectation is that you'll use some kind of IDE, configure it to say where the header files and so forth are, and it will generate the appropriate command strings to build and link everything. On Unix, most things used shared libraries; in Windows you typically seem to bundle libraries a lot more often (which then annoys distro developers when they have to clean up the resulting mess; Firefox is a prime culprit of this). Regardless, you'd think Cabal could provide some way to make it easy to state where the files it needs actually are. Currently it does not. Well, it uses ghc-pkg to record where the various libraries, etc. are. Otherwise, it could be that none of the Cabal developers are really that familiar with the best practices of developing Windows software (and clobbering the registry whilst your at it). By the way, is it possible to have a globally installed library in Windows (for C, etc.) that can be used no matter which IDE or editor you use? Or does each IDE manage all that on its own? Ideally for installing open source libraries the tools used should be the same as the ones used on Linux/Unix where they originated. Not all open source libraries originate on Unix. Some of them are actually native to Windows. But anyway, that's tangental to this discussion... Though I know of more libraries that originate and *nix and migrate to Windows than the other way round... My obviously all desktops are Windows was not meant to be entirely serious. But it's not exactly a revelation to state that Windows has much greater penetration in the desktop market than either Linux or indeed Mac OS. Your assessment is valid for user desktops but highly questionable for developer desktops. I can go along with that. After all, who cares about users? :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On 28 Aug 2010, at 04:58, Andrew Coppin wrote: Mathew de Detrich wrote: There is also Leksah and GVim The Leksah that I recently noted can't be built on Windows? I am not familiar with that Leksah :-) Seriously though here is one way to build it... Install Haskell Platform Use TakeOffGW (http://sourceforge.net/projects/takeoffgw/) to install : * pkg-config (in the Devel section of the installer) * gtksourceview (Libs) * gtksourceview-devel (Libs). * automake1.9-bin (Devel) * msys-bash-bin (MSYS) * msys-gawk-bin (MSYS) * msys-grep-bin (MSYS) * msys-sed-bin (MSYS) * msys-tar-bin (MSYS) (Once GHC 6.14.1 is released, only the first three should be needed, as the rest are needed to build process-leksah). Make sure the following are in your PATH : * Haskell Platform\mingw\bin * c:\mingw\i686-pc-mingw32\sys-root\mingw\bin (needed mainly for pkg-config) * Your Home Folder\AppData\Roaming\cabal\bin (will be needed for the gtk2hs build tools once they are installed) * c:\mingw\bin Also add the following to your environment : * PKG_CONFIG_PATH=/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig C:\cabal install gtk2hs-buildtools C:\cabal install leksah C:\leksah If you get stuck jump on IRC #leksah or email the leksah group. Hamish___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On 29 August 2010 13:24, Hamish Mackenzie hamish.k.macken...@googlemail.com wrote: Use TakeOffGW (http://sourceforge.net/projects/takeoffgw/) to install : Hi Hamish Does TakeOffGW work well in practice? The intentions behind it are admirable but at the moment it seems rather new. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: Significant performance improvements for Data.Map
http://hackage.haskell.org/trac/ghc/ticket/4277 Proposal: Significant performance improvements for Data.Map Description Milan Straka's recent [52] Haskell Symposium paper (PDF) shed light on the containers:Data.Map library, indicating there were both algorithmic and stylistic performance improvements to be made. 52. http://research.microsoft.com/~simonpj/papers/containers/containers.pdf This proposal provides a patch that [53] dramatically improves performance across the API. Three standard techniques are applied to the code: * [54] Worker/Wrapper transformations of recursive functions with constant arguments (aka. the [55] static argument transformation). * Explicit inlining of wrapper functions. * Explicit strictness of keys to functions. 53. http://is.gd/eJHIE 54. http://www.workerwrapper.com/ 55. http://hackage.haskell.org/trac/ghc/ticket/888 Three complementary, but orthogonal patches are provided. 1. Add a testsuite, [56] with coverage data (currently 91% of top level functions, and all core functions). 2. Add a micro-benchmark suite based on [57] Criterion, for empirical evidence of improvements to each function. 3. The optimization patch itself. All 3 patches should be applied, under this proposal. 56. http://code.haskell.org/~dons/tests/containers/hpc_index.html 57. http://hackage.haskell.org/package/criterion The [58] benchmark results are very strong: * An average speedup across the core api of 47% (on intel i7 / linux 64 bit), and; * 36% on Mac / intel core 2 duo 32 bit). http://i.imgur.com/05BWe.png 58. http://is.gd/eJHIE No bugs were identified in the development of the comprehensive testsuite, which includes a large set of unit tests from [60] Kazu Yamamoto 60. http://twitter.com/kazu_yamamoto/status/22351727559 A fork of the containers package, with the 3 patches (and a version bump to make it easier to test out) is available: darcs get http://code.haskell.org/~dons/code/containers/ Separately, the patches are attached to this ticket. The consideration period is 3 weeks (before ICFP). __ Work carried out over 28/29th August, 2010 in Utrecht, NL, by Johan Tibell and Don Stewart. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On 30 Aug 2010, at 00:55, Stephen Tetley wrote: On 29 August 2010 13:24, Hamish Mackenzie hamish.k.macken...@googlemail.com wrote: Use TakeOffGW (http://sourceforge.net/projects/takeoffgw/) to install : Hi Hamish Does TakeOffGW work well in practice? The intentions behind it are admirable but at the moment it seems rather new. They have been able to leverage a lot of the windows cross compilation work done in SUSE. TakeoffGW packages are built on SUSE and it uses the cygwin installer to download and install them. Cygwin installer is fairly mature (has a number of quirks but it works). So far I have only used it to build Leksah, but it has a lot of packages available. Hamish___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Significant performance improvements for Data.Map
On Sunday 29 August 2010 15:17:20, Don Stewart wrote: http://hackage.haskell.org/trac/ghc/ticket/4277 Proposal: Significant performance improvements for Data.Map Description Milan Straka's recent [52] Haskell Symposium paper (PDF) shed light on the containers:Data.Map library, indicating there were both algorithmic and stylistic performance improvements to be made. 52. http://research.microsoft.com/~simonpj/papers/containers/containers.pdf The [58] benchmark results are very strong: * An average speedup across the core api of 47% (on intel i7 / linux 64 bit), and; * 36% on Mac / intel core 2 duo 32 bit). http://i.imgur.com/05BWe.png 58. http://is.gd/eJHIE That is great. Have you any data about the speedup relative to map sizes? Milan Straka's benchmarks ran only on very small maps (= 2^10 elements), I'd be interested in whether size plays a significant role in the effect. The consideration period is 3 weeks (before ICFP). Where do I register my support? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] open and closed
This is pure speculation, inspired in part by Brent Yorgey's blog post[1] from a few weeks ago. I'm wondering if it might be possible, in theory, to have both open and closed variants for each of value-level functions, type functions, and classes, in a fairly analogous way. (Maybe you could even have open (G)ADTs, which you would then need open functions to match on; or maybe a closed one with a case for _ to ensure exhaustiveness.) In each case you'd have the closed variant requiring you to keep all the definitions in the same module, permitting overlap, and trying to match definitions in the order they're listed; whereas the open variant would let you have definitions across modules, would forbid overlap (or would require definitions to be equivalent where they overlap, as with type families), and would always select the uniquely matching definition. Open value-level functions with this scheme would be inherently partial, which is bad. (It's not a problem at the type level because you just get a compile error if nothing matches, but an exception at runtime isn't so nice.) As a solution, perhaps it might be possible to allow a limited form of overlap (or don't even call it overlap) for the open variants: a default use this is if nothing else matches definition (which would need to be in the same module as the original class / type family declaration, or whatever ends up being analogous for open value-level functions, maybe the type signature). That way you could use Maybe for open value-level functions and make the default Nothing, among other options. Overlap in type functions allegedly makes typechecking unsound; I don't know if that would also hold in this more limited case. This would definitely break the property where adding or removing an import can't change the behaviour of a program other than whether it compiles, which is considered very important by many [2], so maybe it's not a good solution. (Possibly you could add explicit import/export control for instances/other-open-things to alleviate this, in a way so that definitions for open thingies with default definitions (at least) would always have to imported explicitly, thereby acknowledging that it might change behaviour... or maybe that would be a bandaid too far, I dunno.) (I think this would also cover most (if not all?) of the use cases for OverlappingInstances, which permits overlap and selects the most specific instance in a more general fashion; but maybe that doesn't matter if the two are equally bad, I don't know. I'm not 100% clear on peoples' opinion of OverlappingInstances, but I as far as I know the problems are twofold: both import-unsafeness, and the matter of how you would actually define most specific in a way that's both rigorous and intuitive; this would remove at least the latter.) Anyway, thoughts? Is this all completely crazy and way out there? [1] http://byorgey.wordpress.com/2010/08/05/typed-type-level-programming-in-haskell-part-iv-collapsing-types-and-kinds/ [2] http://hackage.haskell.org/trac/haskell-prime/wiki/LanguageQualities -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
Isn't there a binary for Leksah on the main site for windows anyways? On 29/08/2010 10:24 PM, Hamish Mackenzie hamish.k.macken...@googlemail.com wrote: On 28 Aug 2010, at 04:58, Andrew Coppin wrote: Mathew de Detrich wrote: There is also Leksah a... I am not familiar with that Leksah :-) Seriously though here is one way to build it... Install Haskell Platform Use TakeOffGW (http://sourceforge.net/projects/takeoffgw/) to install : * pkg-config (in the Devel section of the installer) * gtksourceview (Libs) * gtksourceview-devel (Libs). * automake1.9-bin (Devel) * msys-bash-bin (MSYS) * msys-gawk-bin (MSYS) * msys-grep-bin (MSYS) * msys-sed-bin (MSYS) * msys-tar-bin (MSYS) (Once GHC 6.14.1 is released, only the first three should be needed, as the rest are needed to build process-leksah). Make sure the following are in your PATH : * Haskell Platform\mingw\bin * c:\mingw\i686-pc-mingw32\sys-root\mingw\bin (needed mainly for pkg-config) * Your Home Folder\AppData\Roaming\cabal\bin (will be needed for the gtk2hs build tools once they are installed) * c:\mingw\bin Also add the following to your environment : * PKG_CONFIG_PATH=/i686-pc-mingw32/sys-root/mingw/lib/pkgconfig C:\cabal install gtk2hs-buildtools C:\cabal install leksah C:\leksah If you get stuck jump on IRC #leksah or email the leksah group. Hamish___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-c... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Support for lock-free/wait-free programming?
Gabriel Wicke wi...@wikidev.net writes: Hello Gregory, thanks for your patch. I have just uploaded bits-extras-0.1.1 [1] with tweaked CC-Options to only include -Wall on non-linux systems (plus minor documentation tweaks). Could you check if this compiles on OSX? I would prefer to keep -Wall enabled if possible. It doesn't work because you missed the other half of my patch, removing the reference to libgcc_s -- programs link just fine without it. With it in there I get: Resolving dependencies... Downloading bits-extras-0.1.1... Configuring bits-extras-0.1.1... cabal: Missing dependency on a foreign library: * Missing C library: gcc_s G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unicode pretty-printing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/29/10 07:35 , Ivan Lazar Miljenovic wrote: On 29 August 2010 21:24, Peter Gromov gromop...@gmail.com wrote: $ locale LANG= LC_COLLATE=C LC_CTYPE=C LC_MESSAGES=C LC_MONETARY=C LC_NUMERIC=C LC_TIME=C LC_ALL= Unfortunately, I'm completely lame with locales and googling doesn't help very much to change C to something like UTF-8 (Mac, Snow Leopard). But the terminal does support UTF-8 anyway, as the output from my previous message shows (the main function output). No idea about dealing with Macs, sorry. export LC_ALL=en_US.UTF-8 Terminal.app normally does this automatically; see Preferences Settings, Advanced tab for whatever terminal definition you are using. At the bottom of the pane, under International, make sure Set locale environment variables on startup is checked. Another way to do it is to arrange for the Finder to launch with the locale pre-set. You want something like this: mress:20011 Z$ plutil -convert xml1 -o - ~/.MacOSX/environment.plist ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keyLANG/key stringen_US.UTF-8/string keyLC_ALL/key stringen_US.UTF-8/string /dict /plist You'll have to log out and back in to activate it. (Alternatively to manipulating plists by hand, use something like URI:http://www.apple.com/downloads/macosx/system_disk_utilities/environmentvariablepreferencepane.html ( http://preview.tinyurl.com/3ythrds ).) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx6jeoACgkQIn7hlCsL25XDxwCguNj0ciIDtCOJJvXaCslhTlx0 PG4AoKF79lzQxNfFRQuJjiFdPGfIMzaZ =GacS -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Significant performance improvements for Data.Map
On Sun, Aug 29, 2010 at 3:41 PM, Daniel Fischer daniel.is.fisc...@web.dewrote: That is great. Have you any data about the speedup relative to map sizes? Milan Straka's benchmarks ran only on very small maps (= 2^10 elements), I'd be interested in whether size plays a significant role in the effect. I just ran an ad-hoc test to get an indication of of the performance gains scale with the map size. I ran the lookup benchmark, which looks up all the elements in a map, and I got a 37% improvement running with a map size of 2^22 elements. Compare this to the 42% gain I get on the same benchmark with a map of 2^10 elements. This is just an indication as I didn't really investigate where the time went. It's something I'd like to look into in the future. It'd be worthwhile to rerun all the benchmarks on a larger map on a machine with a lot of RAM. The number of elements is simple to change in benchmarks/Benchmarks.hs. To run the benchmark do: $ cd benchmarks $ ghc -DTESTING --make -O2 -fforce-recomp -i.. Benchmarks.hs $ ./Benchmarks and the run the benchmarks against the old vesion: $ ghc -DTESTING --make -O2 -fforce-recomp -i../../containers-0.3.0.0 Benchmarks.hs $ ./Benchmarks It'll take a while if you use large maps as criterion runs each benchmark 100 times. I recommend using GHC 6.12.3 as it performs better than e.g. 6.12.1. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/29/10 08:05 , Ivan Lazar Miljenovic wrote: On 29 August 2010 21:46, Andrew Coppin andrewcop...@btinternet.com wrote: a) No standard place to find C include files. b) No standard place to find libraries. c) No standard way to find if common open source libraries are installed and where. As best as I can tell, the Unix Standard Way(tm) to do this kind of thing is to put files into well known locations so that they can be easily found. (The fact that tools like autoconf need to exist tells you something about how tricky this can be.) No, autoconf has nothing to do with where the well known locations are. It's having to deal with different versions, etc. of libraries. Not entirely true; it also deals (or used to deal) with the fact that you may have stuff in /opt/SUNWsft (Solaris), /opt/kde (SuSE), /usr/local, /opt/local (MacPorts), /sw (Fink), etc. Then again, that's what pkg-config deals with these days, leaving autoconf to deal with different APIs/ABIs (different versions, different build options) as long as the software you're building is up to date. Regardless, you'd think Cabal could provide some way to make it easy to state where the files it needs actually are. Currently it does not. Well, it uses ghc-pkg to record where the various libraries, etc. are. Otherwise, it could be that none of the Cabal developers are really that familiar with the best practices of developing Windows software (and clobbering the registry whilst your at it). Note that Cabal is no better at tracking location of non-Haskell resources on Unix. (In fact, isn't that what started this topic?) By the way, is it possible to have a globally installed library in Windows (for C, etc.) that can be used no matter which IDE or editor you use? Or does each IDE manage all that on its own? DLLs can be put into C:\WINDOWS\SYSTEM32 or equivalent (e.g. Windows NT liked to install itself in C:\WINNT instead of C:\WINDOWS). LIB files are less standard and I'm under the impression that every IDE uses its own notion of where to put them (and may not use the registry in a non-opaque way). BTW, if there *is* some standard registry tree that can be used for this, it should be possible to provide a Windows version of pkg-config that would hide most of this. Replacing autoconf is harder, though it might be possible to work from configure.in (or even configure.am when automake is involved). - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx6k60ACgkQIn7hlCsL25UeugCdGEYqFmU0GstywKpFaTwDTGHn 1+cAoNNz8A7sM/XM2GCQdeFSTY/ML5hY =eK9N -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Support for lock-free/wait-free programming?
Gregory Collins g...@gregorycollins.net writes: It doesn't work because you missed the other half of my patch, removing the reference to libgcc_s -- programs link just fine without it. With it in there I get: ...sigh... The programs link fine without it part is a partial lie. Anything that the C linker links (i.e. executables) works fine without an explicit -lgcc_s, but ghci and compilations using template haskell fail with an unknown symbol `___bswapdi2', or equivalent. Looking for a workaround now. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/29/10 13:06 , Brandon S Allbery KF8NH wrote: may have stuff in /opt/SUNWsft (Solaris), /opt/kde (SuSE), /usr/local, Wrong path for Solaris. *sigh* We don't use Sun's OSS package, in part because we don't have anything newer than Solaris 9. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx6lDwACgkQIn7hlCsL25Ud+gCfdGrPKCcGTFWcDwoYvFxEbo4T j0sAn1vUOANtSHDL/F9iLnuMYdjVauEz =LnFe -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] open and closed
Hi,
The details of the issues involved in an open and closed facility for
Haskell are way beyond my current understanding of the language.
Nonetheless, I was wondering does this have anything to do with the
expression problem?
Pat
17/08/2010 14:48 Victor Nazarov asviraspossi...@gmail.com wrote:
Finally tagless technique seems to solve expression problem using
pretty basic Haskell:
--
module AddExp where
class AddExp e
where add :: e - e - e
lit :: Int - e
-- Type signature is required
-- monomorphism restriction will act otherwise
test :: AddExp e = e
test = add (lit 6) (lit 2)
-
module MulExp where
class MulExp e
where mul :: e - e - e
-- Type signature is required
-- monomorphism restriction will act otherwise
test1 :: (AddExp e, MulExp e) = e
test1 = mul test (lit 3)
-
module Evaluator
import AddExp where
newtype Eval = E { eval :: Int }
instance AddExp Eval
where lit = E
add (E a) (E b) = E (a + b)
-
module PrettyPrinter where
import AddExp
import MulExp
newtype PrettyPrint = P { prettyPrint :: String }
instance AddExp (PrettyPrint)
where lit n = show n
add (P a) (P b) = concat [a, + , b]
instance MulExp (PrettyPrint)
where mul (P a) (P b) = concat [a, * , b]
-- Victor Nazarov
Gábor Lehel wrote:
This is pure speculation, inspired in part by Brent Yorgey's blog
post[1] from a few weeks ago.
I'm wondering if it might be possible, in theory, to have both open
and closed variants for each of value-level functions, type functions,
and classes, in a fairly analogous way. (Maybe you could even have
open (G)ADTs, which you would then need open functions to match on; or
maybe a closed one with a case for _ to ensure exhaustiveness.)
In each case you'd have the closed variant requiring you to keep all
the definitions in the same module, permitting overlap, and trying to
match definitions in the order they're listed; whereas the open
variant would let you have definitions across modules, would forbid
overlap (or would require definitions to be equivalent where they
overlap, as with type families), and would always select the uniquely
matching definition.
Open value-level functions with this scheme would be inherently
partial, which is bad. (It's not a problem at the type level because
you just get a compile error if nothing matches, but an exception at
runtime isn't so nice.) As a solution, perhaps it might be possible to
allow a limited form of overlap (or don't even call it overlap) for
the open variants: a default use this is if nothing else matches
definition (which would need to be in the same module as the original
class / type family declaration, or whatever ends up being analogous
for open value-level functions, maybe the type signature). That way
you could use Maybe for open value-level functions and make the
default Nothing, among other options. Overlap in type functions
allegedly makes typechecking unsound; I don't know if that would also
hold in this more limited case. This would definitely break the
property where adding or removing an import can't change the behaviour
of a program other than whether it compiles, which is considered very
important by many [2], so maybe it's not a good solution. (Possibly
you could add explicit import/export control for
instances/other-open-things to alleviate this, in a way so that
definitions for open thingies with default definitions (at least)
would always have to imported explicitly, thereby acknowledging that
it might change behaviour... or maybe that would be a bandaid too far,
I dunno.)
(I think this would also cover most (if not all?) of the use cases for
OverlappingInstances, which permits overlap and selects the most
specific instance in a more general fashion; but maybe that doesn't
matter if the two are equally bad, I don't know. I'm not 100% clear on
peoples' opinion of OverlappingInstances, but I as far as I know the
problems are twofold: both import-unsafeness, and the matter of how
you would actually define most specific in a way that's both
rigorous and intuitive; this would remove at least the latter.)
Anyway, thoughts? Is this all completely crazy and way out there?
[1]
http://byorgey.wordpress.com/2010/08/05/typed-type-level-programming-in-haskell-part-iv-collapsing-types-and-kinds/
[2] http://hackage.haskell.org/trac/haskell-prime/wiki/LanguageQualities
This message has been scanned for content and viruses by the DIT Information
Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] open and closed
I'm not sure if they're within my own, either. The expression problem
did fleetingly cross my mind while thinking about this. Open ADTs +
open functions might be a very simple solution to it - that is, if
they make sense at all. I haven't thought it through thoroughly
though.*
Another thing I'm wondering about is that there's a fairly intuitive
correspondence between functions at the value level vs. functions at
the type level, and datatypes to classify the value level vs.
datakinds to classify the type level, but what corresponds to type
classes at the value level? There's also all kinds of weird
interactions like whether you could have an open function as the
implementation of a type class method.
* I think this might be some kind of personal record for density of
unique words matching /th[a-z]*ough[a-z]*/ in a single sentence.
2010/8/29 Patrick Browne patrick.bro...@dit.ie:
Hi,
The details of the issues involved in an open and closed facility for
Haskell are way beyond my current understanding of the language.
Nonetheless, I was wondering does this have anything to do with the
expression problem?
Pat
17/08/2010 14:48 Victor Nazarov asviraspossi...@gmail.com wrote:
Finally tagless technique seems to solve expression problem using
pretty basic Haskell:
--
module AddExp where
class AddExp e
where add :: e - e - e
lit :: Int - e
-- Type signature is required
-- monomorphism restriction will act otherwise
test :: AddExp e = e
test = add (lit 6) (lit 2)
-
module MulExp where
class MulExp e
where mul :: e - e - e
-- Type signature is required
-- monomorphism restriction will act otherwise
test1 :: (AddExp e, MulExp e) = e
test1 = mul test (lit 3)
-
module Evaluator
import AddExp where
newtype Eval = E { eval :: Int }
instance AddExp Eval
where lit = E
add (E a) (E b) = E (a + b)
-
module PrettyPrinter where
import AddExp
import MulExp
newtype PrettyPrint = P { prettyPrint :: String }
instance AddExp (PrettyPrint)
where lit n = show n
add (P a) (P b) = concat [a, + , b]
instance MulExp (PrettyPrint)
where mul (P a) (P b) = concat [a, * , b]
-- Victor Nazarov
Gábor Lehel wrote:
This is pure speculation, inspired in part by Brent Yorgey's blog
post[1] from a few weeks ago.
I'm wondering if it might be possible, in theory, to have both open
and closed variants for each of value-level functions, type functions,
and classes, in a fairly analogous way. (Maybe you could even have
open (G)ADTs, which you would then need open functions to match on; or
maybe a closed one with a case for _ to ensure exhaustiveness.)
In each case you'd have the closed variant requiring you to keep all
the definitions in the same module, permitting overlap, and trying to
match definitions in the order they're listed; whereas the open
variant would let you have definitions across modules, would forbid
overlap (or would require definitions to be equivalent where they
overlap, as with type families), and would always select the uniquely
matching definition.
Open value-level functions with this scheme would be inherently
partial, which is bad. (It's not a problem at the type level because
you just get a compile error if nothing matches, but an exception at
runtime isn't so nice.) As a solution, perhaps it might be possible to
allow a limited form of overlap (or don't even call it overlap) for
the open variants: a default use this is if nothing else matches
definition (which would need to be in the same module as the original
class / type family declaration, or whatever ends up being analogous
for open value-level functions, maybe the type signature). That way
you could use Maybe for open value-level functions and make the
default Nothing, among other options. Overlap in type functions
allegedly makes typechecking unsound; I don't know if that would also
hold in this more limited case. This would definitely break the
property where adding or removing an import can't change the behaviour
of a program other than whether it compiles, which is considered very
important by many [2], so maybe it's not a good solution. (Possibly
you could add explicit import/export control for
instances/other-open-things to alleviate this, in a way so that
definitions for open thingies with default definitions (at least)
would always have to imported explicitly, thereby acknowledging that
it might change behaviour... or maybe that would be a bandaid too far,
I dunno.)
(I think this would also cover most (if not all?) of the use cases for
OverlappingInstances, which permits overlap and selects the most
specific instance in a more general fashion; but maybe that doesn't
matter if the two are equally bad, I
[Haskell-cafe] Re: Announce: Significant performance improvements for Data.Map
Don Stewart dons at galois.com writes: Proposal: Significant performance improvements for Data.Map sounds great! I use Data.Map/Set a lot. Although I guess one reason for their popularity is, well, their popularity - as they used to ship with ghc. And there never was a universally accepted collections framework (type classes) that would allow to exchange implementations easily. Even with such a framework, it might not be that easy. 52. http://research.microsoft.com/~simonpj/papers/containers/containers.pdf for the transformations mentioned there: instead of applying them manually, one would want to have them provided by the compiler? I guess that's a question for a follow-up paper. (I generally avoid/hate to rewrite my programs systematically, just for performance reasons.) J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On 29 August 2010 18:06, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: DLLs can be put into C:\WINDOWS\SYSTEM32 or equivalent (e.g. Windows NT liked to install itself in C:\WINNT instead of C:\WINDOWS). LIB files are less standard and I'm under the impression that every IDE uses its own notion of where to put them (and may not use the registry in a non-opaque way). BTW, if there *is* some standard registry tree that can be used for this, it should be possible to provide a Windows version of pkg-config that would hide most of this. Replacing autoconf is harder, though it might be possible to work from configure.in (or even configure.am when automake is involved). Windows has a standard place for header files path-to-MinGW\MinGW\include Similary for .a's and .o's: path-to-MinGW\MinGW\lib For /usr/local installs the path is: path-to-msys\msys\1.0\local with bin, include, lib and share comfortably placed in local. ./configure make make install will do the right thing for installing source packages. Binary packages are available from MinGW's repository. Its a defacto standard, but its still a standard. If people are using Cygwin or Microsoft's Unix compatibility layer, Visual C or even the parts of MinGW distributed with GHC, they aren't documenting their successes so no-one else can follow them, for all intents and purposes MinGW/Msys is the only game in town. [Caveat - Cygwin is fine for developing if you just want a good shell and aren't working with FFI bindings]. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On Aug 27, 2010, at 4:52 PM, John Millikin wrote: On Thu, Aug 26, 2010 at 20:51, I wrote: Maybe Linux is different. One thing is NOT different, and that is Linux upgrades *DO* reliably break programs that use dynamic linking. Upgrading Linux should never, ever cause applications to stop working unless they were designed incorrectly in the first place. Linux in this context means the system as perceived by users, a distribution, not just a kernel. Desktop-oriented distributions, such as Ubuntu or Fedora, are not suitable for long-term ( 6 years or so) installations. Fedora is one of the Linux distributions I was talking about. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On Aug 27, 2010, at 9:13 PM, Andrew Coppin wrote: Why would you ever want to install a package per-user? I mean, if you don't have permission to do a global install, then you also don't have permission to install GHC in the first place so...? Indeed, the *only* plausible reason I can think of is if you're trying to build something that has unusual package version constraints, and you want to build it without upsetting the entire system. Scenario: A University Computer Science Department. One or more laboratories bung full of machines. A shared file server with rack upon rack of discs holding all the student-accessible files, in another room. Administrators install required software before each semester. If you are lucky, this includes Haskell. A student needs a package. The student *CAN'T* do a global install. The administrators are busy. The student CAN do a per-user install. The day is saved! Much cheering. So the answer to the question is obvious: you want to install a package per-user if you are NOT THE SAME PERSON as the one who originally installed GHC. It's slightly disturbing how the proposal meantions make every three sentences. You realise that make only exists under Unix, right? There _are_ other operating systems out there... Like OpenVMS, which has MMS (Dec's clone of Make), MMK (a clone of MMS), GNU Make, and by now several other ports of make. Like Windows, which has had NMake for yonks, plus ports of other makes, e.g., GNU Make at http://unxutils.sourceforge.net/ (not Cygwin, native Win32). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On Aug 27, 2010, at 11:40 PM, Andrew Coppin wrote: What all this proves is that XML can be horrid, or it can be just fine. Personally, I would have no problem with writing Namefoo/Name Version1.0/Version SynopsisThis does stuff./Synopsis Now I don't have to worry about whitespace; XML has rules for all that. Multiple conflicting sets of rules, in fact. There _is_ a notion of element content white space, however, non-validating parsers like expat can't KNOW which white space is ecws and which is not. Huh, I was under the impression that you could just use unix-style file paths in a relative fashion with Cabal even on Windows... Uhuh, and how do you specify whether the files are under C: or D:? Since early MS-DOS days, / and \ have been interchangeable except in the command language. If you want C:\FOO\BAR to pass to a system function, C:/FOO/BAR will work just as well. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Looking for a course using Haskell in the Tokyo area
Does anybody know where I can find a course (preferably at the graduate level) using Haskell in the Tokyo area? I searched through Haskell in education - HaskellWiki (see http://www.haskell.org/haskellwiki/Haskell_in_education), but was unable to find anything. In particular, if anybody is aware of any courses using Haskell at either the Tokyo Institute of Technology (see http://www.titech.ac.jp/english/) or the University of Tsukuba (see http://www.tsukuba.ac.jp/english/), I would be especially interested. The closest I was able to find was a graduate course in Logic in Computer Software at the University of Tsukuba using OCaml, but I am not especially fond of the syntax of OCaml after having become familiar with Haskell. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Significant performance improvements for Data.Map
On Sunday 29 August 2010 18:48:32, Johan Tibell wrote: On Sun, Aug 29, 2010 at 3:41 PM, Daniel Fischer daniel.is.fisc...@web.dewrote: That is great. Have you any data about the speedup relative to map sizes? Milan Straka's benchmarks ran only on very small maps (= 2^10 elements), I'd be interested in whether size plays a significant role in the effect. I just ran an ad-hoc test to get an indication of of the performance gains scale with the map size. I ran the lookup benchmark, which looks up all the elements in a map, and I got a 37% improvement running with a map size of 2^22 elements. Compare this to the 42% gain I get on the same benchmark with a map of 2^10 elements. This is just an indication as I didn't really investigate where the time went. It's something I'd like to look into in the future. For what it's worth, I ran the benchmarks for various sizes up to 2^20. Since the old Data.Map doesn't have foldlWithKey' and insertLookupWithKey', I used the unprimed versions of those for the old Data.Map. That doesn't have much impact on the insertLookupWithKey' tests, but the foldlWithKey' test is of course terrible with a large map, so that shows atypical behaviour. In general, from just looking at the numbers without statistical analysis, it seems that the size of the map doesn't matter much. For most benchmarks, the speedup doesn't show a clear trend of growing or shrinking with the map size. The numbers in the table are (mean of new Map) / (mean of old Map). A file with a few more sizes is attached. Size of map (2^k) 8 10 12 15 20 alter : 0.5232 0.5050 0.5153 0.5396 0.5449 delete : 0.5825 0.5601 0.5632 0.5810 0.5656 foldlWithKey: 0.6109 0.6028 0.6761 0.6858 0.6810 foldlWithKey' : 0.4761 0.4991 0.3090 0.0890 0.0085 foldrWithKey: 0.8184 0.7933 0.7673 0.5367 0.8977 insert : 0.5943 0.5208 0.5803 0.5656 0.5172 insertLookupWithKey empty : 0.5710 0.5947 0.6025 0.5735 0.5552 insertLookupWithKey update : 0.6733 0.6773 0.7115 0.7265 0.7241 insertLookupWithKey' empty : 0.5992 0.6115 0.5946 0.5935 0.5660 insertLookupWithKey' update : 0.6339 0.6071 0.6256 0.6298 0.6346 insertWith empty: 0.5686 0.5267 0.5776 0.5591 0.5163 insertWith update : 0.6558 0.5949 0.6880 0.7053 0.6822 insertWith' empty : 0.5341 0.4839 0.5691 0.5409 0.5068 insertWith' update : 0.6075 0.5914 0.6814 0.7027 0.6880 insertWithKey empty : 0.5650 0.5031 0.5620 0.5545 0.5098 insertWithKey update: 0.6216 0.5963 0.7005 0.7283 0.7105 insertWithKey' empty: 0.5584 0.5150 0.5585 0.5355 0.5057 insertWithKey' update : 0.5945 0.5908 0.6892 0.6865 0.6814 lookup : 0.6921 0.6772 0.6834 0.6601 0.7013 lookupIndex : 0.5345 0.5225 0.5120 0.5270 0.4873 map : 0.9015 0.8958 0.8544 0.8608 0.8059 mapMaybe: 0.8643 0.8654 0.8283 0.7799 0.7766 mapMaybeWithKey : 0.8546 0.8494 0.8181 0.7842 0.7844 mapWithKey : 0.9442 0.9263 0.8671 0.9236 0.8898 update : 0.5455 0.5266 0.5305 0.5408 0.5518 updateLookupWithKey : 0.5734 0.5511 0.5779 0.5904 0.5927 Size of map (2^k) 56789 10 11 12 15 20 alter : 0.5411 0.5249 0.5389 0.5232 0.5357 0.5050 0.4569 0.5153 0.5396 0.5449 delete : 0.6116 0.5936 0.6005 0.5825 0.5902 0.5601 0.5648 0.5632 0.5810 0.5656 foldlWithKey: 0.6243 0.6261 0.6286 0.6109 0.6266 0.6028 0.5867 0.6761 0.6858 0.6810 foldlWithKey' : 0.5359 0.5422 0.4956 0.4761 0.5076 0.4991 0.4024 0.3090 0.0890 0.0085 foldrWithKey: 0.8671 0.8453 0.8300 0.8184 0.8325 0.7933 0.8055 0.7673 0.5367 0.8977 insert : 0.6745 0.6464 0.6136 0.5943 0.5639 0.5208 0.5774 0.5803 0.5656 0.5172 insertLookupWithKey empty : 0.6254 0.6042 0.5912 0.5710 0.5754 0.5947 0.5955 0.6025 0.5735 0.5552 insertLookupWithKey update : 0.6462 0.6656 0.6691 0.6733 0.6667 0.6773 0.7132 0.7115 0.7265 0.7241 insertLookupWithKey' empty : 0.6611 0.6443 0.6197 0.5992 0.5774 0.6115 0.6034 0.5946 0.5935 0.5660 insertLookupWithKey' update : 0.6363 0.6328 0.6427 0.6339 0.6443 0.6071 0.6380 0.6256 0.6298 0.6346 insertWith empty: 0.6505 0.6374 0.5772 0.5686 0.5389 0.5267 0.5668 0.5776 0.5591
[Haskell-cafe] Using GHC Api to affect compilation of a module
Hello people, I'm evaluating the use of the GHC API (6.12.3) to piggyback into the compilation process (in order, for example, to implement a custom optimization) and I'm having a lot of trouble doing so. In particular, I tried to modify a program being compiled, by working on its Core representation. The idea is that the skeleton of the program would be something like: runGhc (Just libdir) $ do ... c - compileToCoreModule targetFile compileCoreToObj False (modify c) ... with modify :: CoreModule - CoreModule being, for now, a rather trivial (identity) function. The first issue I've found is that compileCoreToObj fails (the error is expectJust mkStubPaths). However, I've also found that when compileToCoreModule ends, the .hi and .o files have already been produced, which kind of defeats any attempt to change the core code and then proceeding with the rest of the compilation. Am I doing this right? By scanning over the GHC API documentation those functions seemed to be the appropriate ones to start testing with, but I guess there's something trivial (or not) I'm missing. I'd be really thankful for any input. Best regards, - Matias H. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ICFP Hotel Room
Hi all, I'm a graduate student (male) and am looking for a (male) roommate to split the cost of a hotel room at ICFP. If anyone is interested in splitting a room, please drop me a line. I will be attending the workshops collocated with ICFP so I currently have a reservation at the conference hotel (at the conference rate) with check-in on September 24 (the day before the first workshop) and check-out on October 3 (the day after the last workshop). Michael D. Adams Ph.D. Student, Indiana University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
Looks like the fmap definition for the Either functor matches what's given in Learn You A Haskell ... instance Functor (Either a) where fmap f (Right x) = Right (f x) fmap f (Left x) = Left x but Hoogle couldn't find Control.Monad.Instances How else can I look at the code? Michael [mich...@localhost ~]$ ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude :m + Control.Monad.Instances Prelude Control.Monad.Instances :m + Data.Either Prelude Control.Monad.Instances Data.Either let l = Left 5 Prelude Control.Monad.Instances Data.Either fmap (*2) l Left 5 Prelude Control.Monad.Instances Data.Either let r = Right five Prelude Control.Monad.Instances Data.Either fmap length r Right 4 --- On Sat, 8/28/10, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: From: Brandon S Allbery KF8NH allb...@ece.cmu.edu Subject: Re: [Haskell-cafe] On to applicative To: haskell-cafe@haskell.org Date: Saturday, August 28, 2010, 9:06 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/28/10 20:43 , michael rice wrote: I'm looking at a discussion of Either (as functor) here: http://learnyouahaskell.com/making-our-own-types-and-typeclasses#the-functor-typeclass instance Functor (Either a) where fmap f (Right x) = Right (f x) fmap f (Left x) = Left x And this line in Data.Either Functor (Either a) but no fmap defined here. How come? Historical accident, to wit: Haskell 98 minimally defined Either in the Prelude, so in practice we get the basic definitions (Either itself and its Functor and Monad instances) from the Prelude and other utility functions from Data.Either. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx5sq4ACgkQIn7hlCsL25WA+QCeKUOuNN4kUpci9fH6BcFZ5WqG bX8AoIBImpWLoxVz7kcwVIuHycYR/v5G =EaIs -END PGP SIGNATURE- ___ 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] On to applicative
On 30 August 2010 14:25, michael rice nowg...@yahoo.com wrote: Looks like the fmap definition for the Either functor matches what's given in Learn You A Haskell ... instance Functor (Either a) where fmap f (Right x) = Right (f x) fmap f (Left x) = Left x but Hoogle couldn't find Control.Monad.Instances How else can I look at the code? http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Monad-Instances.html -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
Hi Ivan, I already looked there and didn't find anything, but went back and noticed the Source Code at the top right of the page and found it there. Why are there two source codes, the one at the top and the ones down the right margin (all the same from what I can tell). Michael --- On Mon, 8/30/10, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: From: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com Subject: Re: [Haskell-cafe] On to applicative To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org, Brandon S Allbery KF8NH allb...@ece.cmu.edu Date: Monday, August 30, 2010, 12:36 AM On 30 August 2010 14:25, michael rice nowg...@yahoo.com wrote: Looks like the fmap definition for the Either functor matches what's given in Learn You A Haskell ... instance Functor (Either a) where fmap f (Right x) = Right (f x) fmap f (Left x) = Left x but Hoogle couldn't find Control.Monad.Instances How else can I look at the code? http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Monad-Instances.html -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On to applicative
On 30 August 2010 14:50, michael rice nowg...@yahoo.com wrote: Hi Ivan, I already looked there and didn't find anything, but went back and noticed the Source Code at the top right of the page and found it there. Why are there two source codes, the one at the top and the ones down the right margin (all the same from what I can tell). The ones on the side are direct links to the sources for a particular function/value/etc.; the top one just links to the file. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
