Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
On Fri, Aug 6, 2010 at 5:58 PM, Alex Stangl a...@stangl.us wrote: On Fri, Aug 06, 2010 at 10:17:26AM -0500, aditya siram wrote: From my vantage point they are (in no particular order) : Reader, Writer, State, IO, ST, STM, Parsec (have I missed any?) and of course the transformer versions. I am debating whether or not to add [] to the bunch. Not sure how much time you have budgeted, but I'd start with a simple one like Maybe, actually show how to implement it, then move on to list, I second that. Especially, if the audience is more familiar with imperative langages, then the reader, writer and state monad may not immediately impress them. David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
Good, we need more functional programmers actually solving real problems. But please put your skills to work in an industry other than investment banking. There are lots of companies outside of investment-banking using functional programming. Bluespec, Galois, TypLab, are all serious Haskell users. Larger companies such as ATT, Facebook, and Google have all used Haskell for various projects. If you look a bit further afield, there are even more companies using F#, Caml, and Erlang. I use Caml almost exclusively in my day job at Vector Fabrics – which is poles apart from investment banking. (And yes, we're always interested in hiring good functional programmers.) If you want a FP job outside of investment banking, keep an eye on the CUFP website and the FP mailing lists. Opportunities abound! Wouter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Odd parallel haskell observations (some more numbers)
Hello, I am no expert in web server tuning, but I will share my thoughts about your approach and expectations nevertheless. On 08.08.2010, at 21:07, Alexander Kotelnikov wrote: So I continue to issue thousands of HTTP GET requests to a local apache an got some ThreadScope pictures and numbers (BTW, I all this happens on a 4-core machine). So your apache configuration is very crucial for the performance figures you will receive from your benchmark. As far as I know web server benchmarks usually run continuously and report a current throughput or average latency of the last n seconds or something like that. This allows the tested web server to adapt to the kind of load it experiences. And the benchmarker is able to wait untill those numbers stabilize. When you execute your program with a different number of capabilities (different -N settings), apache will see a different kind of load and behave different. This makes it hard to change your program and expect similar results. I would point out the following as deserving an explanation: 1. It looks like that none of tests used resources of more than 2 cores. This might be an indication that cpu resources are not the limiting factor in this benchmark. You basically bench the io capabilities of your operating system, your installed apache with your configuration and of your installed ghc. Therefore, increasing available cpu resources does't lead necessarily to increased performance. 2. Sometimes there is no activity in any thread of a running program (get.N4qg_withgaps.eventlog.png, does this mean that process is in a OS queue for scheduling or something else?) 3. Without RTS's -c or -qg multithreaded run suffers from excessive GC actions. 4. Even with -c/-qg thread's run looks to be iterrupted too frequent. 5. Provided that 1 requests in a row can be completed in ~3.4s I would expect that 4 threads might come close or even under 1s, but 1.9s was the best result. A last point to consider: Is getRequest strict? Does it internally use some kind of lazy IO? Is it possible that some resource aren't properly freed? Perhaps, because the library relies on the garbage collector reclaiming sockets? Or because the request aren't completely read? I simply don't no the internall of Network.HTTP, but if it uses lazy IO it is IMHO not suitable for such a benchmark. Just, my two euro cents. -- Jean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Wed, Aug 04, 2010 at 01:00:16AM -0400, Mark Lentczner wrote: The Haddock team has spent the last few months revamping the look of the generated output. We're pretty close to done, but we'd like to get the community's input before we put it in the main release. Please take a look, and then give us your feedback through a short survey Sample pages: http://www.ozonehouse.com/mark/snap-xhtml/index.html Frame version: http://www.ozonehouse.com/mark/snap-xhtml/frames.html Survey: http://spreadsheets.google.com/viewform?formkey=dHcwYzdMNkl5WER1aVBXdV9HX1l5U3c6MQ Short link to same survey: http://bit.ly/9Zvs9B Thanks! - Mark The framed layout has one very crippling disadvantage. It's is impossible to link sanely to individual pages or sections. If you copy the link to a particular page or anchor, you lose the frames. If you grab the URL from the address bar, you end up at the root level. Compare it with the horror that is the Boost.Serialization docs [1] or the C++ draft [2]. The survey seems to be inactive, by the way. [1] http://www.boost.org/doc/libs/1_43_0/libs/serialization/doc/index.html [2] http://www.open-std.org/jtc1/sc22/open/n2356/ -- Lars Viklund | z...@acc.umu.se ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
Hi Lars, On Mon, Aug 9, 2010 at 10:23 AM, Lars Viklund z...@acc.umu.se wrote: The survey seems to be inactive, by the way. It's because Mark already posted the results. :) Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On 06/08/10 03:15, Jeff Zaroyko wrote: On Thu, Aug 5, 2010 at 11:48 PM, Johan Tibelljohan.tib...@gmail.com wrote: On Thu, Aug 5, 2010 at 3:35 PM, Dino Morellid...@ui3.info wrote: On Wed, 4 Aug 2010, Mark Lentczner wrote: One thing I haven't seen anyone else comment on is the width of the new docs. I have a large (26) monitor and use the browser full-screen (with xmonad, so even more screen space). When I load these pages, particularly the non-frame one, something like 50% of my screen real-estate is empty whitespace on either side of the doc content. There is also wasted space in the frames version, just a little less of it. I wish the docs were using that space like the current Haddock does. Is the plan to use a fixed width like this? Yes. There's research suggesting that the line length should be between 65 and 75 characters per line. http://psychology.wichita.edu/surl/usabilitynews/42/text_length.htm http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp This study examined the effects of line length on reading speed, comprehension, and user satisfaction of online news articles. I completely agree with the case of news articles, but not in the case of Haskell documentation, it's structured differently and different parts such as bold or larger typeface serve as points of reference when reading, in contrast to plain old paragraphs found in a news article. The current layout works very well for me, I don't like the additional whitespace in the proposed version. I feel the colour scheme is a step backwards from what we have already, which offers high visibility. Personally I think the way the current layout expands to the full width of the window makes it really hard to read with a wide browser, but since many sites suffer from the same problem I normally use a narrower browser window and fill up the rest of the screen space with IRC windows :-) The great thing about the Haddock redesign is that the content has been separated from the style. If opinions about the style are sufficiently divided we can provide a style switcher on the docs we ship with GHC, and make that the default for Cabal-generated docs. Although the opinions I've seen so far suggest that the majority of people prefer the new style. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Preview the new haddock look and take a short survey
On Mon, Aug 9, 2010 at 10:55 AM, Simon Marlow marlo...@gmail.com wrote: The great thing about the Haddock redesign is that the content has been separated from the style. If opinions about the style are sufficiently divided we can provide a style switcher on the docs we ship with GHC, and make that the default for Cabal-generated docs. Although the opinions I've seen so far suggest that the majority of people prefer the new style. I agree. The most important thing about this change is that it allows people to play with styling more easily. As a bonus we get a new default style that looks more modern than the old style. My personal preference would be for the style to have a left hand menu, like the Python docs. It's now possible for me to play with that idea and, if the result is convincing enough, try to convince other Haskellers that it should be the default. If I can't convince others, I can always use a browser style switcher to have the docs render the way I want in my own browser. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
aditya siram wrote: Thanks all for you suggestions! Upon further reflection I realized that my audience is more pragmatic than theoretical. Instead of emphasizing how monads are constructed and the monad laws I think I want to dive right into the most common and useful monads. From my vantage point they are (in no particular order) : Reader, Writer, State, IO, ST, STM, Parsec (have I missed any?) and of course the transformer versions. I am debating whether or not to add [] to the bunch. Whether you add [] or not, you should definitely include Maybe. Maybe captures the most basic kind of fallible computation, so it shows up all over the place with pragmatic coding. Compare against null pointers, returning -1 to signal error when a positive number is the expected return, using 0 to express an infinite limit on some kind of resource, etc. Maybe does the same thing, except it does them cleanly and correctly because we express the possibility of failure in the type system instead of relying on magic values to express them. Magic values are even worse than magic numbers and other magic constants, IMO. Once you've explained Maybe, you can mention (Either a) in passing; they should figure out the generalization immediately. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: gkt2hs seg fault issue
bri...@aracnet.com writes: On Mon, 09 Aug 2010 11:09:40 +0800 Andy Stewart lazycat.mana...@gmail.com wrote: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com writes: On 9 August 2010 09:44, Andy Stewart lazycat.mana...@gmail.com wrote: Which ghc version? The Glorious Glasgow Haskell Compilation System, version 6.12.1 So just run gdb on ghci to see what is happening ? Since ghci got seg fault, it's maybe the bug of gtk2hs. I recommend you download darcs version and test again. If darcs version get same error, it's new bug, then report it to gtk2hs-us...@lists.sourceforge.net Thanks, -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Please take the State of Haskell, 2010 survey
Hi all, On Mon, Aug 2, 2010 at 3:40 PM, Johan Tibell johan.tib...@gmail.com wrote: I've put together a quick, 9-question State of Haskell, 2010 survey: http://blog.johantibell.com/2010/08/state-of-haskell-2010-survey.html The survey will hopefully give us some insight into how people use Haskell and perhaps also some ideas on how Haskell tools and libraries could be improved. The results of this survey are now available: http://blog.johantibell.com/2010/08/results-from-state-of-haskell-2010.html P.S. Please direct replies to this email to haskell-c...@haskell.org. Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Odd parallel haskell observations (some more numbers)
Hi.
On Mon, 9 Aug 2010 09:44:00 +0200
JG == Jean-Marie Gaillourdet j...@gaillourdet.net wrote:
JG
JG I am no expert in web server tuning, but I will share my thoughts
JG about your approach and expectations nevertheless.
I would better think about ghc than about web server. I believe, that
numbers I already provided (especially their deviation) illustrate that
sometimes ghc runtime perform quite bad.
I also found out that it can do better than it does by default, I can
accept that runtime might be not capable to adjust itself to any taks
the best way, but then it will be nice to know, for instance, why for
such I/O that GC settings change performance in times.
To illustrate even more that httpd has nothing to do with the phenomenon
I wrote a small C application which does pretty much the same. Numbers
tells that apache can serve much faster that it was required to please
haskell version (I will remind that it was 3.4 for single-threaded
haskell and went as low as 1.9s for 4-threaded). I attached the code
just in case.
10:27 sa...@loft4633:~/work/cube-server/tests 99 for i in 1 2 3 4; do for j in
`seq 1 5`;do ./getc $i 1;done;done
1 1.352978
1 1.34
1 1.344545
1 1.345116
1 1.189060
2 0.668219
2 0.625113
2 0.698073
2 0.732621
2 0.722310
3 0.569121
3 0.581570
3 0.563512
3 0.566186
3 0.564232
4 0.510132
4 0.496181
4 0.529212
4 0.504506
4 0.511847
# include stdio.h
# include pthread.h
# include sys/time.h
# include unistd.h
# include string.h
# include stdlib.h
# include sys/socket.h
# include netinet/in.h
#include arpa/inet.h
int fib(int n) {
if ( n 1 )
return fib(n-1) + fib(n-2);
else
return 1;
}
# define REQ GET / HTTP/1.1\r\n\r\n
int get() {
int s;
int n;
struct sockaddr_in sa;
struct in_addr ia;
char buf[1];
sa.sin_family = AF_INET;
if ( !inet_pton(AF_INET, 127.0.0.1, ia) ) {
fprintf(stderr, inet_pton\n);
exit(1);
}
else {
sa.sin_addr.s_addr = ia.s_addr;
}
sa.sin_port = htons(80);
s = socket(AF_INET, SOCK_STREAM, 0);
n = connect(s, (struct sockaddr*)sa, sizeof(sa));
send(s, REQ, strlen(REQ), 0);
while ( (n = recv(s, buf, 1, 0)) 0 );
//printf(%d\n, fib(38));
close (s);
return 0;
}
void* nget(void* p){
int i;
int n = *(int*)p;
for ( i = 0; i n; i++ )
get();
return NULL;
}
int main(int argc, char* argv[]) {
int c;
int n;
int p;
int i;
double run_time;
struct timeval start;
struct timeval end;
c = strtol(argv[1], NULL, 10);
n = strtol(argv[2], NULL, 10);
p = n/c;
pthread_t *thread_ids;
thread_ids = (pthread_t*)malloc(sizeof(pthread_t*) * c);
gettimeofday(start, NULL);
for (i = 0; i c; i++) {
pthread_create(thread_ids[i], NULL, nget, p);
}
for (i = 0; i c; i++) {
pthread_join(thread_ids[i], NULL);
}
gettimeofday(end, NULL);
run_time = end.tv_sec - start.tv_sec + 1e-6 * (end.tv_usec - start.tv_usec);
printf(%d %f\n, c, run_time);
return 0;
}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [web-devel] statically compiled css
OK, I declare myself officially unable to make a decision on this one: there's just too many good options ;). I beseech the community to aid me in my plight, by taking a survey on the names available[1]. Michael [1] https://spreadsheets.google.com/viewform?formkey=dHVOU2p6OVRkcWVQVG10d01OWk8yU2c6MQ On Mon, Aug 9, 2010 at 8:19 AM, wren ng thornton w...@freegeek.org wrote: Alexander Dunlap wrote: CaSSius and JSaesar? +1 for Cassius. -- Live well, ~wren ___ 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] Re: a random numbers generator with a good 'split'
Hello Petr, the mersenne-random package is quite low-level and uses explicit destructive update, so it can only be used with the IO monad. Same with other fast generators like mwc-random. This is incompatible with the RandomGen and Random classes, which can only model a pure interface. About splitting a PRNG: A high quality PRNG can be splitted by using its own output to derive arbitrarily many child states. If the state is just a number, in many cases you can derive PRNGs by adding a constant. Greets, Ertugrul d...@pudlak.name wrote: Hi cafe. recently I was looking at various possibilities of generating random numbers in Haskell. Apparently, the main problem is the 'split' function in the System.Random.RandomGen class. Since it is rarely needed in imperative programs, not much is known how to implement it safely. It's documentation says: The split operation allows one to obtain two distinct random number generators. This is very useful in functional programs (for example, when passing a random number generator down to recursive calls), but very little work has been done on statistically robust implementations of split ([System.Random, System.Random] are the only examples we know of). I consulted it with a friend, who has done much work in the area of random number generators. He suggested that this might be implemented using a random number generator with a very large period, such as Mersene Twister (MT19937 has a period of 2^19937-1). A pair of splitted generators states could be positioned sufficiently far enough from each other so that in practice they never reach each other, and in such a way that successive splits (in practice) never meet. I searched Hackage, where I found a few implementations of Mersene Twister, but AFAIK no one actually implements neither RandomGen nor 'split' alone. I wonder why -- is RandomGen inconvenient or obsolete in some way? Or just nobody tried? With best regards, Petr Pudlak PS: Sorry if you get multiple copies, I had problems sending the mail. -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [web-devel] statically compiled css
@Michael: Have you seen the JSMacro package on hackage? I think it might be a better fit as it adds some nice syntactic goodies to JS in addition to variable interpolation. Cheers. ~Liam On 9 August 2010 22:59, Michael Snoyman mich...@snoyman.com wrote: OK, I declare myself officially unable to make a decision on this one: there's just too many good options ;). I beseech the community to aid me in my plight, by taking a survey on the names available[1]. Michael [1] https://spreadsheets.google.com/viewform?formkey=dHVOU2p6OVRkcWVQVG10d01OWk8yU2c6MQ On Mon, Aug 9, 2010 at 8:19 AM, wren ng thornton w...@freegeek.orgwrote: Alexander Dunlap wrote: CaSSius and JSaesar? +1 for Cassius. -- Live well, ~wren ___ 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] Socket not released
You need to close the parent's socket in the child fork, as well as the parent - if it's inherited by the child, it's held open there, even if the parent closes it. Thanks! That did the trick. I did so by adding close_fds = True to the CreateProcess record. However the documentation of System.Process says that this only works on Windows if std_in, std_out, and std_err are all set to Inherit. This is not the case in my program so it will not work on any nodes that run on Windows. What is the workaround for doing this kind of thing in Windows? Also since the file descriptor of the socket appears to be inherited by the child process, can I just start using it rather than closing it in both the parent and child and then creating a new one? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: philosophy of Haskell
jerzy.karczmarc...@info.unicaen.fr wrote: Alberto G. Corona writes: (...) Desugarize the do notation, after that, desugarize the = and operators down to the function call notation and suddenly everithing lost its magic because it becomes clear that a haskell monad is a sugarization of plain functional tricks. Yep. But, BTW, could you tell me what was the result of the final desugarization and the BASIC sense of the IO monad for you? Example: do x - getLine print (x+1) print (x+2) There are various models. One (the state monad model) of them would desugar this to: \world0 - let (x, world1) = getLine world0 world2 = print (x+1) world1 world3 = print (x+2) world2 in world3 Another one (the EDSL model, which I personally prefer) would desugar it to something as simple as this: GetLine `BindIO` \x - Print (x+1) `BindIO` const (Print (x+2)) I wonder if there are more models for IO. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typo or on purpose? http://haskell.org/ghc/docs/6.12.2/html/users_guide/lang-parallel.html
On 8 Aug 2010, at 20:23, Alexander Kotelnikov wrote: This + 1 in (n1 + n2 + 1) what is it doing there? import Control.Parallel nfib :: Int - Int nfib n | n = 1 = 1 | otherwise = par n1 (pseq n2 (n1 + n2 + 1)) where n1 = nfib (n-1) n2 = nfib (n-2) The nfib function, by convention, counts the number of function calls needed in an evaluation of the fibonacci number, rather than evaluating the fibonacci number itself. Hence the +1. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Socket not released
Quoth Jonathan Geddes geddes.jonat...@gmail.com, You need to close the parent's socket in the child fork, as well as the parent - if it's inherited by the child, it's held open there, even if the parent closes it. Thanks! That did the trick. I did so by adding close_fds = True to the CreateProcess record. However the documentation of System.Process says that this only works on Windows if std_in, std_out, and std_err are all set to Inherit. This is not the case in my program so it will not work on any nodes that run on Windows. What is the workaround for doing this kind of thing in Windows? Only a guess, but I predict that it will work for your purposes, since you're not concerned about what happens to std_in et al. That statement in the documentation is ambiguous, so if it isn't convenient to just test for this, you need someone to clarify what doesn't work means. Also since the file descriptor of the socket appears to be inherited by the child process, can I just start using it rather than closing it in both the parent and child and then creating a new one? Sure! At least from a POSIX perspective, and it would be surprising if a Haskell implementation failed to preserve that. Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: jhc 0.7.4
On 27/07/2010 01:54, John Meacham wrote: For each type I can statically generate an optimal layout based on its structure. For instance, maybe benefits from two of these optimizations, first of all, nullary constructors (Nothing) need never appear in the heap, so they are given values that pack directly into a word, this happens for all nullay constructors in general. Then, since there is only one constructor left (Just) we can discard the tag field, because if something of type Maybe, is in WHNF, and is not Nothing then in must be a Just. so the Just is a single heap allocated word (which are packed end to end in a page with no overhead) I am refining the optimization algorithm, on 64 bit machines I have another few bits to play with for instance that I can take advantage of. A particularly nice case is that characters can be fully integreated into the word, so the entire space usage of Hello is 10 words as lists benefit from the same packing benefits as Maybe. I should point out that in GHC Hello requires 15 words: 3 for each list cell, and the Chars are free because they're statically allocated in the RTS. A Just requires 2 words (one more than JHC, I guess). Tantalisingly, it's almost possible to represent a Just with zero words - the pointer to the Just points directly to the element - but there's nowhere to put the tag bits for the element pointer (the tag bits are for the Just). A Nothing in GHC takes zero words, as do all nullary constructors. I wrote up a summary of the GHC heap representation on Stack Overflow recently: http://stackoverflow.com/questions/3254758/memory-footprint-of-haskell-data-types/3256825#3256825 Cheers, Simon compare this to 30 or so words used in a traditional everything is on the heap and tagged model. The manual has a section describing the RTS, it doesn't describe the GC though, but talks about how I pack things in the pointers. http://repetae.net/computer/jhc/manual.html#the-run-time-system John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Odd parallel haskell observations
GHC seems to have a few bottlenecks once you start to really stress-test its I/O performance. Using a newer HEAD ghc actually gives less awful performance: sc...@cslin209 ~/test $ ghc --make -O2 -threaded -rtsopts get.hs [1 of 1] Compiling Main ( get.hs, get.o ) Linking get ... sc...@cslin209 ~/test $ ./get 1 1 1 6.25696s sc...@cslin209 ~/test $ ./get 1 1 1 5.409605s sc...@cslin209 ~/test $ ./get 2 1 2 3.827393s sc...@cslin209 ~/test $ ./get 2 1 +RTS -N2 2 4.274985s sc...@cslin209 ~/test $ ./get 3 1 3 3.692725s sc...@cslin209 ~/test $ ./get 3 1 +RTS -N2 3 4.186283s sc...@cslin209 ~/test $ ./get 3 1 +RTS -N3 3 4.303649s That it still does not speed up might be the result of Haskell's internal implementation of non-blocking I/O. If I understand the situation correctly, all events are actually passing through one OS thread (the I/O manager) right now. That would explain nicely why you can't get more than single-core performance out of your program. In case you are interested in the details, search for the new Scalable Event Handling for GHC paper by Bryan O'Sullivan and Johan Tibell. Greetings, Peter Wortmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Socket not released
Only a guess, but I predict that it will work for your purposes, since you're not concerned about what happens to std_in et al. I actually am concerned about what happens to std_in. The parent process serializes a bit of state and passes it to the child via the child's std_in. There's probably a better way to do such a thing, but it works for now. That statement in the documentation is ambiguous, so if it isn't convenient to just test for this, you need someone to clarify what doesn't work means. I will wait to test this when (and if) I have to put a node on a Windows box. Sure! At least from a POSIX perspective, and it would be surprising if a Haskell implementation failed to preserve that. If only I knew for sure that all nodes would remain in the POSIX world. I appreciate the help. --Jonathan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] preparing for Haskell 2011
Dear all, Although the Haskell 2010 Language Report has only been published recently, it will soon be time for the Committee to make decisions on the next version, Haskell 2011. I am aiming for the committee to make decisions around the end of Sept or beginning of October 2010. Can I therefore encourage any people who have made proposals, either informally on mailing lists, or formally in the Haskell-prime ticket system, to consider what they need to do to bring those proposals to a state where the committee can vote on them. Perhaps you have not made such a proposal yourself, but are very keen that someone else's proposal be adopted. Work with the proposer to polish it! Here is what you need to know about the proposal process: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Please note especially that the key requirement that will bring your proposal to the attention of the committee for a decision is the Report delta, which describes the changes with exact precision. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestions For An Intro To Monads Talk.
Yes I think that showing the Maybe and List implementation of monads is essential. They're practical and in a lot of ways they represent two completely different types of computation demonstrating the flexibility of the Monad abstraction. Thanks for that suggestion. -deech On Mon, Aug 9, 2010 at 4:33 AM, wren ng thornton w...@freegeek.org wrote: aditya siram wrote: Thanks all for you suggestions! Upon further reflection I realized that my audience is more pragmatic than theoretical. Instead of emphasizing how monads are constructed and the monad laws I think I want to dive right into the most common and useful monads. From my vantage point they are (in no particular order) : Reader, Writer, State, IO, ST, STM, Parsec (have I missed any?) and of course the transformer versions. I am debating whether or not to add [] to the bunch. Whether you add [] or not, you should definitely include Maybe. Maybe captures the most basic kind of fallible computation, so it shows up all over the place with pragmatic coding. Compare against null pointers, returning -1 to signal error when a positive number is the expected return, using 0 to express an infinite limit on some kind of resource, etc. Maybe does the same thing, except it does them cleanly and correctly because we express the possibility of failure in the type system instead of relying on magic values to express them. Magic values are even worse than magic numbers and other magic constants, IMO. Once you've explained Maybe, you can mention (Either a) in passing; they should figure out the generalization immediately. -- Live well, ~wren ___ 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: Haskell in Industry
Yes. I find that out of 10 people I train, only about 2 pick it up and run with it. I'm starting to believe you are either wired for functional programming, or you're not. Couldn't agree more. This is the usual conclusion I arrive at when I find myself wondering why so many very intelligent people reject FP when it's obviously (to my and my FP-wired brain) superior. --Jonathan Geddes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
Good, we need more functional programmers actually solving real problems. But please put your skills to work in an industry other than investment banking. I've received a lot mail on this comment; mostly positive. Here's one from someone who wishes to remain anonymous: First of all I would like to say that I like your work regarding e.g. Atom. Second, I would like to know what exactly is bad about a Haskell job in investment banking as a lot of good programmers work in this industry. It's disproportionate. 95% of the job offerings in functional programming are with investment firms. I believe investment banking is important, but does it really need to dominate a large percentage of the world's top tier programmers? Is computing the risk of derivative contracts more important than pursuing sustainable energy, new drug discovery, improving crop yields, etc. Some will argue investment banking enables all of these things -- and I'm sure many people in the industry go to work everyday feeling proud of their contributions. But I just think most of this talent is going in to improve the bottom line and little else. (Yes, I realize that's were the money is, and that's who's hiring. Actually I'm very glad. Investment banking is the first industry to adopt functional programming on a large scale. And others will follow.) -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
Out of 10 people trained only 2 should do programming anyway. :) On Fri, Aug 6, 2010 at 4:58 AM, Tom Hawkins tomahawk...@gmail.com wrote: Hi Eil, Have you had any trouble training people to use Haskell? Yes. I find that out of 10 people I train, only about 2 pick it up and run with it. I'm starting to believe you are either wired for functional programming, or you're not. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
But do you think there would be more Haskell jobs offered (in absolute terms), if no investment firms offered jobs? Is there some kind of quota of job offers that gets used up? There seems to be more job applicants that job offers at the moment, so I'm not sure what the problem is. On Mon, Aug 9, 2010 at 6:59 PM, Tom Hawkins tomahawk...@gmail.com wrote: It's disproportionate. 95% of the job offerings in functional programming are with investment firms. I believe investment banking is important, but does it really need to dominate a large percentage of the world's top tier programmers? Is computing the risk of derivative contracts more important than pursuing sustainable energy, new drug discovery, improving crop yields, etc. Some will argue investment banking enables all of these things -- and I'm sure many people in the industry go to work everyday feeling proud of their contributions. But I just think most of this talent is going in to improve the bottom line and little else. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Odd parallel haskell observations (some more numbers)
sacha: Hi. On Mon, 9 Aug 2010 09:44:00 +0200 JG == Jean-Marie Gaillourdet j...@gaillourdet.net wrote: JG JG I am no expert in web server tuning, but I will share my thoughts JG about your approach and expectations nevertheless. I would better think about ghc than about web server. I believe, that numbers I already provided (especially their deviation) illustrate that sometimes ghc runtime perform quite bad. I also found out that it can do better than it does by default, I can accept that runtime might be not capable to adjust itself to any taks the best way, but then it will be nice to know, for instance, why for such I/O that GC settings change performance in times. I'd consider boiling this down into a small test case and asking Simon Marlow -- runtime hacker uber-guru -- to help. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
On Mon, Aug 9, 2010 at 12:06 PM, Lennart Augustsson lenn...@augustsson.net wrote: But do you think there would be more Haskell jobs offered (in absolute terms), if no investment firms offered jobs? Is there some kind of quota of job offers that gets used up? No and no. Again, I think it's awesome an industry as finally woken up. I just wish the others would get with the program. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell in Industry
Yes. I find that out of 10 people I train, only about 2 pick it up and run with it. I'm starting to believe you are either wired for functional programming, or you're not. I disagree that only certain brains are wired for FP. I think your experience can be explained by people's inability to change in general. I guess a good counter argument would be if the people who didn't take to FP were able to pick up imperative programming easily. That said it's great that you were able sell Haskell to your company and follow through by actually delivering. It's really nice that the Haskell community has these success stories. -deech ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: jhc 0.7.4
I think the default locale of the terminal app on snow leopard is utf-8.
I can also report that I have no problem compiling the tar version of
jhc 0.7.4 on snow leopard 10.6.4 using ghc 6.12.1, need to install the
editline package though.
On Sun, Jul 11, 2010 at 5:33 AM, John Meacham j...@repetae.net wrote:
On Sat, Jul 10, 2010 at 04:01:53PM -0500, Antoine Latter wrote:
* running DrIFT on src/E/TypeCheck.hs fails with an illegal
bytesequence in hGetContents. I'm guessing that this is only an issue
when building DrIFT with GHC 6.12+, and that the file contains bytes
illegal in UTF8. I deleted everything funny looking in the file and
then it went smooth
Hi, are you compiling from the tarball or the darcs repository? the
tarball shouldn't require DrIFT to be installed. I had not tested DrIFT
with 6.12 but that file should be in UTF8. Hmm... on OSX, is the default
locale a UTF8 one? does ghc 6.12 properly encode to/from utf8 on it by
defualt? could you check, I don't have a mac handy.
* The way you use sed doesn't work with the BSD sed that ships with my
Mac Book. Installing GNU sed and using it works. Similarly, BSD find
doesn't know about '-name', so make hl-clean results in sadness.
Hmm.. yeah, this has been reported before, but I was unable to reproduce
the problem. But I may have accidentally been using a GNU sed, my mac at
the time was highly gnu-ized. Could you send me a version that works.
* jhci works great, but jhc crashes when I try to compile something:
jhc test1.hs
jhc 0.7.4 (tokfekyuvi-27)
Finding Dependencies...
Using Ho Cache: '/Users/alatter/.jhc/cache'
Main [test1.hs]
Typechecking...
[1 of 1] Main (.)
test1.hs:9 - Warning: defaulting: t93 = Jhc.Basics.Integer
Compiling...
[1 of 1] Main
..
Collected Compilation...
-- typeAnalyzeMethods
-- BoxifyProgram
-- Boxy WorkWrap
-- LambdaLift
E
jhc: stdout: hPutChar: invalid argument (Illegal byte sequence)
Again, this seems like the handle is in UTF8 mode and we're trying to
output something non-UTF8.
Hmm.. clearly something about the locale is wrong... It is outputing a
unicode character there, but it shoudl translate adn display to utf8
just fine. perhaps ghc is not actually opening utf8 handles on your
platform...
* cabal install has a --jhc flag, but it doesn't seem to work:
cabal install byteorder --jhc
Resolving dependencies...
cabal: internal error: impossible
I have jhc installed in a non-standard location (under ${HOME}/usr) so
I may need to have some environment variables set up. This is wil
Cabal 1.8.0.4 and cabal-install 0.8.2
The cabal support for jhc never worked actually, it wasn't written by
me. There really isn't any easy way to integrate cabal with jhc right
now, and even if there was, all of hackage has ghc specific
dependencies. No doubt the solution to this problem will be involved, I
have conciously decided to not think about the issue until I have full
haskell 2010 support down pat. That will be more useful for writing
portable programs in the short run.
Keep up the good work!
I have an implementation for STRefs I threw together this afternoon
for jhc if you're interested. I can't test it properly, though, with
the compiler crash above.
Try without the '-v' flag, it shouldn't try printing the non ascii
character then. or modify src/Stats.hs and replacet all the C.char
constants with ascii equivalants. If there is a good way to test whether
the terminal supports non-ascii characters, that would be good to put a
test in jhc for.
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
--
jinjing
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Chez What
Haskell CURRY? Curried potatoes? The lambda calculus? Historical actuality? SI! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Chez What
On Mon, Aug 9, 2010 at 11:47 AM, Jeff Rubard jeffrub...@gmail.com wrote: Haskell CURRY? Curried potatoes? The lambda calculus? Historical actuality? SI! lol wat ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] More Flexible Monad Transformer OR Bad Coding Style
Hi all, I was experimenting with monad transformers and realized that the stacking order of the monads can remain unknown until it is used. Take for example the following code: import mtl Control.Monad.State import mtl Control.Monad.Writer import mtl Control.Monad.Identity test :: (MonadWriter [Char] m, Num t, MonadState t m) = m () test = do put 1 tell hello main = do x - return $ runIdentity $ runStateT (runWriterT test) 1 -- test :: WriterT String (StateT Int Identity) y - return $ runIdentity $ runWriterT $ runStateT test 1 -- test :: StateT Int (WriterT String Identity) z - runWriterT $ runStateT test 1-- test :: StateT Int (WriterT String IO) (((), Int), String) print x print y print z *Main main (((),hello),1) (((),1),hello) (((),1),hello) Until test is called in 'main' we don't know the order of monads. In fact even the base monad is not know. All we know is that it uses the State and Writer monad. In each call to 'test' in main we can determine the stacking order and the base monad yielding different results. This seems to be a more flexible way of using monad transformers but I haven't seen this in code before so is there anything wrong with this style? -deech ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can we come out of a monad?
From: Alexey Khudyakov alexey.sklad...@gmail.com On Fri, 30 Jul 2010 09:29:59 +0200 Stefan Holdermans ste...@vectorfabrics.com wrote: No I think here we breaking out from _arbitrary_ monad. If monadic function works for every monad then it must work for identity monad too. Here is simplest form of purify function: purify2 :: (forall m . Monad m = m a) - a purify2 m = runIdentity m I wonder could this function be written without resorting to concrete monad I don't find purify2 particularly helpful because I almost never want to break out of any arbitrary monad; I want to be able to break out of a specific monad without knowing which monad it is, that is: purify3 :: Monad m = m a - a purify3 = undefined --the only possible definition... However, I just realized that something else is almost as good: evalCont :: Cont r a - r evalCont k = runCont k id As Cont is the Mother of all monads, it can be used to emulate the behavior of any other monad. If you had a library with instances of MonadReader, MonadWriter, MonadState, etc. (or operational equivalents) defined for the Cont monad, then you would have a purify function that works for all interesting monads (except IO, STM, and maybe ST), which is almost as good. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More Flexible Monad Transformer OR Bad Coding Style
Excerpts from aditya siram's message of Mon Aug 09 15:05:14 -0400 2010: Until test is called in 'main' we don't know the order of monads. In fact even the base monad is not know. All we know is that it uses the State and Writer monad. In each call to 'test' in main we can determine the stacking order and the base monad yielding different results. This seems to be a more flexible way of using monad transformers but I haven't seen this in code before so is there anything wrong with this style? There are two points here: * You have observed that running the monads in different orders results in different values: however, in the case of the examples you've chosen, the essential character of the result is still the same. This is not universally true: only some monads commute, so to speak. So you definitely do not want to leave the ordering implicit if order matters. But when the monads are commutative... * The general feeling on this issue, as I've heard from Don, is that generic types for specifying monad stacks are too fragile: due to the extra generality, it's a lot easier to write code that typechecks but doesn't do what you actually want it to. A decent compromise might be to use a concrete stack, and offer a utility function that lifts it into the generic monad typeclasses. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More Flexible Monad Transformer OR Bad Coding Style
Actually, while I haven't even used monad transformers before (just read about them a lot), I was thinking that something like this might be the way to solve the lift . lift . lift . lift . foo problem on the one hand, and by wrapping the 'contents' (e.g. the environment of a reader monad) of every level of the stack in a unique newtype (if the type isn't otherwise unique), the problem of what if I want to use the same transformer more than once, how do I disambiguate them. (Do I have roughly the right idea?) On Mon, Aug 9, 2010 at 9:05 PM, aditya siram aditya.si...@gmail.com wrote: Hi all, I was experimenting with monad transformers and realized that the stacking order of the monads can remain unknown until it is used. Take for example the following code: import mtl Control.Monad.State import mtl Control.Monad.Writer import mtl Control.Monad.Identity test :: (MonadWriter [Char] m, Num t, MonadState t m) = m () test = do put 1 tell hello main = do x - return $ runIdentity $ runStateT (runWriterT test) 1 -- test :: WriterT String (StateT Int Identity) y - return $ runIdentity $ runWriterT $ runStateT test 1 -- test :: StateT Int (WriterT String Identity) z - runWriterT $ runStateT test 1 -- test :: StateT Int (WriterT String IO) (((), Int), String) print x print y print z *Main main (((),hello),1) (((),1),hello) (((),1),hello) Until test is called in 'main' we don't know the order of monads. In fact even the base monad is not know. All we know is that it uses the State and Writer monad. In each call to 'test' in main we can determine the stacking order and the base monad yielding different results. This seems to be a more flexible way of using monad transformers but I haven't seen this in code before so is there anything wrong with this style? -deech ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More Flexible Monad Transformer OR Bad Coding Style
For monads like StateT, WriterT, ReaderT, the order doesn't matter (except perhaps for some pesky performance details). However, for monad transformers like ErrorT or ListT, the order _does_ matter. The code you have there is perfectly fine, sometimes the added generality can be quite handy (especially if you have your own MonadState'esk type classes). The two major drawbacks to this approach (that I can think of off the top of my head) are: 1) Rather large and complicated contexts on quite a few of your functions 2) Can lead to nearly indecypherable error messages Personally, I try to avoid multiparameter typeclasses whenever possible; I've found them to be more trouble than they are worth. My advice would be to leave the code general if the code actually does something general (it actually has more than one use case) and give the code a fixed signature if the code really one has just one purpose (even if ghci can infer a general type for you). This is just a personal preference, but it seems to work well for me :) - Job On Mon, Aug 9, 2010 at 3:05 PM, aditya siram aditya.si...@gmail.com wrote: Hi all, I was experimenting with monad transformers and realized that the stacking order of the monads can remain unknown until it is used. Take for example the following code: import mtl Control.Monad.State import mtl Control.Monad.Writer import mtl Control.Monad.Identity test :: (MonadWriter [Char] m, Num t, MonadState t m) = m () test = do put 1 tell hello main = do x - return $ runIdentity $ runStateT (runWriterT test) 1 -- test :: WriterT String (StateT Int Identity) y - return $ runIdentity $ runWriterT $ runStateT test 1 -- test :: StateT Int (WriterT String Identity) z - runWriterT $ runStateT test 1-- test :: StateT Int (WriterT String IO) (((), Int), String) print x print y print z *Main main (((),hello),1) (((),1),hello) (((),1),hello) Until test is called in 'main' we don't know the order of monads. In fact even the base monad is not know. All we know is that it uses the State and Writer monad. In each call to 'test' in main we can determine the stacking order and the base monad yielding different results. This seems to be a more flexible way of using monad transformers but I haven't seen this in code before so is there anything wrong with this style? -deech ___ 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] More Flexible Monad Transformer OR Bad Coding Style
Excerpts from Gábor Lehel's message of Mon Aug 09 15:39:49 -0400 2010: Actually, while I haven't even used monad transformers before (just read about them a lot), I was thinking that something like this might be the way to solve the lift . lift . lift . lift . foo problem on the one hand, and by wrapping the 'contents' (e.g. the environment of a reader monad) of every level of the stack in a unique newtype (if the type isn't otherwise unique), the problem of what if I want to use the same transformer more than once, how do I disambiguate them. (Do I have roughly the right idea?) In fact, what you describe is already in use by current monad transformer libraries. :-) Take for example StateT in mtl [1]: MonadWriter w m = MonadWriter w (StateT s m) MonadError e m = MonadError e (StateT s m) Monad m = MonadState s (StateT s m) MonadReader r m = MonadReader r (StateT s m) MonadTrans (StateT s) Monad m = Monad (StateT s m) Monad m = Functor (StateT s m) MonadFix m = MonadFix (StateT s m) MonadPlus m = MonadPlus (StateT s m) MonadIO m = MonadIO (StateT s m) MonadCont m = MonadCont (StateT s m) By default, it comes with all of these instances, so that if you use a function that relies on say MonadReader and not Reader, no lifting is necessary. However, newtyping every reader monad because you want to use multiple copies of them isn't as good, because you still have to manually add all of these instances. Cheers, Edward [1] http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/html/Control-Monad-State-Lazy.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can we come out of a monad?
On Monday 09 August 2010 21:19:01, John Lato wrote: I don't find purify2 particularly helpful because I almost never want to break out of any arbitrary monad; I want to be able to break out of a specific monad without knowing which monad it is, that is: purify3 :: Monad m = m a - a purify3 = undefined --the only possible definition... Just to be obnoxious: purify3 = const undefined ;) However, I just realized that something else is almost as good: evalCont :: Cont r a - r evalCont k = runCont k id Wouldn't you want the signature Cont r a - a to break out? Also: ContBreak.hs:6:23: Couldn't match expected type `r' against inferred type `a' `r' is a rigid type variable bound by the type signature for `evalCont' at ContBreak.hs:5:17 `a' is a rigid type variable bound by the type signature for `evalCont' at ContBreak.hs:5:19 In the second argument of `runCont', namely `id' In the expression: runCont k id In the definition of `evalCont': evalCont k = runCont k id evalCont :: (forall r. Cont r a) - a evalCont k = runCont k id would work (but is something different). As Cont is the Mother of all monads, it can be used to emulate the behavior of any other monad. If you had a library with instances of MonadReader, MonadWriter, MonadState, etc. (or operational equivalents) defined for the Cont monad, then you would have a purify function that works for all interesting monads (except IO, STM, and maybe ST), which is almost as good. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Some Haskell mode extensions
Hi there, I've written some very simple Emacs modules for making using Haskell in Emacs a little bit nicer: http://github.com/chrisdone/haskell-mode-exts You can download the project with git, or pick and choose individual files: http://github.com/chrisdone/haskell-mode-exts/raw/master/haskell-navigate-modules.el http://github.com/chrisdone/haskell-mode-exts/raw/master/haskell-align-imports.el http://github.com/chrisdone/haskell-mode-exts/raw/master/haskell-sort-imports.el http://github.com/chrisdone/haskell-mode-exts/raw/master/haskell-installed-packages.el More documentation about installed module completion here, I need to do another module for syntax-aware import editing, but this module is already quite usable: http://www.chrisdone.com/posts/2010-08-07-emacs-haskell-installed-packages.html I have a few more in the works and more planned, e.g. (some of which may already have been implemented somewhere, but): 1) syntax aware import line editing (think: tabbing between sections, toggling qualified on/off, etc.) 2) controlling cabal through inferior-haskell-mode (already done this, but I need to make it portable) 3) tidying up of inferior-haskell (it wastes a lot of space) 4) more interactiveness with inferior-haskell e.g. you need -XExtension should really just prompt me whether I want to add it to the file or enable it in ghci, and then do it. (When you're in the middle of working, adding extensions to the top of the file is laborious.) 5) automatic integration with etags and some improvement to its little issues 6) a high-level .cabal file editing mode 7) unit testing integration And so on. There's loads that can be done. I'm just implementing the stuff I want, and if some of it's useful in general, maybe it can be absorbed into the general haskell-mode distrib. The haskell-emacs mailing list is down at the moment, so I thought I'd post here. Cheers! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More Flexible Monad Transformer OR Bad Coding Style
2010/8/9 Edward Z. Yang ezy...@mit.edu: Excerpts from Gábor Lehel's message of Mon Aug 09 15:39:49 -0400 2010: Actually, while I haven't even used monad transformers before (just read about them a lot), I was thinking that something like this might be the way to solve the lift . lift . lift . lift . foo problem on the one hand, and by wrapping the 'contents' (e.g. the environment of a reader monad) of every level of the stack in a unique newtype (if the type isn't otherwise unique), the problem of what if I want to use the same transformer more than once, how do I disambiguate them. (Do I have roughly the right idea?) In fact, what you describe is already in use by current monad transformer libraries. :-) Take for example StateT in mtl [1]: MonadWriter w m = MonadWriter w (StateT s m) MonadError e m = MonadError e (StateT s m) Monad m = MonadState s (StateT s m) MonadReader r m = MonadReader r (StateT s m) MonadTrans (StateT s) Monad m = Monad (StateT s m) Monad m = Functor (StateT s m) MonadFix m = MonadFix (StateT s m) MonadPlus m = MonadPlus (StateT s m) MonadIO m = MonadIO (StateT s m) MonadCont m = MonadCont (StateT s m) By default, it comes with all of these instances, so that if you use a function that relies on say MonadReader and not Reader, no lifting is necessary. However, newtyping every reader monad because you want to use multiple copies of them isn't as good, because you still have to manually add all of these instances. What I meant was to make certain that the 'r' in `ReaderT r m a`, say, is a unique type in every case, so that when you write `foo :: MonadReader SomethingOrOther m = m a - m a` (for example), it's always unambiguous which MonadReader in the stack you might've meant. (If it's not... would you get an overlapping instances error, or what?) Cheers, Edward [1] http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/html/Control-Monad-State-Lazy.html -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More Flexible Monad Transformer OR Bad Coding Style
I've never used this myself, but the package mtlx seems to offer one possible solution to this problem by tagging the monad transformers with index types: http://hackage.haskell.org/package/mtlx Cheers, Greg On 08/09/10 12:39, Gábor Lehel wrote: Actually, while I haven't even used monad transformers before (just read about them a lot), I was thinking that something like this might be the way to solve the lift . lift . lift . lift . foo problem on the one hand, and by wrapping the 'contents' (e.g. the environment of a reader monad) of every level of the stack in a unique newtype (if the type isn't otherwise unique), the problem of what if I want to use the same transformer more than once, how do I disambiguate them. (Do I have roughly the right idea?) On Mon, Aug 9, 2010 at 9:05 PM, aditya siram aditya.si...@gmail.com wrote: Hi all, I was experimenting with monad transformers and realized that the stacking order of the monads can remain unknown until it is used. Take for example the following code: import mtl Control.Monad.State import mtl Control.Monad.Writer import mtl Control.Monad.Identity test :: (MonadWriter [Char] m, Num t, MonadState t m) = m () test = do put 1 tell hello main = do x - return $ runIdentity $ runStateT (runWriterT test) 1 -- test :: WriterT String (StateT Int Identity) y - return $ runIdentity $ runWriterT $ runStateT test 1 -- test :: StateT Int (WriterT String Identity) z - runWriterT $ runStateT test 1-- test :: StateT Int (WriterT String IO) (((), Int), String) print x print y print z *Main main (((),hello),1) (((),1),hello) (((),1),hello) Until test is called in 'main' we don't know the order of monads. In fact even the base monad is not know. All we know is that it uses the State and Writer monad. In each call to 'test' in main we can determine the stacking order and the base monad yielding different results. This seems to be a more flexible way of using monad transformers but I haven't seen this in code before so is there anything wrong with this style? -deech ___ 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] More Flexible Monad Transformer OR Bad Coding Style
On Mon, Aug 9, 2010 at 3:42 PM, Job Vranish job.vran...@gmail.com wrote: For monads like StateT, WriterT, ReaderT, the order doesn't matter (except perhaps for some pesky performance details). However, for monad transformers like ErrorT or ListT, the order _does_ matter. Is it really correct to say that order doesn't matter for the transformers you mention? More precise would be to say that order doesn't matter when two or more of those are stacked *consecutively*. Unless a function is completely independent of what other functions do with the state values, it can matter a great deal what order two State transformers occur in if there happens to be a ContT sandwiched between them. Furthermore, MonadState doesn't even promise that much; an arbitrary transformer that provides state operations may not commute generally with a StateT. Imagine, for instance, a state transformer augmented with error checking and transactions, that rolls back to a checkpoint if something 'put's an invalid state value. A polymorphic function with multiple monad typeclasses is thus effectively asserting that it does something sensible and well-defined for any set of transformers providing those classes, for any ordering of those transformers in the stack, and with any other possible transformers inside, outside, or amidst them. Combinatorics are not your friend here. Monad transformer polymorphism leads all too easily into a pit of despair. Don't go there unwisely. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] zip-archive performance/memmory usage
Hello, I'm trying some haskell scripting. I'm writing a script to print some information from a zip archive. The zip-archive library does look nice but the performance of zip-archive/lazy bytestring doesn't seem to scale. Executing : eRelativePath $ head $ zEntries archive on an archive of around 12 MB with around 20 files yields Stack space overflow: current size 8388608 bytes. The script in question can be found at : http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs I'm using the latest version of haskell platform. Are these libaries not production ready, or am I doing something terribly wrong ? kind regards, Pieter -- Pieter Laeremans pie...@laeremans.org The future is here. It's just not evenly distributed yet. W. Gibson ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] zip-archive performance/memmory usage
On 10 August 2010 09:29, Pieter Laeremans pie...@laeremans.org wrote: Hello, I'm trying some haskell scripting. I'm writing a script to print some information from a zip archive. The zip-archive library does look nice but the performance of zip-archive/lazy bytestring doesn't seem to scale. Executing : eRelativePath $ head $ zEntries archive on an archive of around 12 MB with around 20 files yields Stack space overflow: current size 8388608 bytes. The script in question can be found at : http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs I'm using the latest version of haskell platform. Are these libaries not production ready, or am I doing something terribly wrong ? I'm not familiar with the library, but I have a sneaking suspicion that you're doing something terribly wrong, namely keeping the entire archive in memory rather than using it lazily. -- 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] Can we come out of a monad?
On Mon, Aug 9, 2010 at 1:19 PM, John Lato jwl...@gmail.com wrote: I don't find purify2 particularly helpful because I almost never want to break out of any arbitrary monad; I want to be able to break out of a specific monad without knowing which monad it is, that is: purify3 :: Monad m = m a - a purify3 = undefined --the only possible definition... However, I just realized that something else is almost as good: evalCont :: Cont r a - r evalCont k = runCont k id Except, of course, you want the signature evalCont :: Cont r a - a Which is not possible. But I am not sure where all this discussion is coming from, Maybe and (r -) cannot be broken out of. Isn't that example enough? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can we come out of a monad?
Excerpts from Luke Palmer's message of Tue Aug 10 01:04:04 -0400 2010: Except, of course, you want the signature evalCont :: Cont r a - a Which is not possible. But I am not sure where all this discussion is coming from, Maybe and (r -) cannot be broken out of. Isn't that example enough? I'm confused... that's the type of evalCont, no? Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [ANNOUNCE] (and request for review): directory-tree v0.9.0
Greetings Haskellers! directory-tree is a module providing a directory-tree-like datatype along with Foldable and Traversable instances, along with a simple, high-level IO interface. You can see the package along with some examples here (apologies if the haddock docs haven't been generated yet) : http://hackage.haskell.org/package/directory-tree This primary change in this release is the addition of two experimental lazy functions: `readDirectoryWithL` and `buildL`. These functions use `unsafePerformIO` behind the scenes to traverse the filesystem as required by pure computations consuming the returned DirTree data structure. I believe I am doing this safely and sanely but would love if some more experienced folks could comment on the code. These changes (and this whole revamping of this originally very simple module) were inspired by the fact that a few people seemed to really like this API, and this recent reddit post lamenting the perceived difficulty of writing a `du`-like function in haskell. http://www.reddit.com/r/haskell/comments/cs54i/how_would_you_write_du_in_haskell/ One could write such a function using directory-tree as follows (sorry if the monadic compositional style is foreign): import System.Directory.Tree import qualified Data.Foldable as F import System.IO import Control.Monad du :: FileName - IO () du = print . F.sum . free = readDirectoryWithL (hFileSize = readHs) where readHs = flip openFile ReadMode Thanks for reading and for any input, especially performance suggestions or opinions on my unsafe function usage. I hope this is useful to someone. SIncerely, Brandon Simmons http://coder.bsimmons.name/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
