Re: [Haskell-cafe] Code that writes code
I would also like to strongly discourage code generators. Any code that has to be generated can and should have its common characteristics separated out with only unique characterstic remaining typically with an interface (i.e. type class) or polymorphic type dividing the two, creating a separation of concerns (this is really just abstraction). Every software project which I've worked on that used a code generator turned into a nightmare, because when we find we need to change something about the generator's output, all the already generated code has to be updated manually while at the same time maintaining all of the unique modifications that have been since the code was first generated. It's a horrible duplication of program logic and maintenance work. Of course code generation is perfectly fine when the output is not intended to be read and maintained by a human. For example, a compiler is technically a code generator, but it is purely for optimization purposes and the output is not intended to then be maintained by a human manually. A compiler might unroll a loop repeating the loop body a hundred times causing obvious duplication of logic, but it's fine because the assembler output is not intended to be maintained by a human, only the source input is. Efficiency and maintainability cannot be satisfied at the same time, which is why assembly sucks (not maintainable) and so do dynamic/scripting languages (not efficient), and compiled languages like Haskell are awesome (source code is highly maintainable, compiler output is highly efficient). Anyway, from my experience if you're generating code intended to be maintained by a human, you're doing it wrong. Though I am very interested to hear counter examples. Jesse On 20/08/2010 6:17 PM, Graham Klyne wrote: Maybe not helpful to you at this stage, but... An alternative to generating source code is to factor out the common boilerplate elements into separate functions, suitably parameterized, and to use higher order functions to stitch these together. An example of this kind of approach, which is handled by code generation in some other languages (e.g. lex, yacc, etc), is the Parsec combinator-based parsing library (http://www.haskell.org/haskellwiki/Parsec) - instead of generating code, the syntax rules are written directly using Haskell functions and assemble the common underlying repeated logic dynamically, behind the scenes. I adopted a development of this approach for a programme with a built-in scripting language that I implemented some time ago: the scripting language was parsed using Parsec, not into a syntax tree, but directly into a dynamically assembled function that could be applied to some data to perform the scripted function (http://www.ninebynine.org/RDFNotes/Swish/Intro.html). What I'm trying to point out here that, rather than go through the step of generating source code and feeding it back into a Haskell compiler, it may be possible to use higher order functions to directly assemble the required logic within a single program. For me, this is one of the great power-features of functional programming, which I now tend to use where possible in other languages that support functions as first class values. #g -- Andrew Coppin wrote: I'm working on a small Haskell package. One module in particular contains so much boilerplate that rather than write the code myself, I wrote a small Haskell program that autogenerates it for me. What's the best way to package this for Cabal? Just stick the generated file in there? Or is there some (easy) way to tell Cabal how to recreate this file itself? ___ 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] Code that writes code
Bill Atkins wrote: Have you looked at creating Template Haskell splices to generate this for you? The thought had crossed my mind. On the other hand, with my current approach, the generated code is just another source file that doesn't look any different. On reflection, I kinda like that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code that writes code
Jesse Schalken wrote: I would also like to strongly discourage code generators. Any code that has to be generated can and should have its common characteristics separated out with only unique characterstic remaining typically with an interface (i.e. type class) or polymorphic type dividing the two, creating a separation of concerns (this is really just abstraction). All the facilities of my family of types is accessed through type classes already. Every software project which I've worked on that used a code generator turned into a nightmare, because when we find we need to change something about the generator's output, all the already generated code has to be updated manually while at the same time maintaining all of the unique modifications that have been since the code was first generated. It's a horrible duplication of program logic and maintenance work. Uh... why edit the generated code? Why not just modify the generator and rerun it? That's kind of the entire *point* of using a code generator rather than writing it all by hand... Anyway, from my experience if you're generating code intended to be maintained by a human, you're doing it wrong. Though I am very interested to hear counter examples. Yeah, I do get the feeling that if your code is repetative enough to require automation, you're probably doing it wrong... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
gdwe...@iue.edu wrote: I will try my hand at building a Windows binary for Sifflet and making it available for folks to download. I too was going to have a go at this. I had a Windows VM (so I don't ruin my *real* Windows box) and I was going to set up all the junk which is apparently necessary to make C bindings build. And then I was going to build all the libraries I want but can't have, package them up into nice little installers with NSIS, and make the binary installers available for each version of the Haskell Platform. But, as I say, I utterly failed to make MinGW and MSYS actually work. I never got as far as installing HP at all! I have recently acquired a Windows 7 system, partly for this very purpose. It's a guest host under Linux/KVM, and I think it's 32-bit Windows so it'll be a 32-bit binary, although my hardware is x86_64. Will that be okay? Better than nothing, I'd imagine. In fact, I'm not actually sure whether there *is* a 64-bit edition of GHC itself... Anybody know? I haven't done *anything* with Haskell on Windows yet! So the first step will be installing the Haskell Platform, which I hope will go smoothly, but the rest might take some time, if I succeed at all. HP installs under Windows just fine from what I've seen. I know GHC used to have an issue where only the current user's search path is updated, not the global one; I haven't tested whether HP does this. (Makes it fun if you have to log in as admin to install things; then only admin can run GHC!) I was surprised and pleased to discover that HP now contains zlib. (And it works!) I was surprised and disappointed to discover that they're planning to remote OpenGL support from HP. Presumably it's impossible to build from source if you want it, so there goes the end of that! Until now, I've held off using HP because Gtk2hs won't work with it. With the new Cabalised, Windows-buildable Gtk2hs, I believe this is no longer an issue. So maybe I'll finally update my main work machine to HP. Other options seem to be: - Asking for curl and hxt to be included in the Haskell Platform - Asking the author of hxt to split it into parts that do and do not depend on curl. But either of these would also probably take some time, if they are approved at all. Just including Curl in HP would presumably fix the problem. (I have a vague recollection that the Hackage Darcs package secretly requires libcurl, but doesn't actually depend on the Haskell curl package...) It's probably generally useful enough that it could be considered. Alternatively, make it possible to build C bindings on Windows. Yeah, don't hold your breath! So, don't hold your breath, Andrew, but I'll try. Good luck... ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code that writes code
Jesse Schalken jesseschal...@gmail.com writes: I would also like to strongly discourage code generators. Any code that has to be generated can and should have its common characteristics separated out with only unique characterstic remaining typically with an interface (i.e. type class) or polymorphic type dividing the two, creating a separation of concerns (this is really just abstraction). Every software project which I've worked on that used a code generator turned into a nightmare, because when we find we need to change something about the generator's output, all the already generated code has to be updated manually while at the same time maintaining all of the unique modifications that have been since the code was first generated. It's a horrible duplication of program logic and maintenance work. Of course code generation is perfectly fine when the output is not intended to be read and maintained by a human. For example, a compiler is technically a code generator, but it is purely for optimization purposes and the output is not intended to then be maintained by a human manually. A compiler might unroll a loop repeating the loop body a hundred times causing obvious duplication of logic, but it's fine because the assembler output is not intended to be maintained by a human, only the source input is. Efficiency and maintainability cannot be satisfied at the same time, which is why assembly sucks (not maintainable) and so do dynamic/scripting languages (not efficient), and compiled languages like Haskell are awesome (source code is highly maintainable, compiler output is highly efficient). Anyway, from my experience if you're generating code intended to be maintained by a human, you're doing it wrong. Though I am very interested to hear counter examples. *ahem* http://code.haskell.org/graphviz/utils/AttributeGenerator.hs Yes, it's ugly; the point is is that every time I want to edit what I do with the different Attributes in graphviz (e.g. I'm thinking of having smart Gen functions for QuickCheck tests that will generate specific types of Attributes suitable for DotNodes, etc.) I don't have to do so by hand and possibly edit code that's already there: I merely add the appropriate code-writing functions into that script, remove the already existing code, run the script and paste the result. Note that this is code that is generated at _write_ time, not build time; as much as possible the code is also generated to be human-readable: http://hackage.haskell.org/packages/archive/graphviz/2999.10.0.1/doc/html/src/Data-GraphViz-Attributes.html#Attribute (but I have stuffed up in the past and tried editing it by hand only to have breakages because I did it piece-meal rather than doing so all in one go, which the script allows me). That is, the script is just there to help me out rather than doing some fancy auto-generation stuff which I have no control over. -- 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
[Haskell-cafe] Hackage on Linux
Browsing around Hackage, I notice that a seemingly random subset of packages are available for something called arch linux. Presumably some sort of automatic conversion system is involved, but does anyone know why only certain packages appear? I've noticed that both Debian and OpenSUSE have a very tiny selection of binary Haskell packages too. I'm guessing that these packages are also auto-generated, but presumably selected by hand. (I also don't recall seeing them listed on Hackage.) Anybody know about that? In general, is there an advantage to having native packages for Haskell things? I guess it means you can have binary packages, so you don't need to build from source. And for executables, it means the native package manager can track all the dependencies and install them all for you, potentially without needing a Haskell build environment at all. Is that it, or have I missed something? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage on Linux
Andrew Coppin andrewcop...@btinternet.com writes: Browsing around Hackage, I notice that a seemingly random subset of packages are available for something called arch linux. Presumably some sort of automatic conversion system is involved, but does anyone know why only certain packages appear? I've noticed that both Debian and OpenSUSE have a very tiny selection of binary Haskell packages too. I'm guessing that these packages are also auto-generated, but presumably selected by hand. (I also don't recall seeing them listed on Hackage.) Anybody know about that? In general, is there an advantage to having native packages for Haskell things? I guess it means you can have binary packages, so you don't need to build from source. And for executables, it means the native package manager can track all the dependencies and install them all for you, potentially without needing a Haskell build environment at all. Is that it, or have I missed something? Hackage has limited support for distro maintainers to state which packages are available on the distribution. Last I checked, it required distro maintainers to keep a text file somewhere up to date. Note that not all distributions bother (in particular none of us involved with packaging Haskell packages for Gentoo can be bothered; we're slowly cutting back into only keeping packages that will actually be used rather than all and sundry), and even those that do might just list what's in the official repository (I think arch does this). Even then, Don Steward has a policy of packaging all and sundry for Arch (at least in the unofficial repository; this includes packages such as haskell-updater that are written for Gentoo). As for why using your distro package manager for Haskell packages is preferable: http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ -- 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] Hackage on Linux
Ivan Lazar Miljenovic wrote: Hackage has limited support for distro maintainers to state which packages are available on the distribution. Last I checked, it required distro maintainers to keep a text file somewhere up to date. Note that not all distributions bother. Yeah, I figured. I don't see any Debian or OpenSUSE anywhere, and I know they do have at least a few pre-built binary packages out there. It looks as if it's automated for Arch, however. Either that or somebody is spending an absurd amount of time keeping it manually up to date. (in particular none of us involved with packaging Haskell packages for Gentoo can be bothered; we're slowly cutting back into only keeping packages that will actually be used rather than all and sundry) Well, I guess you either manually select which packages to convert, or you have an automated system convert everything in sight. This whole observation came about because I noticed that some (but not all) of my own packages have ended up on Arch, despite being of almost no use to anybody. I was just curious as to how that happened. As for why using your distro package manager for Haskell packages is preferable: http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ Right. So Cabal isn't a package manager because it only manages Haskell packages? Not sure I agree with that definition. (It also has a laundry list of problems that can and should be fixed, but won't be.) I actually spent quite a while trying to figure out what the purpose of Cabal *is*. It's not like it's hard to download a bunch of Haskell source code and utter ghc --make Foo. So why do we even need Cabal in the first place? The answer, as far as I can tell, is that registering a library manually is so excruciatingly hard that we actually need a tool to automate the process. (Obviously when I first started using Haskell, I was mainly interested in writing runnable programs, not libraries.) Cabal can also run Haddock for you, which is quite hard. But it wasn't until cabal-install came along that I even realised that Cabal could track and resolve dependencies. (The fact that it doesn't track installed executables is news to me.) If nothing else, I think that what Cabal is should be documented much more clearly. It took me a hell of a long time to figure this out. Now, you say it's preferable to use the native package manager where possible. I've got one word for you: Windows. You know, the most popular OS on the market? The one installed on 98% of all computers world-wide? Guess what: no native package manager. Actually, we have tools that automatically convert Cabal packages to Debian packages or RPMs or whatever. I think there could be some milage in a tool that builds Windows installers. (The problem, of course, is that you have to be able to *build* the library on Windows first!) You would of course then have all kinds of fun and games with dependency tracking... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage on Linux
Andrew Coppin andrewcop...@btinternet.com writes:
Ivan Lazar Miljenovic wrote:
Hackage has limited support for distro maintainers to state which
packages are available on the distribution. Last I checked, it required
distro maintainers to keep a text file somewhere up to date.
Note that not all distributions bother.
Yeah, I figured. I don't see any Debian or OpenSUSE anywhere, and I
know they do have at least a few pre-built binary packages out there.
It looks as if it's automated for Arch, however. Either that or
somebody is spending an absurd amount of time keeping it manually up
to date.
Don has probably written a script to poll which packages are available
and write them to the required file.
(in particular none of us
involved with packaging Haskell packages for Gentoo can be bothered;
we're slowly cutting back into only keeping packages that will actually
be used rather than all and sundry)
Well, I guess you either manually select which packages to convert, or
you have an automated system convert everything in sight.
This whole observation came about because I noticed that some (but not
all) of my own packages have ended up on Arch, despite being of almost
no use to anybody. I was just curious as to how that happened.
The convert everything in sight approach.
As for why using your distro package manager for Haskell packages is
preferable:
http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/
Right. So Cabal isn't a package manager because it only manages
Haskell packages? Not sure I agree with that definition. (It also has
a laundry list of problems that can and should be fixed, but won't
be.)
Well, Cabal is just a build library; cabal-install automates downloading
and building of Haskell packages but not fully, can't uninstall, can't
update, etc.
Part of this is that it has bugs, can be improved, etc. (uninstallation,
etc.). However, I don't think a per-language build-tool like
cabal-install, rubygems, etc. can really be called a package manager.
I actually spent quite a while trying to figure out what the purpose
of Cabal *is*. It's not like it's hard to download a bunch of Haskell
source code and utter ghc --make Foo. So why do we even need Cabal
in the first place? The answer, as far as I can tell, is that
registering a library manually is so excruciatingly hard that we
actually need a tool to automate the process. (Obviously when I first
started using Haskell, I was mainly interested in writing runnable
programs, not libraries.) Cabal can also run Haddock for you, which is
quite hard. But it wasn't until cabal-install came along that I even
realised that Cabal could track and resolve dependencies. (The fact
that it doesn't track installed executables is news to me.)
Well, Cabal (more specifically the actual .cabal file) tells you a few
things:
1) Metadata on the library (homepage, description, version, etc.).
2) A list of dependencies that the package needs; this is especially
important when considering something like mtl vs monads-{fd,tf}:
which library did you grab Control.Monad.State from?
3) Specification of available library and executables.
4) Available modules for libraries, as well as those not actually
visible externally.
5) The ability to create tarballs for distribution (whilst VCS tools
like darcs can also do this, you sometimes keep some files in version
control that shouldn't be shipped with the release tarball).
6) Flags to change the behaviour and what to build, and the ability to
do some auto-detection to be able to have different build options for
Windows, etc.
All in all, Cabal serves two different aims:
* It provides metadata on what a Haskell package is.
* It's a very simplistic build system for Haskell packages.
If nothing else, I think that what Cabal is should be documented
much more clearly. It took me a hell of a long time to figure this
out.
Now, you say it's preferable to use the native package manager where
possible. I've got one word for you: Windows. You know, the most
popular OS on the market? The one installed on 98% of all computers
world-wide? Guess what: no native package manager.
Right, and that's when tools like cabal-install can come in handy (but I
believe there is a new-ish attempt at writing a package manager for
Windows over mingw).
Actually, we have tools that automatically convert Cabal packages to
Debian packages or RPMs or whatever. I think there could be some
milage in a tool that builds Windows installers. (The problem, of
course, is that you have to be able to *build* the library on Windows
first!) You would of course then have all kinds of fun and games with
dependency tracking...
Right, but again note the distinction: Cabal /= cabal-install; most
people call cabal-install a package manager; the distinction is
analogous to (but not quite the same as) RPM/deb vs yum/apt in
Fedora/Debian.
--
Ivan
Re: [Haskell-cafe] Hackage on Linux
Now, you say it's preferable to use the native package manager where possible. I've got one word for you: Windows. You know, the most popular OS on the market? The one installed on 98% of all computers world-wide? Guess what: no native package manager. Isn't Windows Installer (MSI) a package manager? /J On 22 August 2010 12:41, Andrew Coppin andrewcop...@btinternet.com wrote: Ivan Lazar Miljenovic wrote: Hackage has limited support for distro maintainers to state which packages are available on the distribution. Last I checked, it required distro maintainers to keep a text file somewhere up to date. Note that not all distributions bother. Yeah, I figured. I don't see any Debian or OpenSUSE anywhere, and I know they do have at least a few pre-built binary packages out there. It looks as if it's automated for Arch, however. Either that or somebody is spending an absurd amount of time keeping it manually up to date. (in particular none of us involved with packaging Haskell packages for Gentoo can be bothered; we're slowly cutting back into only keeping packages that will actually be used rather than all and sundry) Well, I guess you either manually select which packages to convert, or you have an automated system convert everything in sight. This whole observation came about because I noticed that some (but not all) of my own packages have ended up on Arch, despite being of almost no use to anybody. I was just curious as to how that happened. As for why using your distro package manager for Haskell packages is preferable: http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ Right. So Cabal isn't a package manager because it only manages Haskell packages? Not sure I agree with that definition. (It also has a laundry list of problems that can and should be fixed, but won't be.) I actually spent quite a while trying to figure out what the purpose of Cabal *is*. It's not like it's hard to download a bunch of Haskell source code and utter ghc --make Foo. So why do we even need Cabal in the first place? The answer, as far as I can tell, is that registering a library manually is so excruciatingly hard that we actually need a tool to automate the process. (Obviously when I first started using Haskell, I was mainly interested in writing runnable programs, not libraries.) Cabal can also run Haddock for you, which is quite hard. But it wasn't until cabal-install came along that I even realised that Cabal could track and resolve dependencies. (The fact that it doesn't track installed executables is news to me.) If nothing else, I think that what Cabal is should be documented much more clearly. It took me a hell of a long time to figure this out. Now, you say it's preferable to use the native package manager where possible. I've got one word for you: Windows. You know, the most popular OS on the market? The one installed on 98% of all computers world-wide? Guess what: no native package manager. Actually, we have tools that automatically convert Cabal packages to Debian packages or RPMs or whatever. I think there could be some milage in a tool that builds Windows installers. (The problem, of course, is that you have to be able to *build* the library on Windows first!) You would of course then have all kinds of fun and games with dependency tracking... ___ 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] Hackage on Linux
Jonas Almström Duregård jonas.dureg...@gmail.com writes: Now, you say it's preferable to use the native package manager where possible. I've got one word for you: Windows. You know, the most popular OS on the market? The one installed on 98% of all computers world-wide? Guess what: no native package manager. Isn't Windows Installer (MSI) a package manager? Can you say please download and install darcs for me and take care of any dependencies it might need whilst you're at it with MSI? MSI is more analogous to RPM/deb packages than to yum/apt. -- 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] Unix emulation
Andrew, I was going to chastise you for being the only Windows developer who has problems with MinGW / MSYS and spreading that unpleasant internet commodity FUD. However, I've just gone back to mingw.org and its gone from somewhat confusing circa the last time I installed (Christmas 2009) to frankly abysmal. So while is was easy to install MinGW / MSys a year ago I'll willing concede that it is difficult now. [A side issue - anyone who thinks socializing Hackage is a good idea should pay mingw.org a visit...] I followed this guide the last time I installed: http://www.mingw.org/faq/How_do_I_install_MSYS Having a slightly out-of-date installation shouldn't be a problem for Haskell development. Another side issue, commentators seem to be point to be pointing to TDM-GCC for a sanely packaged version of MinGW, but it isn't accompanied by MSys so wouldn't work for Haskell development. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
Hello! I take it that the problem is that libcurl is a C library with a Unix-like build system, and that is the problem that needs Cygwin, right? I'm not a Windows expert, but having C code is perfectly fine, I guess. My 'hipmunk' library includes a whole C library. When I tried to 'cabal install' it on Windows, it worked flawlessly even if I never really did develop it for Windows. Given that the problem is building libcurl, and not the Haskell curl package, won't a binary distribution of libcurl cut it? I was thinking of [1], where there is an installer for libcurl. http://curl.haxx.se/download.html#Win32 Cheers! =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
On 22 August 2010 13:48, Felipe Lessa felipe.le...@gmail.com wrote: I take it that the problem is that libcurl is a C library with a Unix-like build system, and that is the problem that needs Cygwin, right? No - generally you don't want to compile bindings with Cygwin, compiling with Cygwin brings in dependencies on cygwin1.dll which doesn't work well with GHC. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Simple Sudoku solver using Control.Monad.Logic
Hello All, Apologies if some have you have got this twice but I posted this once via fa.haskell on Goggle but I don't think it goes anywhere outside Google. In an attempt to learn how to use monads, I've tried to write a simple sudoku solver using the LogicT monad. I think it works but it is extremely slow, in fact it won't finish at all if I attempt to enforce the grid constraints. Just using row and column constraints, it will finish for some problems. Am I doing something dreadfully wrong here or is this just a hard problem to solve ? Thanks Andrew here's the listing :- module Main where import Control.Monad.Logic import Data.List (delete, (\\)) board :: [[Int]] board = [ [7, 9, 0, 0, 0, 0, 3, 0, 0], [0, 2, 0, 0, 0, 6, 9, 0, 0], [8, 0, 0, 0, 3, 0, 0, 7, 6], [0, 0, 0, 0, 0, 5, 0, 0, 2], [0, 0, 5, 4, 1, 8, 7, 0, 0], [4, 0, 0, 7, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0]] -- accessors for row, column and grid row b = (b!!) col b c = [x!!c | x - b] grid b g = (t 0) ++ (t 1) ++ (t 2) where t i = take 3 $ drop x $ b !! (y + i) x = 3 * (g `mod` 3) y = 3 * (g `div` 3) -- Ensures all numbers in the list are unique unique :: [Int] - Bool unique r = null (foldl (\a x - delete x a) [x | x - r, x /= 0] [1..9]) choose choices = msum [return x | x - choices] -- Test a cell (0 = unknown value) test :: Int - Logic [Int] - Logic Int test 0 c = do choices - c choose choices test x c = return x -- helper to produce a diff list from a wrapped monadic list mdiff :: [Logic Int] - [Int] - Logic [Int] mdiff a c = do i - sequence a return ([1..9]\\(i++c)) -- the actual solver - attempts to limit choices early on by using diff list of remaining values sudoku :: Logic [[Int]] sudoku = do solution - foldl (\b r - do m - b row - sequence $ foldr (\(n,x) a - (test x (mdiff a $ col m n)):a) [] [(n,x) |x - r | n - [0..8]] guard $ unique row sequence [guard $ unique $ col m i | i - [0..8]] return (m ++ [row]) ) (return []) board sequence $ [guard $ unique $ grid solution i | i - [0..8]] return solution -- solve and print main = do let solution = observe sudoku sequence [print s | s - solution] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
On Sun, Aug 22, 2010 at 5:04 PM, Stephen Tetley stephen.tet...@gmail.com wrote: Andrew, I was going to chastise you for being the only Windows developer who has problems with MinGW / MSYS and spreading that unpleasant internet commodity FUD. However, I've just gone back to mingw.org and its gone from somewhat confusing circa the last time I installed (Christmas 2009) to frankly abysmal. So while is was easy to install MinGW / MSys a year ago I'll willing concede that it is difficult now. Agreed. I tried to set up an msys development environment to compile chicken scheme a couple of weeks ago, and, quite frankly, gave up. I settled for installing mingw and putting the mingw bin directory first in my cygwin path. This worked very well indeed, even though it isn't an officially supported chicken build environment, so it's worth experimenting with for haskell as well. (Note that it needs a reboot of windows after setting up the cygwin environment variables; I never figured out why). martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Sat, Aug 21, 2010 at 23:14, Paulo Tanimoto ptanim...@gmail.com wrote: One question: enumFile has type enumFile :: FilePath - Enumerator SomeException ByteString IO b and iterParser has type iterParser :: Monad m = Parser a - Iteratee ParseError ByteString m a How do we use both together? Something in these lines won't type-check E.run (E.enumFile file E.$$ (E.iterParser p)) because the error types are different. Forgot to mention that -- use the mapError function from enumerator-0.2.1 thusly: http://ianen.org/haskell/enumerator/api-docs/Data-Enumerator.html#v%3AmapError parser :: Parser Foo toExc :: Show a = a - E.SomeException toExc = E.SomeException . E.ErrorCall . show main :: IO () main = do run (enumFile parsetest.txt $$ mapError toExc $$ iterParser parser) = print You don't have to map to SomeException -- any type will do. For example, in a complex pipeline with real error handling at the other end, you might want a custom error type so you'll know at what stage the error occurred. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage on Linux
It looks as if it's automated for Arch, however. Either that or somebody is spending an absurd amount of time keeping it manually up to date. Yeah, it's automated, Don Stewart made a script to do that. http://archhaskell.wordpress.com/ -- == Ivan Sichmann Freitas Engenharia de Computação 2009 UNICAMP http://identi.ca/ivansichmann Grupo Pró Software Livre UNICAMP - GPSL == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Perform a research a la Unix 'find'
Hello, I would like to recode in Haskell a piece of bash program that uses find. The advantage of find is that it is quite easy to use and fast. Is there a package that let us access to find-like functionnalities, with similar performances? Or at least some C functions that could be used through the FFI? (I would like to avoid to recur through directories and match files myself, I tried it and the search lasts for ages). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage on Linux
Hi, Am Sonntag, den 22.08.2010, 10:55 +0100 schrieb Andrew Coppin: Browsing around Hackage, I notice that a seemingly random subset of packages are available for something called arch linux. Presumably some sort of automatic conversion system is involved, but does anyone know why only certain packages appear? I've noticed that both Debian and OpenSUSE have a very tiny selection of binary Haskell packages too. I'm guessing that these packages are also auto-generated, but presumably selected by hand. (I also don't recall seeing them listed on Hackage.) Anybody know about that? I wouldn’t call almost 200 packages¹ a „very tiny selection“ :-) These packages are not auto-generated, but still hand-built and hand-uploaded in every version. The Haskell Team makes selects the packages, decides whether a version updated is required (for example changes that only fix the buildability on win32 do not warrant an upload to Debian) and fixes bugs. This should be a very stable base with most important libraries to build on, without any cabal hell. More information can be found on http://wiki.debian.org/Haskell. The distro listing on hackages was actually implemented by me a while ago, the text file Ivan mentioned can be found on http://people.debian.org/~nomeata/cabalDebianMap.txt and is generated daily by a cron job. Greetings, Joachim ¹ http://pkg-haskell.alioth.debian.org/cgi-bin/pet.cgi plus a few packages not maintained by the team -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
Felipe Lessa wrote: I take it that the problem is that libcurl is a C library with a Unix-like build system, and that is the problem that needs Cygwin, right? One needs a compiler and libraries on the one hand, and a bunch of command-line tools on the other hand. On Windows, MinGW provides the former, while Cygwin provides a package manager to install the latter. MinGW seems to be bundled with the Haskell platform on Windows, so that should be ok. The Cygwin tools however have to be installed in addition to the Haskell platform, which is no big deal, but somewhat annoying. There are two steps to be done: (1) Install the core of Cygwin, and put it in the search path after the MinGW bundled with the Haskell platform. (2) If a cabal package fails to install because some tools (bash, perl, sed, make, ...) are missing, install the missing tool using the Cygwin package manager. So a cabal package is better suited for installation on Windows if it does not depend on any command-line tools for building (or operation, of course). In practice, that means that a portable Setup.hs should contain Haskell code, not system calls to command-line tools. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Perform a research a la Unix 'find'
I've used the FileManip package for this. It works fine for my purposes. I have no idea what the performance is, though, beyond 'good enough not to care at the moment'. Erik On Sun, Aug 22, 2010 at 17:32, Yves Parès limestr...@gmail.com wrote: Hello, I would like to recode in Haskell a piece of bash program that uses find. The advantage of find is that it is quite easy to use and fast. Is there a package that let us access to find-like functionnalities, with similar performances? Or at least some C functions that could be used through the FFI? (I would like to avoid to recur through directories and match files myself, I tried it and the search lasts for ages). ___ 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] Hackage on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/22/2010 06:41 AM, Andrew Coppin wrote: Ivan Lazar Miljenovic wrote: Hackage has limited support for distro maintainers to state which packages are available on the distribution. Last I checked, it required distro maintainers to keep a text file somewhere up to date. Note that not all distributions bother. It looks as if it's automated for Arch, however. Either that or somebody is spending an absurd amount of time keeping it manually up to date. Last I heard, dons had a thing he ran that converted Cabal packages into Arch Linux packages automatically. I wouldn't be surprised if he had something that automated the whole procedure from Hackage download to Arch Linux upload. As for why using your distro package manager for Haskell packages is preferable: http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ Right. So Cabal isn't a package manager because it only manages Haskell packages? Not sure I agree with that definition. (It also has a laundry list of problems that can and should be fixed, but won't be.) So, remember your gripes elsethread about libcurl on Windows? That's what using a real package manager gets you: the non-Haskell dependencies are also handled and (assuming the packager isn't an idiot) Just Work. I actually spent quite a while trying to figure out what the purpose of Cabal *is*. It's not like it's hard to download a bunch of Haskell source code and utter ghc --make Foo. So why do we even need Cabal in the first place? The answer, as far as I can tell, is that registering a library manually is so excruciatingly The answer is that it checks dependencies for you. This is a mixed blessing, however (see cabal upgrade). Actually, we have tools that automatically convert Cabal packages to Debian packages or RPMs or whatever. I think there could be some milage in a tool that builds Windows installers. (The problem, of course, is that you have to be able to *build* the library on Windows first!) You would of course then have all kinds of fun and games with dependency tracking... And the big problem with Windows is an utter lack of consistency in package arrangement. Linux has the FHS; *BSD and the OSX environments (Fink and MacPorts) have mtree specifications; where did the Windows library you just installed decide to stick its files? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxxTNgACgkQIn7hlCsL25UK3wCeMX/OySIyO3JXiDlijLEL1lM/ uesAn2LnchpzHqnbREYbrv347llLFkN6 =Ecxk -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Perform a research a la Unix 'find'
Thanks, I will take a look at it. 2010/8/22 Erik Hesselink hessel...@gmail.com I've used the FileManip package for this. It works fine for my purposes. I have no idea what the performance is, though, beyond 'good enough not to care at the moment'. Erik On Sun, Aug 22, 2010 at 17:32, Yves Parès limestr...@gmail.com wrote: Hello, I would like to recode in Haskell a piece of bash program that uses find. The advantage of find is that it is quite easy to use and fast. Is there a package that let us access to find-like functionnalities, with similar performances? Or at least some C functions that could be used through the FFI? (I would like to avoid to recur through directories and match files myself, I tried it and the search lasts for ages). ___ 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] Hackage on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/22/2010 07:19 AM, Jonas Almström Duregård wrote: Now, you say it's preferable to use the native package manager where possible. I've got one word for you: Windows. You know, the most popular OS on the market? The one installed on 98% of all computers world-wide? Guess what: no native package manager. Isn't Windows Installer (MSI) a package manager? No, the Windows and OSX installers are just that. They provide no facilities for finding packages, identifying the package a given file came from, or dependency tracking. OSX's installer doesn't even have uninstall support; it records the installed files, but provides no mechanism for undoing configuration changes such as removing package-installed kernel modules. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxxTmoACgkQIn7hlCsL25VNsQCfZKJIz+KONa4yWAI97QYyttGU ITMAnjoAhcj3kMrWxnsSxWb5jraFBu1r =ERlI -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Perform a research a la Unix 'find'
On 22/08/10 16:32, Yves Parès wrote: Hello, I would like to recode in Haskell a piece of bash program that uses find. The advantage of find is that it is quite easy to use and fast. Is there a package that let us access to find-like functionnalities, with similar performances? Or at least some C functions that could be used through the FFI? (I would like to avoid to recur through directories and match files myself, I tried it and the search lasts for ages). Take a look at HSH on hackage. I've used that many times to inject some sanity into stuff that I used to do with bash. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Perform a research a la Unix 'find'
Thanks for the HSH link, Magnus. Concerning FileManip, it seems that I can't perform easily a case-insensitive search (for instance with find, you just use -iname instead of -name). Am I wrong? 2010/8/22 Magnus Therning mag...@therning.org On 22/08/10 16:32, Yves Parès wrote: Hello, I would like to recode in Haskell a piece of bash program that uses find. The advantage of find is that it is quite easy to use and fast. Is there a package that let us access to find-like functionnalities, with similar performances? Or at least some C functions that could be used through the FFI? (I would like to avoid to recur through directories and match files myself, I tried it and the search lasts for ages). Take a look at HSH on hackage. I've used that many times to inject some sanity into stuff that I used to do with bash. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
Stephen Tetley wrote: Andrew, I was going to chastise you for being the only Windows developer who has problems with MinGW / MSYS and spreading that unpleasant internet commodity FUD. However, I've just gone back to mingw.org and its gone from somewhat confusing circa the last time I installed (Christmas 2009) to frankly abysmal. So while is was easy to install MinGW / MSys a year ago I'll willing concede that it is difficult now. [A side issue - anyone who thinks socializing Hackage is a good idea should pay mingw.org a visit...] I followed this guide the last time I installed: http://www.mingw.org/faq/How_do_I_install_MSYS Having a slightly out-of-date installation shouldn't be a problem for Haskell development. Well, part of the issue is that it just annoys me as a matter of principle that I have to install a *Unix* emulator in order to write *Windows* software. What's up with that? But anyway, as I say, I figured I could just install the emulator on a VM, build the libraries once, and then use the binaries anywhere. Unfortunately, I was eventually forced to give up after trying to install MSYS / MinGW. You'd think you could just download a file and unzip it, or maybe run an installer... but no. That would be far too easy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
On 22 August 2010 16:56, Tillmann Rendel ren...@mathematik.uni-marburg.de wrote: One needs a compiler and libraries on the one hand, and a bunch of command-line tools on the other hand. On Windows, MinGW provides the former, while Cygwin provides a package manager to install the latter. Its not ideal to use MinGW with Cgywin. For Haskell development, you want to be linking to C libraries compiled with MinGW's GCC. You can use Cygwin, and cross compile with MinGW's GCC, but this is likely to be more tiresome than using MSys and makes a problem for every compile and build - as you are cross compiling you can't just ./configure make make install. Whereas MSys just has the initial problem that it no longer has a comprehensible install plan. The hyperbole in my original message was somewhat tongue-in-cheek, but there's a fair amount of truth in it - MinGW / MSys is a very good system, its sad that it is in such a crazy state at the moment. MSys has all the tools (bash, perl, make, autoconf) needed for compiling and excepting the installer situation, it is very stable. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
Felipe Lessa wrote: Hello! I take it that the problem is that libcurl is a C library with a Unix-like build system, and that is the problem that needs Cygwin, right? No. It's completely possible to download a pre-built binary for libcurl (or just about any other OSS library, for that matter). The problem is that the Haskell curl package expects to just run autoconf and this will actually work. Naturally, on Windows it just complains that no such command exists and dies. (Actually, cabal-install is smart enough to detect this situation and exit gracefully, explaining what the problem is in a sane mannar. It still won't build it though.) Similar problems with Haskell packages that expect to be able to use Make, Bash scripts, run Awk and so forth. These tools do not exist on Windows. (Unless you install MSYS / MinGW.) I'm not a Windows expert, but having C code is perfectly fine, I guess. My 'hipmunk' library includes a whole C library. When I tried to 'cabal install' it on Windows, it worked flawlessly even if I never really did develop it for Windows. Oh, if you just want to install a library which _includes_ C code, that's usually fine. The problem is if you want to access an external C library. Cabal can't find the header files, can't run autoconf, and general chaos ensues. Given that the problem is building libcurl, and not the Haskell curl package, won't a binary distribution of libcurl cut it? Like I say, that part isn't the problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Perform a research a la Unix 'find'
I looked at both, and I have encoding issues with both. My locale is fr_FR.utf8 For instance, with HSH: I have a 'bar' directory, containing a file 'fooé' run $ find bar :: IO [String] returns me : [bar, bar/foo*\233*] and run $ find bar -name fooé returns [] When I provoke an error by running: run $ find fooé it says : find: foo*\351*: No file or directory So it is not the same encoding! 2010/8/22 Yves Parès limestr...@gmail.com Thanks for the HSH link, Magnus. Concerning FileManip, it seems that I can't perform easily a case-insensitive search (for instance with find, you just use -iname instead of -name). Am I wrong? 2010/8/22 Magnus Therning mag...@therning.org On 22/08/10 16:32, Yves Parès wrote: Hello, I would like to recode in Haskell a piece of bash program that uses find. The advantage of find is that it is quite easy to use and fast. Is there a package that let us access to find-like functionnalities, with similar performances? Or at least some C functions that could be used through the FFI? (I would like to avoid to recur through directories and match files myself, I tried it and the search lasts for ages). Take a look at HSH on hackage. I've used that many times to inject some sanity into stuff that I used to do with bash. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Perform a research a la Unix 'find'
On 22/08/10 17:56, Yves Parès wrote: I looked at both, and I have encoding issues with both. My locale is fr_FR.utf8 For instance, with HSH: I have a 'bar' directory, containing a file 'fooé' run $ find bar :: IO [String] returns me : [bar, bar/foo*\233*] and run $ find bar -name fooé returns [] When I provoke an error by running: run $ find fooé it says : find: foo*\351*: No file or directory So it is not the same encoding! Yes, that's no good. I should put in a caveat, I have only used HSH in privileged locales. I urge you to raise it with the maintainer of HSH since it's a serious shortcoming. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Filename encoding error (was: Perform a research a la Unix 'find')
In fact the encoding problem is more general. When I simply do 'readFile bar/fooé', then I'm told: *** Exception: bar/fooé: openFile: does not exist (No such file or directory) How am I supposed to read files whose names contains non-ASCII characters? (I use GHC 6.12.3 under Ubuntu 10.04 32bits) -- Forwarded message -- From: Yves Parès limestr...@gmail.com Date: 2010/8/22 Subject: Re: [Haskell-cafe] Perform a research a la Unix 'find' To: Magnus Therning mag...@therning.org Cc: haskell-cafe@haskell.org I looked at both, and I have encoding issues with both. My locale is fr_FR.utf8 For instance, with HSH: I have a 'bar' directory, containing a file 'fooé' run $ find bar :: IO [String] returns me : [bar, bar/foo*\233*] and run $ find bar -name fooé returns [] When I provoke an error by running: run $ find fooé it says : find: foo*\351*: No file or directory So it is not the same encoding! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Simple Sudoku solver using Control.Monad.Logic
sudoku solver using the LogicT monad. [...] works but it is extremely slow, Any sudoku should be easily solvable by a program that always case-splits on the unknown that has the fewest remaining possible assignments. The proper general framework for this is finite domain constraint systems, Cf. Chapter 5 (Local notions of consistency) of Apt: Principles of Constraint Programming http://homepages.cwi.nl/~apt/books.html I'm sure you know that, and the question was about using a backtracking monad. I am not sure that the Logic(T) monad (transformer) is efficient in solving FD constraint systems. If you just write down all the constraints (as you should) and then simply Control.Monad.Logic.Class.interleave them, then you're probably getting some different (and inefficient) search strategy. So you'd have to prescribe the evaluation strategy somehow - but once you do this, it's not longer logic programmings (since it's becoming functional). J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filename encoding error (was: Perform a research a la Unix 'find')
On 22.08.2010 21:23, Yves Parès wrote: In fact the encoding problem is more general. When I simply do 'readFile bar/fooé', then I'm told: *** Exception: bar/fooé: openFile: does not exist (No such file or directory) How am I supposed to read files whose names contains non-ASCII characters? (I use GHC 6.12.3 under Ubuntu 10.04 32bits) Unicode handling in GHC always was a problem. There are corresponding tickets in bug tracker [1,2] You have to manually encode/decode strings to/from UTF8 which obviously works only for UTF8 locales. [1] http://hackage.haskell.org/trac/ghc/ticket/3307 [2] http://hackage.haskell.org/trac/ghc/ticket/3309 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple Sudoku solver using Control.Monad.Logic
I think the problem is with terribly inefficient data representation. I've written sudoku solver some time ago too using different data structures, including Data.Array, Data.Vector and simple lists. Lists are very inefficient in this case, because accessors for lists have O(n) complexity. Immutable arrays from Data.Array are inefficient too, at least in my case - I used simple backtracking algorithm - because of their immutability. Mutable arrays were slightly better, but still very sluggish. Then I've written two-dimensional arrays implementation over Data.Vector library. This was the most efficient variant - somewhere around 8 seconds. Of course, this implementation is mutable, so I have two variants, for IO and ST s monads. I've also written 2 versions of solving algorithm - the one that nearly identical to C++ imperative version using ContT monad transformer and very dirty foreach loop with breaking, and (as far as I can see) more efficient tail-recursive algorithm with ListZipper over free cell indices. It resembles some state machine to me, though I think I'm incorrect in this sense :) And it was a surprise to me: the tail-recursive algorithm was noticeable slower than the dirty imperative version! I wanted to ask about this here on haskell-cafe, but forgot :) Here is the code: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=29364#a29364 Profiling shows that the most of CPU time take modification functions like (=:). I don't know how to improve the performance further then. 2010/8/22 azwhaley azwha...@googlemail.com: Hello All, Apologies if some have you have got this twice but I posted this once via fa.haskell on Goggle but I don't think it goes anywhere outside Google. In an attempt to learn how to use monads, I've tried to write a simple sudoku solver using the LogicT monad. I think it works but it is extremely slow, in fact it won't finish at all if I attempt to enforce the grid constraints. Just using row and column constraints, it will finish for some problems. Am I doing something dreadfully wrong here or is this just a hard problem to solve ? Thanks Andrew here's the listing :- module Main where import Control.Monad.Logic import Data.List (delete, (\\)) board :: [[Int]] board = [ [7, 9, 0, 0, 0, 0, 3, 0, 0], [0, 2, 0, 0, 0, 6, 9, 0, 0], [8, 0, 0, 0, 3, 0, 0, 7, 6], [0, 0, 0, 0, 0, 5, 0, 0, 2], [0, 0, 5, 4, 1, 8, 7, 0, 0], [4, 0, 0, 7, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0]] -- accessors for row, column and grid row b = (b!!) col b c = [x!!c | x - b] grid b g = (t 0) ++ (t 1) ++ (t 2) where t i = take 3 $ drop x $ b !! (y + i) x = 3 * (g `mod` 3) y = 3 * (g `div` 3) -- Ensures all numbers in the list are unique unique :: [Int] - Bool unique r = null (foldl (\a x - delete x a) [x | x - r, x /= 0] [1..9]) choose choices = msum [return x | x - choices] -- Test a cell (0 = unknown value) test :: Int - Logic [Int] - Logic Int test 0 c = do choices - c choose choices test x c = return x -- helper to produce a diff list from a wrapped monadic list mdiff :: [Logic Int] - [Int] - Logic [Int] mdiff a c = do i - sequence a return ([1..9]\\(i++c)) -- the actual solver - attempts to limit choices early on by using diff list of remaining values sudoku :: Logic [[Int]] sudoku = do solution - foldl (\b r - do m - b row - sequence $ foldr (\(n,x) a - (test x (mdiff a $ col m n)):a) [] [(n,x) |x - r | n - [0..8]] guard $ unique row sequence [guard $ unique $ col m i | i - [0..8]] return (m ++ [row]) ) (return []) board sequence $ [guard $ unique $ grid solution i | i - [0..8]] return solution -- solve and print main = do let solution = observe sudoku sequence [print s | s - solution] ___ 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] Filename encoding error (was: Perform a research a la Unix 'find')
On Sunday 22 August 2010 19:23:03, Yves Parès wrote: In fact the encoding problem is more general. When I simply do 'readFile bar/fooé', then I'm told: *** Exception: bar/fooé: openFile: does not exist (No such file or directory) Try ghci readFile (Data.ByteString.Char8.unpack (Data.ByteString.UTF8.fromString fooé)) (same trick for find). The problem is probably that readFile filePath truncates the characters in filePath to 8 bits while the filepath on your system is UTF-8 encoded, so you have to give a pseudo-UTF-8 encoded filepath to readFile. At least, that's how it works here, inconvenient though it is. How am I supposed to read files whose names contains non-ASCII characters? (I use GHC 6.12.3 under Ubuntu 10.04 32bits) While the inconvenience lasts (people are thinking about how to handle the situation correctly), avoid non-ASCII characters in filepaths if possible. My locale is fr_FR.utf8 For instance, with HSH: I have a 'bar' directory, containing a file 'fooé' run $ find bar :: IO [String] returns me : [bar, bar/foo*\233*] That one is okay, 'é' is '\233' and the Show instance for Char escapes all characters '\127'. and run $ find bar -name fooé returns [] Maybe the same issue, try run $ find bar -name foo\195\169 When I provoke an error by running: run $ find fooé it says : find: foo*\351*: No file or directory On the other hand, if it now says \351, which is ş, there seems to be something else amiss. So it is not the same encoding! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple Sudoku solver using Control.Monad.Logic
On Sunday 22 August 2010 20:12:16, Vladimir Matveev wrote: I think the problem is with terribly inefficient data representation. Worse, it's a terribly inefficient algorithm. The constraints are applied too late, so a huge number of partial boards are created only to be pruned afterwards. Since the ratio between obviously invalid rows and potentially valid rows is large, the constraints should be applied already during the construction of candidate rows to avoid obviously dead branches. I've written sudoku solver some time ago too using different data structures, including Data.Array, Data.Vector and simple lists. Lists are very inefficient in this case, because accessors for lists have O(n) complexity. Since the lists are short, that's not so big a problem here. Immutable arrays from Data.Array are inefficient too, They were pretty good for my solver. What's bad is branching. at least in my case - I used simple backtracking algorithm - Which of course happens a lot in a simple backtracking algorithm. because of their immutability. Mutable arrays were slightly better, but still very sluggish. Then I've written two-dimensional arrays implementation over Data.Vector library. This was the most efficient variant - somewhere around 8 seconds. Of course, this implementation is mutable, so I have two variants, for IO and ST s monads. I've also written 2 versions of solving algorithm - the one that nearly identical to C++ imperative version using ContT monad transformer and very dirty foreach loop with breaking, and (as far as I can see) more efficient tail-recursive algorithm with ListZipper over free cell indices. It resembles some state machine to me, though I think I'm incorrect in this sense :) And it was a surprise to me: the tail-recursive algorithm was noticeable slower than the dirty imperative version! I wanted to ask about this here on haskell-cafe, but forgot :) Here is the code: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=29364#a29364 I'll take a look. Profiling shows that the most of CPU time take modification functions like (=:). I don't know how to improve the performance further then. 2010/8/22 azwhaley azwha...@googlemail.com: Hello All, Apologies if some have you have got this twice but I posted this once via fa.haskell on Goggle but I don't think it goes anywhere outside Google. In an attempt to learn how to use monads, I've tried to write a simple sudoku solver using the LogicT monad. I think it works but it is extremely slow, in fact it won't finish at all if I attempt to enforce the grid constraints. Just using row and column constraints, it will finish for some problems. Am I doing something dreadfully wrong here or is this just a hard problem to solve ? Thanks Andrew here's the listing :- module Main where import Control.Monad.Logic import Data.List (delete, (\\)) board :: [[Int]] board = [ [7, 9, 0, 0, 0, 0, 3, 0, 0], [0, 2, 0, 0, 0, 6, 9, 0, 0], [8, 0, 0, 0, 3, 0, 0, 7, 6], [0, 0, 0, 0, 0, 5, 0, 0, 2], [0, 0, 5, 4, 1, 8, 7, 0, 0], [4, 0, 0, 7, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0]] -- accessors for row, column and grid row b = (b!!) col b c = [x!!c | x - b] grid b g = (t 0) ++ (t 1) ++ (t 2) where t i = take 3 $ drop x $ b !! (y + i) x = 3 * (g `mod` 3) y = 3 * (g `div` 3) -- Ensures all numbers in the list are unique unique :: [Int] - Bool unique r = null (foldl (\a x - delete x a) [x | x - r, x /= 0] [1..9]) choose choices = msum [return x | x - choices] -- Test a cell (0 = unknown value) test :: Int - Logic [Int] - Logic Int test 0 c = do choices - c choose choices test x c = return x -- helper to produce a diff list from a wrapped monadic list mdiff :: [Logic Int] - [Int] - Logic [Int] mdiff a c = do i - sequence a return ([1..9]\\(i++c)) -- the actual solver - attempts to limit choices early on by using diff list of remaining values sudoku :: Logic [[Int]] sudoku = do solution - foldl (\b r - do m - b row - sequence $ foldr (\(n,x) a - (test x (mdiff a $ col m n)):a) [] [(n,x) |x - r | n - [0..8]] guard $ unique row sequence [guard $ unique $ col m i | i - [0..8]] return (m ++ [row]) ) (return []) board sequence $ [guard $ unique $ grid solution i | i - [0..8]] return solution -- solve and print main = do let solution = observe sudoku sequence [print s | s - solution] ___ Haskell-Cafe mailing list
Re: [Haskell-cafe] ANNOUNCE: ipatch, the interactive patch editor
Hi, Am Dienstag, den 03.08.2010, 22:52 +0200 schrieb Joachim Breitner: I have written a tool to interactively edit patches, which under the hood uses the Darcs API. A more catchy introduction, including a screencast, can be found on https://www.joachim-breitner.de/blog/archives/425-ipatch,-the-interactive-patch-editor.html which ends (and this is where you come in) with „So this is an invitation to join me and make ipatch a great tool. This invitation goes especially to the Darcs developers: Please have a look how the code uses the Darcs API and help to improve the collaboration here. I think we can use the darcs-users mailing list until there is need for a dedicated mailing list.“ The code is on http://darcs.nomeata.de/ipatch/. with Darcs 2.5 Beta 3 on Hackage, I could also upload ipatch to hackage: http://hackage.haskell.org/package/ipatch and it is now cabal-install’able. I also made the program now handle patches that add or remove files, extended the help texts a bit and added a test suite. This means that you can actually make use of ipatch as of now, to split patches into several small patches and to apply a patch interactively. Of course it needs some more testing, and you might have feature wishes – in either case, let me know. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple Sudoku solver using Control.Monad.Logic
On Sun, Aug 22, 2010 at 1:18 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: On Sunday 22 August 2010 20:12:16, Vladimir Matveev wrote: I think the problem is with terribly inefficient data representation. Worse, it's a terribly inefficient algorithm. The constraints are applied too late, so a huge number of partial boards are created only to be pruned afterwards. Since the ratio between obviously invalid rows and potentially valid rows is large, the constraints should be applied already during the construction of candidate rows to avoid obviously dead branches. I've written a sudoku solver myself, and IIRC I used lists. It always gave an answer within a second. So I believe Daniel has correctly identified the problem -- you need to prune earlier. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple Sudoku solver using Control.Monad.Logic
Thanks for explanation. One more question: are there any materials except LogicT.pdf from link on the logict hackage entry? I'd like to read something on this interesting topic because the above code looks kinda obfuscated to me :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple Sudoku solver using Control.Monad.Logic
On Sunday 22 August 2010 22:15:02, Luke Palmer wrote:
On Sun, Aug 22, 2010 at 1:18 PM, Daniel Fischer
daniel.is.fisc...@web.de wrote:
On Sunday 22 August 2010 20:12:16, Vladimir Matveev wrote:
I think the problem is with terribly inefficient data representation.
Worse, it's a terribly inefficient algorithm.
The constraints are applied too late, so a huge number of partial
boards are created only to be pruned afterwards. Since the ratio
between obviously invalid rows and potentially valid rows is large,
the constraints should be applied already during the construction of
candidate rows to avoid obviously dead branches.
I've written a sudoku solver myself, and IIRC I used lists. It always
gave an answer within a second. So I believe Daniel has correctly
identified the problem -- you need to prune earlier.
Indeed. The below simple backtracking agorithm with early pruning finds the
first solution in 0.45s here (compiled with -O2, as usual). For an empty
starting board, the first solution is found in less than 0.01s.
Unfortunately, I didn't understand Andrew's code enough to stay close to
it, so it looks very different.
{-# LANGUAGE ParallelListComp #-}
module Main (main) where
import Control.Monad.Logic
import Data.List (delete, (\\))
board :: [[Int]]
board = [ [7, 9, 0, 0, 0, 0, 3, 0, 0],
[0, 2, 0, 0, 0, 6, 9, 0, 0],
[8, 0, 0, 0, 3, 0, 0, 7, 6],
[0, 0, 0, 0, 0, 5, 0, 0, 2],
[0, 0, 5, 4, 1, 8, 7, 0, 0],
[4, 0, 0, 7, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0],
[0, 0, 0, 0, 0, 0, 0, 0, 0]]
-- accessors for row, column and grid
row b = (b!!)
col b c = [x!!c | x - b]
-- grid b g = (t 0) ++ (t 1) ++ (t 2)
grid b g = (take 3 . drop y) b = take 3 . drop x
where -- t i = take 3 $ drop x $ b !! (y + i)
x = 3 * (g `mod` 3)
y = 3 * (g `div` 3)
nextRow :: [[Int]] - [Int] - Logic [[Int]]
nextRow b0 rw = do
let rno = length b0
usd = filter (/= 0) rw
pss = [1 .. 9] \\ usd
u = 3*(rno `quot` 3)
opp yes no (n,0) = let cl = col b0 n
gd = grid b0 (u + n `quot` 3)
in msum . map return $ yes \\ (cl ++ gd)
opp _ _ (n,x) = let cl = col b0 n
gd = grid b0 (u + n `quot` 3)
in guard (x `notElem` (cl ++gd)) return x
-- The above is essential. Since we only look at previous rows,
-- we must check whether a given value violates the constraints
foo _ no [] = return no
foo yes no (p:ps) = do
d - opp yes no p
foo (delete d yes) (no ++ [d]) ps
row - (foo pss [] $ zip [0 .. 8] rw)
return (b0 ++ [row])
-- the actual solver
sudoku :: Logic [[Int]]
sudoku = go [] board
where
go b (r:rs) = do
b1 - nextRow b r
go b1 rs
go b [] = return b
-- solve and print
main = do
let solution = observe sudoku
sequence_ [print s | s - solution]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Error in enumerator when using interpreter instead of compiler
Hi all, I was trying out the enumerator package. I wanted to copy the contents of one file to another: module Main where import Data.Enumerator import Data.Enumerator.IO main = run (enumFile foo $$ iterFile bar) If I compile this code with GHC, it works as expected. But if I run it with runhaskell I get the following error: Left bar: hPutBuf: illegal operation (handle is closed) If I replace the above code with this: module Main where import Data.Enumerator import Data.Enumerator.IO import System.IO main = withBinaryFile bar WriteMode $ \h - run (enumFile foo $$ iterHandle h) It works both compiled and interpreted. Is this a bug in enumerator (probably in the iterFile function) or a deficiency of the interpreter? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Error in enumerator when using interpreter instead of compiler
I forgot to mention that the file bar is created but empty. So it seems the Iteratee opens it and then closes it prematurely. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Error in enumerator when using interpreter instead of compiler
It's certainly a bug in iterFile -- I think it'll have to be modified to close the file on EOF, not after returning a continuation. Semi-working in the compiled version is probably just a quirk of the garbage collector and/or OS. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Compiling UHC
L.S., I am trying to compile the current release of UHC (1.0.1); I started with the installation of the most recent version of uulib and uuagc. When running make uhc I received the following message: EH\Util\CompileRun.hs:46:7: Could not find module `UU.DData.Scc': Use -v to see a list of the files searched for. This module is not in the most recent version of uulib, so I installed uulib-0.9.10, but then I received the message: EH\Util\CompileRun.hs:46:7: Could not find module `UU.DData.Scc': It is a member of the hidden package `uulib-0.9.10'. Use -v to see a list of the files searched for. What can I do to get UHC compiled? (I am using Haskell Platform 2010.2.0.0) Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Simple Sudoku solver using Control.Monad.Logic
Ah, whenever I see div/mod 3 in a Sudoku solver, I feel that's not using the right model. It's not a square, it's a hypercube, folks! type Index = ( Int,Int,Int,Int ) neighbours :: Index - [ Index ] neighbours (a,b,c,d) = do i - [ 0 .. 2 ] ; j - [ 0 .. 2 ] [ (i,j,c,d), (a,b,i,j), (a,i,c,j) ] Here is a solver that branches on the position with the least number of possible values. It is backtracking (in the List monad, could probably be rewritten in Control.Monad.Logic) type Matrix = Array Index (Either [Int] Int) solutions :: Matrix - [ Matrix ] solutions m = case sort $ do ( i, Left xs ) - assocs m return ( length xs, i, xs ) of [] - return m (_,i,xs) : _ - do x - xs solutions $ set (i,x) m set :: (Index, Int) - Matrix - Matrix set (i, x) m = accum ( \ e _ - case e of Left ys - Left $ filter ( /= x ) ys Right y - Right y ) ( m // [ (i, Right x ) ] ) ( zip ( neighbours i ) $ repeat () ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Error in enumerator when using interpreter instead of compiler
Well, now I know why the iteratee package never defined something like iterFile -- it's not really possible. The only way to open handles within an iteratee prevents exception-safe release. enumerator-0.3 will remove the iterFile functions. iterHandle will remain, to be used as in your second example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GADT and problems with rigid type variables
Hello,
playing with GADTs I ran into a problem with rigid type variables
which is ilustrated by the following example. I think it should be
pretty clear what I'am trying to express... Any suggestions?
snip
{-# LANGUAGE GADTs #-}
data Foo where
Foo :: (Eq t) = t - Foo
instance Eq Foo where
(Foo a) == (Foo b) = a == b
{-
Scratch.hs:7:28:
Couldn't match expected type `t' against inferred type `t1'
`t' is a rigid type variable bound by
the constructor `Foo' at /home/alios/src/lab/Scratch.hs:7:3
`t1' is a rigid type variable bound by
the constructor `Foo' at /home/alios/src/lab/Scratch.hs:7:14
In the second argument of `(==)', namely `b'
In the expression: a == b
In the definition of `==': (Foo a) == (Foo b) = a == b
Failed, modules loaded: none.
-}
snip
thnx
Markus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GADT and problems with rigid type variables
The problem is that you have an existential `t` there, and two values of the
type Foo might not have the same `t` inside them.
What do you want to happen if someone writes Foo True == Foo yep?
The only real solution here is to parametrize your Foo type by the t that
lives within it, so you can ensure the inner types are the same. You could
also do some (in my opinion) fairly nasty stuff with Dynamic or Typeable,
adding a constraint to the Eq and attempting to cast at runtime (returning
False if the cast returns Nothing).
Hope this helps!
On Mon, Aug 23, 2010 at 12:36 AM, Markus Barenhoff al...@alios.org wrote:
Hello,
playing with GADTs I ran into a problem with rigid type variables
which is ilustrated by the following example. I think it should be
pretty clear what I'am trying to express... Any suggestions?
snip
{-# LANGUAGE GADTs #-}
data Foo where
Foo :: (Eq t) = t - Foo
instance Eq Foo where
(Foo a) == (Foo b) = a == b
{-
Scratch.hs:7:28:
Couldn't match expected type `t' against inferred type `t1'
`t' is a rigid type variable bound by
the constructor `Foo' at /home/alios/src/lab/Scratch.hs:7:3
`t1' is a rigid type variable bound by
the constructor `Foo' at /home/alios/src/lab/Scratch.hs:7:14
In the second argument of `(==)', namely `b'
In the expression: a == b
In the definition of `==': (Foo a) == (Foo b) = a == b
Failed, modules loaded: none.
-}
snip
thnx
Markus
___
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] GADT and problems with rigid type variables
On Sun, Aug 22, 2010 at 7:47 PM, Daniel Peebles pumpkin...@gmail.com wrote:
You could also do some (in my opinion) fairly nasty stuff with
Dynamic or Typeable, adding a constraint to the Eq and
attempting to cast at runtime (returning False if the cast
returns Nothing).
This is what he's talking about:
{-# LANGUAGE GADTs #-}
import Data.Typeable (Typeable, cast)
data Foo where
Foo :: (Typeable t, Eq t) = t - Foo
instance Eq Foo where
(Foo a) == (Foo b) = maybe False (== b) (cast a)
Cheers,
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
What haskell really needs is a big ' hit' where someone shows how powerful haskell is in some environment. Ruby had RoR, which is what splurged the language into the open On 22/08/2010 3:46 PM, wren ng thornton w...@freegeek.org wrote: Daniel Fischer wrote: On Saturday 21 August 2010 15:35:08, Ivan Lazar Miljenovic wrote: A ... Three! -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A cabal odyssey
On Sat, Aug 21, 2010 at 09:57:52AM +0100, Andrew Coppin wrote: When I first started using Haskell, I got the impression that there were hundreds, maybe even thousands, of developers working on GHC. (After all, how else could you write such a huge codebase in less than two centuries?) But now it appears the number of active developers is nearer to 3. This is obviously a jaw-droppingly tiny number of people to be working on such a gigantic piece of software. If it's really true, it's amazing anything ever gets done at all! Now you see the power of Haskell. By offloading tasks from your brain to the type system you can tackle wildly larger tasks than you would be able to with a lesser language. Haskell programs end up being a tiny fraction of the size and complexity of programs in other languages to acomplish the same task and the difference gets more pronounced as programs get larger. It is how I was able to write jhc for the most part by myself. Haskell is an intelligence multiplier. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Trouble with winGHCi
I just installed Haskell 2010.2.0.0 on Windows XP Pro SP3. When I run winGHCI, I briefly get a displayed window, immediately followed by a black screen. I have to restart my computer to get rid of it. I have been advised that this is a bug and wonder if it can be fixed. David Webster ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: Semantics of iteratees, enumerators, enumeratees?
For anyone interested in iteratees (etc) and not yet on the iteratees mailing list. I'm asking about what iteratees *mean* (denote), independent of the various implementations. My original note (also at the end below): With the encouragement help of Conrad Parker, I've been looking at iteratees, enumerators, enumeratees. I can find plenty written about them, but only about benefits and implementation. In sifting through chunks, error/control messages, and continuations, I find myself longing for a precise semantic basis. I keep wondering: what simpler precise semantic notions do these mechanisms implement? Has anyone worked out a denotational semantics for iteratees, enumerators, enumeratees -- something that simplifies away the performance advantages complexities? I've worked out something tentative, but perhaps I'm covering old ground. - Conal -- Forwarded message -- From: Conal Elliott co...@conal.net Date: Sun, Aug 22, 2010 at 11:02 PM Subject: Re: Semantics of iteratees, enumerators, enumeratees? To: John Lato jwl...@gmail.com Hi John, I just remembered: Luke Palmer wrote an accessible helpful description of this approach to library design. See his post *Semantic Designhttp://lukepalmer.wordpress.com/2008/07/18/semantic-design/ *. (I've switched to using the more specific term denotational design, since I specifically intend denotational semantics, not operational.) Denotational design is at the heart of most of what I do, particularly including the three pieces of work you mentioned: functional images (Pan), FRP, and automatic differentiation. My main goal is simplicity with precision. Without the precision, I can't tell whether the simplicity is real or illusory. We functional programmers have a strong advantage over imperative programming (including OO) in that we can achieve semantic precision. I want to see us exploit this advantage! And not settle for being a power tool for generating semantically inscrutable imperative computations. Regards, - Conal On Sun, Aug 22, 2010 at 10:43 PM, John Lato jwl...@gmail.com wrote: Hi Conal, I've always regarded your work in essentially the same category as Edward Kmett's (and most of Oleg's): stuff that's incredible powerful and concise, but I can't understand at all what it means. I've admired a lot of your work, particularly on Pan, FRP, and automatic differentiation, but most of the rest I couldn't understand at all. I'll take a look at your *Denotational Design* paper again; maybe now that I have a lot more experience I'll be able to make sense of it. John On Sun, Aug 22, 2010 at 8:18 AM, Conal Elliott co...@conal.net wrote: Hi John, Thanks for the reply. A denotational semantics would be independent of any implementation, so it would apply to any of them, as long as they have the same programming interface. The purpose is to simply precisely say what the types and their building blocks (API) mean by providing a precise, implementation-independent, and simple-as-possible math model. Such a semantics can be used to prove properties and to define correctness of any implementation. It also gives clear feedback on how elegant or inelegant a library design is. For instance, given a type, Map k v, of finite maps, we might say the meaning is the type of partial functions from k to v, either k - v (where absent is _|_) or k - Maybe v (where absent is Nothing). Then we'd give the meaning of each Map operation as a function of the meanings of its arguments. This example and several others are given in the paper *Denotational design with type class morphismshttp://conal.net/papers/type-class-morphisms/ *. Regards, - Conal On Sun, Aug 22, 2010 at 8:31 PM, John Lato jwl...@gmail.com wrote: Hi Conal, To my knowledge, nobody has attempted this. Oleg may have some ideas, but I don't think he's written about it. I really don't know anything about denotational semantics, so I couldn't do this myself. For some time I've thought it would be good if somebody were able to put together a formal semantics for iteratees, so I'd be very interested if you'd share what you have so far. Would a denotational semantics apply equally to multiple implementations, or would it be tied to a specific implementation? John On Sun, Aug 22, 2010 at 3:47 AM, Conal Elliott co...@conal.net wrote: With the encouragement help of Conrad Parker, I've been looking at iteratees, enumerators, enumeratees. I can find plenty written about them, but only about benefits and implementation. In sifting through chunks, error/control messages, and continuations, I find myself longing for a precise semantic basis. I keep wondering: what simpler precise semantic notions do these mechanisms implement? Has anyone worked out a denotational semantics for iteratees, enumerators, enumeratees -- something that simplifies away the performance advantages complexities? I've
Re: [Haskell-cafe] Unix emulation
Andrew Coppin wrote: Well, part of the issue is that it just annoys me as a matter of principle that I have to install a *Unix* emulator in order to write *Windows* software. What's up with that? You've actually got that a bit backwards. GHC, Curl and all the other things you are complaining about are all pieces of software that started life on Unix and just so happen to be able to (if you're luck) compile on windows. What you need is not a Unix emaulator, but the build tools that are used on Unix but on windows. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unix emulation
Andrew Coppin wrote: I too was going to have a go at this. I had a Windows VM (so I don't ruin my *real* Windows box) and I was going to set up all the junk which is apparently necessary to make C bindings build. And then I was going to build all the libraries I want but can't have, package them up into nice little installers with NSIS, and make the binary installers available for each version of the Haskell Platform. But, as I say, I utterly failed to make MinGW and MSYS actually work. I never got as far as installing HP at all! I'm going to be a bit of a heretic here and suggest that you attack this problem from the other end. How you ask? Install Debian Testing/Unstable with Wine in a VM and cross compile to Windows. For C libraries that originate on Unix, cross compiling them on from Linux - Windows is often easier than getting them to compile on Windows. For the Haskell stuff, install the windows version of GHC using Wine (I messed with this a bit and it worked like a charm). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
On Aug 21, 2010, at 4:12 AM, John Millikin wrote: This thought occurred to me, but really, how often are you going to have a 10 GiB **text** file with no newlines? When you have a file developed on a system that follows a different new-line convention. I haven't seen a file that big, but I'm sadly used to seeing humanly large files display as single lines. Of course if getLine/hGetLine accept *any* of CR, LF, CR+LF as end-of-line (as opposed to using the platform native convention), there's no problem. That's a darned good idea anyway. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
