Re: [Haskell-cafe] Re: Hugs on iPhone
Rick R wrote: The agreement doesn't specifically prohibit the use of interpreters (just those than run external code). It also doesn't say anything about machine generated code. The only thing one would have to ensure is that the dependencies of JHC are all compiled in, or statically linked. Shared libs are disallowed in any app. If it has a runtime dependency on gcc (is there such a thing?) Then you would have to statically link it and therefore couldn't sell your application. (gotta love GPL) Not true. GPL doesn't forbid selling and never has. RMS used to make money selling emacs tapes. All it requires is that you accompany your sale either with a copy of the source code, or a promise to make source available. Posting the source on a public web site would meet this requirement. Does anything in the iPhone SDK forbid you from posting your source? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Don't forget to vote!
In less than 4 hours the Haskell Logo poll will be closed. If you're not one of the 423 people that voted so far, please take 1-20 minutes (depending on your level of perfectionism) to support your favorite logo(s) :) -- Regards, Eelco Lempsink PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Making videos of your project
Hey guys, I've been making quick youtube videos of projects to convey what they do. Here, for example, using Tim Docker's Charts library in ghci: http://www.youtube.com/watch?v=2Lqzygxvus0 (Click on the HD button for higher res). Or one of Neil Brown's SG OpenGL graphics library, http://www.youtube.com/watch?v=tJ6AtfcorkY You can create your own really simply: 1. install 'recordmydesktop' I use: recordmydesktop --no-sound --v_bitrate 200 2. type 'recordmydesktop' 3. do something with haskell 4. hit control-C 5. upload out.ogv to youtube If you're a library author of one of the 2 or 3D packages, please consider video along with other why I want to use this material. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Are there performant mutable Arrays in Haskell?
Thx for your hints, I played around with them and the performance gets slightly better. But the major boost is still missing :) I noticed, that one real bottleneck seems to be the conversion of the array back into a list. The interesting part is, if I use the elems function (Data.Array.Base) the performance is about 4x better then with my own function. So I thought, I write my own version of elems, (that just converts a part of the array to a list) and I fall back into the same performance as my first approach. To make a long story short, here is the library code: elems arr = case bounds arr of (_l, _u) - [unsafeAt arr i | i - [0 .. numElements arr - 1] And my version: boundedElems arr = case bounds arr of (_l, _u) - [unsafeAt arr i | i - [1737 .. 1752]] Is there a reason, why the library version is 4 times faster, than mine? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Learning Haskell
Tom.Amundsen tomamund...@gmail.com writes: How long did it take you to become proficient in Haskell? Something more than twenty years. By that, I mean - how long until you were just as comfortable with Haskell as you were with your strongest language at that time? Oh, Haskell was my strongest language during all that time! ;-) If I have a serious point, it's that going from writing imperative programmes to writing properly functional ones takes a lot longer than it takes to learn every facet of the language. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Learning Haskell
må. den 23.03.2009 klokka 20:08 (-0700) skreiv Tom.Amundsen: How long did it take you to become proficient in Haskell? By that, I mean - how long until you were just as comfortable with Haskell as you were with your strongest language at that time? It's been nine months since I first started learning, but for about five months in the middle I didn't do any Haskell hacking (or much hacking at all). Measuring completeness of knowledge, Haskell still ranks below Python and Java, but measuring ability to solve a given problem Haskell comes out on top. Of course, I've only been programming for two years total... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Learning Haskell
Tom.Amundsen tomamund...@gmail.com writes: How long did it take you to become proficient in Haskell? Ten years and still working on it. By that, I mean - how long until you were just as comfortable with Haskell as you were with your strongest language at that time? Hm, I'm tempted to rephrase that question as how long before I'd forgotten enough C++... Seriously, learning to think functionally wasn't so hard, and I was relatively quickly able to write useful programs. The challenge with Haskell is that it is very open-ended, there are so many constructs and paradigms that you feel you should learn, but which require a lot of effort first to understand, and even more so to internalize into your programming-fu. When I left C++, the debates were mostly around diagrams and what shape boxes and arrows representing different concepts should have. Now its all comonads and endofunctors and hylomorphisms. (Thankfully, it's possible to ignore topics in any language :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The votes are in!
The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/ results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
Is this the part where all the pundits come out and talk about how Jeff isn't a citizen, eats babies, and wants to turn Haskell into an imperative language? /jve 2009/3/24 Eelco Lempsink ee...@lempsink.nl The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/http://www.cs.cornell.edu/w8/%7Eandru/cgi-perl/civs/ results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ 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] The votes are in!
Ooh, let me pop some popcorn! 2009/3/24 John Van Enk vane...@gmail.com Is this the part where all the pundits come out and talk about how Jeff isn't a citizen, eats babies, and wants to turn Haskell into an imperative language? /jve 2009/3/24 Eelco Lempsink ee...@lempsink.nl The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/http://www.cs.cornell.edu/w8/%7Eandru/cgi-perl/civs/ results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ 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] The votes are in!
2009/3/24 John Van Enk vane...@gmail.com: Is this the part where all the pundits come out and talk about how Jeff isn't a citizen, eats babies, and wants to turn Haskell into an imperative language? Well given the fact that Haskell has been called the world's best imperative language, that we have a multinational community, and that baby eating is an acceptable part of Haskell optimization* I think he'll fit in just fine. * Don Stewart might have a blog post about this, but I'm too lazy to look it up. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [ANN] Safe Lazy IO in Haskell
Excerpts from Wei Hu's message of Mon Mar 23 17:37:15 +0100 2009: Nicolas Pouillard nicolas.pouillard at gmail.com writes: Hi folks, We have good news (nevertheless we hope) for all the lazy guys standing there. Since their birth, lazy IOs have been a great way to modularly leverage all the good things we have with *pure*, *lazy*, *Haskell* functions to the real world of files. We are happy to present the safe-lazy-io package [1] that does exactly this and is going to be explained and motivated in the rest of this post. Hi, Hi, Please let me know if I understood your code correctly. So, the SIO module is used only to ensure that the file processing is finished before the finalizer closes the file, right? In System.IO.Lazy.Input, run is defined as run :: NFData sa = LI sa - IO sa run = run' . fmap return' Can I change it to run = run' . fmap return ? Yes I think the semantics is the same because run' will strictly force the processing anyway? Exactly I've pushed the change to the repository [1] Thanks for spotting this! [1]: http://patch-tag.com/publicrepos/safe-lazy-io -- Nicolas Pouillard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Are there performant mutable Arrays in Haskell?
Brettschneider, Matthias brettschnei...@hs-albsig.de wrote: Thx for your hints, I played around with them and the performance gets slightly better. But the major boost is still missing :) I noticed, that one real bottleneck seems to be the conversion of the array back into a list. The interesting part is, if I use the elems function (Data.Array.Base) the performance is about 4x better then with my own function. So I thought, I write my own version of elems, (that just converts a part of the array to a list) and I fall back into the same performance as my first approach. To make a long story short, here is the library code: elems arr = case bounds arr of (_l, _u) - [unsafeAt arr i | i - [0 .. numElements arr - 1] And my version: boundedElems arr = case bounds arr of (_l, _u) - [unsafeAt arr i | i - [1737 .. 1752]] Is there a reason, why the library version is 4 times faster, than mine? Uhhhmmm... I've got no idea. But as the list is constructed lazily, you shouldn't expect a real speedup by being lazy manually, anyway. You might want to try the stream-fusion list implementation of lists, or get rid of lists, alltogether. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs on iPhone
Go ahead sell your GPL application. I'll get your code, build the application, and sell it for less than half of what you're selling it for. How exactly will you make your money, then? When people say, You can't make commercial software with GPL code, they don't mean it's not legally possible to sell GPL code, only that it's not commercially viable. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 24, 2009, at 1:27 AM, Jules Bean wrote: Rick R wrote: The agreement doesn't specifically prohibit the use of interpreters (just those than run external code). It also doesn't say anything about machine generated code. The only thing one would have to ensure is that the dependencies of JHC are all compiled in, or statically linked. Shared libs are disallowed in any app. If it has a runtime dependency on gcc (is there such a thing?) Then you would have to statically link it and therefore couldn't sell your application. (gotta love GPL) Not true. GPL doesn't forbid selling and never has. RMS used to make money selling emacs tapes. All it requires is that you accompany your sale either with a copy of the source code, or a promise to make source available. Posting the source on a public web site would meet this requirement. Does anything in the iPhone SDK forbid you from posting your source? ___ 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: Hugs on iPhone
John A. De Goes wrote: Go ahead sell your GPL application. I'll get your code, build the application, and sell it for less than half of what you're selling it for. How exactly will you make your money, then? Ask RedHat how they make money from RHEL while Oracle and CentOS are exact copies of it. Ask RedHat/JBoss how they make money from JBoss AS when all the source code is available in their repository. Probably, it's not only about the software anymore, but also about the service you get with the software subscription... Although I agree that this applies only to software which crossed some kind of complexity already (hence service is needed) and that majority of phone apps might not fall into this category yet especially if they are not tied to some kind of server based services. Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hugs on iPhone
John A. De Goes j...@n-brain.net wrote: Go ahead sell your GPL application. I'll get your code, build the application, and sell it for less than half of what you're selling it for. I don't think you can go below 0.79 in the Apple store, and I guess you'll have a hard time convincing Apple to list your identical program alongside with the original version. How exactly will you make your money, then? Selling tapes, not software. Unless you invent something like the internet that gets rid of time needed write tapes and packageshipment costs, you're going to have a very, very hard time being cheaper than anybody else unless you live on a different continent, and an incredibly hard time financing the advertisement you need to place your product more prominently than RMS can do simply by being himself. When people say, You can't make commercial software with GPL code, they don't mean it's not legally possible to sell GPL code, only that it's not commercially viable. Oh, it is. Id is still selling Quake I data files, and you'll be surprised how much you're allowed to do since the GPL isn't the Affero GPL. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help on using System.Win32.Com.Automation
Thank you Sigbjorn. The generated WMI module had the information I
was looking for.
I wasn't able to find the ihc. Would an old hdirect package work? I
just needed to map a handful of functions so I did it by hand.
For posterity, here are the mappings I've needed so far:
createConnection :: String - IO (IDispatch a)
createConnection dsn = do
c - createObject ADODB.Connection
openConnection dsn c
return c
openConnection :: String - IDispatch a - IO ()
openConnection dsn = method0 Open [inString dsn]
closeConnection :: IDispatch a - IO ()
closeConnection = method0 Close []
execute :: IDispatch i - String - IO (IDispatch a)
execute connection sqlStatement =
function_1_1 Execute sqlStatement connection
eof :: IDispatch i - IO Bool
eof = propertyGet_0 EOF
fields :: IDispatch i - IO (IDispatch a)
fields = propertyGet_0 Fields
count :: IDispatch i - IO Int
count = propertyGet_0 Count
moveFirst :: IDispatch i - IO ()
moveFirst = method_0_0 MoveFirst
moveNext :: IDispatch i - IO ()
moveNext = method_0_0 MoveNext
item :: IDispatch i - Int - IO String
item rs key = fields rs = function1 Item [inInt key] outString
On Mon, Mar 23, 2009 at 1:11 AM, Sigbjorn Finne
sigbjorn.fi...@gmail.com wrote:
Hi Wilkes,
you may want to have a look at a simple example of how to
interop with Windows WMI using the COM package at --
http://haskell.forkio.com/com-examples
Hope it is of some help to you.
--sigbjorn
On 3/19/2009 16:49, Wilkes Joiner wrote:
I'm playing around with the com package, but I'm having a hard time
understanding how to map a COM call to the appropriate methodN or
functionN call. Does anyone have any example code that uses the
method1 or higher. Any help or pointers would be appreciated.
Here's the code I have so far:
import System.Win32.Com
import System.Win32.Com.Automation
dsn = Provider=vfpoledb.1;Data Source=C:\\SomeDirectory\\
main = coInitialize
openConnection = \con -
closeConnection con
openDSN :: String - IDispatch a - IO ()
openDSN dsn con = method0 Open [inString dsn] con
openConnection :: IO (IDispatch a)
openConnection = createObject ADODB.Connection = \con - openDSN
dsn con return con
closeConnection :: IDispatch a - IO ()
closeConnection = method0 Close []
{-
Wraps ADO Connection.Execute
http://msdn.microsoft.com/en-us/library/ms675023(VS.85).aspx
Set recordset = connection.Execute (CommandText, RecordsAffected, Options)
execute :: String - IDispatch a - IO a
execute cmd con = method1 Execute [inString cmd] (inEmpty,resWord64) con
-}
Thank You,
Wilkes
___
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: Hugs on iPhone
Like I said, go ahead and try that with an iPhone application. If the iPhone app is so buggy or complicated so as to require support, no one will buy it. If it's not, I'll make all the money by selling it for half the price you sell it for. In any case, the examples you mention involve companies selling the labors of others. Joe Schmoe who contributed patch #2345235 to fix a critical bug never sees a cent from RedHat. So your examples don't support your case as much as you seem to think. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 24, 2009, at 6:58 AM, Karel Gardas wrote: John A. De Goes wrote: Go ahead sell your GPL application. I'll get your code, build the application, and sell it for less than half of what you're selling it for. How exactly will you make your money, then? Ask RedHat how they make money from RHEL while Oracle and CentOS are exact copies of it. Ask RedHat/JBoss how they make money from JBoss AS when all the source code is available in their repository. Probably, it's not only about the software anymore, but also about the service you get with the software subscription... Although I agree that this applies only to software which crossed some kind of complexity already (hence service is needed) and that majority of phone apps might not fall into this category yet especially if they are not tied to some kind of server based services. Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
Well done! Although I am quite happy with the result, this was definitely my favorite, this logo is not really 'finished'. Is there going to be some kind of second round in which we can vote for/suggest variations of this logo? With different texts/fonts/colors/ etc? Gr, Sebastiaan On Mar 24, 2009, at 1:20 PM, Eelco Lempsink wrote: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/ civs/results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs on iPhone
Again, go ahead and write your GPL app -- i.e. put your money where your mouth is. After you spend a year developing some cool app, I'll take your code and sell it -- maybe under a different name, with different screenshots, and a different description. Or maybe I'll just list it in the free section so no one makes any money. You can't make money selling tapes of iPhone apps because no one wants tapes and iPhone apps come exclusively from the iPhone store (unless you're an iPhone developer). You simply can't make a living selling GPL software. If the software's complicated enough and you know your way around it, then you can sell support maintenance. However, those conditions doesn't apply to consumer software, because consumers don't want complicated software. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Mar 24, 2009, at 7:00 AM, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: Go ahead sell your GPL application. I'll get your code, build the application, and sell it for less than half of what you're selling it for. I don't think you can go below 0.79 in the Apple store, and I guess you'll have a hard time convincing Apple to list your identical program alongside with the original version. How exactly will you make your money, then? Selling tapes, not software. Unless you invent something like the internet that gets rid of time needed write tapes and packageshipment costs, you're going to have a very, very hard time being cheaper than anybody else unless you live on a different continent, and an incredibly hard time financing the advertisement you need to place your product more prominently than RMS can do simply by being himself. When people say, You can't make commercial software with GPL code, they don't mean it's not legally possible to sell GPL code, only that it's not commercially viable. Oh, it is. Id is still selling Quake I data files, and you'll be surprised how much you're allowed to do since the GPL isn't the Affero GPL. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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] The votes are in!
On 24 mrt 2009, at 13:20, Eelco Lempsink wrote: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/ civs/results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! And, also congratulations to Darrin Thompson! He's the one that originally came up with the idea: http://www.haskell.org/pipermail/haskell-cafe/2008-December/051939.html I'll set up a page with the results visibile. The page is at http://community.haskell.org/~eelco/results.html (I hope the community server will survive, I expect so since the images are hosted at the main Haskell server.) The next step is to decide what the next steps are ;) We could have polls all year deciding by committee on every little detail, but that will most likely not only kill all creativity, but also the willingness to vote. In my mind, the competition was mainly about deciding for a new emblem to be featured on Haskell.org and to be used on t-shirts and websites as people please. The font to be used to write 'Haskell', a slogan, etc, are probably not issues that need to be decided on and would only make the whole process a lot more complex. Given the winner, the possible variations are limited to color (oh, boy), coloring (lambda accented, bind accented or all the same) and possible font-like things such as the line shapes (much like George Pollard did with his variant, entry #50, placed 9th). My preference would be to have one person with sense of (and education in, if possible) design make some nice looking variations and have a second (final) round of voting, but, we could also do the wiki-thing again ;) -- Regards, Eelco Lempsink PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs on iPhone
John A. De Goes j...@n-brain.net writes: In any case, the examples you mention involve companies selling the labors of others. ...like the original poster wanted to, by linking to GCC and sell it as part of his proprietary product? The difference is that Red Hat et al benefit from the labor of others in a way intended and explicitly allowed by the authors. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hugs on iPhone
John A. De Goes j...@n-brain.net wrote: You simply can't make a living selling GPL software. If the software's complicated enough and you know your way around it, then you can sell support maintenance. However, those conditions doesn't apply to consumer software, because consumers don't want complicated software. Sure, times have changed. Still, go to a campus, figure out who doesn't have internet access (personally, back then I bought a 100mb zip drive to get my software). You might not be able to earn a living burning Debian CD's, but you're going able to finance your beer consumption. Not only because you're bound to get some free beer while helping people to install it. OTOH, magazines still come with CDs or DVDs, which means that there's a demand for hard-copies of software. People _will_ buy your 1000 best open source games collection. The costs of setting up distribution and manufacturing will prevent others from doing the same: They'd rather distribute other OSS software, avoiding competition that's only going to lessen their own profits. Additionally to the physical medium, you're providing the service of compiling the compilation, in the first place: I can tell you it's a bugger to rummage through OSS games to find out what's cool. Surely, it's not a big market and won't make you a millionaire, but no source of income can be used by everyone without breaking down. Just to make things clear: I wouldn't hand out venture capital to such an endeavour, either. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Equations for `foo' have different numbers of arguments
Hi. There is a limitation, in Haskell, that I'm not sure to understand. Here is an example: module Main where divide :: Float - Float - Float divide _ 0 = error division by 0 divide = (/) main = do print $ divide 1.0 0.0 print $ divide 4.0 2.0 With GHC I get: Equations for `divide' have different numbers of arguments With HUGS: Equations give different arities for divide However the two equations really have the same number of arguments. What's the problem? Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: The votes are in!
Eelco Lempsink ee...@lempsink.nl wrote: My preference would be to have one person with sense of (and education in, if possible) design make some nice looking variations and have a second (final) round of voting, but, we could also do the wiki-thing again ;) That was the plan, yes. This time 'round, we should nitpick about half-a-point-off layouts, as well as require sanely-written svg's or even metapost, so we have clearly defined proportions of linewith vs. gapwidth and so on. I'm not sure whether it's good to deal with layout and colour in one voting, the bickering about the last vote suggests it's better to do multiple votes with a smaller quantity of options. I'd say the next round is about triples of monochrome a) logo appearance, b) logo with Haskell c) logo with Haskell and slogan. ...the problem being, we don't have an official slogan, yet. Maybe there shouldn't be one and the candidates should just give example layouts for a short, medium and long slogan. Colour can be dealt with later, and t-shirt manufacturers can already now begin to print variations that don't qualify for letter-heads, like lambda-bind shaped quines and stuff. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SOC idea ticket: Rendering Engine
I tried it and it goes out of memory. The log attached. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain Script started on Tue Mar 24 16:50:41 2009 [materials,.,..,.svn,car,packs,models] [texturemapping.vert,toonf2.frag,.,..,.svn,Example_CelShading.vert,texturemapping.frag,Example_CelShading.frag,toonf2.vert,ambient.vert,ambient.frag,diffuse.vert,diffuse.frag] [.,Robot.material,..,.svn,RZR-002.material,Ogre.material,Scene.material,todo,jaiqua.material,ogrehead.material] load: Robot.material load: RZR-002.material load: Ogre.material load: Scene.material load: jaiqua.material load: ogrehead.material [.,blue_jaiqua.jpg,..,cel_shading_edge.png,.svn,cel_shading_specular.png,r2skin.jpg,GreenSkin.jpg,WeirdEye.png,cel_shading_diffuse.png,spheremap.png,dirt01.jpg,RZR-002.png] [.,..,.svn,robot.skeleton.xml,athene.mesh.xml,ninja.mesh.xml,RZR-002.mesh.xml,Cube.mesh.xml,robot.mesh.xml,facial.mesh.xml,jaiqua.mesh.xml,ogrehead.mesh.xml,Suzanne.mesh.xml] [chasis.jpg,.,scooby_body.material,..,.svn,chasis_a.jpg,ventanas.jpg,scooby_body.mesh.xml] load: scooby_body.material creating entity: OgreHead from mesh: ogrehead.mesh.xml parsing XML file [Ogre/Tusks,Ogre/Earring,Ogre/Skin,Ogre/Eyes] compiling material: Ogre/Eyes WeirdEye.png loaded resolution = 256 x 256, 3 bytes per pixel compiling material: Ogre/Skin GreenSkin.jpg loaded resolution = 256 x 256, 3 bytes per pixel compiling material: Ogre/Earring spheremap.png loaded resolution = 256 x 256, 3 bytes per pixel compiling material: Ogre/Tusks dirt01.jpg loaded resolution = 96 x 96, 3 bytes per pixel done creating entity: Robot from mesh: robot2.mesh.xml parsing XML file [Examples/Robot] compiling material: Examples/Robot r2skin.jpg loaded resolution = 512 x 512, 3 bytes per pixel Compiling program: (Just Examples/AmbientShadingVP,Just Examples/AmbientShadingFP) Mesa 7.0.3 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org Mesa 7.0.3 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org Mesa 7.0.3 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org Mesa 7.0.3 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org Mesa 7.0.3 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org example1: out of memory (requested 2944401408 bytes) Script done on Tue Mar 24 16:50:45 2009 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equations for `foo' have different numbers of arguments
Hello Manlio, Tuesday, March 24, 2009, 5:44:14 PM, you wrote: divide _ 0 = error division by 0 divide = (/) Equations for `divide' have different numbers of arguments you should write divide a b = a/b -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Equations for `foo' have different numbers of arguments
Manlio Perillo manlio_peri...@libero.it wrote: Hi. There is a limitation, in Haskell, that I'm not sure to understand. Here is an example: module Main where divide :: Float - Float - Float divide _ 0 = error division by 0 divide = (/) main = do print $ divide 1.0 0.0 print $ divide 4.0 2.0 With GHC I get: Equations for `divide' have different numbers of arguments With HUGS: Equations give different arities for divide However the two equations really have the same number of arguments. What's the problem? Equations not being what you think they are. They aren't the symbol 'divide' equals that function but lhs of '=', '=', and rhs of '='. The problem is mostly syntactical, in the sense that most occurrences of definitions with a different number of arguments are plain typos. The other might be implementation issues: it makes pattern match rules more complex. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs on iPhone
On Mon, Mar 23, 2009 at 07:00:26PM -0400, Rick R wrote: The agreement doesn't specifically prohibit the use of interpreters (just those than run external code). It also doesn't say anything about machine generated code. The only thing one would have to ensure is that the dependencies of JHC are all compiled in, or statically linked. Shared libs are disallowed in any app. If it has a runtime dependency on gcc (is there such a thing?) Then you would have to statically link it and therefore couldn't sell your application. (gotta love GPL) No problem here, the gcc licence explicity states things compiled with it are not considered derivative works. And after all, Mac OS X is compiled with gcc, apple X-Code uses gcc as its compiler and I think gcc may even be the only objective C compiler out there. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
Eelco Lempsink wrote: Given the winner, the possible variations are limited to color (oh, boy), coloring (lambda accented, bind accented or all the same) and possible font-like things such as the line shapes (much like George Pollard did with his variant, entry #50, placed 9th). I agree that we should have only one more round of voting. I also like the idea of choosing a logo without text, much like the now standard feed icon ( http://www.feedicons.com/ ). It allows for international recognition without dependency on language. It also can be flexibly used for web and t-shirt designs with multiple fonts. In fact, I would expect to see a version of this logo become the new favicon ( http://en.wikipedia.org/wiki/Favicon ) for haskell.org and other sites, and there's no room for text there. Having multiple color combinations would be a bonus. Again, see the feed icon for a decent example. I would also like to see how one image looks at different scales, e.g. feed icon (of course) and very large (for posters). This isn't necessarily a single image scaled, of course, but it should be obvious that an icon comes from the same design as a poster splash. My preference would be to have one person with sense of (and education in, if possible) design make some nice looking variations and have a second (final) round of voting, but, we could also do the wiki-thing again ;) I would also like to see skilled designers compete in this round as well. I don't know whether it should be limited to just one person, one team, or several teams. The focus is narrower, so the details are more important. It might be good to have multiple small groups involved. Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SOC idea ticket: Rendering Engine
Oh, I managed to enjoy ogre by disabling other entities. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Equations for `foo' have different numbers of arguments
Achim Schneider wrote: The other might be implementation issues: it makes pattern match rules more complex. But only marginally, right? f A B = biz f B = bar f = bam could be trivially rewritten to: f A B = biz f B y = bar y f x y = bam x y Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
On 2009 Mar 24, at 8:29, John Van Enk wrote: Is this the part where all the pundits come out and talk about how Jeff isn't a citizen, eats babies, and wants to turn Haskell into an imperative language? He uses unsafeInterleaveIO! -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
He ONCE used unsafeInterleaveIO, but he never evaluated it, and never tried it again! 2009/3/24 Brandon S. Allbery KF8NH allb...@ece.cmu.edu On 2009 Mar 24, at 8:29, John Van Enk wrote: Is this the part where all the pundits come out and talk about how Jeff isn't a citizen, eats babies, and wants to turn Haskell into an imperative language? He uses unsafeInterleaveIO! -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH ___ 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] Something wrong with happs.org?
Hi, http://happs.org/ has some Javascript visible as plain text. It looks like some tags are missing in the page... I hope that's the right website, because it turned up first on my Google search happs with a nice description too. -- Vimal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Equations for `foo' have different numbers of arguments
Yes, but this seems to have terrifying implications... On Tue, Mar 24, 2009 at 11:25 AM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: Achim Schneider wrote: The other might be implementation issues: it makes pattern match rules more complex. But only marginally, right? f A B = biz f B = bar f = bam could be trivially rewritten to: f A B = biz f B y = bar y f x y = bam x y Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Something wrong with happs.org?
I thought that HAppS has gone, replaced by happstack? http://happstack.com/ -Ross On Mar 24, 2009, at 11:32 AM, Vimal wrote: Hi, http://happs.org/ has some Javascript visible as plain text. It looks like some tags are missing in the page... I hope that's the right website, because it turned up first on my Google search happs with a nice description too. -- Vimal ___ 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: Equations for `foo' have different numbers of arguments
Martijn van Steenbergen mart...@van.steenbergen.nl wrote: f x y = bam x y This would introduce another matching of x on the outside of bam, and I don't know if this works without significantly messing with e.g. strictness. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] The votes are in!
Hello Andrew, Tuesday, March 24, 2009, 6:29:18 PM, you wrote: then it was thoughtcrime and that sort of things even more dangerous for State! He ONCE used unsafeInterleaveIO, but he never evaluated it, and never tried it again! 2009/3/24 Brandon S. Allbery KF8NH allb...@ece.cmu.edu On 2009 Mar 24, at 8:29, John Van Enk wrote: Is this the part where all the pundits come out and talk about how Jeff isn't a citizen, eats babies, and wants to turn Haskell into an imperative language? He uses unsafeInterleaveIO! -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SOC idea ticket: Rendering Engine
Does your video card support shaders?
If it's an old card with fixed function opengl, then edit
/media/materials/scripts/Robot.material file.
Disable shaders:
{
//source ambient.vert
//source diffuse.vert
source toonf2.vert
}
fragment_program Examples/AmbientShadingFP glsl
{
//source ambient.frag
//source diffuse.frag
source toonf2.frag
}
material Examples/Robot
{
// Software blending technique
technique
{
pass
{
// vertex_program_ref Examples/AmbientShadingVP
// {
// // map shininess from custom renderable
param 1
// //param_named_auto shininess custom 1
// }
//fragment_program_ref Examples/AmbientShadingFP
//{
//// map shininess from custom renderable
param 1
////param_named_auto shininess custom 1
// }
texture_unit
{
texture r2skin.jpg
}
}
}
}
2009/3/24 Roman Cheplyaka r...@ro-che.info
Oh, I managed to enjoy ogre by disabling other entities.
--
Roman I. Cheplyaka :: http://ro-che.info/
Don't let school get in the way of your education. - Mark Twain
___
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] Something wrong with happs.org?
We need a redirect... rmm-haskell: I thought that HAppS has gone, replaced by happstack? http://happstack.com/ -Ross On Mar 24, 2009, at 11:32 AM, Vimal wrote: Hi, http://happs.org/ has some Javascript visible as plain text. It looks like some tags are missing in the page... I hope that's the right website, because it turned up first on my Google search happs with a nice description too. -- Vimal ___ 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
Exception handling in numeric computations (was Re: [Haskell-cafe] Use unsafePerformIO to catch Exception?)
Henning Thielemann lemm...@henning-thielemann.de writes: Try to never use exception handling for catching programming errors! Division by zero is undefined, thus a programming error when it occurs. http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception I'm afraid, a Maybe or Either or Exceptional (see explicit-exception package) return value is the only way to handle exceptional return values properly. Maybe in the larger context of your problem zero denominators can be avoided? Then go this way. Using div is just an example I'm testing with what I read in the book Real World Haskell. The real thing I'm trying to do is inverting a matrix. Say, I want to write invMat :: Matrix - Matrix You won't be able to invert all the matrix, mathematically. And computationally, even a larger set of matrix might fail to be inverted because of the finite precision. It is relatively easier and more efficient to spot such a problem within this 'invMat' function. Because testing the singularity of a matrix is equally hard as invert it. So all I can do when 'invMat' spot a singular matrix are a) Return Either/Maybe to signal an error. b) Wrap it in a monad. c) Define a dynamic exception and throw it. The problem is that there will be many functions using such a function to invert a matrix, making this inversion function return Either/Maybe or packing it in a monad is just a big headache. It is impractical to use method (a), because not every function that uses 'invMat' knows how to deal with 'invMat' not giving an answer. So we need to use method (b), to use monad to parse our matrix around. invMat :: Matrix - NumericCancerMonad Matrix It hides the exceptional nature of numerical computations very well, but it is cancer in the code. Whenever any function wants to use invMat, it is mutated. This is just madness. You don't want to make all the code to be monadic just because of singularities in numeric calculation. Therefore, in my opinion, method (c) is my only option. And because I don't always want to deal with such problem in the IO monad, I create this beast 'unsafePerformIO . try . evaluate' to convert some potential disastrous result to 'Either Disaster Result'. You might argue that Haskell actually deals with such numerical problem with 'NaN', 'Infinite'. But, some numerical operations behave weird with these special values, and using 'isNan', 'isInfinite' alike is just another big mess. They are going to be all over the place and not actually better than 'case ... of' and 'fromMaybe'. I can't really think of another option for this kind of situation, apart from letting my code to be infected by NumericCancerMonad. If anyone on this list has some thoughts on this matter, please share them. Many thanks. -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Are there performant mutable Arrays in Haskell?
barsoap: Brettschneider, Matthias brettschnei...@hs-albsig.de wrote: Thx for your hints, I played around with them and the performance gets slightly better. But the major boost is still missing :) I noticed, that one real bottleneck seems to be the conversion of the array back into a list. The interesting part is, if I use the elems function (Data.Array.Base) the performance is about 4x better then with my own function. So I thought, I write my own version of elems, (that just converts a part of the array to a list) and I fall back into the same performance as my first approach. To make a long story short, here is the library code: elems arr = case bounds arr of (_l, _u) - [unsafeAt arr i | i - [0 .. numElements arr - 1] And my version: boundedElems arr = case bounds arr of (_l, _u) - [unsafeAt arr i | i - [1737 .. 1752]] Is there a reason, why the library version is 4 times faster, than mine? Uhhhmmm... I've got no idea. But as the list is constructed lazily, you shouldn't expect a real speedup by being lazy manually, anyway. You might want to try the stream-fusion list implementation of lists, or get rid of lists, alltogether. Yes, avoid constructing the list, if you're not doing that in C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Exception handling in numeric computations (was Re: [Haskell-cafe] Use unsafePerformIO to catch Exception?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xiao-Yong Jin wrote: | The problem is that there will be many functions using such | a function to invert a matrix, making this inversion | function return Either/Maybe or packing it in a monad is | just a big headache. I disagree. If you try to take the inverse of a noninvertable matrix, this is an *error* in your code. Catching an error you created in pure code and patching it with chewing gum it is just a hack. A monadic approach (I'm putting Either/Maybe under the same umbrella for brevity) is the only solution that makes any sense to me, and I don't think it's ugly as you are making it out to be. | It is impractical to use method (a), | because not every function that uses 'invMat' knows how to | deal with 'invMat' not giving an answer. So we need to use | method (b), to use monad to parse our matrix around. | | invMat :: Matrix - NumericCancerMonad Matrix | | It hides the exceptional nature of numerical computations | very well, but it is cancer in the code. Whenever any | function wants to use invMat, it is mutated. This is just | madness. You don't want to make all the code to be monadic | just because of singularities in numeric calculation. For functions that don't know or don't care about failure, just use fmap or one of its synonyms. ~scalarMult 2 $ invMat x See? The scalarMult function is pure, as it should be. There is no madness here. - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJEN8ACgkQye5hVyvIUKk3UQCfVDcVzVOKNeWDOozwfMsyQFnP 1XgAoJZSMa/3QEQus79FS2KTqF4DYu8X =BzYt -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Exception handling in numeric computations (was Re: [Haskell-cafe] Use unsafePerformIO to catch Exception?)
On Tue, Mar 24, 2009 at 1:27 PM, Xiao-Yong Jin xj2...@columbia.edu wrote: Henning Thielemann lemm...@henning-thielemann.de writes: Try to never use exception handling for catching programming errors! Division by zero is undefined, thus a programming error when it occurs. http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception I'm afraid, a Maybe or Either or Exceptional (see explicit-exception package) return value is the only way to handle exceptional return values properly. Maybe in the larger context of your problem zero denominators can be avoided? Then go this way. Using div is just an example I'm testing with what I read in the book Real World Haskell. The real thing I'm trying to do is inverting a matrix. Say, I want to write invMat :: Matrix - Matrix You won't be able to invert all the matrix, mathematically. And computationally, even a larger set of matrix might fail to be inverted because of the finite precision. It is relatively easier and more efficient to spot such a problem within this 'invMat' function. Because testing the singularity of a matrix is equally hard as invert it. So all I can do when 'invMat' spot a singular matrix are a) Return Either/Maybe to signal an error. b) Wrap it in a monad. c) Define a dynamic exception and throw it. In general if a function is partial we can either make it total by extending its range or restricting its domain. Also we can signal it using runtime or compile-time mechanisms. Options a b are equivalent (i.e. extend the range, compile-time notification) and option c is also another way of extending the range, but using runtime notification. If we try the other approach, we need to express the totality of invMat by restricting its domain, so we can add, for example, a phantom type to Matrix to signal it is invertible. As you need to construct the Matrix before trying to invert it you can always make the constructors smart enough to bundle the Matrix with such properties. Of course there's need to do some runtime verifications earlier, but the clients of invMat are required to do the verification earlier or pass it to their clients (up to the level that can handle with this issue): data Invertible tryInvertible :: Matrix a - Maybe (Matrix Invertible) invMat :: Matrix Invertible - Matrix Invertible You could use different forms of evidence (e.g. phantom types, type classes) but the idea is the same. The problem is that there will be many functions using such a function to invert a matrix, making this inversion function return Either/Maybe or packing it in a monad is just a big headache. It is impractical to use method (a), because not every function that uses 'invMat' knows how to deal with 'invMat' not giving an answer. So we need to use method (b), to use monad to parse our matrix around. invMat :: Matrix - NumericCancerMonad Matrix It hides the exceptional nature of numerical computations very well, but it is cancer in the code. Whenever any function wants to use invMat, it is mutated. This is just madness. You don't want to make all the code to be monadic just because of singularities in numeric calculation. Therefore, in my opinion, method (c) is my only option. And because I don't always want to deal with such problem in the IO monad, I create this beast 'unsafePerformIO . try . evaluate' to convert some potential disastrous result to 'Either Disaster Result'. You might argue that Haskell actually deals with such numerical problem with 'NaN', 'Infinite'. But, some numerical operations behave weird with these special values, and using 'isNan', 'isInfinite' alike is just another big mess. They are going to be all over the place and not actually better than 'case ... of' and 'fromMaybe'. I can't really think of another option for this kind of situation, apart from letting my code to be infected by NumericCancerMonad. If anyone on this list has some thoughts on this matter, please share them. Many thanks. -- c/* __o/* \ * (__ */\ Best regards, Daniel Yokomizo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs on iPhone
Correct. My point was only in the case that it would need to statically link to a GPL'd lib (which I'm not sure if such a case exists) If the gcc license suddenly decided to claim compiled items as derivative works, the IT world as we know it would end. On Tue, Mar 24, 2009 at 11:06 AM, John Meacham j...@repetae.net wrote: On Mon, Mar 23, 2009 at 07:00:26PM -0400, Rick R wrote: The agreement doesn't specifically prohibit the use of interpreters (just those than run external code). It also doesn't say anything about machine generated code. The only thing one would have to ensure is that the dependencies of JHC are all compiled in, or statically linked. Shared libs are disallowed in any app. If it has a runtime dependency on gcc (is there such a thing?) Then you would have to statically link it and therefore couldn't sell your application. (gotta love GPL) No problem here, the gcc licence explicity states things compiled with it are not considered derivative works. And after all, Mac OS X is compiled with gcc, apple X-Code uses gcc as its compiler and I think gcc may even be the only objective C compiler out there. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] about Haskell code written to be too smart
Hi. In these days I'm discussing with some friends, that mainly use Python as programming language, but know well other languages like Scheme, Prolog, C, and so. These friends are very interested in Haskell, but it seems that the main reason why they don't start to seriously learning it, is that when they start reading some code, they feel the Perl syndrome. That is, code written to be too smart, and that end up being totally illegible by Haskell novice. I too have this feeling, from time to time. Since someone is starting to write the Haskell coding style, I really suggest him to take this problem into strong consideration. Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equations for `foo' have different numbers of arguments
Bulat Ziganshin ha scritto: Hello Manlio, Tuesday, March 24, 2009, 5:44:14 PM, you wrote: divide _ 0 = error division by 0 divide = (/) Equations for `divide' have different numbers of arguments you should write divide a b = a/b Right. But my question was: why can't I write the function as I did? Why can't I write an equation in the curried form? Thanks (and thanks for the other responses, I will reply only here) Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SOC idea ticket: Rendering Engine
* Csaba Hruska csaba.hru...@gmail.com [2009-03-24 16:54:51+0100] Does your video card support shaders? If it's an old card with fixed function opengl, then edit /media/materials/scripts/Robot.material file. Disable shaders: Yeah, that helped. (It's video card embedded in my laptop.) -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC 6.10.2 - PCap package - affected by the change of Finalizers?
Hi Looks like pcap package needs a little tweek for 6.10.2 - programs compiled with it bomb out with ..error: a C finalizer called back into Haskell. use Foreign.Concurrent.newForeignPtr for Haskell finalizers. Is my interpretation of this error message correct? Cheers Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
These friends are very interested in Haskell, but it seems that the main reason why they don't start to seriously learning it, is that when they start reading some code, they feel the Perl syndrome. That is, code written to be too smart, and that end up being totally illegible by Haskell novice. I too have this feeling, from time to time. Since someone is starting to write the Haskell coding style, I really suggest him to take this problem into strong consideration. When you think about it, what you are saying is that Haskell programmers shouldn't take advantage of the extra tools that Haskell provides. Haskell provides the ability to abstract code beyond what many other programming systems allow. This abstraction gives you the ability to express things much more tersely. This makes the code a lot harder to read for people who are not familiar with the abstractions being used. This can be overcome with practice and experience. I'm not trying to say that code can never get too complex. Humans have some complexity budget and its not too hard to push the limits and blow your complexity budget. But that is true in any language. The ability to abstract lets you factor out common patterns that are easy to reuse and remember (with practice) and lets you spend your complexity budget elsewhere. As a programmer you still need to use your judgement to balance complexity against understandability. [Obviously if you are writing code that you want to be readable by people who arent well versed in common Haskell idioms, you'd limit your use of abstractions.] Manlio Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
I know what you're saying, in a way. There is much haskell code that's completely illegible to me. I would say there is a difference between Haskell and Perl though, in that Perl code is too smart aka. clever, while Haskell code is usually simply, well, too smart. This means code written using aspects of covariant generalized applicative combinators in a closed Hillbert-space like continuous field ring, and other similar nonsense. There was a time when monadic parser combinator sounded equally nonsensical to me. It doesn't anymore, and I'm a better programmer for it, being able to reduce one of my earliest Haskell programs from 200 to 20 lines using that knowledge alone while making it more comprehensible and maintainable at the same time. The difference between Haskell and Perl is that Haskell programmers use clever ideas while Perl programmers use clever abuse of syntax. Ideas, at least, you have a hope of understanding sometime in the future. ty. den 24.03.2009 klokka 18:41 (+0100) skreiv Manlio Perillo: Hi. In these days I'm discussing with some friends, that mainly use Python as programming language, but know well other languages like Scheme, Prolog, C, and so. These friends are very interested in Haskell, but it seems that the main reason why they don't start to seriously learning it, is that when they start reading some code, they feel the Perl syndrome. That is, code written to be too smart, and that end up being totally illegible by Haskell novice. I too have this feeling, from time to time. Since someone is starting to write the Haskell coding style, I really suggest him to take this problem into strong consideration. Manlio ___ 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] about Haskell code written to be too smart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manlio Perillo wrote: | These friends are very interested in Haskell, but it seems that the main | reason why they don't start to seriously learning it, is that when they | start reading some code, they feel the Perl syndrome. | | That is, code written to be too smart, and that end up being totally | illegible by Haskell novice. | | I too have this feeling, from time to time. I used to think this as well, but have since changed my mind about most cases. It is simply the case that Haskell code is extremely dense. The more powerful your abstractions, the more functionality you can cram into one line of code. This can give the appearance of being overly clever, since we are accustomed to clever code being unnervingly short and using lots of short variable names and operators. It is generally encouraged to use single-letter variable names in Haskell because there are many cases that you haven't a clue what the type of that variable might be, again due to Haskell's amazing ability to abstract such things away. All these factors combined just means that you have to concentrate just as hard to understand one line of Haskell as you might 10 or 20 lines of other languages. There is 10 or 20 times the amount of information. - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJJpIACgkQye5hVyvIUKl8dgCgp+YSwdJpmeVlrlUEnzGGgVBQ VFoAoMSDkOV+YdAoEbmLjtjza+byEUTi =9pZZ -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Well, I'd say that there is something close to the Perl syndrome, in some sense. After all, code IS usually very smart. The difference is that in Perl all smartness is about knowing how the computer works, or how the interpreter works. In Haskell, instead, the smartness is about knowing - or inventing - the general setting in which the problem looks less complex. On 24 Mar 2009, at 20:41, Manlio Perillo wrote: Hi. In these days I'm discussing with some friends, that mainly use Python as programming language, but know well other languages like Scheme, Prolog, C, and so. These friends are very interested in Haskell, but it seems that the main reason why they don't start to seriously learning it, is that when they start reading some code, they feel the Perl syndrome. That is, code written to be too smart, and that end up being totally illegible by Haskell novice. I too have this feeling, from time to time. Since someone is starting to write the Haskell coding style, I really suggest him to take this problem into strong consideration. Manlio ___ 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] about Haskell code written to be too smart
Tim Newsham ha scritto: These friends are very interested in Haskell, but it seems that the main reason why they don't start to seriously learning it, is that when they start reading some code, they feel the Perl syndrome. That is, code written to be too smart, and that end up being totally illegible by Haskell novice. I too have this feeling, from time to time. Since someone is starting to write the Haskell coding style, I really suggest him to take this problem into strong consideration. When you think about it, what you are saying is that Haskell programmers shouldn't take advantage of the extra tools that Haskell provides. No, I'm not saying this. But, as an example, when you read a function like: buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns that can be rewritten (argument reversed) as: takeList :: [Int] - [a] - [[a]] takeList [] _ = [] takeList _ [] = [] takeList (n : ns) xs = head : takeList ns tail where (head, tail) = splitAt n xs I think that there is a problem. The buildPartition contains too many blocks. And I have read code with even more blocks in one line. It may not be a problem for a seasoned Haskell programmer, but when you write some code, you should never forget that your code will be read by programmers that can not be at your same level. I think that many Haskell programmers forget this detail, and IMHO this is wrong. Haskell provides the ability to abstract code beyond what many other programming systems allow. This abstraction gives you the ability to express things much more tersely. This makes the code a lot harder to read for people who are not familiar with the abstractions being used. The problem is that I have still problems at reading and understanding code that is too much terse... Because I have to assemble in my mind each block, and if there are too many blocks I have problems. [...] Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Making videos of your project
Perhaps the make a video slogan doesn't quite explain what is intended - it didn't to me!-) Reading John Udell's short article What is Screencasting? http://www.oreillynet.com/pub/a/oreilly/digitalmedia/2005/11/16/what-is-screencasting.html?page=1 gave me a better idea: the screen video part is the modern, animated version of manuals with screenshots, now with audio or text caption annotations (a canned demo). He also gives some tool references, and some suggestions for focussing the bandwidth on useful contents, editing, privacy considerations, etc. Almost certainly, this 2. type 'recordmydesktop' 3. do something with haskell 4. hit control-C 5. upload out.ogv to youtube is not a useful recipe - screencasts need planning of the steps one wants to demonstrate, editing out of aimless moving around or thinking about what to show next, annotations that guide the viewer (text labels or audio track that explains what can be seen, or what keyboard shortcuts are used, or what the plan is), and probably several attempts to get one useful result (minimal bandwith/length/.. with maximal ah, that is how I do it or ah, that is how it works or cool, I want to install that effect). But with a little effort, this could be very useful, more so than simple screenshots, lots of text, or combinations thereof, if the focus is not so much on producing a video to watch, but on showing potential users what they are going to see, and how to work with it if they decide to install it. For instance, I'd now like to replace my old tour of haskellmode for Vim with a screencast. As a windows user, I tried playing with CamStudio and that almost seems to do the job (capture, annotation, replay, conversion of .avi to compressed .swf) but I don't like the resolution of the .swf it generates (screen text isn't as readable as I've seen in other screencasts). Perhaps I'm missing an option to improve the quality, or can anyone recommend another free tool for windows, from positive experience (wikipedia has a whole list of tools http://en.wikipedia.org/wiki/Comparison_of_screencasting_software )? For the purpose I have in mind, it would be good to have many small pieces of screencast, one for each feature, or even better, one continuous screencast with the ability to link directly to sections dealing with particular topics - a hyperlinked animation. Is that supported by some (free) tool? Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Jake McArthur ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manlio Perillo wrote: | These friends are very interested in Haskell, but it seems that the main | reason why they don't start to seriously learning it, is that when they | start reading some code, they feel the Perl syndrome. | | That is, code written to be too smart, and that end up being totally | illegible by Haskell novice. | | I too have this feeling, from time to time. I used to think this as well, but have since changed my mind about most cases. The same for me. [...] All these factors combined just means that you have to concentrate just as hard to understand one line of Haskell as you might 10 or 20 lines of other languages. There is 10 or 20 times the amount of information. This is right. The problem is that often (IMHO) a function definition can be rewritten so that it is much more readable. As an example, with the takeList function I posted. In other cases, you can just break long lines, introducing intermediate functions that have a descriptive name *and* a type definition. Doing this is an art, but a coding style for Haskell should try to document this. [...] Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
On Tue, 2009-03-24 at 19:42 +0100, Manlio Perillo wrote: Tim Newsham ha scritto: These friends are very interested in Haskell, but it seems that the main reason why they don't start to seriously learning it, is that when they start reading some code, they feel the Perl syndrome. That is, code written to be too smart, and that end up being totally illegible by Haskell novice. I too have this feeling, from time to time. Since someone is starting to write the Haskell coding style, I really suggest him to take this problem into strong consideration. When you think about it, what you are saying is that Haskell programmers shouldn't take advantage of the extra tools that Haskell provides. No, I'm not saying this. But, as an example, when you read a function like: buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns that can be rewritten (argument reversed) as: takeList :: [Int] - [a] - [[a]] takeList [] _ = [] takeList _ [] = [] takeList (n : ns) xs = head : takeList ns tail where (head, tail) = splitAt n xs Huh? This is ugly and un-readable. Seriously. I think that there is a problem. Damn straight. It should be: buildPartitions xs ns = zipWith take ns $ init $ scanl (flip drop) xs ns Or, if you're really worried about blocks/line, you can increase the line count a bit (I do this regularly): buildPartitions xs ns = zipWith take ns $ -- Select just the indicated prefix of each element init $ -- Skip the last (empty) element scanl (flip drop) xs $ -- Cumulatively remove prefixes of indicated length ns The buildPartition contains too many blocks. And I have read code with even more blocks in one line. It may not be a problem for a seasoned Haskell programmer, but when you write some code, you should never forget that your code will be read by programmers that can not be at your same level. Not if I can help it. More seriously, beginner code belongs in the first two-three chapters of Haskell programming textbooks, not anywhere else. It's like putting Fun with Dick Jane-speak in an adult novel.[1] I think that many Haskell programmers forget this detail, and IMHO this is wrong. Haskell provides the ability to abstract code beyond what many other programming systems allow. This abstraction gives you the ability to express things much more tersely. This makes the code a lot harder to read for people who are not familiar with the abstractions being used. The problem is that I have still problems at reading and understanding code that is too much terse... Because I have to assemble in my mind each block, and if there are too many blocks I have problems. jcc [1] Well, not that bad. Beginner-level code is useful for teaching the basics of the language; Fun with Dick Jane is child abuse. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manlio Perillo wrote: | This is right. | The problem is that often (IMHO) a function definition can be rewritten | so that it is much more readable. | | As an example, with the takeList function I posted. I looked at it, found nothing wrong with the original, and absolutely hated your fixed version. I might have written it like this, instead: ~buildPartitions xs ns = zipWith take ns . init . scanl (flip drop) xs $ ns I think this way separates the different stages of the function somewhat better, but it's barely a change. The original was fine. | In other cases, you can just break long lines, introducing intermediate | functions that have a descriptive name *and* a type definition. | | Doing this is an art, but a coding style for Haskell should try to | document this. Agreed. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJL1gACgkQye5hVyvIUKnF/ACgjbd+gjolHCiS9tWosbiH3gnX j0EAn2zbeanj9UUQnl1pnQ+GRdPpYiRj =h5bU -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
When you think about it, what you are saying is that Haskell programmers shouldn't take advantage of the extra tools that Haskell provides. No, I'm not saying this. But, as an example, when you read a function like: buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns that can be rewritten (argument reversed) as: takeList :: [Int] - [a] - [[a]] takeList [] _ = [] takeList _ [] = [] takeList (n : ns) xs = head : takeList ns tail where (head, tail) = splitAt n xs I think this is a perfect example. Haskell allows you to abstract out the concepts of recursion, zipping and iteration. Your alternative reproduces these explicitely and intermixes them. You are saying that programmers should avoid using these higher level abstractions and instead fall back to more explicit constructs that are, for you, easier to read. The problem is that I have still problems at reading and understanding code that is too much terse... Because I have to assemble in my mind each block, and if there are too many blocks I have problems. It takes practice to read and to write. The benefit is more expressiveness and more code reuse. Manlio Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
2009/3/24 Manlio Perillo manlio_peri...@libero.it: Tim Newsham ha scritto: These friends are very interested in Haskell, but it seems that the main reason why they don't start to seriously learning it, is that when they start reading some code, they feel the Perl syndrome. That is, code written to be too smart, and that end up being totally illegible by Haskell novice. I too have this feeling, from time to time. Since someone is starting to write the Haskell coding style, I really suggest him to take this problem into strong consideration. When you think about it, what you are saying is that Haskell programmers shouldn't take advantage of the extra tools that Haskell provides. No, I'm not saying this. But, as an example, when you read a function like: buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns Wow, very cool! And very readable; I actually got the idea of the function is going to do after reading the scanl (flip drop) and the rest of the function only convinced me that I was right. The second version is far worse, because it forces me to think about what to do if the lists are empty, how to decompose them if they aren't - all this stuff is 'imperative' and irrelevant to the problem, and is elegantly omitted in the one-liner. that can be rewritten (argument reversed) as: takeList :: [Int] - [a] - [[a]] takeList [] _ = [] takeList _ [] = [] takeList (n : ns) xs = head : takeList ns tail where (head, tail) = splitAt n xs I think that there is a problem. The buildPartition contains too many blocks. And I have read code with even more blocks in one line. It may not be a problem for a seasoned Haskell programmer, but when you write some code, you should never forget that your code will be read by programmers that can not be at your same level. I think that many Haskell programmers forget this detail, and IMHO this is wrong. Haskell provides the ability to abstract code beyond what many other programming systems allow. This abstraction gives you the ability to express things much more tersely. This makes the code a lot harder to read for people who are not familiar with the abstractions being used. The problem is that I have still problems at reading and understanding code that is too much terse... Because I have to assemble in my mind each block, and if there are too many blocks I have problems. [...] Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
| As an example, with the takeList function I posted. I looked at it, found nothing wrong with the original, and absolutely hated your fixed version. I might have written it like this, instead: ~buildPartitions xs ns = zipWith take ns . init . scanl (flip drop) xs $ ns Maybe it's just me, but I think that takeList ns xs = evalState (mapM (State . splitAt) ns) xs or even takeList = evalState . map (State . splitAt) would be much clearer than both versions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ACM Task for C++ and Java programmers in Haskell. How to make code faster?
I changed the program, now it similar to the program from the wiki (http://www.haskell.org/haskellwiki/Phone_number) The version with ByteString compared to version with ordinary Strings works 3.5 times faster. (I put it to http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2830) But version with Data.Trie dissapointed me, it works 5 times slover than version with Data.Map ByteString. (here is the code http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2829) Anyway, thanks to everyone who helped me, Haskell is really powerfull tool in clever hands :) 2009/3/23 wren ng thornton w...@freegeek.org: Vasyl Pasternak wrote: The entire code I placed on http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2764 Could someone help me to make this code faster? I'd like to see solution that will be elegant and fast, without heavy optimizations, that will make code unreadable. Also, if it possible, prepare the program to support SMP parallelism. The solution's already been posted, but to make this particular code faster, I recommend using Data.Trie instead of Data.Map ByteString. Tries are faster for lookup since they don't redundantly check the prefix of the query; also they're better for memory usage because they don't store redundant copies of the prefixes. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Vasyl Pasternak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Pretty cool once you know what the function does, but I must admit I wouldn't immediately guess the purpose of the function when written in this way. 2009/3/24 Miguel Mitrofanov miguelim...@yandex.ru: | As an example, with the takeList function I posted. I looked at it, found nothing wrong with the original, and absolutely hated your fixed version. I might have written it like this, instead: ~ buildPartitions xs ns = zipWith take ns . init . scanl (flip drop) xs $ ns Maybe it's just me, but I think that takeList ns xs = evalState (mapM (State . splitAt) ns) xs or even takeList = evalState . map (State . splitAt) would be much clearer than both versions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miguel Mitrofanov wrote: | Maybe it's just me, but I think that | | takeList ns xs = evalState (mapM (State . splitAt) ns) xs | | or even | | takeList = evalState . map (State . splitAt) | | would be much clearer than both versions. Definitely. I stuck with only the functions that were already being used because I figured the point was to make things readable with a limited set of building blocks. Thanks for sharing though. That was definitely not a solution that I was thinking of. - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJN9gACgkQye5hVyvIUKn5AACgpLGOwp5asyFxPj6r/sjt4jz/ I7AAoIDDvYbpmWB8/Ag5ui+vNzvbHQ4l =NxfM -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Jake McArthur ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manlio Perillo wrote: | This is right. | The problem is that often (IMHO) a function definition can be rewritten | so that it is much more readable. | | As an example, with the takeList function I posted. I looked at it, found nothing wrong with the original, and absolutely hated your fixed version. With the original version, you have to follow 3 separate operations: Prelude let xs = [1, 2, 3, 4] :: [Int] Prelude let ns = [3, 1] :: [Int] Prelude let _1 = scanl (flip drop) xs ns Prelude let _2 = init _1 Prelude let _3 = zipWith take ns _2 With my function, instead, you only have to follow 1 operation: Prelude (head, tail) = splitAt n xs [...] Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
and that baby eating is an acceptable part of Haskell optimization
Actually, yes. It's usually best used like this:
data Foo = Bar {-# UNPACK #-} {-# EAT BABY #-} !Int
On Tue, Mar 24, 2009 at 8:42 AM, Creighton Hogg wch...@gmail.com wrote:
2009/3/24 John Van Enk vane...@gmail.com:
Is this the part where all the pundits come out and talk about how Jeff
isn't a citizen, eats babies, and wants to turn Haskell into an
imperative
language?
Well given the fact that Haskell has been called the world's best
imperative language, that we have a multinational community, and that
baby eating is an acceptable part of Haskell optimization* I think
he'll fit in just fine.
* Don Stewart might have a blog post about this, but I'm too lazy to look
it up.
--
/jve
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Manlio Perillo complained about: buildPartitions xs ns = zipWith take ns . init . scanl (flip drop) xs $ ns Miguel Mitrofanov wrote: takeList = evalState . mapM (State . splitAt) Ha! Bravo! As the author of the offending zipWith/scanl version, I can say that love those State monad one-liners. However, ironically, I stopped using them for pretty much the same reason that Manlio is saying. The difference is that zipWith and scanl are classic Haskell idioms that any Haskell programmer will learn fairly early on. Whereas State monad one-liners used to be thought of as new and fancy and esoteric. But now they are becoming more mainstream, so perhaps I should go back to them. So the bottom line is that Manlio is right, really. It's just that Haskell is still very different than what most programmers are used to. So it does take a while to get a feeling for what is too smart. Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hugs on iPhone
2009/3/24 Rick R rick.richard...@gmail.com Correct. My point was only in the case that it would need to statically link to a GPL'd lib (which I'm not sure if such a case exists) If the gcc license suddenly decided to claim compiled items as derivative works, the IT world as we know it would end. Any linkage to GPL has different implications than dynamic or static linkage to LGPL code. And I'm not a lawyer, so I won't comment on this crap because it's all freaking ridiculous. People who believe in using and writing software that people are free to use any way they want should just stay the hell away from anything from the FSF. I like freedom from restrictions, not freedom with restrictions. Dave On Tue, Mar 24, 2009 at 11:06 AM, John Meacham j...@repetae.net wrote: On Mon, Mar 23, 2009 at 07:00:26PM -0400, Rick R wrote: The agreement doesn't specifically prohibit the use of interpreters (just those than run external code). It also doesn't say anything about machine generated code. The only thing one would have to ensure is that the dependencies of JHC are all compiled in, or statically linked. Shared libs are disallowed in any app. If it has a runtime dependency on gcc (is there such a thing?) Then you would have to statically link it and therefore couldn't sell your application. (gotta love GPL) No problem here, the gcc licence explicity states things compiled with it are not considered derivative works. And after all, Mac OS X is compiled with gcc, apple X-Code uses gcc as its compiler and I think gcc may even be the only objective C compiler out there. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein ___ 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] about Haskell code written to be too smart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manlio Perillo wrote: | With the original version, you have to follow 3 separate operations: | | Prelude let xs = [1, 2, 3, 4] :: [Int] | Prelude let ns = [3, 1] :: [Int] | Prelude let _1 = scanl (flip drop) xs ns | Prelude let _2 = init _1 | Prelude let _3 = zipWith take ns _2 | | | With my function, instead, you only have to follow 1 operation: | | Prelude (head, tail) = splitAt n xs I think you are way oversimplifying your own code. ~takeList :: [Int] - [a] - [[a]] ~takeList [] _ = [] ~takeList _ [] = [] ~takeList (n : ns) xs = head : takeList ns tail ~where (head, tail) = splitAt n xs In order to understand this, I have to look at three different cases, an uncons, a splitAt, a cons, *and* a recursive call. This is *seven* different things I have to absorb. - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJQ1MACgkQye5hVyvIUKl+hQCfc7Yd8mi8uXDRTZQa11Pn8zeT cZMAnApAcI+pr0wpYUP6Z0jHQ2vtf0ze =Z5ze -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Exception handling in numeric computations (was Re: [Haskell-cafe] Use unsafePerformIO to catch Exception?)
On Tue, 24 Mar 2009, Xiao-Yong Jin wrote: invMat :: Matrix - Matrix You won't be able to invert all the matrix, mathematically. And computationally, even a larger set of matrix might fail to be inverted because of the finite precision. It is relatively easier and more efficient to spot such a problem within this 'invMat' function. Because testing the singularity of a matrix is equally hard as invert it. So all I can do when 'invMat' spot a singular matrix are a) Return Either/Maybe to signal an error. This is the way to go. b) Wrap it in a monad. Either and Maybe are monads. These monads behave like exceptions in other languages. I like to call these exceptions. c) Define a dynamic exception and throw it. You cannot throw an exception in code that does not return Maybe, Either, IO or such things. You can only abuse 'undefined' and turn it into a defined value later by a hack. Think of 'undefined' as an infinite loop, that cannot detected in general. GHC is kind enough to detect special cases, in order to simplify debugging. But this should be abused for exceptional return values. The problem is that there will be many functions using such a function to invert a matrix, making this inversion function return Either/Maybe or packing it in a monad is just a big headache. It is impractical to use method (a), because not every function that uses 'invMat' knows how to deal with 'invMat' not giving an answer. How shall it deal with 'undefined' then? 'undefined' can only be handled by a hack, so Maybe or Either are clearly better. invMat :: Matrix - NumericCancerMonad Matrix It hides the exceptional nature of numerical computations very well, but it is cancer in the code. Whenever any function wants to use invMat, it is mutated. This is just madness. No it makes explicit what's going on. This is the idea of functional programming. You have nice Applicative infix operators in order to write everything in a functional look anyway. In contrast, I think it is mad that there is no function of type mulInt :: Int - Int - Maybe Int which allows us to catch overflows without using hacks. This function could be easily integrated in a compiler, since the CPUs show by a flag, that an overflow occurs. In most high level languages this is not possible, and thus programming in an overflow-proof way needs additional computations. You don't want to make all the code to be monadic just because of singularities in numeric calculation. Therefore, in my opinion, method (c) is my only option. Then better stick to MatLab. :-( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
On Tue, Mar 24, 2009 at 7:48 PM, Jonathan Cast jonathancc...@fastmail.fmwrote: On Tue, 2009-03-24 at 19:42 +0100, Manlio Perillo wrote: But, as an example, when you read a function like: buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns that can be rewritten (argument reversed) as: takeList :: [Int] - [a] - [[a]] takeList [] _ = [] takeList _ [] = [] takeList (n : ns) xs = head : takeList ns tail where (head, tail) = splitAt n xs Huh? This is ugly and un-readable. Seriously. I think this is subjective. Personally I can understand the second definition immediately, but the first one requires some puzzling. But that might be because I'm relatively new to Haskell. Of course the usage of head and tail in the example is unfortunate, one should not use these shadowing names. But aren't these two definitions different algoritms? At first sight I think the second one is more efficient than the first one. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Exception handling in numeric computations (was Re: [Haskell-cafe] Use unsafePerformIO to catch Exception?)
On Tue, 24 Mar 2009, Daniel Yokomizo wrote: If we try the other approach, we need to express the totality of invMat by restricting its domain, so we can add, for example, a phantom type to Matrix to signal it is invertible. As you need to construct the Matrix before trying to invert it you can always make the constructors smart enough to bundle the Matrix with such properties. Of course there's need to do some runtime verifications earlier, but the clients of invMat are required to do the verification earlier or pass it to their clients (up to the level that can handle with this issue): data Invertible tryInvertible :: Matrix a - Maybe (Matrix Invertible) invMat :: Matrix Invertible - Matrix Invertible This would be a very elegant solution. However when it comes to floating point numbers I'm afraid there are no much other ways than inverting a matrix if you want to know if it is invertible. You may however use representations of a matrix (like an LU decomposition or a QR decomposition) internally that are half-way of inversion. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Yitzchak Gale ha scritto: [...] So the bottom line is that Manlio is right, really. It's just that Haskell is still very different than what most programmers are used to. So it does take a while to get a feeling for what is too smart. Right, you centered the problem! The problem is where to place the separation line between normal and too smart. Your function is readable, once I mentally separate each step. For someone with more experience, this operation may be automatic, and the function may appear totally natural. When writing these dense function, it is important, IMHO, to help the reader using comments, or by introducing intermediate functions. Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
I demand a recount! The one that launches the missile should have won! 2009/3/24 Eelco Lempsink ee...@lempsink.nl: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ 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] The votes are in!
Doesn't matter how many times you seq the results, the thunk has been forced. -Ross On Mar 24, 2009, at 4:45 PM, FFT wrote: I demand a recount! The one that launches the missile should have won! 2009/3/24 Eelco Lempsink ee...@lempsink.nl: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl? num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ 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] The votes are in!
On Tue, Mar 24, 2009 at 2:45 PM, FFT fft1...@gmail.com wrote: I demand a recount! The one that launches the missile should have won! I guess nobody evaluated its merits. 2009/3/24 Eelco Lempsink ee...@lempsink.nl: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpathhttp://www.cs.cornell.edu/w8/%7Eandru/cgi-perl/civs/results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ 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] The votes are in!
Unless there's a rogue unsafeChangeVotes call in there somewhere. On Tue, Mar 24, 2009 at 4:46 PM, Ross Mellgren rmm-hask...@z.odi.ac wrote: Doesn't matter how many times you seq the results, the thunk has been forced. -Ross On Mar 24, 2009, at 4:45 PM, FFT wrote: I demand a recount! The one that launches the missile should have won! 2009/3/24 Eelco Lempsink ee...@lempsink.nl: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl ?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ 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 -- /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
import Diebold.Unsafe (unsafeChangeVotes) ... ? -Ross On Mar 24, 2009, at 4:47 PM, John Van Enk wrote: Unless there's a rogue unsafeChangeVotes call in there somewhere. On Tue, Mar 24, 2009 at 4:46 PM, Ross Mellgren rmm- hask...@z.odi.ac wrote: Doesn't matter how many times you seq the results, the thunk has been forced. -Ross On Mar 24, 2009, at 4:45 PM, FFT wrote: I demand a recount! The one that launches the missile should have won! 2009/3/24 Eelco Lempsink ee...@lempsink.nl: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl? num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ 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 -- /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Jake McArthur ha scritto: [...] | With my function, instead, you only have to follow 1 operation: | | Prelude (head, tail) = splitAt n xs I think you are way oversimplifying your own code. ~takeList :: [Int] - [a] - [[a]] ~takeList [] _ = [] ~takeList _ [] = [] ~takeList (n : ns) xs = head : takeList ns tail ~where (head, tail) = splitAt n xs In order to understand this, I have to look at three different cases, an uncons, a splitAt, a cons, *and* a recursive call. This is *seven* different things I have to absorb. These cases are, IMHO, more natural. We have a set of equations, pattern matching and recursion. These are one of the basic building block of Haskell. The only foreign building block is the splitAt function. But this may be really a question of personal taste or experience. What is more natural? 1) pattern matching 2) recursion or 1) function composition 2) high level functions ? [...] Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Another helpful strategy for the reader is to get smarter, i.e. to invest effort in rising to the level of the writer. Or just choose a different book if s/he prefers. - Conal On Tue, Mar 24, 2009 at 1:44 PM, Manlio Perillo manlio_peri...@libero.itwrote: Yitzchak Gale ha scritto: [...] So the bottom line is that Manlio is right, really. It's just that Haskell is still very different than what most programmers are used to. So it does take a while to get a feeling for what is too smart. Right, you centered the problem! The problem is where to place the separation line between normal and too smart. Your function is readable, once I mentally separate each step. For someone with more experience, this operation may be automatic, and the function may appear totally natural. When writing these dense function, it is important, IMHO, to help the reader using comments, or by introducing intermediate functions. Manlio ___ 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] about Haskell code written to be too smart
Recursion is the goto of functional programming. Also, Do not confuse what is natural with what is habitual. - Conal On Tue, Mar 24, 2009 at 1:51 PM, Manlio Perillo manlio_peri...@libero.itwrote: Jake McArthur ha scritto: [...] | With my function, instead, you only have to follow 1 operation: | | Prelude (head, tail) = splitAt n xs I think you are way oversimplifying your own code. ~takeList :: [Int] - [a] - [[a]] ~takeList [] _ = [] ~takeList _ [] = [] ~takeList (n : ns) xs = head : takeList ns tail ~where (head, tail) = splitAt n xs In order to understand this, I have to look at three different cases, an uncons, a splitAt, a cons, *and* a recursive call. This is *seven* different things I have to absorb. These cases are, IMHO, more natural. We have a set of equations, pattern matching and recursion. These are one of the basic building block of Haskell. The only foreign building block is the splitAt function. But this may be really a question of personal taste or experience. What is more natural? 1) pattern matching 2) recursion or 1) function composition 2) high level functions ? [...] Manlio ___ 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] Making videos of your project
claus.reinke: Perhaps the make a video slogan doesn't quite explain what is intended - it didn't to me!-) Reading John Udell's short article What is Screencasting? http://www.oreillynet.com/pub/a/oreilly/digitalmedia/2005/11/16/what-is-screencasting.html?page=1 gave me a better idea: the screen video part is the modern, animated version of manuals with screenshots, now with audio or text caption annotations (a canned demo). He also gives some tool references, and some suggestions for focussing the bandwidth on useful contents, editing, privacy considerations, etc. Almost certainly, this 2. type 'recordmydesktop' 3. do something with haskell 4. hit control-C 5. upload out.ogv to youtube is not a useful recipe - screencasts need planning of the steps one wants to demonstrate, editing out of aimless moving around or thinking about what to show next, annotations that guide the viewer (text labels or audio track that explains what can be seen, or what keyboard shortcuts are used, or what the plan is), and probably several attempts to get one useful result (minimal bandwith/length/.. with maximal ah, that is how I do it or ah, that is how it works or cool, I want to install that effect). But with a little effort, this could be very useful, more so than simple screenshots, lots of text, or combinations thereof, if the focus is not so much on producing a video to watch, but on showing potential users what they are going to see, and how to work with it if they decide to install it. For instance, I'd now like to replace my old tour of haskellmode for Vim with a screencast. Great! Yes, this is exactly what I hope. It is so much clearer why I would want to use something when I can see it in use. As a windows user, I tried playing with CamStudio and that almost seems to do the job (capture, annotation, replay, conversion of .avi to compressed .swf) but I don't like the resolution of the .swf it generates (screen text isn't as readable as I've seen in other screencasts). Perhaps I'm missing an option to improve the quality, or can anyone recommend another free tool for windows, from positive experience (wikipedia has a whole list of tools http://en.wikipedia.org/wiki/Comparison_of_screencasting_software )? For the purpose I have in mind, it would be good to have many small pieces of screencast, one for each feature, or even better, one continuous screencast with the ability to link directly to sections dealing with particular topics - a hyperlinked animation. Is that supported by some (free) tool? That would be very cool. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Conal Elliott ha scritto: Another helpful strategy for the reader is to get smarter, i.e. to invest effort in rising to the level of the writer. Or just choose a different book if s/he prefers. - Conal This strategy is doomed to failure, unfortunately. We live in the real world, compromises are necessary. [...] Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Exception handling in numeric computations
Jake McArthur j...@pikewerks.com writes: Xiao-Yong Jin wrote: | The problem is that there will be many functions using such | a function to invert a matrix, making this inversion | function return Either/Maybe or packing it in a monad is | just a big headache. I disagree. If you try to take the inverse of a noninvertable matrix, this is an *error* in your code. Catching an error you created in pure code and patching it with chewing gum it is just a hack. A monadic approach (I'm putting Either/Maybe under the same umbrella for brevity) is the only solution that makes any sense to me, and I don't think it's ugly as you are making it out to be. Then, why is 'div' not of type 'a - a - ArithExceptionMonad a' ? Why does it throws this /ugly/ /error/ when it is applied to 0? Why is it not using some beautiful 'ArithExceptinoMonad'? Is 'Control.Exception' just pure /ugly/ and doesn't make any sense? | It is impractical to use method (a), | because not every function that uses 'invMat' knows how to | deal with 'invMat' not giving an answer. So we need to use | method (b), to use monad to parse our matrix around. | | invMat :: Matrix - NumericCancerMonad Matrix | | It hides the exceptional nature of numerical computations | very well, but it is cancer in the code. Whenever any | function wants to use invMat, it is mutated. This is just | madness. You don't want to make all the code to be monadic | just because of singularities in numeric calculation. For functions that don't know or don't care about failure, just use fmap or one of its synonyms. ~scalarMult 2 $ invMat x See? The scalarMult function is pure, as it should be. There is no madness here. Of course, 'scalarMult' is invulnerable and free of monad. But take a look at the following functions, f1 = scalarMult 2 . invMat f2 l r = l `multMat` invMat r ff :: Matrix - Matrix - YetAnotherBiggerMonad Matrix ff x y = do let ff' = f1 x + f2 y put . (addMat ff') . f1 get tell $ f2 ff' when (matrixWeDontLike (f1 ff') $ throwError MatrixWeDontLike return $ scalarMult (1/2) ff' Yes, I know, it's not really complicate to rewrite the above code. But, what do I really gain from this rewrite? -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The votes are in!
If any one seconds the motion, i'm picking up this part of the thread and putting it in the humor section of the haskell wiki. /jve On Tue, Mar 24, 2009 at 4:48 PM, Ross Mellgren rmm-hask...@z.odi.ac wrote: import Diebold.Unsafe (unsafeChangeVotes)... ? -Ross On Mar 24, 2009, at 4:47 PM, John Van Enk wrote: Unless there's a rogue unsafeChangeVotes call in there somewhere. On Tue, Mar 24, 2009 at 4:46 PM, Ross Mellgren rmm-hask...@z.odi.acwrote: Doesn't matter how many times you seq the results, the thunk has been forced. -Ross On Mar 24, 2009, at 4:45 PM, FFT wrote: I demand a recount! The one that launches the missile should have won! 2009/3/24 Eelco Lempsink ee...@lempsink.nl: The results of the Haskell logo competition are in! You can view them at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl ?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath Congratulations Jeff Wheeler! I'll set up a page with the results visibile. -- Regards, Eelco Lempsink ___ 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 -- /jve ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Grouping - Map / Reduce
Hi,
let say I got an unordered lazy list of key/value pairs like
[('a', 99), ('x', 42), ('a', 33) ... ]
and I need to sum up all the values with the same keys.
So far I wrote a naive implementation, using Data.Map, foldl and insertWith.
The result of this grouping operation, which is effectively another list
of key/value pairs, just sums this time, needs to be further processed.
The building of this map is of course a bottleneck, the successive
processing needs to wait until the entire list is eventually consumed
the Map is built and flattened again.
Is there another way of doing this, something more streaming
architecture like?
Is Googles Map - Reduce related to this?
Günther
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Sometimes that is very hard when the writer is way smarter than the reader :-) 2009/3/24 Conal Elliott co...@conal.net Another helpful strategy for the reader is to get smarter, i.e. to invest effort in rising to the level of the writer. Or just choose a different book if s/he prefers. - Conal On Tue, Mar 24, 2009 at 1:44 PM, Manlio Perillo manlio_peri...@libero.itwrote: Yitzchak Gale ha scritto: [...] So the bottom line is that Manlio is right, really. It's just that Haskell is still very different than what most programmers are used to. So it does take a while to get a feeling for what is too smart. Right, you centered the problem! The problem is where to place the separation line between normal and too smart. Your function is readable, once I mentally separate each step. For someone with more experience, this operation may be automatic, and the function may appear totally natural. When writing these dense function, it is important, IMHO, to help the reader using comments, or by introducing intermediate functions. Manlio ___ 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] about Haskell code written to be too smart
* Manlio Perillo wrote: But this may be really a question of personal taste or experience. What is more natural? 1) pattern matching 2) recursion or 1) function composition 2) high level functions Composition of library functions is usually much more readable than hand written recursion, simply because the typical idiom is highlighted instead of checking yourself, that there is no strange matching against the obvious case. Composition of library functions is usually much more efficient and preferable than hand written recursion, simply because the fine tuned fusion capabilities. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Hah! It sure is. :) On Tue, Mar 24, 2009 at 2:17 PM, Peter Verswyvelen bugf...@gmail.comwrote: Sometimes that is very hard when the writer is way smarter than the reader :-) 2009/3/24 Conal Elliott co...@conal.net Another helpful strategy for the reader is to get smarter, i.e. to invest effort in rising to the level of the writer. Or just choose a different book if s/he prefers. - Conal On Tue, Mar 24, 2009 at 1:44 PM, Manlio Perillo manlio_peri...@libero.it wrote: Yitzchak Gale ha scritto: [...] So the bottom line is that Manlio is right, really. It's just that Haskell is still very different than what most programmers are used to. So it does take a while to get a feeling for what is too smart. Right, you centered the problem! The problem is where to place the separation line between normal and too smart. Your function is readable, once I mentally separate each step. For someone with more experience, this operation may be automatic, and the function may appear totally natural. When writing these dense function, it is important, IMHO, to help the reader using comments, or by introducing intermediate functions. Manlio ___ 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] about Haskell code written to be too smart
The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw On Tue, Mar 24, 2009 at 2:11 PM, Manlio Perillo manlio_peri...@libero.itwrote: Conal Elliott ha scritto: Another helpful strategy for the reader is to get smarter, i.e. to invest effort in rising to the level of the writer. Or just choose a different book if s/he prefers. - Conal This strategy is doomed to failure, unfortunately. We live in the real world, compromises are necessary. [...] Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
On Tue, Mar 24, 2009 at 10:11 PM, Manlio Perillo manlio_peri...@libero.itwrote: This strategy is doomed to failure, unfortunately. So it is the good strategy, because Haskell's slogan is avoid success at all cost :-) We live in the real world, compromises are necessary. I don't think so. It's just that we have different kinds of people with different skills. If you try to please the whole world, you please nobody. As a beginner Haskeller, I just know I need more practice. folding is now natural to me, but monad transformers and applicative stuff not yet, but that's a matter of time. I just need to practice practice practice. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
On Tue, Mar 24, 2009 at 1:42 PM, Manlio Perillo
manlio_peri...@libero.it wrote:
But, as an example, when you read a function like:
buildPartitions xs ns = zipWith take ns . init $ scanl (flip drop) xs ns
that can be rewritten (argument reversed) as:
takeList :: [Int] - [a] - [[a]]
takeList [] _ = []
takeList _ [] = []
takeList (n : ns) xs = head : takeList ns tail
where (head, tail) = splitAt n xs
I think that there is a problem.
This crops up all the time even in simple mathematics. One way to
provide assistance to newcomers is to provide a quasi-English reading
of the notation. Take as an example a simple set comprehension
expression (using Z email notation,
http://csci.csusb.edu/dick/samples/z.lexis.html):
{ x : Int | 0 x 10 /\ x %e Odd @ 2*x }
That's pretty opaque for beginners until they learn to read | as such
that, %e as member of and @ as generate, so that they can express
the idea in quasi-English: form a set by taking all integers x such
that ... and ..., then generate the result by doubling them or the
like. Or take | as filter and @ as map; the point is it helps to
be able to express it in something like natural language.
Do something similar for your buildPartitions definition and I'll bet
you'll end up with something much more user friendly than takeList.
-gregg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
2009/3/24 Peter Verswyvelen bugf...@gmail.com: But aren't these two definitions different algoritms? At first sight I think the second one is more efficient than the first one. Some performance numbers: -- module Main where import System.Environment (getArgs) import Control.Monad.State (State(..), evalState) takeList1, takeList2, takeList3 :: [Int] - [a] - [[a]] takeList1 [] _ = [] takeList1 _ [] = [] takeList1 (n : ns) xs = head : takeList1 ns tail where (head, tail) = splitAt n xs takeList2 ns xs = zipWith take ns . init . scanl (flip drop) xs $ ns takeList3 = evalState . mapM (State . splitAt) test :: Int - [[Int]] test n = takeList1 (take n [1..]) [1..] main :: IO () main = print . sum . map sum . test . read . head = getArgs -- compile with: ghc --make TakeList.hs -o takeList1 -O2 $ time ./takeList1 5000 739490938 real0m6.229s user0m5.787s sys 0m0.342s $ time ./takeList2 5000 739490938 real0m5.089s user0m4.455s sys 0m0.348s $ time ./takeList3 5000 739490938 real0m6.224s user0m5.750s sys 0m0.347s -- regards Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Miguel Mitrofanov wrote: takeList = evalState . mapM (State . splitAt) However, ironically, I stopped using them for pretty much the same reason that Manlio is saying. Are you saying there's a problem with this implementation? It's the only one I could just read immediately. The trick is to see that evalState and State are just noise for the type inferencer so we just need to think about mapM splitAt. This turns a sequence of integers into a sequence of splitAts, each one chewing on the leftovers of the previous one. *Way* easier than both the zipWith one-liner and the explicit version. It says exactly what it means, almost in English. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Exception handling in numeric computations
On Tue, Mar 24, 2009 at 3:14 PM, Xiao-Yong Jin xj2...@columbia.edu wrote: Jake McArthur j...@pikewerks.com writes: Xiao-Yong Jin wrote: | The problem is that there will be many functions using such | a function to invert a matrix, making this inversion | function return Either/Maybe or packing it in a monad is | just a big headache. I disagree. If you try to take the inverse of a noninvertable matrix, this is an *error* in your code. Catching an error you created in pure code and patching it with chewing gum it is just a hack. A monadic approach (I'm putting Either/Maybe under the same umbrella for brevity) is the only solution that makes any sense to me, and I don't think it's ugly as you are making it out to be. Then, why is 'div' not of type 'a - a - ArithExceptionMonad a' ? Why does it throws this /ugly/ /error/ when it is applied to 0? Why is it not using some beautiful 'ArithExceptinoMonad'? Is 'Control.Exception' just pure /ugly/ and doesn't make any sense? It's a proof obligation, like using unsafePerformIO. It is okay to use unsafePerformIO when it exhibits purely functional semantics, but it's possible to use it incorrectly, and there is no ImpureSemanticsException. If you are being rigorous, you simply have to prove that the denominator will not be zero, rather than relying on it to be caught at runtime. You can move the check to runtime easily: safeDiv x 0 = Nothing safeDiv x y = Just (x `div` y) Going the other way, from a runtime check to an obligation, is impossible. | It is impractical to use method (a), | because not every function that uses 'invMat' knows how to | deal with 'invMat' not giving an answer. So we need to use | method (b), to use monad to parse our matrix around. | | invMat :: Matrix - NumericCancerMonad Matrix | | It hides the exceptional nature of numerical computations | very well, but it is cancer in the code. Whenever any | function wants to use invMat, it is mutated. This is just | madness. You don't want to make all the code to be monadic | just because of singularities in numeric calculation. For functions that don't know or don't care about failure, just use fmap or one of its synonyms. ~scalarMult 2 $ invMat x See? The scalarMult function is pure, as it should be. There is no madness here. Of course, 'scalarMult' is invulnerable and free of monad. But take a look at the following functions, f1 = scalarMult 2 . invMat f2 l r = l `multMat` invMat r ff :: Matrix - Matrix - YetAnotherBiggerMonad Matrix ff x y = do let ff' = f1 x + f2 y put . (addMat ff') . f1 get tell $ f2 ff' when (matrixWeDontLike (f1 ff') $ throwError MatrixWeDontLike return $ scalarMult (1/2) ff' Yes, I know, it's not really complicate to rewrite the above code. But, what do I really gain from this rewrite? -- c/*__o/* \ * (__ */\ ___ 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] about Haskell code written to be too smart
On Tue, Mar 24, 2009 at 4:11 PM, Manlio Perillo manlio_peri...@libero.itwrote: Conal Elliott ha scritto: Another helpful strategy for the reader is to get smarter, i.e. to invest effort in rising to the level of the writer. Or just choose a different book if s/he prefers. - Conal This strategy is doomed to failure, unfortunately. We live in the real world, compromises are necessary. It depends, IMO. Making changes to the programming style one uses, in particular ones such as you propose, would ultimate lead to programs in haskell being less flexible and/or powerful than if they are. I'm a bit new to haskell myself, but I do understand that one of the primary uses cases and/or motivating factors for using Haskell is when you really just NEED that extra abstraction and power you get from being able to do these types of things. Someone once said that simple problems should be simple and difficult problems should be possible. That doesn't mean the difficult problems become EASY. One of the best uses for haskell is solving difficult problems. It's obviously still going to be difficult to solve, and as such the writer (and hence by extension the reader) is going to have to be smart as well. C++ is actually beginning to suffer the complexity problem as well, especially with C++0x, but I fundamentally disagree with the added complexity in C++, specifically because it is a language which is supposed to excel at solving solve all kinds of problems. Haskell excels at solving difficult problems, so I don't think the target audience for Haskell necessarily needs to include people who can't figure out difficult code. C++ otoh they need to agree on a target audience or set of problems that it's geared toward, and then either s**t or get off the pot. It's fine if they keep adding complexity until the cows come home, but just agree up front that that's what it is and programmers who aren't cut out for it use a different language. With Haskell I think you have that up-front agreement, so there's no problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Exception handling in numeric computations
On Tue, Mar 24, 2009 at 3:28 PM, Luke Palmer lrpal...@gmail.com wrote: On Tue, Mar 24, 2009 at 3:14 PM, Xiao-Yong Jin xj2...@columbia.eduwrote: Jake McArthur j...@pikewerks.com writes: Xiao-Yong Jin wrote: | The problem is that there will be many functions using such | a function to invert a matrix, making this inversion | function return Either/Maybe or packing it in a monad is | just a big headache. I disagree. If you try to take the inverse of a noninvertable matrix, this is an *error* in your code. Catching an error you created in pure code and patching it with chewing gum it is just a hack. A monadic approach (I'm putting Either/Maybe under the same umbrella for brevity) is the only solution that makes any sense to me, and I don't think it's ugly as you are making it out to be. Then, why is 'div' not of type 'a - a - ArithExceptionMonad a' ? Why does it throws this /ugly/ /error/ when it is applied to 0? Why is it not using some beautiful 'ArithExceptinoMonad'? Is 'Control.Exception' just pure /ugly/ and doesn't make any sense? It's a proof obligation, like using unsafePerformIO. It is okay to use unsafePerformIO when it exhibits purely functional semantics, but it's possible to use it incorrectly, and there is no ImpureSemanticsException. If you are being rigorous, you simply have to prove that the denominator will not be zero, rather than relying on it to be caught at runtime. You can move the check to runtime easily: safeDiv x 0 = Nothing safeDiv x y = Just (x `div` y) Going the other way, from a runtime check to an obligation, is impossible. (well, except for div x y = fromJust (safeDiv x y).. but the runtime check is still there in terms of operation) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Exception handling in numeric computations
Daniel Yokomizo daniel.yokom...@gmail.com writes: On Tue, Mar 24, 2009 at 1:27 PM, Xiao-Yong Jin xj2...@columbia.edu wrote: Henning Thielemann lemm...@henning-thielemann.de writes: Try to never use exception handling for catching programming errors! Division by zero is undefined, thus a programming error when it occurs. http://www.haskell.org/haskellwiki/Error http://www.haskell.org/haskellwiki/Exception I'm afraid, a Maybe or Either or Exceptional (see explicit-exception package) return value is the only way to handle exceptional return values properly. Maybe in the larger context of your problem zero denominators can be avoided? Then go this way. Using div is just an example I'm testing with what I read in the book Real World Haskell. The real thing I'm trying to do is inverting a matrix. Say, I want to write invMat :: Matrix - Matrix You won't be able to invert all the matrix, mathematically. And computationally, even a larger set of matrix might fail to be inverted because of the finite precision. It is relatively easier and more efficient to spot such a problem within this 'invMat' function. Because testing the singularity of a matrix is equally hard as invert it. So all I can do when 'invMat' spot a singular matrix are a) Return Either/Maybe to signal an error. b) Wrap it in a monad. c) Define a dynamic exception and throw it. In general if a function is partial we can either make it total by extending its range or restricting its domain. Also we can signal it using runtime or compile-time mechanisms. Options a b are equivalent (i.e. extend the range, compile-time notification) and option c is also another way of extending the range, but using runtime notification. If we try the other approach, we need to express the totality of invMat by restricting its domain, so we can add, for example, a phantom type to Matrix to signal it is invertible. As you need to construct the Matrix before trying to invert it you can always make the constructors smart enough to bundle the Matrix with such properties. Of course there's need to do some runtime verifications earlier, but the clients of invMat are required to do the verification earlier or pass it to their clients (up to the level that can handle with this issue): data Invertible tryInvertible :: Matrix a - Maybe (Matrix Invertible) invMat :: Matrix Invertible - Matrix Invertible You could use different forms of evidence (e.g. phantom types, type classes) but the idea is the same. This is theoretically sound, we can make a type 'Integer Invertible' and make a 'safeDiv' to get rid of one of the ArithException. But as I said above, testing the singularity of a matrix is equally hard as inverting it, doing it with matrix is more impractical than make 'div' safe. I don't mind my haskell code runs 6 times slower than c++ code. But I'm not ready to make it 10 times slower just because I want to do something twice and it might as well be useless most of the time. -- c/*__o/* \ * (__ */\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
On Tue, 2009-03-24 at 22:33 +0300, Eugene Kirpichov wrote: Pretty cool once you know what the function does, but I must admit I wouldn't immediately guess the purpose of the function when written in this way. I wouldn't immediately guess the purpose of the function written in any way. I think, in general, the best way to document the purpose of the function is -- | Split a function into a sequence of partitions of specified lenth takeList :: [Int] - [a] - [[a]] jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
