[Haskell-cafe] Re: New slogan... (A long speculation)
On 2007-10-15, [EMAIL PROTECTED] wrote: ok writes: On 11 Oct 2007, at 1:00 pm, [EMAIL PROTECTED] wrote: An anonymous called ok writes: I am not anonymous. That is my login and has been since 1979. Oh, bother... According to my imperfect knowledge of English, an anonymous is somebody who doesn't sign his/her letters. And doesn't unveil his name. Just OK as login, even since 1979, is still anonymous, whatever you may say. In my dialect, anonymous is never used as noun, solely an adjective. Further, maintaining the same identity but not revealing the corresponding legal identity is pseudonymous. Pseudonym can be used as a noun, but it refers strictly to the name itself, and never the bearer. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-curry, classical logic, excluded middle
Now that that works, one more question. Is it possible to hide the r that is attached to every single type? For example to do something like this (which doesn't compile): No answer needed. Duh.. I can just pick r to be any type (like ()). I've got intuitionistic logic and classic logic in haskell types now, using an identical interface/notation (ie. they're swappable for proofs that don't need excluded-middle). The interfaces use infix type names that read similarly to their meanings: logic: http://www.thenewsh.com/%7Enewsham/formal/curryhoward/IntLogic.hs http://www.thenewsh.com/%7Enewsham/formal/curryhoward/ClassLogic.hs and example theorems: http://www.thenewsh.com/%7Enewsham/formal/curryhoward/IntTheorems.hs http://www.thenewsh.com/%7Enewsham/formal/curryhoward/ClassTheorems.hs Should this go up on the wiki somewhere? 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] Hosting of Haskell project
On Sun, Oct 14, 2007 at 21:24:50 +0200, Gour wrote: On Sun, 14 Oct 2007 15:22:13 +0100 Ian Lynagh [EMAIL PROTECTED] wrote: We could perhaps have web pages on projects.haskell.org, and some sort of bug tracker on bugs.haskell.org (or perhaps trac.haskell.org etc). Some days ago I stumbled upon Redmine tracker (http://redmine.org/) written in Ruby (well, Trac is also not Haskell :-) but has support for darcs ;) Just an idea... There is support for darcs in tracs as well. I never got around to writing a blog post about setting up darcs+trac+lighttpd on Debian and by now I fear I've forgotten how I did it... I remember it being remarkably easy though. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
The really amazing thing about the IO Monad in Haskell is that there *isn't* any magic going on. An level of understanding adequate for using the I/O and State monads stuff (that is, adequate for practically anything analogous to what you might do in another language) goes like this:[...] Yes, I am at the stage where I can understand most of whats going on, as you described it in your email. I was wondering if understanding Category Theory would help me model situations better. Thats all :) But for now, I guess I will stick with this. Assuming that its a black box and it does what its supposed to do. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Sun, Oct 14, 2007 at 15:22:13 +0100, Ian Lynagh wrote: On Wed, Oct 10, 2007 at 05:05:28PM +0100, Magnus Therning wrote: I've almost reached a state where I wouldn't be ashamed of sharing the code so I looked into my options of free hosting. It seems I only have one option for publishing the code: - Request a project on code.haskell.org. I could only find one option for a homepage for the project: - Create a page on the Wiki. There seems to be no option when it comes to tracking bugs. :-( I could also not locate any option for publishing haddock pages. :-( We'd like community.haskell.org to be usable for all of this, it just needs someone to ask us for something, and then us to get around to setting it up. Currently source repos go on code.haskell.org. We could perhaps have web pages on projects.haskell.org, and some sort of bug tracker on bugs.haskell.org (or perhaps trac.haskell.org etc). Would it be better to make things consistent for users, and have all projects use trac (or something else), or for each project to be able to easily use the bug tracker of their choice? It sounds like things are moving in a good direction. I have some suggestions on what is currently there: 1. Make sure that requesting an account via the web form works. I was met with a 500 when I tried a few days ago. (I reported it and [rt.haskell.org #92] is the ticket ID.) 2. Make the flow more explicit. It isn't clear that one needs an account before requesting the creation of a project. It doesn't have to be enforced in code on the site, just a bit of text would be enough. My thoughts: - Offer as few options as possible, ideally just offer one. Trac is a good example of something that's good enough. It combines homepage, documentation, bug tracking and VC inspection in one tool. The main reason for offering just one option: minimise the burden administration (I'm assuming administrators are volunteers). Secondary reason: consistency for users. - Have one instance of trac¹ on trac.haskell.org per project. - Have one entry point that is separate from trac.haskell.org. I think this is what Hackage is supposed to be. /M ¹ I'm just using trac and trac.haskell.org as examples without really saying that's what should be used. -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On 10/14/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: If you want I can dig up my old source code where I converted a random number generator from a purely functional approach to a monadic approach, but I'm not sure reading it would help you, it's creating the code yourself that will be useful I guess. Actually I stopped bothering long ago about 'understanding monads'. After reading many blog posts, wikis, tutorials, etc, often multiple times, I developped a fuzzy idea of what you can do using monads, and that's enough for me to use monads like IO, STM, State, Parsec, etc. without too much problems. I use haskell to solve many little problems in my job and I'm damned sad that I can't use it for larger projects. I feel I'm still a long way from identifying a situation where I would need to write my own monad, and be able to do it, but by the time such situation arises, I don't think it'd be too much a problem. That being said, I plead guilty of not provinding feeback where I found the doc lacking. I have no excuse. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Mon, 15 Oct 2007 07:36:55 +0100 Magnus Therning [EMAIL PROTECTED] wrote: There is support for darcs in tracs as well. I never got around to writing a blog post about setting up darcs+trac+lighttpd on Debian and by now I fear I've forgotten how I did it... I remember it being remarkably easy though. I was playing with it in the past, but it's 3rd party, ie. Trac does not have official support. otoh, Redmine has it out-of-the-box and, even more important, Redmine has support for multiple projects (I know a person who plans to configure SF-like service based on Redmine) which is scheduled for Trac-1.0, but considering how long we are waiting for trac-0.11, who know when it will happen... Sincerely, Gour signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: On the verge of ... giving up!
[EMAIL PROTECTED] wrote: However, arguably the biggest imperatives for Haskell 98 was to remove features that would confuse undergraduates. [...] People want to write map instead of fmap. We could have come up with an alternative name for the list-version of map and not showed map to newbies. Couldn't the too much overloading for undergrads issue be solved by providing a LearningPrelude and a RealHackersPrelude? :) The condition is that the former exports the same or less functions with the same or less general types than the latter, so that function names are the same and there's no infantilizing. A stronger condition would be that every valid LearningPrelude program should be a valid RealHackersPrelude program. This is probably preferred, but may be tricky due to overloading ambiguities. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] do
Actually I stopped bothering long ago about 'understanding monads'. I think that's a shame, because when I wrote the source code myself to get from a pure functional approach (passing the object from function to function as an extra argument) to a monadic approach, it was a real eye opener. Many of the different FP techniques, like partial http://www.haskell.org/haskellwiki/Partial_application application, reversed' http://www.haskell.org/haskellwiki/Parameter_order parameter order, lambas http://www.haskell.org/haskellwiki/Anonymous_function , pointfree notation http://haskell.org/haskellwiki/Pointfree etc were required to do this, which might be one of the reasons it's a bit difficult for newbies to see how a monad is just pure FP in disguise. After cracking the code myself, I had so much appreciation for the guys who invented this stuff, it's really the work of a genius, at least that's the way it felt to me. And then the math approach to abstract the whole thing into a type class, so it can be used for many other single-flow (or how should I call that?) computations,... so nice. I can't say that I can write a monad instance myself yet without peeking in the book, but I think I would recognize the pattern if I see code that could make use of monads (at least the simple cases). Now I'm figuring out arrows, and this gives me a feeling like... euh... well... it's even more abstract, it encapsulates any kind of computation, also the ones then can be split into multiple branches (okay, I should not talk about this, I don't really get arrows yet...) Of course, I'm a kind of guy who likes to understand the inner details before I'm really pleased... So for Haskell, I still have a long way to go :) But you seem to be much further ahead than I am when it comes to *using* monads, so your approach is probably better. Just get used to the damn things and accept them (ouch, that feels a lot like religion...) Cheers, Peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of david48 Sent: Monday, October 15, 2007 9:15 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] do On 10/14/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: If you want I can dig up my old source code where I converted a random number generator from a purely functional approach to a monadic approach, but I'm not sure reading it would help you, it's creating the code yourself that will be useful I guess. Actually I stopped bothering long ago about 'understanding monads'. After reading many blog posts, wikis, tutorials, etc, often multiple times, I developped a fuzzy idea of what you can do using monads, and that's enough for me to use monads like IO, STM, State, Parsec, etc. without too much problems. I use haskell to solve many little problems in my job and I'm damned sad that I can't use it for larger projects. I feel I'm still a long way from identifying a situation where I would need to write my own monad, and be able to do it, but by the time such situation arises, I don't think it'd be too much a problem. That being said, I plead guilty of not provinding feeback where I found the doc lacking. I have no excuse. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
Magnus Therning wrote: There is support for darcs in tracs as well. Gour wrote: I was playing with it in the past, but it's 3rd party, ie. Trac does not have official support. I happen to be looking for a project mgmt framework right now. It seems to me that the opposite is true. Trac is a mature app with a huge community of people supporting it and writing plugins, including some departments at NASA. It is being used successfully for many large projects, such as GHC. It will not go away for a long, long time. Much of the Haskell community is already accustomed to Trac. Redmine is quite new. Based on posts and commits, it appears to be maintained by a single person. I don't know of any major project or organization that is using it yet. So I am a little worried that its future is not yet assured. And I am not sure if anyone knows yet how stable it is currently, or how it scales under load. For that reason, I am currently not considering Redmine for my organization. However, Redmine definitely looks nicer and easier to use than Trac. Please let me know if my impression of its stability and track record are wrong. Also - if the Haskell community adopts Redmine, that itself could give it a big push. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
Richard A. O'Keefe writes: (2) The mathematical background of Haskell is extremely important for implementations. Some important data structures and techniques are practical in large part because of the kinds of optimisations that are only straightforward in a language that has such foundations. (3) Beginners do not need to understand all the mathematics behind Haskell to use it. (5) Precisely because it seeks generality, category theory seems difficult to concrete thinkers. And books on category theory tend to be extremely fast-paced, so ideas which are not in themselves particularly esoteric (which may in fact be eminently practical) tend to be presented in a way which people trying to study by themselves have trouble with. So people can be scared off by what _ought_ to be a big help to them. Yes. Yes. And when *additionally* people whose experience/competence is rather weak, spread the fear, hatred and carelessness, I have the impression that this is something similar to a guy in primary school (and this list *is* a kind of school) who bothers the pupils with such discoveries as the differential calculus is a swearword, just to annoy you, you will =never= need that, I live happily without. There IS a problem. The fast pace of Category theory is a bit incomplete diagnosis. For me, what was most annoying was an awful trap. Everything began slowly, and nicely. And authors are kind, helpful, and understanding. And they promise that it is *for me*. Or for Brandon S. Allbery KF8NH... (BTW, Why Andrew Bromage says that the book of Lawvere is pricey? Cambridge Univ. Press sells the Conceptual Mathematics for 33 pounds. This is not so much...) Check some other titles, *free*, please: *Categories for =working comp. sci'ists=, AspertiLungo. *Categorical Primer by Chris Hillman (he - apparently - still revises the next version...) *Gentle introduction to Cat. Th., a calculational approach by Fokkinga. *Basic Cat., by Jaap Van Osten, a course for undergraduates, which begins by saying that for the Author the basic experience counts more than theory. (And, of course, Barr and Wells...) Now, you start reading, it goes smoothly, you understand functors, natural transformations, retracts, initial objects, etc. And then the slope begins to increase exponentially, you hit a wall... It seems that people who finally decided to write books, tutorials, etc. are so conditioned, that they cannot put themselves into a skin of a true profan, even people so perfect, so didactically skilled as Barr and Wells. But as says the quotation from a science-fiction story /Born among the dead/: you must elevate yourself to their level, since you cannot force them to descend to yours... Still, monads, Kleisli triples, etc. belong to the *EASY* part!! === So, if some people really *want* to learn something, some time devote they shall. But, there are some shortcuts as well, although nothing complete. http://en.wikibooks.org/wiki/Haskell/Category_theory is a nice introduction! The paper on Bananas, lenses and barbed wire (Meijer, Fokkinga, Paterson) is almost a compulsory reference. The craziness of generalization/universality is very well exposed in the compilation of Fritz Ruehr, which can be read by *ANYBODY*. There is no hard science inside, just examples! http://www.willamette.edu/~fruehr/haskell/evolution.html Once upon a time, Eric Meijer and Luc Duponcheel wrote a paper entitled On the expressive power of constructor classes, where they proposed a new categorical prelude for Gofer. It is an extremely inspiring paper! (Citeseer shall have it.) Some of ideas therein, in a different setting, can be easily read in the Varmo Vene thesis on coinduction, and other horrible stuff. And, of course, there is a paper by Conor McBride and Ross Paterson on applicative programming with effects, with an interesting discussion *around* monads. http://www.soi.city.ac.uk/~ross/papers/Applicative.pdf ... Ugh. I am afraid I began an infinite, corecursive strem. Perhaps it is time to break it. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] do
On Mon, 15 Oct 2007, Peter Verswyvelen wrote: Actually I stopped bothering long ago about 'understanding monads'. I think that's a shame, because when I wrote the source code myself to get from a pure functional approach (passing the object from function to function as an extra argument) to a monadic approach, where monadic is still pure functional, but somehow tries to hide that ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: but calling split-base base goes directly against all basic assumptions of all packages depending on base. The new base will have a new version number. There is no expectation of compatibility when the major version is bumped; but we do have an informal convention that minor version bumps only add functionality, and sub-minor version bumps don't change the API at all. So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options: - if we rename base, the package will *definitely* be broken - if the package specified an upper bound on its base dependency, it will *definitely* be broken In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. Yes I know we've changed other names - very little in packaging is clear-cut. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Mon, 15 Oct 2007 11:39:27 +0200 Yitzchak Gale [EMAIL PROTECTED] wrote: It seems to me that the opposite is true. Trac is a mature app with a huge community of people supporting it and writing plugins, including some departments at NASA. It is being used successfully for many large projects, such as GHC. It will not go away for a long, long time. Much of the Haskell community is already accustomed to Trac. That's true. Redmine is quite new. Based on posts and commits, it appears to be maintained by a single person. I don't know of any major project or organization that is using it yet. So I am a little worried that its future is not yet assured. And I am not sure if anyone knows yet how stable it is currently, or how it scales under load. I'm doing some small tests and cannot say anything concrete. However, Redmine supports MySQL PostgreSQL (besides SQLite), so that part should scale well. otoh, I am waiting quite long for Trac-0.11 to appear and based on recent post(s) from its devs on ml, it looks it is not so close. Solution for hosting for many projects, should have built-in support for multiple-projects and Trac won't have it for some time. However, Redmine definitely looks nicer and easier to use than Trac. Please let me know if my impression of its stability and track record are wrong. I'll try, although I cannot mimic proper scaling on my localhost with few small projects. Also - if the Haskell community adopts Redmine, that itself could give it a big push. I fully agree and hope someone more qualified (from Haskell community) will take a look too. Sincerely, Gour signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Mon, Oct 15, 2007 at 09:24:28 +0200, Gour wrote: On Mon, 15 Oct 2007 07:36:55 +0100 Magnus Therning [EMAIL PROTECTED] wrote: There is support for darcs in tracs as well. I never got around to writing a blog post about setting up darcs+trac+lighttpd on Debian and by now I fear I've forgotten how I did it... I remember it being remarkably easy though. I was playing with it in the past, but it's 3rd party, ie. Trac does not have official support. Yes, that's true. It seemed very good at the time though and it integrated well with trac. Personally I don't see the 3rd-party state as an issue. otoh, Redmine has it out-of-the-box and, even more important, Redmine has support for multiple projects (I know a person who plans to configure SF-like service based on Redmine) which is scheduled for Trac-1.0, but considering how long we are waiting for trac-0.11, who know when it will happen... It being implemented in Ruby-on-Rails, which I've /read/ has bad scaling properties, could be a problem. I'm also not convinced support for multiple projects is an important feature. It could even pose a problem in the future since, depending on how it's done underneath, it could make migrating a single project off the site more difficult than tarring up a directory and copy it to its new home. I'm somewhat sad to learn trac might be going in that direction. On the other hand Redmine does look cleaner somehow and I've never seen a trac site that is as easy to find my way around as www.redmine.org. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus pgpCzobeAItnw.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
Yes, exactly, but how does one call the way of programming without monads / do notation then, explicitly passing the object? Does this approach have a name? Or just non-monadic style? Henning Thielemann wrote: On Mon, 15 Oct 2007, Peter Verswyvelen wrote: Actually I stopped bothering long ago about 'understanding monads'. I think that's a shame, because when I wrote the source code myself to get from a pure functional approach (passing the object from function to function as an extra argument) to a monadic approach, where monadic is still pure functional, but somehow tries to hide that ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
Peter Verswyvelen writes: Yes, exactly, but how does one call the way of programming without monads / do notation then, explicitly passing the object? Does this approach have a name? Or just non-monadic style? In the jargon of CPS, somehow related to Monads, the constructions which do not use continuations are often called in Direct Style. I think it can be exported to Monads in general. State Monad in particular. IO is different, you *cannot* make it non-monadic. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On 10/15/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: Yes, exactly, but how does one call the way of programming without monads / do notation then, explicitly passing the object? Does this approach have a name? Or just non-monadic style? the painful style ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
On 10/15/07, apfelmus [EMAIL PROTECTED] wrote: Of course, the solution is to first drop n elements and then take tails instead of dropping n elements every time. map (drop n) . tails = tails . drop n O(m*n) O(m) Nice identity. I'll remember this one. With this, we can write a function that returns the last n elements of a list in O(m) time and O(n) space as lasts :: Int - [a] - [a] lasts n xs = head $ [x | (x,[]) - zip (tails xs) (tails $ drop n xs)] and use it as a drop-in replacement main n = print . sum . map read . lasts n . lines = getContents But that's a a two-liner now heh =). Thanks for your great postings, apfelmus. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
2007/10/15, Felipe Lessa [EMAIL PROTECTED]: On 10/15/07, apfelmus [EMAIL PROTECTED] wrote: Of course, the solution is to first drop n elements and then take tails instead of dropping n elements every time. map (drop n) . tails = tails . drop n O(m*n) O(m) Nice identity. I'll remember this one. With this, we can write a function that returns the last n elements of a list in O(m) time and O(n) space as lasts :: Int - [a] - [a] lasts n xs = head $ [x | (x,[]) - zip (tails xs) (tails $ drop n xs)] and use it as a drop-in replacement main n = print . sum . map read . lasts n . lines = getContents But that's a a two-liner now heh =). If we're talking about (more than one)-liners, isn't this simpler to read? Or is it just me lasts n xs = let (_,remn) = splitAt n xs in go xs remn go lag [] = lag go [] _ = error shouldn't happen go (l:ls) (x:xs) = go ls xs -- Daniil Elovkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: On the verge of ... giving up!
Felipe Lessa wrote: apfelmus wrote: Of course, the solution is to first drop n elements and then take tails instead of dropping n elements every time. map (drop n) . tails = tails . drop n O(m*n) O(m) Nice identity. I'll remember this one. Oops, please don't because it's wrong :) Data.List let xs = [1..3] Data.List map (drop 2) . tails $ xs [[3],[],[],[]] Data.List tails . drop 2 $ xs [[3],[]] The first one produces some extra empty lists at the end. In other words, the left hand side and the right hand side have different lengths length . map (drop n) . tails = (+1) . length but length . tails . drop n = (\k - 1 + max 0 (k-n)) . length But the wrong version looks much nicer :) Thanks for your great postings, apfelmus. λ(^_^)λ Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
but calling split-base base goes directly against all basic assumptions of all packages depending on base. The new base will have a new version number. There is no expectation of compatibility when the major version is bumped; but we do have an informal convention that minor version bumps only add functionality, and sub-minor version bumps don't change the API at all. if this is the official interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options: - if we rename base, the package will *definitely* be broken - if the package specified an upper bound on its base dependency, it will *definitely* be broken why do you omit the most popular (because most obvious to users) option? - if base remains what it is and a new package is created providing the rest of base after the split, then every user is happy (that it is currently hard to implement this by reexporting the split packages as base is no excuse) In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. sorry, i don't want to turn package management into a betting system. and i don't see how knowing how much is broken (so cabal can now only work with central hackage?) is any better than avoiding such breakage in the first place. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. but the name that is everywhere does not stand for what the new version provides! any place that is currently referring to 'base' will have to be inspected to check whether it will or will not work with the reduced base package. and any place that is known to work with the new base package might as well make that clear, by using a different name. Yes I know we've changed other names - very little in packaging is clear-cut. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet (provided that someone told it that 'expects: base' can be met by 'provides: rest-base containers ..'). claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
On Oct 15, 2007, at 7:01 , Yitzchak Gale wrote: But I think we are still at the stage where a programmer who wants practical results is better off starting out by learning how to use monads in practice, not by delving into category theory. No argument from a Haskell standpoint. Still, when people here or on #haskell start tossing CT around, it'd be nice to have more than a very vague and probably incorrect notion of what they're saying. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Oct 15, 2007, at 7:02 , [EMAIL PROTECTED] wrote: IO is different, you *cannot* make it non-monadic. Not really true; it's just much more painful. You just e.g. explicitly do what the ghc library's implementation of IO does: construct a chain of functions with an opaque (and optionally(?) existential to enforce the opacity) RealWorld type which is passed as state from one invocation to the next, with the top level application partially applied. Or one of the operationally equivalent tricks used by other Haskell runtime implementations, cf. IO Inside. It's not so much hard as it is far too much busywork for a programmer to want to deal with when programming... hence hiding the scaffolding in the type, which is perhaps the most general description of what a Haskell monad actually is. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Oct 15, 2007, at 7:02 , david48 wrote: On 10/15/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: Yes, exactly, but how does one call the way of programming without monads / do notation then, explicitly passing the object? Does this approach have a name? Or just non-monadic style? the painful style ? Explicit style, cf. my previous message? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
On Oct 15, 2007, at 7:59 , Felipe Lessa wrote:
On 10/15/07, apfelmus [EMAIL PROTECTED] wrote:
lasts :: Int - [a] - [a]
lasts n xs = head $ [x | (x,[]) - zip (tails xs) (tails $ drop
n xs)]
(...)
main n = print . sum . map read . lasts n . lines = getContents
But that's a a two-liner now heh =).
.oO { if you want Perl, you know where to find it... }
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
On Oct 15, 2007, at 9:48 , Brandon S. Allbery KF8NH wrote: On Oct 15, 2007, at 7:02 , [EMAIL PROTECTED] wrote: IO is different, you *cannot* make it non-monadic. Not really true; it's just much more painful. Expanding on this slightly: the neat thing about Haskell's monads is not that they are somehow not pure. It is that they a completely pure and referentially transparent way to capture and safely encapsulate concepts that themselves may *not* be pure or referentially transparent, such as IO --- while simultaneously being useful for concepts that *are* pure and referentially transparent, such as State or Maybe/Either/[]. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke [EMAIL PROTECTED] writes: if this is the official interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? Me too. This is not a criticism nor endorsement of any particular scheme, just a vote in favor of having a - one, single, universal - scheme. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). You need a way to specify foo 1.2 foo 2, which is a suggestion that was tossed around here recently. Also, you'd need foo 1.x for x=2 to be available after foo-2.0 arrives. 'base' aside, I don't think we want a system that requires us to rename a library any time incompatible changes are introduced. The major/minor scheme has worked nicely for .so for ages. I'd like to make the additional suggestion that a major version number of 0 means no compatibility guarantees. Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. Much like 'fps', now known as 'bytestring', no? I had some problems finding it, true, but the upside is that old stuff is free to reference fps until I can get around to test and update things. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet Scrap cabal in favor of 'ghc --make'? :-) Seriously though, how hard would it be to automatically generate a (suggested) build-depends from ghc --make? -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
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: Simon Marlow wrote: Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. but the name that is everywhere does not stand for what the new version provides! any place that is currently referring to 'base' will have to be inspected to check whether it will or will not work with the reduced base package. and any place that is known to work with the new base package might as well make that clear, by using a different name. base changed its API between 2.0 and 3.0, that's all. The only difference between what happened to the base package between 2.0 and 3.0 and other packages is the size of the changes. In fact, base 3.0 provides about 80% the same API as version 2.0. Exactly what percentage change should in your opinion require changing the name of the package rather than just changing its version number? Neither 0% nor 100% are good choices... packaging is rarely clear-cut! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Java - Haskell adjustment
Hi, its Ryan here... I've just come from an intensive course in java and have been thrown into the imperative world of haskell. The problem that I have is extremely simple in java but I am having trouble adjusting my old mindset. A multiset is a collection of items. Each item may occur one or more times in the multiset. All items are of the same type. The scenario we could use is a students' grades for their A levels: 3A, 4B and 2C grades for our pupil 'x'. A multiset may be implemented by a list... so ['A', 'A', 'A', 'B', 'B', 'B', 'B, 'C', 'C'] but this very ineffiecient and tedious. How might one set out into putting this into action thanks... Any help that complements my ideas is welcome _ Feel like a local wherever you go. http://www.backofmyhand.com___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Laziness (was: [Haskell-cafe] Performance problem with random numbers)
On Sun, Oct 14, 2007 at 11:54:54PM +0200, ntupel wrote:
On Sat, 2007-10-13 at 09:56 -0400, Brandon S. Allbery KF8NH wrote:
Now you need to start forcing things; given laziness, things tend to
only get forced when in IO, which leads to time being accounted to
the routine where the forcing happened. If random / randomR are
invoked with large unevaluated thunks, their forcing will generally
be attributed to them, not to functions within the thunks.
(Yes, this means profiling lazy programs is a bit of a black art.)
After more testing I finally realized how right you are. It appears that
my problem is not related to random/randomR but only to laziness. I came
up with a test that doesn't use random numbers at all and still needs
about 2.5 seconds to complete (it is really just meaningless
computations):
Here's a modified version of your code that prints out a real result, by
using sum rather than seq to force the computation:
module Main where
main :: IO ()
main = do let n = 100 :: Int
print $ sum (take n $ test 1 [1,2..])
test :: Int - [Int] - [Int]
test t g =
let (n, g') = next t g
in
n:test t g'
next :: Int - [Int] - (Int, [Int])
next x (y:ys) =
let n = func y
in
if n = 0.5 then (x, ys) else (0, ys)
where
func x = fromIntegral x / (10 ^ len x)
where
len 0 = 0
len n = 1 + len (n `div` 10)
On my computer this takes 4 seconds to run. I can speed it up by an order
of magnitude by writing code that is friendlier to the compiler:
module Main where
main :: IO ()
main = do let n = 100 :: Int
print $ sum (take n $ test 1 [1,2..])
test :: Int - [Int] - [Int]
test t g = map f g
where f :: Int - Int
f y = if func y = 0.5 then t else 0
func :: Int - Double
func x = fromIntegral x / mypow x
mypow 0 = 1
mypow n = 10*(mypow (n `div` 10))
Switching to map and simplifying the structure gained me 30% or so, but the
big improvement came from the elimination of the use of (^) by writing
mypow (ill-named).
I have no idea if this example will help your actual code, but it
illustrates that at least in this example, it's pretty easy to gain an
order of magnitude in speed. (That func is a weird function, by the
way.)
Incidentally, implementing the same program in C, I get:
#include stdio.h
int test(int, int);
double func(int);
int mypow(int);
int mypow(int n) {
double result = 1;
while (n0) {
result *= 10;
n /= 10;
}
return result;
}
double func(int x) {
return x / (double) mypow(x);
}
int test(int t, int y) {
if (func(y) = 0.5) {
return t;
} else {
return 0;
}
}
int main() {
int i;
int sum = 0;
for (i=0;i100;i++) {
sum += test(1,i);
}
printf(sum is %d\n, sum);
return 0;
}
Which runs more than 10 times faster than my Haskell version, so there's
obviously still a lot of room for optimization. :( Incidentally, a version
written in C that uses pow for the 10^(len n) runs in only half the time of
my haskell version (five time the time of the C version I give)--confirming
that pow is indeed a very expensive operation (as I already knew) and that
if you call the pow function it *ought* to dominate your timing. But we've
also still clearly got some seriously painful loop overhead. :(
--
David Roundy
Department of Physics
Oregon State University
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke wrote: if this is the official interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? Yes - I think it would be a good idea to make that convention explicit somewhere (I'm sure we've talked about it in the past, but I can't remember what happened if anything). However, I'd like to separate it from Cabal. Cabal provides mechanism not policy, regarding version numbers. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). base = 2.0 3.0 I believe Cabal is getting (or has got?) some new syntax to make this simpler. why do you omit the most popular (because most obvious to users) option? - if base remains what it is and a new package is created providing the rest of base after the split, then every user is happy (that it is currently hard to implement this by reexporting the split packages as base is no excuse) Omitted only because it isn't implemented. Well, it is implemented, on my laptop, but I'm not happy with the design yet. In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. sorry, i don't want to turn package management into a betting system. and i don't see how knowing how much is broken (so cabal can now only work with central hackage?) is any better than avoiding such breakage in the first place. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). what assumptions does Cabal build in? Yes I know we've changed other names - very little in packaging is clear-cut. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. Using the version number convention mentioned earlier, base-1.0 funcionality is provided by base-1.0.* only. A package can already specify that explicitly. I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. That is possible, but much more work for the maintainer. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux
Thanks for all the feedback. I removed GHC 6.4 and re-installed 6.6.1 and was able to install Haddock and other things in a few seconds. It seems that the GOA and Lambdabot complicated the environment under the hook, I will just leave them alone for now. Life is too short (and haskell has enough other complications) to be installing stuff from source :) Indeed, I don't want to waste time but have no choice (rpm needs root), and in today's world, software should be built by simply config,build,install. Maybe in the academic world, people always have their own machines and root access, but this is not true for people living on ISP accounts (and corporate world too) where root access is restricted. Consider that Haskell is not a mainstream software like perl or java, it is hard to ask sysadmin to put it under root. I was exploring Haskell website and finding more and more things I need to install. The time to figure out how to build each one of them is too much (consider I am a fluent IT software builder). I am wondering why Haskell community does not pacakge a full package that includes ghc, haddock, happy, alex, darcs, cabal, etc... Things that a typical developer will bump into eventually. I understand that putting two large compilers (ghc+hugs) may take a lot space, but for smaller utilities, it would be nice if they are included (if there is no unwelcomed side effect). Steve -Original Message- From: Stefan O'Rear [mailto:[EMAIL PROTECTED] Sent: Friday, October 12, 2007 11:04 PM To: Brandon S. Allbery KF8NH Cc: Lihn, Steve; Haskell-Cafe Haskell-Cafe Subject: Re: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux On Fri, Oct 12, 2007 at 07:31:45PM -0400, Brandon S. Allbery KF8NH wrote: I don't think haddock has to depend on lamdbabot. But I saw Skipping HaddockHoogle during the build. Isn't the Hoogle thing related to Lambdabot? Or they are unrelated. Only insofar has Lambdabot has an interface to Hoogle (which IIRC depends on Haddock knowing how to build Hoogle indexes, which is what that segment is about). Haddock doesn't build the Hoogle stuff by default, IIRC. Besides, Skipping foo is GHC-ese for foo is already up to date, not wasting time... Stefan -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Java - Haskell adjustment
Ryan Bloor wrote: Hi, its Ryan here... I've just come from an intensive course in java and have been thrown into the imperative world of haskell. The problem that I have is extremely simple in java but I am having trouble adjusting my old mindset. A multiset is a collection of items. Each item may occur one or more times in the multiset. All items are of the same type. The scenario we could use is a students' grades for their A levels: 3A, 4B and 2C grades for our pupil 'x'. A multiset may be implemented by a list... so ['A', 'A', 'A', 'B', 'B', 'B', 'B, 'C', 'C'] but this very ineffiecient and tedious. How might one set out into putting this into action thanks... Why do you think a list is inefficient and tedious? It sounds fine for this simple application. If you have complexity constraints which rule a list out, then consider Data.Sequence. Actually Data.Sequence has a very similar API to the programmer; you will feel much like you're using List, but it is faster for certain things. (most things, in fact). Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Java - Haskell adjustment
On Mon, Oct 15, 2007 at 03:49:44PM +0100, Ryan Bloor wrote: Hi, its Ryan here... I've just come from an intensive course in java and have been thrown into the imperative world of haskell. The problem that I have is extremely simple in java but I am having trouble adjusting my old mindset. A multiset is a collection of items. Each item may occur one or more times in the multiset. All items are of the same type. The scenario we could use is a students' grades for their A levels: 3A, 4B and 2C grades for our pupil 'x'. A multiset may be implemented by a list... so ['A', 'A', 'A', 'B', 'B', 'B', 'B, 'C', 'C'] but this very ineffiecient and tedious. You might try, for example, rle encoding : [(3, 'A'), (4, 'B'), (2, 'C')]. Don't know if this would be more efficient for your task, but if you wish to 'just optimize something' you can give that a try. How might one set out into putting this into action thanks... Any help that complements my ideas is welcome _ Feel like a local wherever you go. http://www.backofmyhand.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- pierre ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Java - Haskell adjustment
On Mon, 15 Oct 2007, Ryan Bloor wrote: Hi, its Ryan here... I've just come from an intensive course in java and have been thrown into the imperative world of haskell. The problem that I have is extremely simple in java but I am having trouble adjusting my old mindset. A multiset is a collection of items. Each item may occur one or more times in the multiset. All items are of the same type. The scenario we could use is a students' grades for their A levels: 3A, 4B and 2C grades for our pupil 'x'. A multiset may be implemented by a list... so ['A', 'A', 'A', 'B', 'B', 'B', 'B, 'C', 'C'] but this very ineffiecient and tedious. You might model it using Map Char Int which maps each multiset element to its multiplicity. Maybe 'Char' is not the appropriate type, but an enumeration? data Grade = A | B | C | D | E deriving (Show, Eq, Ord) then use 'Map Grade Int' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
Magnus Therning wrote: On the other hand Redmine does look cleaner somehow and I've never seen a trac site that is as easy to find my way around as www.redmine.org. That site loads slowly for me in Firefox (loading several files per page, perhaps?). In some page's source on that site, it claims to be XHTML, and it puts some Javascript code inside an XML comment, which is stupid. Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] do
Yes indeed, Concurrent Clean actually just passes around the world object in direct/explicit style but uses uniquness typing to make sure nothing happens that would violate the nice FP paradigm (mainly referential transparency?). That is, I think it's like that :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brandon S. Allbery KF8NH Sent: Monday, October 15, 2007 3:49 PM To: [EMAIL PROTECTED] Cc: haskell-cafe Cafe Subject: Re: [Haskell-cafe] do On Oct 15, 2007, at 7:02 , [EMAIL PROTECTED] wrote: IO is different, you *cannot* make it non-monadic. Not really true; it's just much more painful. You just e.g. explicitly do what the ghc library's implementation of IO does: construct a chain of functions with an opaque (and optionally(?) existential to enforce the opacity) RealWorld type which is passed as state from one invocation to the next, with the top level application partially applied. Or one of the operationally equivalent tricks used by other Haskell runtime implementations, cf. IO Inside. It's not so much hard as it is far too much busywork for a programmer to want to deal with when programming... hence hiding the scaffolding in the type, which is perhaps the most general description of what a Haskell monad actually is. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] 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
Re: [Haskell-cafe] do
Peter Verswyvelen writes, about non-monadic IO, after the posting of Brandon S. Allbery, who reacted to my claim that IO Monad is unavoidable: Not really true; it's just much more painful. You just e.g. explicitly do what the ghc library's implementation of IO does: construct a chain of functions with an opaque (and optionally(?) existential to enforce the opacity) RealWorld type which is passed as state from one invocation to the next, with the top level application partially applied. P.V.: Yes indeed, Concurrent Clean actually just passes around the world object in direct/explicit style but uses uniquness typing to make sure nothing happens that would violate the nice FP paradigm (mainly referential transparency?). That is, I think it's like that :) Well, I think I am one of not-so-numerous people on this list who use Clean. (After all, it is the competitor... We might forget about the buzzword Concurrent...) So, I know about unique *World, *FileSystem, *File, etc., I have used it for graphics and for generation of sound. But I didn't find a way to use *really* this awful State# RealWorld in Haskell! Somebody can show me some working examples? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Haskell Selenium bindings, version 0.2.1
Hi, I'm pleased to announce the first external release of a set of Haskell bindings for the Selenium automated web testing system (specifically, the Selenium Remote Control). These bindings make it possible to use Haskell to write test scripts that automatically exercise arbitrary web sites by controlling a web browser. More information on Selenium is available here: http://www.openqa.org/ You can get the tagged release from Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ selenium-0.2.1 Or you can keep up with the development version from darcs (which currently has no changes from 0.2.1): darcs get http://code.haskell.org/selenium Many thanks to Don Stewart for code and design contributions. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
Peter Verswyvelen writes about non-monadic IO, unique external worlds: But... isn't this what the Haskell compiler runtime do internally when IO monads are executed? Passing the RealWorld singleton from action to action? I never looked into any Haskell compiler. Chalmers, or York, don't remember, used continuations, this seems a bit different from the Clean approach, but I don't really know the gory details. To me, no real difference exists between IO monads and Clean's uniques types; it's just a different approach to tackle the same problem. Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
[EMAIL PROTECTED] wrote: Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Jerzy Karczmarczuk Ah yes, I see what you mean now. I have no idea, I guess only unsafePerformIO will allow you to do something like that... But that will completely break referential transparency. But I really don't know. What do the experts have to say? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
And Haskell embedded a logical programming language on accident. On 10/15/07, Manuel M T Chakravarty [EMAIL PROTECTED] wrote: Dan Piponi wrote, On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: He wants to write entire programs in the type system, something like the crazies who write programs in C++ templates such that template expansion does all the work at compile time Crazies? :-) http://homepage.mac.com/sigfpe/Computing/peano.html Having switched from C++ to Haskell (at least in my spare time) I thought I'd escaped that kind of type hackery but it seems to be following me... The way I see, we are trying to come up with a clean way of providing type-level computations (ie, we use and extend the standard theory of HM type systems). C++ embedded a functional language in the type systems mostly by accident, whereas we do it on purpose. Manuel ___ 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] HSSDL (was Pixel Plotter)
I tried this library on Win32. A very nice initiative indeed. Currently, I found the following problems: - as mentioned in the WIN32 readme file, the library does not seem to work with GHCI. Firstly, it seems to look for incorrect DLLs. When I copy SDL.DLL to both SDLmain.DLL and SDL.DLL.DLL, then GHCI starts the Test app, but it hangs as soon as the window is displayed. This behavior is similar to what I initially had with SOE/Gtk, but that got fixed in the latest release of Gtk2HS. Maybe the author of Gtk2HS (Duncan?) and HSSDL (lemmih) could exchange information on how to get it running under GHCI? - the documentation contains links to non-existing files. I had to rename Graphics.IO.SDL.name.html to Graphics-IO-SDL-name.html, then the docs worked. Cheers, Peter Verswyvelen Luke Palmer wrote: YEEESSS!! W00t11 I've been looking for that for a long time. I get so sick of glut... Thanks. Luke On 10/14/07, Roel van Dijk [EMAIL PROTECTED] wrote: I say someone binds SDL[1]. (If it hasn't been done already.) Ask and you shall receive: http://darcs.haskell.org/~lemmih/hsSDL/ I use those SDL bindings to plot pixels with OpenGL and play with 3D stuff in Haskell. ___ 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] do
On Oct 15, 2007, at 13:32 , Peter Verswyvelen wrote: [EMAIL PROTECTED] wrote: Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Ah yes, I see what you mean now. I have no idea, I guess only unsafePerformIO will allow you to do something like that... But that will completely break referential transparency. But I really don't know. What do the experts have to say? Use the source of unsafePerformIO as an example of how to write code which passes around RealWorld explicitly, but without unencapsulating it like unsafePerformIO does. The main problem here, I think, is that because all the GHC runtime's functions that interact with RealWorld (aside from unsafe*IO) are themselves only exported wrapped up in IO, you can't (as far as I know) get at the lower level internal (e.g.) putStrLn' :: RealWorld - String - (# RealWorld,() #) to do I/O in a direct/explicit/non- monadic style. In theory, one could export those and use them directly. (Actually, as a practical matter, IIRC GHC knows about RealWorld and removes all of it when generating cmm code once it's done the job of sequencing Haskell evaluation; I'm not sure how well that would work if you wrote I/O in direct/explicit style. unsafePerformIO doesn't really count for that because it removes the RealWorld itself.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] 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] Re: do
[EMAIL PROTECTED] wrote:
Peter Verswyvelen writes about non-monadic IO, unique external worlds:
But... isn't this what the Haskell compiler runtime do internally
when IO monads are executed? Passing the RealWorld singleton from
action to action?
In GHC, yes.
I never looked into any Haskell compiler. Chalmers, or York, don't
remember,
used continuations, this seems a bit different from the Clean approach, but
I don't really know the gory details.
To me, no real difference exists between IO monads and Clean's uniques
types; it's just a different approach to tackle the same problem.
Yes, *different approach*. So, there *are* differences. Compilers, anyway,
are special applications. I wanted to see - responding to Brandon - a
normal Haskell program, which does IO without monads, that't all.
The problem is then when you hide something, you hide. It is possible to
superpose a kind of monadic framework on unique worlds, files, etc. in
Clean, but the reverse operation goes beyond my horizons.
Some examples, anybody?
Jerzy Karczmarczuk
I don't have examples, but I can show you where the gory details are hiding:
The Haskell 98 standard specifies the API for input/output to be using the IO
monad. If you want to use Haskell 98 to do input/output without the IO monad
then you will find that you cannot do so. I see three ways to go around
Haskell98.
Common caveat: The thing that using the provided IO monad does is provide a
standard way of sequencing two input/output operations. Once you avoid that
sequencing then you indeterminism unless you provide your own sequencing
manually.
The first, which you may decide does not really count, is using
unsafePerformIO or unsafeInterleaveIO and avoiding the sequencing provided
by the IO monad. This still does nothing to tell you about the gory details.
As a cheat: If you use the FFI addendum then you can access all the impure c
input/output functions and lie about their type so that are not in IO. Then you
could manually manage their sequencing and control everything. This comes
closer to understanding how the standard IO operations are implemented in the
gory details.
For the GHC implementation of Haskell it is possible to go inside the IO monad
and operate using the same gory details that GHC uses. This is probably what
you want to see, but note that it is not the only compiler or the only way to do
this.
The details are in the source at
http://darcs.haskell.org/ghc-6.6/packages/base/GHC/
in IOBase.lhs and IO.hs and so on...
From IOBase.lhs I see that GHC uses a newtype around a function of type
State b - (State b, a) to represent IO a.
The State b is actually an unboxed type State# RealWorld. The tuple is
likewise an unboxed (# , #) tuple.
newtype IO a = IO (State# RealWorld - (# State# RealWorld, a #))
unIO :: IO a - (State# RealWorld - (# State# RealWorld, a #))
unIO (IO a) = a
Also in IOBase.lhs this is made into a Functor and, inevitably, a monad:
instance Functor IO where
fmap f x = x = (return . f)
instance Monad IO where
{-# INLINE return #-}
{-# INLINE () #-}
{-# INLINE (=) #-}
m k = m = \ _ - k
return x = returnIO x
m = k = bindIO m k
fail s= failIO s
returnIO :: a - IO a
returnIO x = IO (\ s - (# s, x #))
bindIO :: IO a - (a - IO b) - IO b
bindIO (IO m) k = IO ( \ s -
case m s of
(# new_s, a #) - unIO (k a) new_s
)
failIO :: String - IO a
failIO s = ioError (userError s)
-- | Raise an 'IOError' in the 'IO' monad.
ioError :: IOError - IO a
ioError = ioException
ioException :: IOException - IO a
ioException err = IO $ raiseIO# (IOException err)
Where raiseIO# is from GHC.Prim
http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC-Prim.html
http://darcs.haskell.org/ghc/compiler/prelude/primops.txt.pp
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Laziness (was: [Haskell-cafe] Performance problem with random numbers)
On Mon, 2007-10-15 at 10:48 -0400, David Roundy wrote:
I have no idea if this example will help your actual code, but it
illustrates that at least in this example, it's pretty easy to gain an
order of magnitude in speed. (That func is a weird function, by the
way.)
Thanks for your reply David,
Unfortunately my original problem was that System.Random.{random,
randomR} is used instead of all these weird test functions that I came
up with during experimentation. And I can't force anything inside StdGen
so I see no way of speeding up the original program sans replacing the
random number generator itself. When I did that I became about 4 times
faster than with System.Random but still an order of magnitude slower
than for instance by using the Java implementation (and I can confirm
that (^) is *very* expensive in this context).
Many thanks again,
Thoralf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
You need a way to specify foo 1.2 foo 2, which is a suggestion that was tossed around here recently. but what does such a version range say? that i haven't tested any versions outside the range (because they didn't exist when i wrote my package)? or that i have, and know that later versions won't do? Also, you'd need foo 1.x for x=2 to be available after foo-2.0 arrives. indeed. available, and selectable. so the package manager needs to be able to tell which package versions can be used to fulfill which dependencies. if that decision is based on version numbers alone, we need to be specific about the meaning of version numbers in dependencies. and if the major/minor scheme is to be interpreted as Simon summarised, the only acceptable form of a dependency is an explicit version range (the range of versions known to work). which means that package descriptions have to be revisited (manually) and updated (after inspection) as time goes on. so we seem to be stuck with a choice between breaking packages randomly (because version numbers were too imprecise to prevent breakage accross dependency updates) or having packages unable to compile (because version numbers were needlessly conservative, and newer dependencies that may be acceptable in practice are not listed). neither option sounds promising to me (instead of the package manager managing, it only keeps a record while i have to do the work), so i wonder why everyone else claims to be happy with the status quo? 'base' aside, I don't think we want a system that requires us to rename a library any time incompatible changes are introduced. i was talking only about the base split, as far as renaming is concerned. but i still don't think the interpretations and conventions of general haskell package versioning have been pinned down sufficiently. and i still see lots of issues in current practice, even after assuming some common standards. The major/minor scheme has worked nicely for .so for ages. i'm not so sure about that. it may be better than alternatives, but it includes standards of common practice, interpretation, and workarounds (keep several versions of a package, have several possible locations for packages, renumber packages to bridge gaps or to fake unavailable versions, re-export functionality from specific package versions as generic ones, ...). and i don't think cabal packages offer all the necessary workarounds, even though they face all the same issues. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet Scrap cabal in favor of 'ghc --make'? :-) ultimately, perhaps that is something to aim for. i was thinking of a simpler form, though, just liberating the provider side a bit: - currently, every package provides it's own version only; it is the dependent's duty to figure out which providers may or may not be suitable; this introduces a lot of extra work, and means that no package is ever stable - even if nothing in the package changes, you'll have to keep checking and updating the dependencies! - instead, i suggest that every package can stand for a range of versions, listing all those versions it is compatible with; that way, the dependent only needs to specify one version, and it becomes the provider's duty to check and specify which api uses it is compatible with (for instance, if a package goes through several versions because of added features, it will still be useable with its initial, limited api). of course, if you refine that simple idea, you get to typed interfaces as formally checkable specifications of apis (as in the ML's, for instance). and then you'd need something like 'ghc --make' or 'ghc -M' to figure out the precise interface a package depends on, and to provide a static guarantee that some collection of packages will provide those dependencies. Seriously though, how hard would it be to automatically generate a (suggested) build-depends from ghc --make? i'd like to see that, probably from within ghci. currently, you'd have to load your project's main module, then capture the 'loading package ...' lines. there is a patch pending for ghci head which would give us a ':show packages' command. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
but the name that is everywhere does not stand for what the new version provides! any place that is currently referring to 'base' will have to be inspected to check whether it will or will not work with the reduced base package. and any place that is known to work with the new base package might as well make that clear, by using a different name. base changed its API between 2.0 and 3.0, that's all. The only difference between what happened to the base package between 2.0 and 3.0 and other packages is the size of the changes. In fact, base 3.0 provides about 80% the same API as version 2.0. so it is not just an api extension, nor an api modification with auxiliary definitions to preserve backwards api compatibility, nor a deprecation warning for api features that may disappear in the distant future; it is an api shrinkage - features that used to be available from dependency 'base' no longer are. and it isn't just any package, it is 'base'! the decision to make the difference visible in package names was made when subpackages were created from the old base. if cabal can handle multiple versions of base coexisting, and can guess which version was meant when someone wrote 'base', then no renaming is necessary. but if cabal can't handle that (yet), then renaming might be a workaround, to avoid more trouble. if ghc told me that expected type 'base' doesn't match inferred type 'base', i'd file a bug report. why do we throw out such standards when grouping modules into packages? Exactly what percentage change should in your opinion require changing the name of the package rather than just changing its version number? Neither 0% nor 100% are good choices... packaging is rarely clear-cut! then we should ask: why not? it seems to be a standard type system problem: either we have no subtyping, then the types/versions/apis must match precisely, however inconvenient that might be, or we have subtyping, then we need to define what we want it to mean that one package version may be used instead of another. just having names and numbers and schemes that give no guarantees that matches imply compatibility is no solution. i don't want a package manager that tells me: congratulations! your package is 88.745% likely to be buildable, it provides between 45% and 95% of the features your package spec promises (since all promises are informal, no precise validation is possible, but most users should be happy), provided that our dependencies really do provide all the features we depend on (i have no idea what those features might be). go ahead and publish it. let others clean up the mess. oh, and remember to come back every couple of months or so to clean up the mess made by those providing your package's dependencies.. of course, cabal doesn't even tell me that. it lets me publish anything (shouldn't there be a './Setup check' to validate? or is there?) and only gets involved when people try to build what i published, usually months later, when anything might happen (depending on how good my package spec was, and on what happened to the dependencies in the meantime), followed by someone chasing me, then me chasing someone else, or someone giving up. is this too bleak a view?-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
However, I'd like to separate it from Cabal. Cabal provides mechanism not policy, regarding version numbers. but the examples in the cabal docs should reflect the standard interpretation of version numbers. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). base = 2.0 3.0 that only works if older versions of base are kept side by side with base = 3.0. otherwise, any package with that range will refuse to build (which may be better than failing to build), even though nothing in that package has changed, and all the features it depends on are still available. Omitted only because it isn't implemented. Well, it is implemented, on my laptop, but I'm not happy with the design yet. i look forward to hearing more. here, you say you are working on an implementation; earlier, you said that re-exporting modules via several packages was not the way forward. cabal is fairly new and still under development, so there is no need to build in assumptions that are sure to cause grief later (and indeed are doing so already). what assumptions does Cabal build in? its documentation is not very precise about what version numbers mean. going by the examples, i thought that 'base' was an acceptable dependency, but it isn't. i also assumed that lower bounds (foo 1.2) could be relied on, but they can't. perhaps i'm the only one reading the cabal docs this way, but i feel mislead!-) and even if i translate your versioning scheme into cabal dependencies, i end up with explicit version ranges as the only valid option, so the assumption becomes that every package *will* break as its dependencies move on. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. Using the version number convention mentioned earlier, base-1.0 funcionality is provided by base-1.0.* only. A package can already specify that explicitly. not entirely correct. you said that major versions implied api changes. that does not imply that the api is no longer backwards compatible, only that there are sufficiently substantial new features that a version naming them seems called for. while base breaks backwards compatibility, other packages might not do so. and cabal does not allow me to specify anything but a name and a range of numbers as dependencies (there is exposed-modules:, but no imported-modules:), so i can't say which parts of base-1.0 my package depends on, and cabal can't decide which versions of base might be compatible with those more specific dependencies. I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. That is possible, but much more work for the maintainer. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). yes. it's called automatic memory management!-) as long as there's a package X depending on package Y-a.b, package Y-a.b should not disappear. not having to waste time on such issues is one reason why programmers are supposed to prefer haskell over non-functional languages, right?-) claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Equality Question
Hi is const = id? const 'x' 'y' 'x' id 'x' 'x' Cheers, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equality Question
On 10/15/07, PR Stanley [EMAIL PROTECTED] wrote: Hi is const = id? You answered the question yourself const 'x' 'y' 'x' id 'x' 'x' const has another parameter. Their types are id:: a - a const :: a - b - a HTH, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Equality Question
PR Stanley wrote: is const = id? No, const is saturated with 2 arguments, id with 1. const 1 2 - 1 id 1 2 - type error b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: do
Brandon S. Allbery KF8NH wrote: On Oct 15, 2007, at 13:32 , Peter Verswyvelen wrote: [EMAIL PROTECTED] wrote: Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a normal Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Ah yes, I see what you mean now. I have no idea, I guess only unsafePerformIO will allow you to do something like that... But that will completely break referential transparency. But I really don't know. What do the experts have to say? Use the source of unsafePerformIO as an example of how to write code which passes around RealWorld explicitly, but without unencapsulating it like unsafePerformIO does. The main problem here, I think, is that because all the GHC runtime's functions that interact with RealWorld (aside from unsafe*IO) are themselves only exported wrapped up in IO, you can't (as far as I know) get at the lower level internal (e.g.) putStrLn' :: RealWorld - String - (# RealWorld,() #) to do I/O in a direct/explicit/non-monadic style. In theory, one could export those and use them directly. Well, if you import GHC.IOBase then you get newtype IO a = IO (State# RealWorld - (# State# RealWorld, a #)) unIO :: IO a - (State# RealWorld - (# State# RealWorld, a #)) unIO (IO a) = a Then the type of putStrLn: -- putStrLn :: String - IO () means that putStrLn' can be defined as putStrLn' :: String - State# RealWorld - (# State# RealWorld, a #) putStrLn' = unIO . putStrLn Now you have the unboxed tuple and need to work with many 'case' statements to accomplish anything. Also you need to get you hand on State# RealWorld either (1) Honestly, by wrapping your code in IO again and using it normally (2) From a copy, via unsafeInterleaveIO (3) From nowhere, via unsafePerformIO (Actually, as a practical matter, IIRC GHC knows about RealWorld and removes all of it when generating cmm code once it's done the job of sequencing Haskell evaluation; I'm not sure how well that would work if you wrote I/O in direct/explicit style. unsafePerformIO doesn't really count for that because it removes the RealWorld itself.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do
On Oct 15, 2007, at 19:00 , ChrisK wrote: Brandon S. Allbery KF8NH wrote: Use the source of unsafePerformIO as an example of how to write code which passes around RealWorld explicitly, but without unencapsulating it like unsafePerformIO does. The main problem here, I think, is that because all the GHC runtime's functions that interact with RealWorld (aside from unsafe*IO) are themselves only exported wrapped up in IO, you can't (as far as I know) get at the lower level internal (e.g.) putStrLn' :: RealWorld - String - (# RealWorld,() #) to do I/O in a direct/explicit/non-monadic style. In theory, one could export those and use them directly. Well, if you import GHC.IOBase then you get newtype IO a = IO (State# RealWorld - (# State# RealWorld, a #)) unIO :: IO a - (State# RealWorld - (# State# RealWorld, a #)) unIO (IO a) = a Then the type of putStrLn: -- putStrLn :: String - IO () means that putStrLn' can be defined as putStrLn' :: String - State# RealWorld - (# State# RealWorld, a #) putStrLn' = unIO . putStrLn Now you have the unboxed tuple and need to work with many 'case' statements to accomplish anything. Also you need to get you hand on State# RealWorld either (1) Honestly, by wrapping your code in IO again and using it normally (2) From a copy, via unsafeInterleaveIO (3) From nowhere, via unsafePerformIO (4) Honestly but unwrapped, by defining main in the same desugared way (takes State# RealWorld and returns (# State# RealWorld,a #) (or (# State# RealWorld,() #) if you stick to the H98 definition of main's type), allowing the runtime to pass it in and otherwise not doing anything other than propagating it. My real problem was that I incorrectly recalled IO's type to be based on ST, not State (i.e. had a forall to prevent anything from being able to do anything to/with the State# RealWorld other than pass it on unchanged without triggering a type error). I should have realized that was wrong because unsafePerformIO is itself expressible in Haskell (-fglasgow-exts is needed to make # an identifier character and to enable unboxed types and unboxed tuples, but does not make it possible to cross an existential type barrier). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] 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] Help parsing dates and times
I am trying to parse various date and time formats using the parseTime function found in (GHC 6.6.1) Data.Time.Format. The one that is giving me trouble looks like this: 2008-06-26T11:00:00.000-07:00 Specifically, the time zone offset isn't covered by the format parameters given. I can almost parse it with this: %FT%X.000 But that doesn't take into account the -07:00 bit. I'm sure this has been solved - can someone point me to the solution? Thanks in advance. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell libraries for computer vision
http://alberrto.googlepages.com/easyvision An experimental Haskell system for fast prototyping of computer vision and image processing applications. Looks ridiculously cool. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help parsing dates and times
jgbailey: I am trying to parse various date and time formats using the parseTime function found in (GHC 6.6.1) Data.Time.Format. The one that is giving me trouble looks like this: 2008-06-26T11:00:00.000-07:00 Specifically, the time zone offset isn't covered by the format parameters given. I can almost parse it with this: %FT%X.000 But that doesn't take into account the -07:00 bit. I'm sure this has been solved - can someone point me to the solution? Thanks in advance. Is there anything in the parsedate library? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parsedate-2006.11.10 http://hackage.haskell.org/packages/archive/parsedate/2006.11.10/doc/html/System-Time-Parse.html -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
Lennart Augustsson wrote, And Haskell embedded a logical programming language on accident. Well, we are just trying to fix that :) On 10/15/07, *Manuel M T Chakravarty* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dan Piponi wrote, On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: He wants to write entire programs in the type system, something like the crazies who write programs in C++ templates such that template expansion does all the work at compile time Crazies? :-) http://homepage.mac.com/sigfpe/Computing/peano.html Having switched from C++ to Haskell (at least in my spare time) I thought I'd escaped that kind of type hackery but it seems to be following me... The way I see, we are trying to come up with a clean way of providing type-level computations (ie, we use and extend the standard theory of HM type systems). C++ embedded a functional language in the type systems mostly by accident, whereas we do it on purpose. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do
On 10/15/07, ChrisK [EMAIL PROTECTED] wrote:
Also you need to get you hand on State# RealWorld either
(1) Honestly, by wrapping your code in IO again and using it normally
(2) From a copy, via unsafeInterleaveIO
(3) From nowhere, via unsafePerformIO
Or you can get it honestly via lifting:
liftRawIO :: (State# RealWorld - (# State# RealWorld, a #)) - IO a
liftRawIO = GHC.IOBase.IO
main = liftRawIO rawMain
rawMain :: State# RealWorld- (# State# RealWorld, () #)
{- implement rawMain here -}
-- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do
Oops, I read too fast, you mentioned that as #1. On 10/15/07, ChrisK [EMAIL PROTECTED] wrote: Also you need to get you hand on State# RealWorld either (1) Honestly, by wrapping your code in IO again and using it normally Silly me. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] System.Posix
Hello,
In a Hugs environment, I am able to import System.Directory but not to
import System.Posix. Here is my environment ...
.;{Hugs}\packages\*;C:\ftp\CatTheory\Haskell\SOE\graphics\lib\win32\*. I
really want to use the Posix module. Help!!!
Kind regards, Bill Halchin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Tuesday 16 October 2007 11:45, Claus Reinke wrote: how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. Using the version number convention mentioned earlier, base-1.0 funcionality is provided by base-1.0.* only. A package can already specify that explicitly. not entirely correct. you said that major versions implied api changes. that does not imply that the api is no longer backwards compatible, only that there are sufficiently substantial new features that a version naming them seems called for. while base breaks backwards compatibility, other packages might not do so. and cabal does not allow me to specify anything but a name and a range of numbers as dependencies (there is exposed-modules:, but no imported-modules:), so i can't say which parts of base-1.0 my package depends on, and cabal can't decide which versions of base might be compatible with those more specific dependencies. I've been giving only cursory attention to this thread so I might have the wrong end of the stick, or indeed the entirely wrong shrub. If the convention for modifying package versions of form x.y.z is: - increment z for bugfixes/changes that don't alter the interface - increment y for changes that consist solely of additions to the interface, parts of the interface may be marked as deprecated - increment x for changes that include removal of deprecated parts of the interface - (optionally) x == 0 = no guarantee and package maintainers are rigorous in following these rules then specifying dependencies as foo-x, foo-x.y, foo-x.y.z should be sufficient. This rigour could largely be enforced by hackage or an automated build system. foo-x is a shortcut for foo-x.0.0 foo-x.y is a shortcut for foo-x.y.0 foo-x.y.z is satisfied by any foo-i.j.k where i=x, j.k=y.z The 'foo' package name is just an indicator of lineage. foo-2.xxx is not the same package as foo-1.xxx, it's interface is missing something that foo-1.xxx's interface provided. Dependencies of foo shouldn't appear in published cabal files. There is a case for their use in development where you are specifying that you want to depend on the very latest version of foo available, perhaps from darcs. When you publish that latest version number gets burned in, eg foo-2.1.20071016. As for provides/expects and imported-modules instead, isn't that just an arbitrary line drawn in the granularity sand? Perhaps package versions could be expanded to include the type of every function they expose, plus more information to indicate which bugfix version of those functions is present. That's maybe the Right Way... and probably a lot of work. A more convenient place to draw the line seems to be at the package level. I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. That is possible, but much more work for the maintainer. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). yes. it's called automatic memory management!-) as long as there's a package X depending on package Y-a.b, package Y-a.b should not disappear. not having to waste time on such issues is one reason why programmers are supposed to prefer haskell over non-functional languages, right?-) I think it's a no-brainer that old versions of packages should remain available for people to use for 'a long time'. If their dependencies are specified properly they should continue building successfully as time passes. Isn't the main problem the use of foo dependencies and the resulting version guessing/ambiguity? Presumably it's not usually a problem if indirect package dependencies require incompatible versions of a package. Is this a problem with base because it implicitly has a dependency on a particular version of the GHC internals? Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote: so i wonder why everyone else claims to be happy with the status quo? We aren't happy with the status quo. Rather, we know that no matter how much we do, the situation will never improve, so most of us have stopped wasting out time. Furthermore, we know that people who DO offer alternatives instantly lose all public credibility - look at what happened to Alex Jacobson. Stefan (who will readily admit his bleak outlook) signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
stefanor: On Mon, Oct 15, 2007 at 10:57:48PM +0100, Claus Reinke wrote: so i wonder why everyone else claims to be happy with the status quo? We aren't happy with the status quo. Rather, we know that no matter how much we do, the situation will never improve, so most of us have stopped wasting out time. Furthermore, we know that people who DO offer alternatives instantly lose all public credibility - look at what happened to Alex Jacobson. Stefan (who will readily admit his bleak outlook) Be happy: we're about 15 years ahead of the lisp guys. 'cabal install xmonad' works, for example. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Of phantom types and type extentions
All,
I've been casually developing a PacketBB (i.e. Generalized Manet Packet
Format) library in Haskell. I think I have a need to pass state
information as a phantom type - I'll step through the issue now.
With the 'AddressBlock' (S5.2.1 packetBB draft 8), network addresses are
abbreviated as sets of bytes (potentially just one byte each, with a
head or tail identical with other addresses). How many bytes are in the
set is determined, in part, by the type of address stored (ex: IPv4 or
IPv6). Thus, when serializing, I need to provide this information.
Saying this again, but in (simplified) code:
data NetworkAddress a = AddressBlock a =
AddrBlkWire {
lenHd :: Word8,
hd :: [Word8],
lenTl :: Word8,
tl :: [Word8],
nrAddrs :: Word8,
addrs :: [Word8] }
| AddrBlkAbstract [a]
data (NetworkAddress a) = SomeHigherLevelStruct a =
SHLS (AddressBlock a) Word32 Word8
-- length (addrs x) == (TotalAddressLength - lenHd - lenTl) * nrAddrs
I can think of several ways to convert between AddrBlkWire and
ByteStrings:
1) Make separate instance of 'Binary' for each data type element of
NetworkAddress.
instance Binary (AddressBlock IPv4) where
get = ...
put = ...
instance Binary (AddressBlock IPv6) where
get = ...
put = ...
This solution immediately causes problems with every higher level
structure you wish to serialize. For example, now you have to have
individual instance for SHLS, you can't do:
instance (NetworkAddress a) = Binary (SomeHigherLevelStruct a) where
...
2) You can pass another argument into a custom 'get' routine. I see
this as a hack that makes me break a good naming convention.
getNetworkAddress :: Int-- bytes per address
- Get NetworkAddress
3) If you don't worry about decoding, only encoding, then an extra field
in the data structure can fill the void of an extra argument. Also a
hack.
I'm hoping someone here has a better solution. Perhaps I am making a
mountain out of a mole hill, or perhaps this requires one of those type
system extensions I have yet to look hard at. The solution I would want
looks like this:
class NetworkAddress a where
addressByteSize :: a - Int
instance (NetworkAddress a) = Binary (AddressBlock a) where
get = do
lenH - get
h- replicateM get (fromIntegral lenH)
lenT - get
t- replicateM get (fromIntegral lenT)
nr - get
let addrSize = addressByteSize (undefined :: a)
bytes = (addrSize - lenH - lenT) * nr
addrs - replicateM get (fromIntegral bytes)
return ...
The line 'addrSize = ' is what I don't know how to write. How does one
call an instance of a type class without knowing the type at compile
time?
Thanks,
Tom
--
The philosophy behind your actions should never change, on the other
hand, the practicality of them is never constant. - Thomas Main
DuBuisson
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: System.Posix
Hello, I am fairly familiar with 1st order logic ... hence I think I understand where Z (Zed) is going ... i.e. http://en.wikipedia.org/wiki/Z_notation. It seems to be based on the ZFC formal notion of set theory. 1) I have a formal spec in Z (Zed) and the implementation is in ANSI C. Can I (easily!) develop a Haskell implementation from the Zed`specification? The reason I ask is that I don't want to waste a lot of time reading the Zed spec if useless. Kind regards, Vasili Galchin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: do
I actually got this done several hours ago, but my DSL is being
annoying tonight...
Anyway, here's a simple example of how to do explicit/non-monadic I/O
in GHC. (It *only* works in GHC; other compilers have different
internal implementations of IO.) I specifically modeled it to
highlight its resemblance to State.
{-# OPTIONS_GHC -fno-implicit-prelude -fglasgow-exts #-}
import GHC.Base
import GHC.IOBase
import GHC.IO
import GHC.Handle (stdout)
{-
This is horrible evil to demonstrate how to do I/O without the
help of
the IO monad. And yes, it is very much a help.
The trick here is that the type IO is a state-like type: a value
constructor which wraps a function. Thus, working with it manually
requires that we have a runIO.(*) Naively, this looks like
unsafePerformIO;
but in fact it is not, as unsafePerformIO uses the magic builtin
RealWorld#
to create a new State# RealWorld on the fly, but in fact we are
passing on
the one we get from somewhere else (ultimately, the initial state
for main).
(Additionally, we don't unwrap the resulting tuple; we return it.)
This is why runIO is really *safePerformIO* (i.e. entirely normal
I/O).
(*) Well, not absolutely. GHC.IOBase uses unIO instead:
unIO (IO f) = f
I think this is a little cleaner, and better demonstrates how
IO is
really not all that special, but simply a way to pass state
around.
-}
-- treat IO like State, for demonstration purposes
runIO :: IO a - State# RealWorld - (# State# RealWorld,a #)
runIO (IO f) s = f s
-- And here's our simple hello, world demo program
main :: IO ()
main = IO (\s - runIO (putStrLn' hello, world) s)
-- this is just to demonstrate how to compose I/O actions. we could
just
-- call the real putStrLn above instead; it is operationally identical.
-- write a string followed by newline to stdout
-- this is completely normal!
putStrLn' :: String - IO ()
putStrLn' = hPutStrLn' stdout
-- write a string followed by newline to a Handle
hPutStrLn' :: Handle - String - IO ()
hPutStrLn' h str = IO (\s - let (# s',_ #) = runIO (hPutStr' h str) s
in runIO (hPutChar h '\n') s')
-- write a string, iteratively, to a Handle
hPutStr' :: Handle - String - IO ()
hPutStr' _ [] = IO (\s - (# s,() #))
hPutStr' h (c:cs) = IO (\s - let (# s',_ #) = runIO (hPutChar h c) s
in runIO (hPutStr' h cs) s')
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
