Re: [Haskell-cafe] Re: Go Haskell!
Manuel M T Chakravarty wrote: Claus Reinke: What do those folks working on parallel Haskell arrays think about the sequential Haskell array baseline performance? You won't like the answer. We are not happy with the existing array infrastructure and hence have our own. Roman recently extracted some of it as a standalone package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector In the longer run, we would like to factor our library into DPH-specific code and general-purpose array library that you can use independent of DPH. So we have two vector libraries, vector and uvector, which have a lot in common - they are both single-dimension array types that support unboxed instances and have list-like operations with fusion. They ought to be unified, really. The main difference between these libraries and Haskell's arrays is the Ix class. So perhaps Haskell's arrays should be reimplemented on top of the low-level vector libraries? The Ix class is the root cause of the problems with optimising the standard array libraries. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell!
On Fri, Nov 28, 2008 at 10:04 AM, Simon Marlow [EMAIL PROTECTED] wrote: Manuel M T Chakravarty wrote: In the longer run, we would like to factor our library into DPH-specific code and general-purpose array library that you can use independent of DPH. So we have two vector libraries, vector and uvector, which have a lot in common - they are both single-dimension array types that support unboxed instances and have list-like operations with fusion. They ought to be unified, really. Yes please! Could we please have a ByteString style interface with qualified imports instead of using ad-hoc name prefixes/suffixes as a namespacing mechanism if we're going to merge the two libraries? Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Question about fastcgi
Hi, I'm learnng to use fastcgi and, reading the examples, I see the main loop is like this: main = runFastCGI my_work However, isn't a fastcgi program supposed to choose a port where to listen to calls? For instance, in this C example: xzdev.com/nginx_fastcgi.html doesn't the line listen_socket = FCGX_OpenSocket(:8002, 2000); says it's listening to port 8002? I read the code for fastcgi, from hackage, and I can't find anything related to ports like, for instance, a default port. Am I understanding something the wrong way? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] workarounds for Codec.Compression.Zlib errors in darcs
On Thu, 2008-11-27 at 17:20 +, Ian Lynagh wrote: On Wed, Nov 26, 2008 at 10:28:21PM +, Duncan Coutts wrote: I should note that one moral of this story is to check that your FFI imports are correct. That is, check they import the foreign functions at the right Haskell types. In this case the mistake was that the foreign function returned a C int, but the Haskell foreign import declaration stated that the C function returned IO () rather than IO CInt. While that's true, Haskell also makes it easy to make the same sort of error with IO (or any other Monad) values, whether created with the FFI or not. If you say f = do x y z and y has type IO CInt then you won't get an error (and I don't think you can even ask for a warning with the current implementations). Right, which is why we do not use IO CInt style error handling much in Haskell. For functions that return a real result we use Maybe, or for things that would otherwise be IO (), then using IO exceptions is the obvious thing to do. In either case the error is hard to ignore. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: catting to cat gets stuck at 135K
On Thu, 2008-11-27 at 11:38 -0500, Brandon S. Allbery KF8NH wrote: On 2008 Nov 27, at 8:51, Simon Marlow wrote: No, the issue is that without real OS threads, a foreign call can't be pre-empted (pretty obvious when you think about it). waitForProcess ends up making a blocking foreign call - non-obvious, but at least it's documented. The way this is usually handled in the non-threaded case is to either use SIGCHLD or non-blocking waitpid() so that green threads can continue running. I'm a little surprised this wasn't done. Yes, we've discussed this in detail a few months back. We even have a partial implementation. However it stalled on needing a better signals API which we have not managed to get through the standardisation process. Unfortunately there is no non-blocking (non-polling) waitpid() and the global (process-scope) nature of signals is a pain. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Question about fastcgi
Er, no. A fastcgi executable is (like a cgi executable) controlled by the front end web server. I run my fastcgi using Apache as the front end. The front end web server will control things like the port number. Mauricio wrote: Hi, I'm learnng to use fastcgi and, reading the examples, I see the main loop is like this: main = runFastCGI my_work However, isn't a fastcgi program supposed to choose a port where to listen to calls? For instance, in this C example: xzdev.com/nginx_fastcgi.html doesn't the line listen_socket = FCGX_OpenSocket(:8002, 2000); says it's listening to port 8002? I read the code for fastcgi, from hackage, and I can't find anything related to ports like, for instance, a default port. Am I understanding something the wrong way? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Question about fastcgi
ChrisK == ChrisK [EMAIL PROTECTED] writes: ChrisK Er, no. A fastcgi executable is (like a cgi executable) ChrisK controlled by the front end web server. I run my fastcgi ChrisK using Apache as the front end. The front end web server ChrisK will control things like the port number. There are different ways to run a FasctCGI executable (three if my memory serves me correctly). I have only ever written FasctCGI executables (not in Haskell) when the server accepts a port number at start up, and is started independently of Apache (or whatever). And Apache is told which port numbers it will find the servers on. ChrisK Mauricio wrote: Hi, I'm learnng to use fastcgi and, reading the examples, I see the main loop is like this: main = runFastCGI my_work However, isn't a fastcgi program supposed to choose a port where to listen to calls? For instance, in this C example: xzdev.com/nginx_fastcgi.html doesn't the line listen_socket = FCGX_OpenSocket(:8002, 2000); says it's listening to port 8002? I read the code for fastcgi, from hackage, and I can't find anything related to ports like, for instance, a default port. Am I understanding something the wrong way? Thanks, Maurício -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Question about fastcgi
I have only used this, all of these are from Haskell: pamac-cek10:~ chrisk$ cat /etc/apache2/other/httpd-fastcgi.conf IfModule mod_fastcgi.c Alias /fcgi-bin/ /Library/WebServer/FastCGI-Executables/ Directory /Library/WebServer/FastCGI-Executables/ AllowOverride None Options None Order allow,deny Allow from all SetHandler fastcgi-script Options +ExecCGI /Directory FastCgiIpcDir /tmp/fastcgi FastCgiServer /Library/WebServer/FastCGI-Executables/hw.fastcgi -pass-header Cookie FastCgiServer /Library/WebServer/FastCGI-Executables/test.fastcgi -pass-header Cookie FastCgiServer /Library/WebServer/FastCGI-Executables/xwords.fastcgi -pass-header Cookie /IfModule The above is included from the main httpd.conf which has: pamac-cek10:~ chrisk$ grep -i fast /etc/apache2/httpd.conf LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Go Haskell! - array libraries
On Fri, 28 Nov 2008, Simon Marlow wrote: Manuel M T Chakravarty wrote: Claus Reinke: What do those folks working on parallel Haskell arrays think about the sequential Haskell array baseline performance? You won't like the answer. We are not happy with the existing array infrastructure and hence have our own. Roman recently extracted some of it as a standalone package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector In the longer run, we would like to factor our library into DPH-specific code and general-purpose array library that you can use independent of DPH. So we have two vector libraries, vector and uvector, which have a lot in common - they are both single-dimension array types that support unboxed instances and have list-like operations with fusion. They ought to be unified, really. It's worse: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storablevector :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell!
On Fri, 28 Nov 2008, Johan Tibell wrote: On Fri, Nov 28, 2008 at 10:04 AM, Simon Marlow [EMAIL PROTECTED] wrote: So we have two vector libraries, vector and uvector, which have a lot in common - they are both single-dimension array types that support unboxed instances and have list-like operations with fusion. They ought to be unified, really. Yes please! Could we please have a ByteString style interface with qualified imports instead of using ad-hoc name prefixes/suffixes as a namespacing mechanism if we're going to merge the two libraries? StorableVector is organized this way. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Shared modification inside lambdas
Andrew Hunter [EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in gmane.comp.lang.haskell.cafe: All well and good, but it seems to me that if I'm embedding the DSl, shouldn't I be able to use the host language's facilities--for example, function abstractions and applications--directly? Indeed. Using binding in the host language to represent binding in the embedded language is called higher-order abstract syntax (HOAS). Well, I tried this, and it seems it works OK, like so: data Expr = Var String | Const Int | Plus Expr Expr | Quantified Range (Int - Expr) (Do you still need or even want Var String?) ... I could write something like: refine (Quantified range pred) = Quantified range pred' where pred' = \c - refine (pred c) But the problem is that this refines the term, again, every time I apply an argument to pred' ... The paper by Jacques Carette, Oleg Kiselyov, and me http://www.cs.rutgers.edu/~ccshan/tagless/jfp.pdf (revised version to appear in JFP) shows how to perform partial evaluation (which is an optimization, like your refinement) using HOAS. However, it's a bit tricky, in a language like Haskell (98) without so-called metaprogramming or staging facilities at the term level, to make the optimizations happen only once (rather than every time the embedded abstraction is invoked). It can be done! Let me point you to some code that we only mention in passing in that paper, which performs type-checking using HOAS. The type-checking happens only once; then the type-checked term can be interpreted many times. http://okmij.org/ftp/tagless-final/ http://okmij.org/ftp/tagless-final/IncopeTypecheck.hs Hope this helps. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2008-11-25 Elimination of Violence Against Women http://unifem.org/vaw/ 1948-12-10 Universal Declaration of Human Rights http://everyhumanhasrights.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: pbkdf2 on hackage Re: Re[2]: [Haskell-cafe] Password hashing
Thomas Hartman wrote: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/PBKDF2 Since no one took up my code review request I just did the best I could and uploaded to hackage. There were indeed some mistakes in my initial post, fixed now. (Code review is still wished, though!) Alas, documentation doesn't build with hackage, altough it does for me locally. (Seems like almost everything I do these days -- what am I doing wrong?!) Also I'm open to folding this into a more established crypto package if there are any takers... psst, dominic. I'd be happy to do so. In fact, I have another contribution which I need to work on so maybe now is a good time to roll my sleeves up. I haven't been following the thread on this. Could you give me some references? I assume it's a perfectly good cryptographic function, then it would be very helpful for me if you created a patch against the crypto repository. Also, dominic, shouldn't your crypto package be added to category Cryptography (a cabal file change) so it lists aside the other crypto packages? Yes good point - something else that needs doing. I've created the first ticket in the trac http://trac.haskell.org/crypto/ticket/1 If there are any crypto gurus who can code-review this I would be much obliged, and when I'm confident enough that this does the right thing I'll put it up on hackage. I don't do much crypto so this *definitely* needs a review before it becomes a library? It depends what you are going to use it for. I've put a big disclaimer on the crypto library because there are all sorts of attacks I've not checked it's proof against (e.g. who knows how long keys are kept in memory by a runtime system). You'd probably have to put in quite a lot of work researching how e.g. this is done in other implementations and seeing how the equivalent protection could be implemented in Haskell. 2008/11/26 John Meacham [EMAIL PROTECTED]: What you are using there is not a salt, but rather a secret key. The important thing about a salt is that it is different for _every user_. and you actually store the salt unhashed along with the hash. (it is not secret information). A salt protects against a dictionary attack, for instance, you might have a dictionary of hash's and the common passwords they go to but if you add a 32 bit salt, you would need 2^32 entries for each dictionary word, making such an attack unworkable. You can also trivially tell if two users have the _same_ password just by comparing the hashes without a salt. John is right but it still doesn't stop you publishing your function which someone can then use as John describes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: catting to cat gets stuck at 135K
Quoth Duncan Coutts [EMAIL PROTECTED]: | On Thu, 2008-11-27 at 11:38 -0500, Brandon S. Allbery KF8NH wrote: | | The way this is usually handled in the non-threaded case is to either | use SIGCHLD or non-blocking waitpid() so that green threads can | continue running. I'm a little surprised this wasn't done. | | Yes, we've discussed this in detail a few months back. We even have a | partial implementation. However it stalled on needing a better signals | API which we have not managed to get through the standardisation | process. | | Unfortunately there is no non-blocking (non-polling) waitpid() and the | global (process-scope) nature of signals is a pain. SIGCHLD can be a pain in its own unusual way. Once you have a SIGCHLD handler, process exits will interrupt long I/O, so every such read(), recv() or whatever must now check for EINTR and restart. Even though the authors of GHC go to great lengths to convert all I/O to non-blocking anyway, this will still apply to external library functions that are beyond GHC's reach. So it's a strategy I would use only if I were kind of desperate. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Question about fastcgi
I was able to get this working with lighttpd, and I did had to choose a port, but only at lighttpd configuration, not at the Haskell source. Thanks, Maurício ChrisK a écrit : I have only used this, all of these are from Haskell: pamac-cek10:~ chrisk$ cat /etc/apache2/other/httpd-fastcgi.conf IfModule mod_fastcgi.c Alias /fcgi-bin/ /Library/WebServer/FastCGI-Executables/ Directory /Library/WebServer/FastCGI-Executables/ AllowOverride None Options None Order allow,deny Allow from all SetHandler fastcgi-script Options +ExecCGI /Directory FastCgiIpcDir /tmp/fastcgi FastCgiServer /Library/WebServer/FastCGI-Executables/hw.fastcgi -pass-header Cookie FastCgiServer /Library/WebServer/FastCGI-Executables/test.fastcgi -pass-header Cookie FastCgiServer /Library/WebServer/FastCGI-Executables/xwords.fastcgi -pass-header Cookie /IfModule The above is included from the main httpd.conf which has: pamac-cek10:~ chrisk$ grep -i fast /etc/apache2/httpd.conf LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell! - array libraries
Henning Thielemann wrote: On Fri, 28 Nov 2008, Simon Marlow wrote: Manuel M T Chakravarty wrote: Claus Reinke: What do those folks working on parallel Haskell arrays think about the sequential Haskell array baseline performance? You won't like the answer. We are not happy with the existing array infrastructure and hence have our own. Roman recently extracted some of it as a standalone package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vector In the longer run, we would like to factor our library into DPH-specific code and general-purpose array library that you can use independent of DPH. So we have two vector libraries, vector and uvector, which have a lot in common - they are both single-dimension array types that support unboxed instances and have list-like operations with fusion. They ought to be unified, really. It's worse: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/storablevector :-) What *I* propose is that somebody [you see what I did there?] should sit down, take stock of all the multitudes of array libraries, what features they have, what obvious features they're missing, and think up a good API from scratch. Once we figure out what the best way to arrange all this stuff is, *then* we attack the problem of implementing it for real. It seems lots of people have written really useful code, but we need to take a step back and look at the big picture here before writing any more of it. IMHO, anyway... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell! - array libraries
andrewcoppin: What *I* propose is that somebody [you see what I did there?] should sit down, take stock of all the multitudes of array libraries, what features they have, what obvious features they're missing, and think up a good API from scratch. Once we figure out what the best way to arrange all this stuff is, *then* we attack the problem of implementing it for real. It seems lots of people have written really useful code, but we need to take a step back and look at the big picture here before writing any more of it. No. My view would be to let the free market of developers decide what is best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). And this approach has yielded more code than ever before, more libraries than ever before, and library authors are competing. So let the market decide. We're a bazaar, not a cathedral. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell! - array libraries
But I don't want Perl, I want a well designed language and well designed libraries. I think it's find to let libraries proliferate, but at some point you also need to step back and abstract. -- Lennart On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart [EMAIL PROTECTED] wrote: andrewcoppin: What *I* propose is that somebody [you see what I did there?] should sit down, take stock of all the multitudes of array libraries, what features they have, what obvious features they're missing, and think up a good API from scratch. Once we figure out what the best way to arrange all this stuff is, *then* we attack the problem of implementing it for real. It seems lots of people have written really useful code, but we need to take a step back and look at the big picture here before writing any more of it. No. My view would be to let the free market of developers decide what is best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). And this approach has yielded more code than ever before, more libraries than ever before, and library authors are competing. So let the market decide. We're a bazaar, not a cathedral. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] definitive list of editline bindings anywhere?
All -- Anyone have a definitive list of editline keybindings available? I find myself missing some of the capabilities of readline, and there doesn't seem to be documentation. -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] definitive list of editline bindings anywhere?
On Fri, Nov 28, 2008 at 2:37 PM, Paul Brown [EMAIL PROTECTED] wrote: All -- Anyone have a definitive list of editline keybindings available? I find myself missing some of the capabilities of readline, and there doesn't seem to be documentation. You can usually get this from man editrc, or otherwise the following page: http://www.manpagez.com/man/5/editrc/ -Judah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Using Parsec with other monads
Hi, I've spent some time writing a parser using the Parsec library and was looking forward to being able to plug in some side-behaviour once I'd got the parser working. Now it seems I can't actually do that in a nice way because Parsec appears to be fixed to a simple State monad. I found this mentioned in the Cafe archives, but not much discussion. Is there a reason Parsec wasn't implemented using the monad transformer approach? Are there any plans to open it up? It's a nice powerful library and a natural thing to want to do for example would be to plug in something like a Reader to track a variable context. I guess one could abuse the State monad to achieve the goal but that feels like the wrong tool for the job. Any insights appreciated. thanks, Roly ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using Parsec with other monads
On Fri, 2008-11-28 at 23:27 +, Roly Perera wrote: Hi, I've spent some time writing a parser using the Parsec library and was looking forward to being able to plug in some side-behaviour once I'd got the parser working. Now it seems I can't actually do that in a nice way because Parsec appears to be fixed to a simple State monad. I found this mentioned in the Cafe archives, but not much discussion. Is there a reason Parsec wasn't implemented using the monad transformer approach? Are there any plans to open it up? It's a nice powerful library and a natural thing to want to do for example would be to plug in something like a Reader to track a variable context. I guess one could abuse the State monad to achieve the goal but that feels like the wrong tool for the job. Any insights appreciated. Parsec3 is implemented as a monad transformer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using Parsec with other monads
Hello Roly, Saturday, November 29, 2008, 2:27:22 AM, you wrote: Now it seems I can't actually do that in a nice way because Parsec appears to be fixed to a simple State monad. afaik, version 3 is implemented as monad transformer -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell!
On 28/11/2008, at 20:04, Simon Marlow wrote: So we have two vector libraries, vector and uvector, which have a lot in common - they are both single-dimension array types that support unboxed instances and have list-like operations with fusion. They ought to be unified, really. Yes. This shouldn't be too hard to do since both libraries are based on the internal DPH arrays. Although I have to admit that I never really looked at Don's code and have no idea how much he has changed. But it's more than that. The basic idea behind vector is to provide a common framework for normal arrays, ByteString, StorableVector etc. It's not finished by a long shot but (unsurprisingly) I think it goes in the right direction. The proliferation of array-like libraries is counterproductive. The main difference between these libraries and Haskell's arrays is the Ix class. So perhaps Haskell's arrays should be reimplemented on top of the low-level vector libraries? The Ix class is the root cause of the problems with optimising the standard array libraries. Yes, Haskell arrays should be based on a lower-level array library. I would also argue that they should be redesigned and given a more streamlined and efficient interface. The Ix class is not the only problem wrt efficiency. In particular, the H98 array library relies quite heavily on lists which makes implementing any kind of array fusion rather hard. In contrast to Ix, this is completely unnecessary, IMO. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell! - array libraries
But I don't want Perl, I want a well designed language and well designed libraries. I think it's find to let libraries proliferate, but at some point you also need to step back and abstract. -- Lennart Especially so if the free marketeers claim there is something fundamentally wrong with the standard libraries and language, as in the case of arrays. When someone did that nice little survey of the last bunch of array libraries (Bulat, I think? now in the wiki book), I was hoping there would be a grand unification soon. Instead, it seems that those who have worked most with Haskell arrays recently have simply abandoned all of the standard array libraries. Okay, why not, if there are good reasons. But can't you document those reasons, for each of your alternative proposals, so that people have some basis on which to choose (other than who has the loudest market voice;-)? And would it be difficult for you all to agree on a standard API, to make switching between the alternatives easy (if it is indeed impossible to unify their advantages in a single library, the reasons for which should also be documented somewhere)? And what is wrong about Simon's suggestion, to use the standard array lib APIs on top of your implementations? Not that I see Haskell' coming soon, but I'd certainly not want it to continue standardising a kind of array that appears to have no backing among the Haskell array user/library author community. Nor would I like something as central as arrays to remain outside the standard, where it won't remain stable enough for Haskell programmers to rely on in the long run. bazaar, yes; mayhem, no. Claus On Fri, Nov 28, 2008 at 9:46 PM, Don Stewart [EMAIL PROTECTED] wrote: andrewcoppin: What *I* propose is that somebody [you see what I did there?] should sit down, take stock of all the multitudes of array libraries, what features they have, what obvious features they're missing, and think up a good API from scratch. Once we figure out what the best way to arrange all this stuff is, *then* we attack the problem of implementing it for real. It seems lots of people have written really useful code, but we need to take a step back and look at the big picture here before writing any more of it. No. My view would be to let the free market of developers decide what is best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). And this approach has yielded more code than ever before, more libraries than ever before, and library authors are competing. So let the market decide. We're a bazaar, not a cathedral. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell! - array libraries
On 29/11/2008, at 08:43, Andrew Coppin wrote: What *I* propose is that somebody [you see what I did there?] should sit down, take stock of all the multitudes of array libraries, what features they have, what obvious features they're missing, and think up a good API from scratch. Once we figure out what the best way to arrange all this stuff is, *then* we attack the problem of implementing it for real. That is the idea behind vector. I don't know how good it is but it's the best I could come up with (or will be once it's finished). That said, I don't think there is such a thing as a perfect array API. Different libraries serve different purposes. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell! - array libraries
claus.reinke: But I don't want Perl, I want a well designed language and well designed libraries. I think it's find to let libraries proliferate, but at some point you also need to step back and abstract. -- Lennart Especially so if the free marketeers claim there is something fundamentally wrong with the standard libraries and language, as in the case of arrays. When someone did that nice little survey of the last bunch of array libraries (Bulat, I think? now in the wiki book), I was hoping there would be a grand unification soon. Instead, it seems that those who have worked most with Haskell arrays recently have simply abandoned all of the standard array libraries. I don't think Bulat uploaded his libraries to hackage in the end. And if it's not on hackage, then no one will use it, so it may as well not exist. Okay, why not, if there are good reasons. But can't you document those reasons, for each of your alternative proposals, so that people have some basis on which to choose (other than who has the loudest market voice;-)? And would it be difficult for you all to agree on a standard API, to make switching between the alternatives easy (if it is indeed impossible to unify their advantages in a single library, the reasons for which should also be documented somewhere)? And what is wrong about Simon's suggestion, to use the standard array lib APIs on top of your implementations? Nothing. This would be great. Who's volunteering to write the code? The new 'list-like' fusible array libraries are still in alpha, anyway. Not that I see Haskell' coming soon, but I'd certainly not want it to continue standardising a kind of array that appears to have no backing among the Haskell array user/library author community. Nor would I like something as central as arrays to remain outside the standard, where it won't remain stable enough for Haskell programmers to rely on in the long run. Hence the Haskell Platform. To provide the stability that people rely on in the long run. Haskell' is not the process by which new libraries will be standardised -- there's simply too many libraries being produced. The platform let's us: * Take libraries out of the standardisation process. * Let developers develop in competition, and converge on agreed designs. * Let users decide what to use, rather than waste time standardising things when the developer community has already moved on. * And then publish a list of blessed code. Since arrays are just another (non-obvious) data structure, there's a huge design space: * flat and/or nested arrays? * strict or lazy or eager? * callable from C or Fortran? * mutable/immutable * polymorphic in what dimensions? * mmap-able? * read / write API, or list-like API? We've not yet found the perfect implementation, but we're learning a lot. And since it is not yet clear what the optimal solution looks like, I say let the developers keep hacking for a while, until we get an idea of what works. And by all means, if someone thinks they know what the best API is, step up and show us the implementation! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell! - array libraries
On 29/11/2008, at 10:47, Claus Reinke wrote: But I don't want Perl, I want a well designed language and well designed libraries. I think it's find to let libraries proliferate, but at some point you also need to step back and abstract. -- Lennart Especially so if the free marketeers claim there is something fundamentally wrong with the standard libraries and language, as in the case of arrays. When someone did that nice little survey of the last bunch of array libraries (Bulat, I think? now in the wiki book), I was hoping there would be a grand unification soon. Instead, it seems that those who have worked most with Haskell arrays recently have simply abandoned all of the standard array libraries. Okay, why not, if there are good reasons. But can't you document those reasons, for each of your alternative proposals, so that people have some basis on which to choose (other than who has the loudest market voice;-)? I think so far, it's always been the same two reasons: efficiency and ease of use. H98 arrays are inherently inefficient and IMO not very easy to use, at least not for the things that I'm doing. And would it be difficult for you all to agree on a standard API, to make switching between the alternatives easy (if it is indeed impossible to unify their advantages in a single library, the reasons for which should also be documented somewhere)? Yes, it is very difficult. A sensible API for a standard array library is something that needs more research. FWIW, I don't know of any other language that has what I'd like to see in Haskell. C++ probably comes closest but they have it easy - they don't do fusion. And what is wrong about Simon's suggestion, to use the standard array lib APIs on top of your implementations? Again, IMO H98 arrays are only suitable for a very restricted set of array algorithms. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (15th ed., November 2008)
Good work! It is always interesting to see the secret Haskell projects that only get announced via the HCAR. Things not on haskell@ or on hackage. For example, this under-the-radar project: http://www.haskell.org/communities/11-2008/html/report.html#sect7.7 7.7 IVU Traffic Technologies AG Rostering Group Haskell to solve constraints on EU bus timetables! In production use! -- Don voigt: On behalf of the many, many contributors, I am pleased to announce that the Haskell Communities and Activities Report (15th edition, November 2008) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in PDF and HTML formats. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Go Haskell! - array libraries
Yes, it is very difficult. A sensible API for a standard array library is something that needs more research. FWIW, I don't know of any other language that has what I'd like to see in Haskell. C++ probably comes closest but they have it easy - they don't do fusion. I assume you've looked at SAC? http://www.sac-home.org/ Their main research and development focus was/has been on arrays (fusion/layout/padding/tiling/slicing/data-parallelism/shape-invariance (source algorithms parameterized over array dimensionality/shape)/ whole-array ops/list-like ops/lots of surface operations reducable to a minimal set of core operations that need implementation/cache behaviour/performance/performance/performance/..). When they started out, I tried to make the point that I would have liked to have their wonderful array ideas in our otherwise wonderful language, but they preferred to follow their own way towards world domination (*). Does that sound familiar?-) Claus (*) ok, they did have a good motive: they came out of a research group that had done non-sequential functional programming in the 1980s, with all the things we see today: great speedups, shame about the sequential baseline; creating parallel threads is easy, load balancing slightly harder, but pumping (creating thread hierarchies recursively, only to see them fold into a small result, for the process to begin again) is a waste, etc.; so they decided to start from a fast sequential baseline instead of full functional language, and designed their language around arrays instead of trying to add arrays to an existing language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: Real World Haskell, now shipping
Andrew Coppin 쓴 글: Then again, one day I sat down and tried to draw a diagram of the essential concepts, techniques and syntax of Haskell and how they're related... The result looked like alphabet soup! It's not clear how you start to explain anything without immediately needing to explain 20 other things you just used to explain the first thing. (Somebody commented recursive tutorials for a recursive language. It was meant as an insult, but I actually kinda like it...) Given that that's the case, I'm not really sure that I could do any better than the Three Kings, so maybe I should just shuffle off and keep my comments to myself. :-/ If one needs introductory Haskell programming tutorial explaining about the language concepts from first principles, then one should read a textbook written for that purpose such as Programming in Haskell. Real World Haskell is a collection of practical tips and know-hows to get things done at work rather than a step-by-step Haskell tutorial. And I believe that many other O'Reilly books are like that. What I *haven't* done yet is read the chapters where they try to claim that database programming is possible in Haskell. I'll have to do that at some point. Maybe this is where they reveal the Secret Formula that makes this stuff actually work properly... but somehow I doubt it. What do you mean by that they are trying database programming is possible in Haskell? I've done very simple database programming in Haskell using HDBC, and it just works using the binary package from debian. If you need more complicated examples, you can take a look at the hpodder source code or any other applications that use database. They are all on Hackage. -- Ahn, Ki Yung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: I spoke with the author of the fork a bit in IRC around the time it happened and my understanding is that: 1) John sternly objects to using cabal as the build system for JHC This is a fairly silly reason to fork a project, especially jhc, for a number of reasons. It is important to me that jhc be as widely accessible at possible. The number of machines './configure make install' will work on outnumbers those that cabal install will work on hundreds or thousands to one. I am pleased to have anyone experiment with jhc in the first place, I don't want to make things harder for my users. This alone would be enough of a reason all other things being equal, but other things arn't equal to boot. The quality of support I can provide is diminished with cabal. Someone tries to compile jhc, they get a moderately tricky build error. they send it to me, I take a look, figure out the workaround and release a new version that same day. one day turnaround. A bug is found in the way cabal does something. I track down the bug, hope it is something fixable, then further hope when I send a fix it is accepted. Maybe it takes a week or two. Now, do I release a new version of jhc that requires a development version of cabal? do I hold off and tell the user they need a personalized workaround? do I demand that to use jhc you have to use the latest cabal snapshots? Do I then have to support them when the latest snapshots break something else of theirs? In any case. it is not a situation I want to be in. Cabal just isn't elegant. let's put it in perspective, cabal has 4 times as many lines of code as mk (a superset of make)*. That is four times as many lines of haskell code as C. Given how much more dense and expressive haskell code is than C, that is a huge amount. Yet cabal can't handle what even mildly complicated make scripts can do. Cabal is not flexible. I decide I want to include a nice graph of code motion in jhc, so I add the following 2 lines to my makefile %.pdf: %.dot dot $ -Tpdf -o$@ and done! my build system now understands how to create pdf documents from graph description files. now, I _could_ add support for this to cabal, I _could_ wait several months for the new version to propagate to users. And I _would_ fully expect to have to go through the whole process again the next time I want to do something slightly unorthodox. Cabal is just a huge dependency I don't need. Every dependency I add to a project is a bigger hassle for my users and for me. A fairly complicated dependency like cabal would have to have fairly compelling benefits. Now, I am saying these things so people don't think I am just being stubborn. I have valid, compelling, and logical reasons to not want to use cabal. I think it is the wrong tool for the job and it is that simple. If you want me to switch to cabal, address its issues, and then _in addition_ add a killer feature on top to put it ahead of other systems to make the work involved in switching worth it. I have a goal with jhc, to write a kick ass haskell compiler. Not to fight a build system that is not suited to my task and that made some dubious design decisions. Not to promote an agenda. And before you respond, think about this. What if the ghc developers were constantly bombarded with whining from the perl people that ghc doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What would your impression of the perl community be? What if people kept trying to convince _you_ to rewrite your haskell project in java _and_ provide support for it because they never had to use referential transparency, so it can't be that important to you. Sometimes that is what it feels like, which is disapointing from this community. We all came to haskell because we thought it was the better choice at some point. The hegemony was pushing java, C++, or worse but we didn't bite (or at least were still hungry). Just because something is popular, it doesn't mean it is good, just because it is written in haskell, it doesn't mean it is elegant. So don't begrudge me for holding out for something better. Perhaps franchise will be it, perhaps some future version of cabal, perhaps nothing will replace make/autoconfs sweet spot (though I would hope there is still some innovation in this area the OSS community can explore). I hope John doesn't take the fork as any sort of aggressive or insulting action. He's made a compiler that is sufficiently interesting to have users that want to take over. I am still actively working on jhc for the record. Actual code checkin tends to be very spurty, but don't think the project is dead. More in a design phase than anything else. There is no surer way to instigate another spurt than by submitting some patches or bringing up discussion of an interesting topic or paper on the jhc mailing list. John * if you include the source of all the libraries mk depends
Re: [Haskell-cafe] Compilers
john: On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: I spoke with the author of the fork a bit in IRC around the time it happened and my understanding is that: 1) John sternly objects to using cabal as the build system for JHC This is a fairly silly reason to fork a project, especially jhc, for a number of reasons. One of the reasons though, for the branching, is that the potential developers, who all have Haskell toolchains, couldn't do: $ cabal install jhc Then now can, but have to write 'lhc' instead of 'jhc'. We've probably just increased the jhc alpha user base 10 fold. Hooray! Integrating into the ecology of the vast majority of Haskell code is a good way to get and keep developers. And since GHC -- which we need to build JHC anyway -- already ships with Cabal, no additional dependencies are required. Looks like win to me. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers
On Fri, Nov 28, 2008 at 7:30 PM, John Meacham [EMAIL PROTECTED] wrote: On Wed, Nov 26, 2008 at 07:20:12PM -0800, Jason Dagit wrote: I spoke with the author of the fork a bit in IRC around the time it happened and my understanding is that: 1) John sternly objects to using cabal as the build system for JHC This is a fairly silly reason to fork a project, especially jhc, for a number of reasons. It is important to me that jhc be as widely accessible at possible. The number of machines './configure make install' will work on outnumbers those that cabal install will work on hundreds or thousands to one. I am pleased to have anyone experiment with jhc in the first place, I don't want to make things harder for my users. This alone would be enough of a reason all other things being equal, but other things arn't equal to boot. The command './configure make install' only works in Windows if the user bother to install some form of unix environment emulation like msys or cygwin. I don't know if windows platform support matters to jhc, but if it does that's one reason to want to provide an alternative to the autotools build option. The quality of support I can provide is diminished with cabal. Someone tries to compile jhc, they get a moderately tricky build error. they send it to me, I take a look, figure out the workaround and release a new version that same day. one day turnaround. A bug is found in the way cabal does something. I track down the bug, hope it is something fixable, then further hope when I send a fix it is accepted. Maybe it takes a week or two. Now, do I release a new version of jhc that requires a development version of cabal? do I hold off and tell the user they need a personalized workaround? do I demand that to use jhc you have to use the latest cabal snapshots? Do I then have to support them when the latest snapshots break something else of theirs? In any case. it is not a situation I want to be in. Cabal just isn't elegant. let's put it in perspective, cabal has 4 times as many lines of code as mk (a superset of make)*. That is four times as many lines of haskell code as C. Given how much more dense and expressive haskell code is than C, that is a huge amount. Yet cabal can't handle what even mildly complicated make scripts can do. Cabal is not flexible. I decide I want to include a nice graph of code motion in jhc, so I add the following 2 lines to my makefile %.pdf: %.dot dot $ -Tpdf -o$@ and done! my build system now understands how to create pdf documents from graph description files. now, I _could_ add support for this to cabal, I _could_ wait several months for the new version to propagate to users. And I _would_ fully expect to have to go through the whole process again the next time I want to do something slightly unorthodox. Cabal is just a huge dependency I don't need. Every dependency I add to a project is a bigger hassle for my users and for me. A fairly complicated dependency like cabal would have to have fairly compelling benefits. Your arguments make it sound as though providing an option for building with cabal is out of the question. Since I'm not invovled with JHC or LHC in any way I don't know how you would answer this question: Would you consider a cabal based build inaddition to the autotools one? Personally, I look at it this way. Both build systems have different advantages that the other cannot provide but they are not mutually exclusive. Also, the effort to keep them both working for the respective groups of users is rather small in practice. Now, I am saying these things so people don't think I am just being stubborn. I have valid, compelling, and logical reasons to not want to use cabal. I think it is the wrong tool for the job and it is that simple. If you want me to switch to cabal, address its issues, and then _in addition_ add a killer feature on top to put it ahead of other systems to make the work involved in switching worth it. I have a goal with jhc, to write a kick ass haskell compiler. Not to fight a build system that is not suited to my task and that made some dubious design decisions. Not to promote an agenda. The reason to provide a .cabal file is exactly the one Don wrote about. This is possible both using make as the build system or in a way that is independent of the make based build system. And before you respond, think about this. What if the ghc developers were constantly bombarded with whining from the perl people that ghc doesn't use MakeMaker.pm since ghc uses perl in the evil demangler? What would your impression of the perl community be? I don't recall if I've expressed this publicly before or not, but I'm not fond of the language specific reimplementations of make. I think it's silly that every language has 2-3 language specific build systems and package formats. But, it's too late for me to stop Cabal from existing. Hackage is too
Re: [Haskell-cafe] ANN: Real World Haskell, now shipping
Andrew Coppin [EMAIL PROTECTED] wrote: What I *haven't* done yet is read the chapters where they try to claim that database programming is possible in Haskell. I'll have to do that at some point. Maybe this is where they reveal the Secret Formula that makes this stuff actually work properly... but somehow I doubt it. Well, it's certainly possible to interact with a SQL database. You have had some kind of trouble, or you have a higher notion of database programming? -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
