[Haskell-cafe] automonadization of code?
Is there any work on automatic translation of code in some tiny imperative language into Haskell code that uses the ST and/or IO monads (or perhaps even pure functional code)? For example, the user writes something vaguely like array = newArray (1,100) 1 for x=2 to 99 array[x] := array[x-1]+array[x+1] And it is transformed into something like foldl (=) (newArray (1,100) 1) $ map (\n arr - do a - readArray arr (n-1) b - readArray arr (n+1) writeArray arr n (a+b) return arr) [2..99] Obviously the small imperative language would have to be highly restricted and carefully chosen in order for the translation to always work and be predictable. I'm interested in any existing work on choosing such a sublanguage. Thanks! - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
Not sure whether this is the right place to discuss computers and programming in general: But Dijkstra's metaphor is suggesting, that while Beethoven learned by experiment and debugging compositions, Mozart did not have a need for reflection while writing down music ? The observation above sounds to me more as a difference between youthful enthousiasm (= allows few time for reflection but a lot for action) and old wisdom (= no risk taking but few action for the young). Also this difference has already been documented in Aristotele's Rethorics. It is of course difficult to transmit the characteristics of old age to young age, or vice versa. Furthermore about Dijkstra's quote on computers and telescopes which I like more. Telescopes are indeed not saying anything at all about the laws of the universe, as computers themselves don't say anything at all about complexity. But I wonder if we would have concepts as gravity or general relativity if we would have never had observed the movement of planets and light with telescopes. Equally, what can parallelity in computers teach us about the concept of monad ? I also find the approach of the designers of telescopes (= computer architects) interesting to understand parallel processes: http://view.eecs.berkeley.edu/wiki/Main_Page I think they use the name dwarfs for monads. PS I like the idea of a book Hakell for Hackers ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Trivial database access in Haskell
Paul The people you want are probably HDBCJohn Goerzen [EMAIL PROTECTED] HaskellDB Anders Höckersten [EMAIL PROTECTED] and Bjorn Bringert [EMAIL PROTECTED] HSQLKrasimir Angelov [EMAIL PROTECTED] Takusen Bayley, Alistair [EMAIL PROTECTED] (did I miss any?) They probably haven't been online since your msg, but I'm sure they'll be keen to help you use the fruit of their labours -- and would welcome your help in documenting them better. You might also find help on the #haskell IRC channel. Simon | OK, thanks for the gentle push. After a bit of digging, I decided that | the takusen link looked like a darcs repository, and I downloaded | darcs and got takusen. I installed GHC 6.6 in a spare VM (no PC round | I can install stuff on just now, I'll do this properly later). On the | assumption that the takusen.cabal file means I should look at Cabal, I | had a dig and found the incantation runhaskell setup.hs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trivial database access in Haskell
Hi Paul, as Simon notes, I maintain HaskellDB. I think that HaskellDB isn't exactly what you are looking for at the moment. You seem to want to run SQL queries, and HaskellDB is designed to free you from writing SQL. I'm not sure if anyone has mentioned it yet, but HSQL 1.7 includes Oracle support (though I haven't tested it). You can get it from http://sourceforge.net/project/showfiles.php? group_id=65248package_id=93958 Here's what I would do in your situation: 1. Join the #haskell IRC channel on irc.freenode.net. 2. Try to install your chosen library. 3. Ask questions in the IRC channel when you run into problems. Chances are that you will have some library and Cabal developers there to help you. /Björn On 12 dec 2006, at 10.11, Simon Peyton-Jones wrote: Paul The people you want are probably HDBCJohn Goerzen [EMAIL PROTECTED] HaskellDB Anders Höckersten [EMAIL PROTECTED] and Bjorn Bringert [EMAIL PROTECTED] HSQLKrasimir Angelov [EMAIL PROTECTED] Takusen Bayley, Alistair [EMAIL PROTECTED] (did I miss any?) They probably haven't been online since your msg, but I'm sure they'll be keen to help you use the fruit of their labours -- and would welcome your help in documenting them better. You might also find help on the #haskell IRC channel. Simon | OK, thanks for the gentle push. After a bit of digging, I decided that | the takusen link looked like a darcs repository, and I downloaded | darcs and got takusen. I installed GHC 6.6 in a spare VM (no PC round | I can install stuff on just now, I'll do this properly later). On the | assumption that the takusen.cabal file means I should look at Cabal, I | had a dig and found the incantation runhaskell setup.hs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: a cabal/database lib experience (was: [Haskell-cafe] Trivialdatabase access in Haskell)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Reinke That situation seems to be slightly embarrassing (if only because we are tempted to think that we have no time for the traditional README and INSTALL files - after all, all darcs/cabal stuff is self-explanatory, isn't it, and has been discussed to death somewhere, hasn't it, and the library does the obvious thing, doesn't it, and isn't quite ready for prime time yet anyway, at which time it is going to be carved in stone and documented thoroughly by a team of Pulitzer-price-winning authors?-) I guess I should comment, as one of the Takusen authors. Yes, this is embarrasing. We have made a number of assumptions which Paul exposed: - users should know to do darcs get, then runhaskell Setup.hs configure/build/install - users should know to look for Haddock docs - users should know how to look for and install dependent libraries (Cabal-1.1.6.1, in this case) If you're an experienced Haskell programmer then these assumptions are valid, so yes, we do need to do more for the novice. It is nice to actually get some kind of feedback, even if negative. It means we can make our library nicer to install and use, which hopefully will encourage more users to install and use it... + add a dedicated command cabal, which does nothing more than runhaskell Setup, but is more memorable and suggestive Did you mean an executable that comes with cabal or the compiler (i.e. in ghc's bin), or something provided by the library author? From my POV (as a library author) I could provide a cabal.bat (for Windows users) and a cabal.sh (for everyone else), but that seems a bit messy. - cabal/darcs/haddock are no replacement for minimal help texts: cabal should require the existence of a README (darcs should complain if there is a *.cabal, but no README..). Yes. I will create one of these. - sample code for trivial queries (aka, I know about databases, but I need to see the way this particular library handles things, so that I can figure out whether it is the right one for me) is not obvious to find We have made a reasonable effort in Takusen to document the API extensively, and give example code. The problem seems to be that the documentation is too well hidden: http://darcs.haskell.org/takusen/doc/html/Database-Enumerator.html The best thing I can think of now is to put a reference to this in the README file. Any other ideas? I wanted to keep the documentation in Haddock (so that it stays close to, and hopefully consistent with, the source) but maybe that's not the best idea for this kind of documentation, which is really a HOW-TO manual. - distributions are bare-boned: Option 2, Takusen, leads to a file listing, but no downloadable package. My fault for not providing a proper release. I'm still learning about darcs, so the instructions in http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_program#Releas es are quite valuable. If you have any further Takusen-specific questions, don't hesitate to contact me. Also, if you're having trouble installing or chasing down dependent libraries then I should be able to help. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Thanks again.
Look all. When I (and I think everybody here) make a discussion about
Haskell, It is not about to dominating anyone('s opinions) or attacking to
Haskell (for Haskell evangelists!); Haskell is great enough that surely will
lead - if not be - the next picture for meaning of SOFTWARE DEVELOPING.
I did not know anything about functional programming. I have a B.S. in
telecommunications and ... as you know one day I woke up in bed lying beside
my beloved codes! And there I became a programmer! Then I came across with
scripting : Ruby! Lovely! Fantastic! At first It was very hard for my
c-writer mind to even understand what this scripting thing is. But at
last I felt It and learned how to do It.
And with more reading, suddenly there was something totally different :
Functional Programming.
See : Reduced of many many type of bugs in your code; why? No side effect!
Debugging! Profiling! Type safety!
So why I say that?
Again see : In less than five years we will have processors with normally
six cores or more and fast hardware - very cheap. Hold that.
So you still want to pay your developers for checking NULL values,
correctness of INTERFACES, writing IF ELSE and SELECT CASEs full of
side effect and junks (Something that can be simply implemented by Pattern
Matching), continuing OO world that has not even a accurate calculus for
describing things (and came from industrial engineering), code that may
crash through exceptions and very stupid-complex execution paths, checking
array out-of rang things, handling and passing and dereferencing pointers
correctly...H! Just calculate that how % of developer's time
is being consumed by this stupid tasks? You know; this will be a big-bang
for commercials! (If their stupid consultants can understand).
I am a usual developer, not smart and academic as you, and not as stupid
ones to pretend to know something better than all. Even this kind of
programming still is very hard for me. I am still struggling with monads and
monad transformers! So I am choosing the hard path - even very hard one.
Why? Because I am sure every mean developer like me can be productive in
functional programming in 6 to 12 months. And imagine that huge bunch of
stupid things that we are handling everyday : Just wast of life and money
without any joy and honor.
This is my vision : FIVE YEARS ...
Best Regards
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: a cabal/database lib experience (was: [Haskell-cafe] Trivialdatabase access in Haskell)
On 12/12/06, Claus Reinke [EMAIL PROTECTED] wrote: if you're using Haskell at all, you *are* the Haskell community. [..lots of I searched, I found, I tried, I got this error, I thought, I tried this workaround, I got to this point, now I'm stuck here..] I just wanted to comment that I find this kind of experience report very helpful, especially if someone does not give up at the first hurdle, and goes through the trouble of writing up all the frustrating steps and thoughts rather than summarizing (it didn't work/I got it to work after some fiddling) - thanks! Thank you! That's exactly the sort of report I was trying to give, although (from my point of view) it's pretty hard to report this sort of thing without feeling like you're giving a complaining and ungrateful impression. It's nice to have the reassurance that I got my message across. On 12/12/06, Bayley, Alistair [EMAIL PROTECTED] wrote: Yes, this is embarrasing. We have made a number of assumptions which Paul exposed: It's hardly embarrassing - as Claus pointed out, the developers of any package are *always* too close to the problem to see this sort of issue. - users should know to do darcs get, then runhaskell Setup.hs configure/build/install - users should know to look for Haddock docs - users should know how to look for and install dependent libraries (Cabal-1.1.6.1, in this case) Yes, those are probably the key ones I tripped up on. If you're an experienced Haskell programmer then these assumptions are valid, so yes, we do need to do more for the novice. One thing that (from my POV as a Windows user) helped enormously in the Python community was adding the ability to distutils (their Cabal equivalent) to build Windows binary installers. With that, it became relatively easy for developers to package up binaries of their libraries, which made the Windows experience a simple download and run one. I've no idea if that is a practical or useful goal for Cabal, and I anticipate it being a long time before I'm at a level of understanding where I could help in implementing it, but it may be something to think about. - sample code for trivial queries (aka, I know about databases, but I need to see the way this particular library handles things, so that I can figure out whether it is the right one for me) is not obvious to find We have made a reasonable effort in Takusen to document the API extensively, and give example code. The problem seems to be that the documentation is too well hidden: http://darcs.haskell.org/takusen/doc/html/Database-Enumerator.html Yes, I suspect that's the case. The best thing I can think of now is to put a reference to this in the README file. Any other ideas? I wanted to keep the documentation in Haddock (so that it stays close to, and hopefully consistent with, the source) but maybe that's not the best idea for this kind of documentation, which is really a HOW-TO manual. Something as simple as here's how to issue a query and print the results in the README would have been enough for me. When I get to that point, I'll write a few lines and let you see what you think. If you have any further Takusen-specific questions, don't hesitate to contact me. Also, if you're having trouble installing or chasing down dependent libraries then I should be able to help. Thanks for the offer. As others have pointed out, the level of help available from the community is excellent - it's just that needing to ask for help puts off those of us who work on a let's just play with this Haskell stuff while my backup runs basis :-) The backup has finished now, so I must run. Thanks again! Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [newbie]any nice code for newbie to read?
On Tue, Dec 12, 2006 at 13:53:57 +0900, 云杨 wrote: hello,all, I am new to haskell,and have read some tutorial, but I would like to read some real code from real haskell project, I believe this will help me study and use haskell quickly. would anyone please give me some suggestion about opensource project that a new haskell user should study? thanks you. People post code on this list every now and then, often that code isn't newbie friendly (my experience as a newbiw myself) but it's still worth it trying to read and understand it. There are a few open-source projects in haskell, at the moment I can think of pugs, darcs and hpodder. I suspect that hpodder might be a good place to start looking. Otherwise I think the majority of haskell code is in libraries. It's been suggested that reading Prelude itself is a good idea. Another strategy would be to get others to comment on _your_ code, and learning that way :-) My personal experience is that posting here, and blogging are good ways of sucking in reviews. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] http://therning.org/magnus Software is not manufactured, it is something you write and publish. Keep Europe free from software patents, we do not want censorship by patent law on written works. It was real. At least, if it wasn't real, it did support them, and as that is what sofas are supposed to do, this, by any test that mattered, was a real sofa. pgpzaOVnWDTFV.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Kaveh Shahbazian [EMAIL PROTECTED] wrote: So you still want to pay your developers for checking NULL values, correctness of INTERFACES, writing IF ELSE and SELECT CASEs full of side effect and junks (Something that can be simply implemented by Pattern Matching), continuing OO world that has not even a accurate calculus for describing things (and came from industrial engineering), code that may crash through exceptions and very stupid-complex execution paths, checking array out-of rang things, handling and passing and dereferencing pointers correctly...H! Just calculate that how % of developer's time is being consumed by this stupid tasks? You know; this will be a big-bang for commercials! (If their stupid consultants can understand). Yes. It's always hard to convince people that they've been doing something the wrong way, though. People includes smart academic types, sometimes, too. I think you're absolutely right, but if you have ideas for what to say in those commercials, you can post them here :-) And of course it's not quite as simple as people have been doing it the wrong way, because sometimes there are reasons even for the kinds of code that look the most horrible on the surface. Functional programming people have a reputation for arrogance -- whether that impression is fair or not and whether that arrogance is merited or not, the impression exists, and some people find it a turn-off. Avoid being the overenthusiastic convert. I am a usual developer, not smart and academic as you, and not as stupid ones to pretend to know something better than all. Even this kind of programming still is very hard for me. I am still struggling with monads and monad transformers! So I am choosing the hard path - even very hard one. Why? Because I am sure every mean developer like me can be productive in functional programming in 6 to 12 months. And imagine that huge bunch of stupid things that we are handling everyday : Just wast of life and money without any joy and honor. This is my vision : FIVE YEARS ... I hope so! And I think if you got to know at least *some* of the smart and academic types, you would find that they struggle sometimes too. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt What is research but a blind date with knowledge? -- Will Henry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
On 12/12/06, Patrick Mulder [EMAIL PROTECTED] wrote: Not sure whether this is the right place to discuss computers and programming in general: You're implying that there's a *more* appropriate forum somewhere for discussing analogies between music composition and programming languages? If so, I'd like to know what it is! But Dijkstra's metaphor is suggesting, that while Beethoven learned by experiment and debugging compositions, Mozart did not have a need for reflection while writing down music ? I've been thinking about this. Are there really any programmers who are like Mozart in the way you describe? Donald Knuth might be one, or at least, he wrote that he wrote and debugged all of TeX on paper before entering it into a computer and only found 13 more bugs (or something like that), once he did. I don't remember if it was 13 exactly, but 13 more bugs might be the closest that any programmer gets to Mozart, or at least any programmer in the 20th or early 21st century. But, can you imagine waking up in the middle of the night, sitting down, and writing a compiler from start to finish? Well, of course, easily, undergrads do it all the time during finals period. But, one that works, and that contains original ideas? I know some awesome programmers, but I don't think any of them are quite that awesome. Whereas it's conceivable to imagine somebody writing a piece of music that way, or a poem. Does that just mean that computer science has a long way to go in maturation? Or does it mean something else? PS I like the idea of a book Hakell for Hackers Maybe Haskell for People Who Want to Be Hackers? (Since, of course, one should never apply the term hacker to oneself.) I'm not sure whether it's best to aim at people who might be already hackers who want to learn Haskell, or people who are already programmers who want to be Haskell hackers, in particular. I suppose that the first group of people is probably larger. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt What is research but a blind date with knowledge? -- Will Henry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Stratified monads
Hello J., Monday, December 11, 2006, 10:20:17 PM, you wrote: Haskell implementations of the transformers in Espinosa's paper are discussed in Mark Jones's 1995 paper Functional Programming with Overloading and Higher-Order Polymorphism, and are available with the mtl package that is (I believe) usable with all the major Haskell compilers and distributed with at least ghc and hugs. (I've never used yhc or jhc, so I don't know what libraries they distribute.) afair, mtl uses multi-parameter type classes which is supportred only by ghc/hugs at now -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On Tue, Dec 12, 2006 at 10:58:18AM +, Kirsten Chevalier wrote: Functional programming people have a reputation for arrogance -- whether that impression is fair or not and whether that arrogance is merited or not, the impression exists, and some people find it a turn-off. Aren't you talking about the LISP community? ;-) Best regards Tomasz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Paul Hudak wrote: Maybe some of you can do better, but it's really tough to show someone how an /advanced/ Haskell programmer would solve /advanced /problems that arise in the real world. As a simple example, I love this recent quote by Garrett Morris: I'm personally fond of framing most non-trivial Haskell problems as defining domain specific languages; as a result, everything over about 200 lines that I've written in the past 3 years has used the mtl [Monad Transformer Library] in some form or fashion. It's great. So how do we teach Garrett's way of programming (which I like very much) to the masses? I don't know either, but I would really like to have that book. I started out with Haskell using resources like SOE, Thomson's Craft of, and the Gentle Introduction. Apart from reading the Structure and Interpretation of Computer Programs, this was my first exposure to functional programming. Some things took a bit of effort to wrap my head around, but it generally wasn't too hard to get to a level where I could write useful programs. Now there is a plethora of introductions, tutorials and guides, and I wonder if we really need yet another 'for dummies' resource? The challenge for me is to learn more advanced practices. This is much harder to do - at least for me - for several reasons: * there is less material describing the advanced stuff * a lot of the existing material is in the form of research papers or similar communications between the cognoscenti. This (often) implies - it is hard to understand for us laymen - it isn't tied to practical problems * I'm already productive with what I know, so I don't have the direct motivation I generally manage to absorb just enough to get by, but I think there is a niche for a book (coupled to practical problems and complete with excercises etc) that is waiting to be filled. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Tomasz Zielonka [EMAIL PROTECTED] wrote: On Tue, Dec 12, 2006 at 10:58:18AM +, Kirsten Chevalier wrote: Functional programming people have a reputation for arrogance -- whether that impression is fair or not and whether that arrogance is merited or not, the impression exists, and some people find it a turn-off. Aren't you talking about the LISP community? ;-) That's exactly the problem! For most people there *is* no difference. You say functional programming to most people, even professional programmers, and usually the only chance you have of getting them to understand what what you mean is by asking so, have you heard of Lisp, or Scheme? Avoiding the question of whether the Lisp community deserves that reputation, *we* need to be sure to avoid acquiring the same. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Research is what I'm doing when I don't know what I'm doing.--Wernher von Braun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Large data structures
Hallo, On 12/11/06, Matthew Brecknell [EMAIL PROTECTED] wrote: Yes. Take a look at Data.Map. This data structure provides various operations which create a new map from an old one in O(log n) time, by splicing bits of the old map into the new one. Importantly, performing any of these operations does not destroy the old map if your code still references it. On the other hand, if your code drops references to the old map, then the garbage collector can reclaim any branches of the old map not used in the new one. You may also be interested in this paper: http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf Thanks for the info and the link, looks interesting. Cheers, -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Hi That's exactly the problem! For most people there *is* no difference. You say functional programming to most people, even professional programmers, and usually the only chance you have of getting them to understand what what you mean is by asking so, have you heard of Lisp, or Scheme? Talking to professional programmers, if I tell anyone I program in Haskell they nearly always say oh, Pascal, that's cool. No one knows what functional programming is, Scheme/Lisp are the closest. Maybe we should try and hijack the phrase functional programming - Haskell is just too similar to Pascal. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Large data structures
Hallo, On 12/12/06, Benjamin Franksen [EMAIL PROTECTED] wrote: Alex Queiroz wrote: On 12/11/06, Stefan O'Rear [EMAIL PROTECTED] wrote: No. Haskell's lists are linked lists, enlarge creates a single new link without modifying (and copying) the original. Thanks. Is there a way to mimic this behaviour with my own code? It is the default for any data structure you define. Data is by default represented internally as a pointer to the actual value. Otherwise recursive structures (see below for an example) would not be easily possible. And since no part of the data structure is 'mutable', different instances can share (memory-wise) as much of their structure as the implementation is able to find. Ok, I think I got it now. :-) PS: Please try to include exactly the relevant context in replies, no more, no less. Your original question (stripped down to the body of the text) would have been relevant, here, but neither 'Hello', nor 'Cheers' are worth quoting. Sorry, but I did not quote hello or cheers. -- -alex http://www.ventonegro.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Neil Mitchell [EMAIL PROTECTED] wrote: Haskell is just too similar to Pascal. That statement sounds very wrong to me :-) -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
ndmitchell: Hi That's exactly the problem! For most people there *is* no difference. You say functional programming to most people, even professional programmers, and usually the only chance you have of getting them to understand what what you mean is by asking so, have you heard of Lisp, or Scheme? Talking to professional programmers, if I tell anyone I program in Haskell they nearly always say oh, Pascal, that's cool. No one knows what functional programming is, Scheme/Lisp are the closest. Maybe we should try and hijack the phrase functional programming - Haskell is just too similar to Pascal. Who wants to join the Lisp is not functional programming movement with me? -- Don If it ain't pure, it ain't functional Stewart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: a cabal/database lib experience
Claus Reinke wrote: cabal: - the separation into interpreter/compiler and resource as Setup does not set up the right mindset in users. for instance, you can runhaskell Setup.hs --help as for most unixy tools, but who'd think of that in this situation, and how much does it help? + add a dedicated command cabal, which does nothing more than runhaskell Setup, but is more memorable and suggestive cabal-setup does this, but wasn't included with the latest release of Cabal. It should be in the next one, I hope. The plan is to deprecate 'runhaskell Setup.lhs' in favour of 'cabal-setup'. Feel free to suggest changing the name to 'cabal', although some might argue that 'cabal-get' is the high-level tool and should therefore get the name 'cabal' instead. - cabal/darcs/haddock are no replacement for minimal help texts: cabal should require the existence of a README absolutely, this has occurred to me too. There should be a stanard Cabal README file, and Don's mkcabal tool could drop it in the tree. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: a cabal/database lib experience
simonmarhaskell: Claus Reinke wrote: cabal: - the separation into interpreter/compiler and resource as Setup does not set up the right mindset in users. for instance, you can runhaskell Setup.hs --help as for most unixy tools, but who'd think of that in this situation, and how much does it help? + add a dedicated command cabal, which does nothing more than runhaskell Setup, but is more memorable and suggestive cabal-setup does this, but wasn't included with the latest release of Cabal. It should be in the next one, I hope. The plan is to deprecate 'runhaskell Setup.lhs' in favour of 'cabal-setup'. Feel free to suggest changing the name to 'cabal', although some might argue that 'cabal-get' is the high-level tool and should therefore get the name 'cabal' instead. - cabal/darcs/haddock are no replacement for minimal help texts: cabal should require the existence of a README absolutely, this has occurred to me too. There should be a stanard Cabal README file, and Don's mkcabal tool could drop it in the tree. This occurred to me too. My current plan for mkcabal is that it creates: foo.cabal Setup.lhs README LICENSE based on a series of interactive questions, or command line args. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Good Haskell introduction for an Ocaml programmer?
Greetings, all. I'm an experienced Ocaml programmer, looking to broaden my horizons yet further and pick up Haskell, and I'm wondering if there's a good introduction to Haskell for me. I have Simon Thompson's Haskell: The Craft of Functional Programming, which isn't a bad book, but I'm something of a special case. I'm already familiar with and comfortable with a lot of concepts which are new to your average C++/Java programmer- things like symbolic computation and recursion as looping and applicative data structures. So churning through introductions to these concepts looking for the rare nugget of new information is, well, kinda boring. On the other hand there are a lot of Haskell concepts I'm not comfortable with, like monads. So I was wondering if there was a better introduction for me out there? I'm willing to pay for a book or read something online, whichever. Thanks, Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Good Haskell introduction for an Ocaml programmer?
bhurt: Greetings, all. I'm an experienced Ocaml programmer, looking to broaden my horizons yet further and pick up Haskell, and I'm wondering if there's a good introduction to Haskell for me. I have Simon Thompson's Haskell: The Craft of Functional Programming, which isn't a bad book, but I'm something of a special case. I'm already familiar with and comfortable with a lot of concepts which are new to your average C++/Java programmer- things like symbolic computation and recursion as looping and applicative data structures. So churning through introductions to these concepts looking for the rare nugget of new information is, well, kinda boring. On the other hand there are a lot of Haskell concepts I'm not comfortable with, like monads. So I was wondering if there was a better introduction for me out there? I'm willing to pay for a book or read something online, whichever. All good things are findable from http://haskell.org :) We've been working recently on a comparative OCaml/Haskell introductory text, which might be helpful for some beginner issues, syntax, and a few intermediate things like typeclasses: http://haskell.org/haskellwiki/A_brief_introduction_to_Haskell it can be read side-by-side with the Introduction to OCaml, linked on the same page. Otherwise, YAHT is a good start: http://darcs.haskell.org/yaht/yaht.pdf and there's some other good things on: http://haskell.org/haskellwiki/Books_and_tutorials Feel free to drop by #haskell, we've quite a few OCaml refugees there :) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Aim Of Haskell
Neil Mitchell [EMAIL PROTECTED] writes: Talking to professional programmers, if I tell anyone I program in Haskell they nearly always say oh, Pascal, that's cool. You need to say askell... No one knows what functional programming is, Scheme/Lisp are the closest. Maybe we should try and hijack the phrase functional programming I think we should call it Abstraction Oriented Programming. It's got the oriented buzzword in it, and we don't need to tell folk that abstraction means more than one thing to us until we're sure they're OK. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: -- Don If it ain't pure, it ain't functional Stewart flame-bait Oh, so you're saying that we should trademark the phrase functional programming so that no language with uncontrolled side effects would be allowed to use it? /flame-bait -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Research is what I'm doing when I don't know what I'm doing.--Wernher von Braun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: December 12, 2006
On 12/12/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: --- Haskell Weekly News http://sequence.complete.org/ Issue 53 - December 12, 2006 --- [snip] Quotes of the Week * Jim Apple: The Haskell list probably has the widest 'knowledge bandwidth' of any mailing list I've ever seen, from total beginner questions to highly abstruse stuff which probably represents the cutting edge of PhD research. All are answered with detail and good humour. I like that quote, but I'm an American, so I think they're answered with good humor. The quote looks like it is from http://www.oreillynet.com/mac/blog/2006/03/haskell_vs_ocamlwhich_do_you_p.html#comment-23152 , and the attributions are actually beneath, rather than above, the quotes. The true author is Jeremy O'Donoghue. Jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: a cabal/database lib experience (was: [Haskell-cafe] Trivialdatabase access in Haskell)
Hello Alistair, Tuesday, December 12, 2006, 12:50:43 PM, you wrote: I guess I should comment, as one of the Takusen authors. Yes, this is embarrasing. We have made a number of assumptions which Paul exposed: - users should know to do darcs get, then runhaskell Setup.hs configure/build/install - users should know to look for Haddock docs - users should know how to look for and install dependent libraries (Cabal-1.1.6.1, in this case) If you're an experienced Haskell programmer then these assumptions are valid, so yes, we do need to do more for the novice. these steps are standard for any haskell library and it's really sort of knowledge that is spread in air. can someone just put this into wiki? there is a great wikipage on creating your own library, thanks to Donald, who is started it. but there is no even simpler page about using libraries. while we don't have cabal-get it will be great to setup such page -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: a cabal/database lib experience (was: [Haskell-cafe] Trivialdatabase access in Haskell)
Hello Paul, Tuesday, December 12, 2006, 1:35:52 PM, you wrote: Thank you! That's exactly the sort of report I was trying to give, although (from my point of view) it's pretty hard to report this sort of thing without feeling like you're giving a complaining and ungrateful impression. It's nice to have the reassurance that I got my message across. we are very interested in such sort of reports because it enlightens information that is considered as self-evident, but not so evident for new haskellers -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: December 12, 2006
jbapple+haskell-cafe: On 12/12/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: --- Haskell Weekly News http://sequence.complete.org/ Issue 53 - December 12, 2006 --- [snip] Quotes of the Week * Jim Apple: The Haskell list probably has the widest 'knowledge bandwidth' of any mailing list I've ever seen, from total beginner questions to highly abstruse stuff which probably represents the cutting edge of PhD research. All are answered with detail and good humour. I like that quote, but I'm an American, so I think they're answered with good humor. The quote looks like it is from http://www.oreillynet.com/mac/blog/2006/03/haskell_vs_ocamlwhich_do_you_p.html#comment-23152 , and the attributions are actually beneath, rather than above, the quotes. The true author is Jeremy O'Donoghue. Ah sorry, Jim! My mistake. And apologies to Jeremy too. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Brian Hulley [EMAIL PROTECTED] wrote: Neil Mitchell wrote: Maybe we should try and hijack the phrase functional programming - Haskell is just too similar to Pascal. This reminds me of when I was getting an X-ray a few months ago and I struck up a conversation with the radiologist who turned out to be an ex-computer programmer so he asked what language I was using so I said Haskell and he said something like Oh yeah Pascal I know that... Perhaps we need a tutorial on how to pronounce the word Haskell so that it doesn't sound like Pascal :-) (eg Hiskll) Actually, the more I think of it, the more I think we should rename the language altogether. It seems like people say Haskell with stress on the first syllable if they were either on the committee or learned it inside academia, and Haskell with stress on the second syllable if they learned it from online sources. And we really don't need more pronunciation-based class distinctions. Curry would have avoided this problem. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt It was cold in the house so I slept in my car / And I steamed up the windows, then it started to rain / And I dreamed about sex and I dreamed about peppers / Woke up doing 85 in the passing lane -- Ed's Redeeming Qualities ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: a cabal/database lib experience
Simon Marlow wrote: + add a dedicated command cabal, which does nothing more than runhaskell Setup, but is more memorable and suggestive cabal-setup does this, but wasn't included with the latest release of Cabal. It should be in the next one, I hope. The plan is to deprecate 'runhaskell Setup.lhs' in favour of 'cabal-setup'. I'm possibly using cabal in a simplistic way, but I generally do either ./Setup.lhs configure -p ./Setup.lhs build ./Setup.lhs install or ./Setup.lhs configure -p --prefix=$HOME --user ./Setup.lhs build ./Setup.lhs install --user #perhaps not needed anymore? This is a lot of typing, and at least once I wrote a Makefile to automate it (oh, the irony of it!) Anyway, it would be nice if a 'cabal' command automated the whole sequence in one go, at least as an option. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: a cabal/database lib experience (was: [Haskell-cafe] Trivialdatabase access in Haskell)
On 12/12/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote: bulat.ziganshin: there is a great wikipage on creating your own library, thanks to Donald, who is started it. but there is no even simpler page about using libraries. while we don't have cabal-get it will be great to setup such page The wiki can be edited by anyone! Start now! My plan is to write up what I end up doing (plus some notes on my false starts, if they seem helpful) on the wiki. I'll probably add a new page off the Libraries and Tools page - does that sound reasonable? I have to admit that I haven't found the obvious place on the wiki for this yet - I'm familiar with wikis in general, but the structure of the Haskell wiki is a bit hard to get to grips with. That's not a very helpful comment, because I can't articulate *why* I feel this :-( As a data point, the old Haskell wiki felt a bit easier to navigate - maybe because it was less structured in some way. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: a cabal/database lib experience
On 12/12/06, Ketil Malde [EMAIL PROTECTED] wrote: I'm possibly using cabal in a simplistic way, but I generally do either ./Setup.lhs configure -p ./Setup.lhs build ./Setup.lhs install [...] This is a lot of typing, and at least once I wrote a Makefile to automate it (oh, the irony of it!) Anyway, it would be nice if a 'cabal' command automated the whole sequence in one go, at least as an option. I come from a Python background, and Python's distutils (which feels very like cabal - or should that be the other way round?) tends to have later commands include earlier ones. So, setup.py install automatically does build (there is no explicit configure step). Distutils tracks changes somehow (probably by file timestamp) to avoid rerunning builds when not needed. Could cabal do that? I find it hard to see why someone would want to do install without having done an up to date build. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New to Haskell - Question about hugsIORun from old Prelude
On Mon, 11 Dec 2006, Rahul Naik wrote: Hello, I am trying to rewrite some older (2001) haskell : myReadFile :: String - String myReadFile f = case hugsIORun (readFile f) of Right s - s Left _ - Can someone provide me with a up to date version of the above bit of code without using code from the old Prelude? http://www.haskell.org/hawiki/ThatAnnoyingIoType ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Hi, Actually, the more I think of it, the more I think we should rename the language altogether. It seems like people say Haskell with stress on the first syllable if they were either on the committee or learned it inside academia, and Haskell with stress on the second syllable if they learned it from online sources. And we really don't need more pronunciation-based class distinctions. If you'd all speak West-Flemish, the problem would solve itself :-) We say Haskul - Has(lle)ul(cer) At least, that what I think the Oxford dictionary means with its pronounciation description. Maybe we can claim it should be 'has kell', where kell is something cool, and no cornflakes. It has kell. -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Donald Bruce Stewart wrote: Who wants to join the Lisp is not functional programming movement with me? Oh, lordy. As if the Scheme is not Lisp flames on comp.lang.lisp weren't enough... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Andy Georges [EMAIL PROTECTED] wrote: Hi, Actually, the more I think of it, the more I think we should rename the language altogether. It seems like people say Haskell with stress on the first syllable if they were either on the committee or learned it inside academia, and Haskell with stress on the second syllable if they learned it from online sources. And we really don't need more pronunciation-based class distinctions. If you'd all speak West-Flemish, the problem would solve itself :-) Didn't this discussion originally start out as a warning not to say If you'd all speak [or program in] _, the problem would solve itself? :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt What you call 'lying', other people would call 'abstraction'. -- Alex Aiken ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pretty printing HTML
Hi, I want to pretty print some text as HTML, using the standard HughesPJ combinators. The problem is that I want the length of a text string to be its textual context, not its character length. For example, a keyword will display as case, but internally will be the string span class='keyword'case/span Is there any way to acheive this? I have come up with something, but its not nice at all. It basically involves parsing the generated text and inserting the extra HTML back in. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: Phooey -- a Functional UI library for Haskell
Brian Hulley wrote: Conal Elliott wrote: GUIs are usually programmed in an unnatural style, in that ... Also, suppose you have a gui consisting of an edit widget such that when the user types something it gets lexed, parsed, and fontified as a Haskell program, ie from the user's point of view the widget maintains a syntax highlighted view of the code which is continuously updated. Would your system do the lexing/parsing for every key that was pressed or only once, when the widget needs to be re-rendered (a typical gui for Windows would only propagate changes and re-draw the gui (ie lex/parse/fontify) when there are no event messages pending)? Thinking about this more, a better example would be a gui with 2 widgets: an edit widget to type in code and a list widget which displays a list of top level functions defined in that code. (The code could be Haskell or some simple toy language.) Then the question becomes: how to set things up such that the code in the edit widget is only parsed when the list widget (and/or edit widget) is asked to render it's contents rather than every time the user presses a key. I think perhaps the problem would be solved by the edit widget passing a lazy parse tree (ie an expression evaluating to the parse tree) to the list widget. But an interesting thing is if you compare this to imperative guis, in the functional gui each widget passes lazy expressions eagerly whereas in imperative guis each widget passes eagerly evaluated expressions lazily ie functional is push messages whereas imperative is pull changes when I'm asked to pick or render something etc and I'm dirty. (Have I got this wrong?) I imagine that the overhead of eager passing in the functional gui is a small price to pay for the ease of using a functional gui, since the important thing is that in both guis, the hard work of parsing the code in the edit buffer would only be done on demand, unless I'm much mistaken. If you're still thinking of examples for your paper it would also be really great to see how you'd create a widget that displays the result of another process (eg a window that displays the output as ghc compiles a program) or some other example of how to use the IO monad inside a widget for those unfamiliar with combining arrows with monads. It would also be useful to know more about the relationship between the functional gui and WxWidgets to see what characteristics an imperative gui toolkit must have in order to be usable with it. (Like the extremely useful discussion of low level details in the Fudgets thesis.) Best regards, Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
You're implying that there's a *more* appropriate forum somewhere for discussing analogies between music composition and programming languages? If so, I'd like to know what it is! Yes, music and programming languages are ultimately phenomena of our human brains/minds. Therefore, the expression of music or algorithms touch as much mathematics as they touch the field of philosophy (and here the philosophy of the mind). Sometimes there are interesting posts in comp.ai.philosophy and attempts to discuss the semantics in Mozart or Beethoven's style: http://groups.google.de/groups/search?hl=deq=beethoven+mozart+comparison I've been thinking about this. Are there really any programmers who are like Mozart in the way you describe? No, and I think Dijkstra perception is a bit flawed with respect to Mozart's compositions. Certainly, there are very strong rewarding mechanisms in the brain which can be activated by special circumstances and allow to develop special capabilities (Feynman spoke about falling in love with an idea). But it is not highly desirable for a society to have every member to develop radical new idea's or skills. A species would quickly stop to reproduce if everyone would be sitting in a room thinking about a certain abstract subject. Whereas it's conceivable to imagine somebody writing a piece of music that way, or a poem. I think in general it is underestimated how rare such moments of divine inspiration are in reality. There is this nice speech by Wislawa Szymborska about the difficulties of inspiration in poetry (http://nobelprize.org/nobel_prizes/literature/laureates/1996/index.html) and also the late Beethoven explains this in his music: Have a listening to the 3rd movement of his op.106. In my view, he explains about the suffering of a lonely genius, and then starts laughing about it because our own nature changes all the time, and that there is almost no way to control these changes, nor on time that passed away or predicting times to come, neither a judgement whether he is happy or not with this fact of life- I find it a very powerful observation on how learning works. ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Aim Of Haskell
Haskell is just too similar to Pascal. This makes me wonder how people pronounce Pascal. It's probably because I'm from Europe, but I put the stress on the second syllable. Pronouncing it like rascal is, well, funny :-). Greetings, Arie -- making someone not survive must surely count as non-verbal communication -- bring ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
On 12/12/06, Arie Peterson [EMAIL PROTECTED] wrote: Haskell is just too similar to Pascal. This makes me wonder how people pronounce Pascal. It's probably because I'm from Europe, but I put the stress on the second syllable. Pronouncing it like rascal is, well, funny :-). For whatever it's worth, I'm American and have mainly heard Americans pronounce it with the stress on the second syllable -- however, when I mention programming in Haskell to other Americans, I get the oh, you mean Pascal? response sometimes too, even though I pronounce Haskell with the stress on the first syllable. I'm not sure why, since it's not as if anyone programs in Pascal anymore. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Never wear shorts with the name of your town across the ass if you live in Needham. -- Beth Murphy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: a cabal/database lib experience (was: [Haskell-cafe]Trivialdatabase access in Haskell)
We have made a number of assumptions which Paul exposed: - users should know to do darcs get, then runhaskell Setup.hs configure/build/install - users should know to look for Haddock docs - users should know how to look for and install dependent libraries (Cabal-1.1.6.1, in this case) and there you have the beginnings of your README file!-) If you're an experienced Haskell programmer then these assumptions are valid, so yes, we do need to do more for the novice. the difference, as far as it is relevant for getting going, is often just context, which can be rectified by surprisingly small steps, such as collecting the assumptions in one obvious-to-find file. + add a dedicated command cabal, which does nothing more than runhaskell Setup, but is more memorable and suggestive Did you mean an executable that comes with cabal or the compiler yes, part of the cabal infrastructure, not something from the library author. as Simon has pointed out, cabal-setup is going to do the job, and with a more descriptive name. thanks, claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: a cabal/database lib experience
absolutely, this has occurred to me too. There should be a stanard Cabal README file, and Don's mkcabal tool could drop it in the tree. This occurred to me too. My current plan for mkcabal is that it creates: foo.cabal Setup.lhs README LICENSE based on a series of interactive questions, or command line args. is mkcabal going to be a standard part of cabal installations? btw, here is some suggested text for the useful how to write.. page you started (I know it is a wiki, but I don't want to mess up the page at this point;-). thanks, claus 0. The intended user experience When Haskell programmers go out in search of existing functionality, be it a library, a tool, or an application, the intended approach is roughly this: 1 visit haskell.org, 2 find the library/program they are looking for (if not found, try mailing list; if it is hidden, try improving haskell.org; if it does not exist, try contributing code/documentation/requirements/..) 3 download 4 install 5 enjoy but each of these steps is endangered by several potential road blocks, and code authors can do a lot to help code users avoid such blocks. Even if steps 1/2 are successful, and ensuring step 5 is the main concern of code authors and users, it is often steps 3/4 that get in the way: - which is the latest version? what state is it in? is it still maintained/in use? - what are its aims? where is the documentation? - which is the right version for given OS and Haskell implementation? - how is it packaged, and what tools are needed to get and unpack it? - how is it installed, and what tools are needed to install it? - how do we avoid IDR (infinite dependency recursion)? - how do we provide/acquire the knowledge and tool-chains needed? There is a well-established tradition for communicating the answers to these questions: the README text file, placed in a prominent position at the code's location (these days often accompanied, but not replaced, by a more extensive web page). But as other communities, the Haskell community has Haskell-specific answers to many of these questions, independent of the particular Haskell code to publish. This document is all about how to publish your Haskell code in such a way as to make the Haskell code users' experience as smooth as possible. Until there is a version of this text targetted more specifically at code users, they might find it helpful to browse this page for insights into the Haskell code authors' mind- and tool-set. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trivial database access in Haskell
Taral wrote: On 12/11/06, Paul Moore [EMAIL PROTECTED] wrote: F:\cabal-1.1.6.1runhaskell Setup.lhs install Installing: C:\Program Files\Haskell\Cabal-1.1.6.1\ghc-6.6 C:\Program Files\Haskell\bin Cabal-1.1.6.1... Setup.lhs: Error: Could not find module: Distribution.Compiler with any suffix: [hi] The magic commands are: runhaskell Setup.lhs configure Also, if you're going to profile the code that uses this module, you need to compile the libraries with profiling enabled; you can do this by doing configure -p instead of configure above. runhaskell Setup.lhs build runhaskell Setup.lhs install ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Good Haskell introduction for an Ocaml programmer?
Brian Hurt wrote: Greetings, all. I'm an experienced Ocaml programmer, looking to broaden my horizons yet further and pick up Haskell, and I'm wondering if there's a good introduction to Haskell for me. Okasaki's _Purely Functional Data Structures_ discusses (among other things) the pros and cons of lazily evaluated structures. The examples in the body of the book are in ML and an appendix has translations into Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
Kirsten Chevalier wrote: since it's not as if anyone programs in Pascal anymore. Yet I'm sure most people who did a computer science degree some decades ago remember the old joke about passing things by name or value for what it's Wirth... :-) Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Maybe we can claim it should be 'has kell', where kell is something cool, and no cornflakes. It has kell. if there was an implementation of Haskell on Cell processors, it could be has cell.. I wonder if knowing what people are going to do with your name is sufficient to put students off becoming a mathematician ;-) but on the Pascal note: is there anything in Pascal that Haskell doesn't provide, and improves on (nested procedures, procedure parameters, distinguishing in and out parameters, types, ..)? it has been too long since my Pascal days, I don't remember.. apart from the communication problem of understanding Haskell as Pascal: if you're talking to someone who knows Pascal, it might not be a bad idea to position Haskell as a drastically modernized version of Pascal, to get the discussion of real merits going? claus -- Trac ticket #-42: subject: when trying to bootstrap GHC on the PS3, configure complains can't find hardware? status - closed (no bug) comment: it is a _next_ generation console! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
On 12/12/06, Brian Hulley [EMAIL PROTECTED] wrote: Kirsten Chevalier wrote: since it's not as if anyone programs in Pascal anymore. Yet I'm sure most people who did a computer science degree some decades ago remember the old joke about passing things by name or value for what it's Wirth... :-) I was kidding slightly. My first programming language was Pascal, but I guess I should be grateful that I didn't take the same course a year later, because then my first language would have been Java. In fact, a comment from Lyn Turbak, who taught the second-semester computer science class I took at Wellesley, is in some sense or another half of the reason why I'm participating in this discussion today -- a student (not me) asked him, why are we learning Pascal if you hate the language so much? and he explained, Historical accident... and talked about the reasons why Pascal ended up being a popular teaching language. Much later, I'm amazed at how few students ask this kind of question and how few teachers talk about the answers to them. I think this relates back to the point of the original discussion. People (except people on this mailing list, and a few similar fora) don't talk much about the reasons for choosing programming languages. When they do talk about it, it's usually very prescriptively oriented rather than descriptively oriented. I think that it would serve this community well if somebody was able to achieve a better understanding of the social reasons why some programming languages are adopted and some aren't. I think all of us already know that the reason isn't because some are better than others, but it might be time for someone to go beyond that. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt THEY CAN KILL YOU, BUT THE LEGALITIES OF EATING YOU ARE QUITE A BIT DICIER --David Foster Wallace ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Paul Hudak wrote: Hi Sebastian. As a writer of one of those academic Haskell textbooks, I've been following this thread with some interest. BTW, I found your textbook very helpful. The first time I tried to learn Haskell, I got the Bird and Wadler textbook, and got bogged down about halfway through. It just wasn't the sort of approach that was good for someone in my position, i.e., trying to pick up the language in my spare time without the structure of a college class to check my work and give me the occasional kick in the rear. But with SOE--ooh! pretty pictures! (The only problem was figuring out the magic incantation to make Hugs on my system talk to the SOEGraphics library.) Maybe some of you can do better, but it's really tough to show someone how an /advanced/ Haskell programmer would solve /advanced /problems that arise in the real world. As a simple example, I love this recent quote by Garrett Morris: I'm personally fond of framing most non-trivial Haskell problems as defining domain specific languages; as a result, everything over about 200 lines that I've written in the past 3 years has used the mtl [Monad Transformer Library] in some form or fashion. It's great. So how do we teach Garrett's way of programming (which I like very much) to the masses? One would guess that we'd need to explain not only monads, but also monad transformers, first. My first thought would be to develop some kind of cheap-ass NLP system, starting with simple VERB NOUN constructions or some kind of text filter, and building up to the kind of parser that the Infocom Z-machine uses. (N.B.: applications that are too reminiscent of math class, like arithmetic-expression evaluators or symbolic differentiators, are turn-offs. If the rest of us were that thoroughly comfortable with math, we'd be expert Haskell programmers already. :-) Sebastian Sylvan wrote: There must be some way of teaching Haskell breadth first, so to speak. In the ed biz they call this a spiral curriculum. As applied to a Haskell textbook, what I would suggest is something like this: In chapter 1, introduce the IO monad, and point out a few key features (e.g., explain why a function with type IO a - a would be unsafe). In chapter 2, introduce the Maybe monad, and point out that constructions like (Just 5) = putStrLn won't compile. In the next few chapters, introduce other common and useful monads, so the student has some hope of getting an intuitive sense of what's going on with them; at the same time, dribble in a few useful facts about monads or useful operators for manipulating them. *Then*, no earlier than chapter 5, provide the formal definition of a monad and explain how you can roll your own. (I'm not sure whether it would be helpful to give some examples of monad transformers before the formal definition of a monad, or whether those should come afterward.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
Claus Reinke wrote: but on the Pascal note: is there anything in Pascal that Haskell doesn't provide, and improves on (nested procedures, procedure parameters, distinguishing in and out parameters, types, ..)? Subrange types, maybe? But I'm sure Oleg will show us that Haskell already has them. :-) - Andreas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Andreas Rossberg [EMAIL PROTECTED] wrote: Claus Reinke wrote: but on the Pascal note: is there anything in Pascal that Haskell doesn't provide, and improves on (nested procedures, procedure parameters, distinguishing in and out parameters, types, ..)? Subrange types, maybe? But I'm sure Oleg will show us that Haskell already has them. :-) Maybe the real question should be: is there anything in Pascal that Haskell's type system doesn't provide? Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Other than to amuse himself, why should a man pretend to know where he's going or to understand what he sees? -- William Least Heat Moon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] automonadization of code?
Well, there's the Haskell Array Preprocessor (http://www.cs.utah.edu/~hal/APP/index.html), but I've never really used it. I think the first thing to notice is that Control.Monad really does contain a lot of functions which are useful control structures. The way that you wrote that loop seems extremely awkward to me. How I'd write it would be something like: import Control.Monad import Data.Array.IO main = do a - (newArray (1,100) 1) :: IO (IOArray Int Int) forM [2..99] $ \i - do v - liftM2 (+) (readArray a (i-1)) (readArray a (i+1)) writeArray a i v print = getAssocs a (Note that forM = flip mapM is a recent addition to Control.Monad) It's possible to go quite a way to cleaning things up just using appropriate functions. On 12/12/06, Adam Megacz [EMAIL PROTECTED] wrote: Is there any work on automatic translation of code in some tiny imperative language into Haskell code that uses the ST and/or IO monads (or perhaps even pure functional code)? For example, the user writes something vaguely like array = newArray (1,100) 1 for x=2 to 99 array[x] := array[x-1]+array[x+1] And it is transformed into something like foldl (=) (newArray (1,100) 1) $ map (\n arr - do a - readArray arr (n-1) b - readArray arr (n+1) writeArray arr n (a+b) return arr) [2..99] Obviously the small imperative language would have to be highly restricted and carefully chosen in order for the translation to always work and be predictable. I'm interested in any existing work on choosing such a sublanguage. Thanks! - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380 ___ 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] Type problem with simple takusen code (was: Trivial database access in Haskell)
(Wow, it looks like my message has generated quite a bit of traffic! Thanks, guys!) On 12/11/06, Taral [EMAIL PROTECTED] wrote: The magic commands are: runhaskell Setup.lhs configure runhaskell Setup.lhs build runhaskell Setup.lhs install Excellent! Now I'm getting somewhere. I even found the sample code in the takusen documentation. I'm trying to modify the sample code to work with a local database I have, and I'm getting some type errors which mean nothing much to me. The code I have, stored in a file called db.hs and run via runhaskell db.hs is: import Control.Monad.Trans import Database.Oracle.Enumerator import Database.Enumerator query1Iteratee :: (Monad m) = String - IterAct m [String] query1Iteratee a accum = result' (a:accum) main :: IO () main = do withSession (connect USER PASSWORD DB) $ do -- simple query, returning reversed list of rows. r - doQuery (sql select username from all_users) query1Iteratee [] liftIO $ putStrLn $ show r The error I'm getting is db.hs:10:64: Couldn't match expected type `forall mark. DBM mark Session a' against inferred type `a1 b' In the second argument of `($)', namely `do r - doQuery (sql select username from all_users) query1Iteratee [] liftIO $ (putStrLn $ (show r))' In the expression: (withSession (connect USER PASSWORD DB)) $ (do r - doQuery (sql select username from all_users) query1Iteratee [] liftIO $ (putStrLn $ (show r))) In the expression: do (withSession (connect USER PASSWORD DB)) $ (do r - doQuery (sql select username from all_users) query1Iteratee [] liftIO $ (putStrLn $ (show r))) I'm not sure what might be wrong here - or even, for that matter, how to diagnose the problem. To complicate the matter, it's possible that I'm getting a database connection error which I've not got code in to report. (I've no easy way to test that the database connection from Haskell is working, or rather *this* is the easy way :-)) Can anyone offer any pointers? (I take the suggestions about asking on IRC, but I can't get at IRC from here due to firewall issues, so I'll have to stick to email). Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: a cabal/database lib experience (was: [Haskell-cafe]Trivialdatabase access in Haskell)
On 12/12/06, Claus Reinke [EMAIL PROTECTED] wrote: the difference, as far as it is relevant for getting going, is often just context, which can be rectified by surprisingly small steps, such as collecting the assumptions in one obvious-to-find file. Indeed. I can now confirm that it's *not* hard to get takusen set up - it's just a bit hard to find out it's not hard :-) Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type problem with simple takusen code (was: Trivial database access in Haskell)
Paul Moore wrote: db.hs:10:64: Couldn't match expected type `forall mark. DBM mark Session a' against inferred type `a1 b' In the second argument of `($)', namely `do r - doQuery (sql select username from all_users) query1Iteratee [] liftIO $ (putStrLn $ (show r))' In the expression: (withSession (connect USER PASSWORD DB)) $ (do r - doQuery (sql select username from all_users) query1Iteratee [] liftIO $ (putStrLn $ (show r))) In the expression: do (withSession (connect USER PASSWORD DB)) $ (do r - doQuery (sql select username from all_users) query1Iteratee [] liftIO $ (putStrLn $ (show r))) I had the same problem... ($) doesn't have the expected semantics with existential types (like forall mark. DBM mark Session a). Some day I will be able to explain why this is so, but in the meantime, if you replace liftIO $ putStrLn $ show r with liftIO (putStrLn (show r)), it should work. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Good Haskell introduction for an Ocaml programmer?
On 12/12/06, Brian Hurt [EMAIL PROTECTED] wrote: Greetings, all. I'm an experienced Ocaml programmer, looking to broaden my horizons yet further and pick up Haskell, and I'm wondering if there's a good introduction to Haskell for me. I think that O'Caml programmers would be one audience where I'd start with the Gentle Introduction (It's doesn't seem nearly gentle enough to the imperative-minded, but should be fine for someone used to functional programming). http://www.haskell.org/tutorial/ You're likely to find YAHT boring, but I think it may still be a good idea to skim it a bit. Also, you might like reading some specialised tutorials directly. http://haskell.org/haskellwiki/Introduction_to_IO -- a brief 5 minute introduction I wrote about how we think about IO in Haskell. My favourite monad tutorials: http://www.nomaware.com/monads/html/index.html -- This is really thorough and mostly very well written, though there are places where the examples are both highly contrived and hard to comprehend due to excessive use of the continuation monad. http://haskell.org/haskellwiki/Monads_as_containers -- this one I wrote myself, and takes a somewhat different approach to things than most others, treating monads as an abstraction of container types rather than of types of computation. These are just some of my personal recommendations, but there's a lot of stuff that's out there. There are some decent guides to what's available on the wiki: http://haskell.org/haskellwiki/Books_and_tutorials http://haskell.org/haskellwiki/Research_papers -- There's actually quite a lot of introductory material in papers, because writers often can't assume that their audience is intimately familiar with Haskell already, though they may assume a certain level of familiarity with CS in general. Also, make sure you fire up an IRC client and join us at #haskell on irc.freenode.org. There are lots of friendly people there who are always happy to discuss things, answer questions (don't worry if they seem simple), and point you at resources. Welcome to the list and have fun learning Haskell! - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Type problem with simple takusen code (was: Trivialdatabase access in Haskell)
main :: IO () main = do withSession (connect USER PASSWORD DB) $ do -- simple query, returning reversed list of rows. r - doQuery (sql select username from all_users) query1Iteratee [] liftIO $ putStrLn $ show r The error I'm getting is db.hs:10:64: Couldn't match expected type `forall mark. DBM mark Session a' against inferred type `a1 b' In the second argument of `($)', namely `do r - doQuery (sql select username from all_users) ... This is a fault in the example. Try this: -- ($) replaced here with () withSession (connect USER PASSWORD DB) ( do r - doQuery (sql ... liftIO $ putStrLn $ show r --- here should be OK ) ($) doesn't handle higher-ranked types, and overusing it can lead to these kinds of errors. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: a cabal/database lib experience (was: [Haskell-cafe]Trivialdatabase access in Haskell)
[trimmed replies] On 12/12/06, Paul Moore [EMAIL PROTECTED] wrote: On 12/12/06, Claus Reinke [EMAIL PROTECTED] wrote: the difference, as far as it is relevant for getting going, is often just context, which can be rectified by surprisingly small steps, such as collecting the assumptions in one obvious-to-find file. Indeed. I can now confirm that it's *not* hard to get takusen set up - it's just a bit hard to find out it's not hard :-) If you generalize from takusen there, I think you'll understand a lot about Haskell :-) Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Dare to be naive.--R. Buckminster Fuller ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: a cabal/database lib experience
Paul Moore wrote: On 12/12/06, Ketil Malde [EMAIL PROTECTED] wrote: I'm possibly using cabal in a simplistic way, but I generally do either ./Setup.lhs configure -p ./Setup.lhs build ./Setup.lhs install [...] This is a lot of typing, and at least once I wrote a Makefile to automate it (oh, the irony of it!) Anyway, it would be nice if a 'cabal' command automated the whole sequence in one go, at least as an option. I come from a Python background, and Python's distutils (which feels very like cabal - or should that be the other way round?) tends to have later commands include earlier ones. So, setup.py install automatically does build (there is no explicit configure step). Sounds entirely reasonable to me. Though configure takes a bunch of arguments; so if configure is run automatically it'll always be with the default settings. Maybe that's ok. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Name that function =)
Hi all; I'm new to the list, so I just wanted to say hi and -- of course -- ask a quick question: I have some IO actions that I want to map over a list of pairs -- these are just directory names and their down-cased versions. It wasn't difficult to actually get the right behavior by just doing mapM twice. -- putDirs just outputs something like mv fst snd mapM_ putDirs pairs mapM_ (uncurry renameFile) pairs This bothered me though, because I suspected that this could be done in one pass. Naively I proceeded to this. mapM_ (putDirs (uncurry renameFile)) pairs Which didn't work. I thought about it a little more before realizing that putDirs wouldn't get any parameters this way: I needed some way to distribute the pair over both operations. Here's the higher-order function I needed: foo h f g i = h (f i) (g i) which could then be curried and we get: mapM_ (foo () putDirs $ uncurry renameFile) pairs Works great. So my question: is there a established name for foo? What about foo partially applied to ()? This was a fun exercise, but I'd like to use the standard implementations if they exist. Thanks! -- Lou. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type problem with simple takusen code (was: Trivialdatabase access in Haskell)
On 12/12/06, Bayley, Alistair [EMAIL PROTECTED] wrote: ($) doesn't handle higher-ranked types, and overusing it can lead to these kinds of errors. Thanks - not something I'd have ever found on my own. Next one: runhaskell db.hs can't load .so/.DLL for: sqlite3 (addDLL: unknown error) This seems odd, as I'm not (intending to be) using sqlite here. If I copy a sqlite3.dll onto my PATH (just to get by, it's quite possible sqlite isn't set up right but I really don't care just now) I get past this, but get runhaskell db.hs interactive: C:\Program Files\Haskell\Takusen-0.6\ghc-6.6/HSTakusen-0.6.o: unknown symbol `_PQconnectdb' ghc.exe: unable to load package `Takusen-0.6' No chance here - I don't have any sort of PostgreSQL software around. I've no idea how it might have thought I did. Can I somehow force PostgreSQL to be disabled? If I need to rebuild to do so (grumble) then how do I uninstall the current version of takusen (it's not in Add/Remove programs and runhaskell Setup.hs doesn't seem to offer an uninstall option... Thanks again, Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type problem with simple takusen code (was: Trivialdatabase access in Haskell)
On 12/12/06, Paul Moore [EMAIL PROTECTED] wrote: Can I somehow force PostgreSQL to be disabled? If I need to rebuild to do so (grumble) then how do I uninstall the current version of takusen (it's not in Add/Remove programs and runhaskell Setup.hs doesn't seem to offer an uninstall option... There should be a README or INSTALL file in the original tarball that explains how to do that. I suspect it is a flag you have to pass to runhaskell Setup.lhs configure. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Translating Haskell to VHDL. What approach to follow?
After considering the different options (specially Yhc.Core) I decided to go for Embedded Compiling [1] + Observable Sharing[2] to translate from ForSyDe[3] to VHDL[4] instead of making a whole Haskell-Compiler backend. Creating a backend would fit a more ambitious goal: translating any haskell source file to VHDL, and of course would be more difficult to approach. The drawback of the Embedded Compiler approach is that ForSyDe will need to be adapted. But instead the translation would be quite easy to make and what is more important, a lot more maintainable due to being independent of external tools and embedded in the library itself. Thanks a lot for your suggestions. Specially to Neil who is fortunately always open to help. References [1] http://haskell.org/haskellwiki/Research_papers/Domain_specific_languages [2] http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html [3] http://www.imit.kth.se/info/FOFU/ForSyDe/ [4] http://en.wikipedia.org/wiki/VHDL On 11/12/06, Alfonso Acosta [EMAIL PROTECTED] wrote: For .hi files just compile it with Yhc and take a look at the .hi file it creates, they are plain text. If they are top level functions (which they certainly are, I guess) this should be all you need. Another approach is to get the type information out of Hugs with the :t command line prod. I've done this before in another project. Sorry for the delay answering. I didn't (and still won't) have access to the Internet for a few days but Ill try it and tell you if it worked once I'm back to normality. Thanks, Alfonso Acosta ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mozart versus Beethoven (was: Writing Haskell For Dummies ...)
Hello, In the spring of 1978, I wrote a (circa) 700-word microprogram for multiprecision integer arithmetic on paper, typed it into a computer, had it cleaned of syntax errors by the micro-code assembler, printed it, and spent much of the summer in my mother's summer house debugging this program text by hand, without the use of any automated computing device of any kind. I found lots of errors, corrected them, rechecked the result by hand, found additional errors, corrected those and, finally, (in the autumn of 1978) ran the program for the first time. Every multiprecision integer operation but division worked. After some debugging, a single (rather silly) error was found in the division routine. I never found additional errors in this code. This is not intended to imply that I am a Mozart rather than a Beethoven (most likely neither!) in the field of programming. Rather, it is an attempt to point out that the development environments that we use these days encourage a completely different mode of work than what was used some 20-30 years ago. Thus, today, I do like I have the impression most programmers do, compile and run (tests) as often as possible, even every very few keystrokes of code changes. I am not an expert in the difference between composers like Mozart and Beethoven, but my expert father tells me that Mozart, reputedly, had a phenomenal musical memory that allowed him both to recall large sequences of music played to him and, undoubtably also, work with long sequences of hypothetical music, that is, music being composed, for prolonged periods, in his head, without the need to make any notes on paper etc. It seems that such differences in modes of work does not imply any similar interesting or usefully utilizable difference in the way we should produce our programs. The analogy seems irrelevant, in other words. Best regards Thorkil On Tuesday 12 December 2006 12:07, Kirsten Chevalier wrote: ... I've been thinking about this. Are there really any programmers who are like Mozart in the way you describe? Donald Knuth might be one, or at least, he wrote that he wrote and debugged all of TeX on paper before entering it into a computer and only found 13 more bugs (or something like that), once he did. I don't remember if it was 13 exactly, but 13 more bugs might be the closest that any programmer gets to Mozart, or at least any programmer in the 20th or early 21st century. ... Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt What is research but a blind date with knowledge? -- Will Henry ___ 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] Dynamic types through unsafeCoerce
On 12/10/06, Taral [EMAIL PROTECTED] wrote: On 12/10/06, Alfonso Acosta [EMAIL PROTECTED] wrote: On 12/10/06, Taral [EMAIL PROTECTED] wrote: Sure it is. The type you gave (MyType Int Char - MyType a b) can easily crash your program. Ok I see. Why would that happen? I'm (maybe wrongly) taking as granted that the compiler/interpreter uses the same internal representation for both types. But that makes me think it shouldn't be that dangerous if nothing is later assumed about the type parameters a and b. 1. The Haskell Report does not guarantee that these things have the same representation. Well, to be honest the idea of using unsafeCoerce came after browing the sources of the Lava (http://www.md.chalmers.se/~koen/Lava/ ) library. Now I have explicit permission to reuse them so I guess I'm allowed to paste a few snippets here as well. Here they approach the same problem I have by using unsafe Coerce -- This code implements Observable sharing references for circuits -- Some Comments made by Koen describing the problem: -- The disadvantage is that, since the types of the -- Tables vary, the Ref has no idea what type of -- values it is supposed to store. So we use dynamic -- types. toDyn :: a - Dyn toDyn = unsafeCoerce fromDyn :: Dyn - a fromDyn = unsafeCoerce -- If GHC is used unsafeCoerce :: a - b unsafeCoerce a = unsafePerformIO $ do writeIORef ref a readIORef ref where ref = unsafePerformIO $ do newIORef undefined -- If Hugs is used primitive unsafeCoerce primUnsafeCoerce :: a - b -- Pieces of code where toDyn/fromDyn is used data Ref a = Ref (IORef [(TableTag, Dyn)]) a type TableTag = IORef () newtype TableIO a b = TableIO TableTag deriving Eq extendIO :: TableIO a b - Ref a - b - IO () extendIO (TableIO t) (Ref r _) b = do list - readIORef r writeIORef r ((t,toDyn b) : filter ((/= t) . fst) list) findIO :: TableIO a b - Ref a - IO (Maybe b) findIO (TableIO t) (Ref r _) = do list - readIORef r return (fromDyn `fmap` lookup t list) 2. Assuming that a polymorphic type will never be made monomorphic is like running without a safety net. The typecheck will not save you, and it'll be a pain to debug if it goes wrong. If you're not using those type parameters, then wrap it up so they can't be used. The problem is that, even if not mandatory, the binding would look more intuitive and similar to the original library with the (internal and user-hidden) use of those type parameters. I already tried to hide them through an existential and actually that's how the last version of the binding is implemented. As I already said. The user is only able to transform to dynamic but not back to a polymorphic type so I have control over those parameters. Why not post some code snippets so we can see what you're doing? If this mail doesn't clarify the problem I will try paste some snippets of my code (it's a real pain to try to simplify it) Thanks for your help Taral :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
Sure it is. The type you gave (MyType Int Char - MyType a b) can easily crash your program. Ok I see. Why would that happen? I'm (maybe wrongly) taking as granted that the compiler/interpreter uses the same internal representation for both types. But that makes me think it shouldn't be that dangerous if nothing is later assumed about the type parameters a and b. If the parameters aren't used, why not create a new data type without them? They are used, but no monomorphic type is assumed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
On 12/12/06, Conal Elliott [EMAIL PROTECTED] wrote: Try foo = liftM2, and check out the recent haskell thread Cannot understand liftM2. That's actually what I reached for first. The problem is that the arguments aren't monads: *Main :t (uncurry renameFile) (uncurry renameFile) :: (FilePath, FilePath) - IO () *Main :t putDirs putDirs :: (String, String) - IO () and liftM2 works on monadic arguments: liftM2 :: (Monad m) = (a1 - a2 - r) - m a1 - m a2 - m r I need to somehow get the mapped elements to be applied to each of the arguments before they can be combined. Substituting liftM2 for (foo ()) yields: No instance for (Monad ((-) (String, String))) arising from use of `liftM2' at DCFiles.hs:30:9-14 Probable fix: add an instance declaration for (Monad ((-) (String, String))) The foo function does the job, so I assume that I'm trying to solve a different problem than liftM. I wouldn't be surprised if I was wrong, however. -- Lou. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
On Dec 12, 2006, at 12:53 PM, Louis J Scoras wrote: On 12/12/06, Conal Elliott [EMAIL PROTECTED] wrote: Try foo = liftM2, and check out the recent haskell thread Cannot understand liftM2. That's actually what I reached for first. The problem is that the arguments aren't monads: (...) No instance for (Monad ((-) (String, String))) Read the thread more completely; ((-) a) is indeed a monad, but you need to include an additional module to get the definition. -- brandon s. allbery [linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
On 12/12/06, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: Read the thread more completely; ((-) a) is indeed a monad, but you need to include an additional module to get the definition. Ahh, okay I did see that. I thought that importing Control.Monad would be sufficient. What I didn't realize is that even though the documentation for Control.Monad says that (-(r)) is an instance, it must not be defined there. Importing Control.Monad.Reader indeed does make it work, thanks for pointing that out again. So I guess my next question would be, looking here http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html How do I figure out that the instance declaration is actually in the Reader module? Is it just because the (-) constructor is special -- or just not hyperlinked? -- Lou. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Aim Of Haskell
On 12/12/06, Claus Reinke [EMAIL PROTECTED] wrote: Maybe we can claim it should be 'has kell', where kell is something cool, and no cornflakes. It has kell. if there was an implementation of Haskell on Cell processors, it could be has cell.. Pronounced hassle? :-) -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
On 12/12/06, Louis J Scoras [EMAIL PROTECTED] wrote: What I didn't realize is that even though the documentation for Control.Monad says that (-(r)) is an instance, it must not be defined there. Importing Control.Monad.Reader indeed does make it work, thanks for pointing that out again. So I guess my next question would be, looking here http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html How do I figure out that the instance declaration is actually in the Reader module? Is it just because the (-) constructor is special -- or just not hyperlinked? It's pretty subtle, but the Haddock there does list an instance of MonadReader r ((-) r). In newer GHC's the instance is also found in Control.Monad.Instances. In my opinion, it belongs in the Prelude. :) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
On 12/12/06, Cale Gibbard [EMAIL PROTECTED] wrote: It's pretty subtle, but the Haddock there does list an instance of MonadReader r ((-) r). Yup, I see that one. What I meant was that in the Mondad package it says that ((-) r) is an instance of Monad, but I can't find way to get from there to Reader. In newer GHC's the instance is also found in Control.Monad.Instances. In my opinion, it belongs in the Prelude. :) Hmm. Yeah, it seems like there aren't many monad instances imported into prelude. Just [], Maybe and IO. I'll have to keep that in mind. Thanks for your help everybody. -- Lou. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Hello everyone, On 12/12/06, Ketil Malde [EMAIL PROTECTED] wrote: snip Some things took a bit of effort to wrap my head around, but it generally wasn't too hard to get to a level where I could write useful programs. snip * I'm already productive with what I know, so I don't have the direct motivation I think this is the major obstacle. I've had similar experiences with programmers of all skill levels. For one example, when I was TA'ing an introduction to FP course in college, we regularly had students who, once they had learned primitive recursion, would write every assignment (that didn't specifically exclude primitive recursion) recursively for the remainder of the quarter, no matter how much easier it would have been in terms of (for example) map and filter. For another examples, I've spent more time than I want to admit reinventing (or failing to reinvent) various wheels in Haskell (including arrows and COM's IUnknown) because I was fairly convinced that I knew everything I needed to solve whatever problem I was working on. From my experience, I'd suggest a couple of things: first, I think starting from simple ideas -- like primitive recursion -- is deadly. Instead, I'd rather earlier sections focused on less complex applications of rich ideas. For example, in a discussion of rewriting the aforementioned FP class, I rewrote the first project of the quarter from relying on primitive recursion over the integers to using function and Kleisli composition. I'm not necessarily suggesting that freshmen will understand Kleisli composition, but in this case the development of the composition operator was fairly natural for the problem, and when they came back to Kleisli composition later, they would have already seen it (as opposed to having seen a less useful variation). Second, I think that introducing at least monadic programming as early as possible is a good idea. My experience with people who've learned Haskell for jobs or courses (as opposed to for love of the game, so to speak) is that monadic programming frequently ends up regarded as a separate set of mysteries that's perhaps convenient for wizards but not necessary for normal programmers. This leads to another boundary when people who have learned a certain amount of Haskell and even written large amounts of Haskell look at code from more monad-happy projects and find it written in what looks like a foreign tongue. Finally, count me among those who would be happy to contribute as soon as there's a wiki or similar available! /g -- It is myself I have never met, whose face is pasted on the underside of my mind. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/12/06, Alfonso Acosta [EMAIL PROTECTED] wrote: On 12/10/06, Lemmih [EMAIL PROTECTED] wrote: How about using a StablePtr to a Dynamic? Uhm, that's a good idea cause no Typeable context will then be required and thus the function can be exported by the FFI. On the other hand, using Data.Dynamic requires any type to be an instance of Typeable. And thus requires the user to make such instantiation (which is a pain) GHC supports the deriving clause for the Typeable class, but it's not standard Haskell98 (and as far as I know, for example hugs doesn't support it) So it would be great to be able to use unsafeCoerce. Ah, you want type-safe casts without using Typeable? Good luck, you'll need it. -- Cheers, Lemmih ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cannot understand liftM2
Using the cool lambdabot pointless utility I found out that: \x - snd(x) - fst(x) is the same as: liftM2 (-) snd fst I like the elegance of this but I cannot reconcile it with its type. I can't understand it. I check the signature of liftM2 and I get: Prelude :t liftM2 Prelude liftM2 :: (Monad m) = (a1 - a2 - r) - m a1 - m a2 - m r Can someone help me understand what's happening here ? What does a Monad have to do with a simple subtraction ? What is actually the m of my example ? I think the simplest way to understand liftM and liftM2 are in terms of their do-notation: liftM op act = do x - act return (op x) that is: perform the action, bind the result to x, compute (op x) and return that in the monad. Similarly for liftM2: liftM2 op act1 act2 = do x - act1 y - act2 return (x `op` y) in your case: liftM2 (-) snd fst = do x - snd y - fst return (x - y) this is in the monad of functions that require an argument. Snd is a function that takes an argument (a pair) and returns a value (the 2nd member of the pair). Similarly fst is a fnction that takes an argument. The whole do-block represents a function that takes an argument (also a pair). As usual, do-blocks combine several actions (in this case functions of one arguments) into a new action. The description for this one is: the function that, when given an argument (say a) computes the snd item of the pair (snd a) binds, computes the fst item of the pair (fst a) and subtracts the two values (snd a - fst a). Nick Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Refactoring recklessly
I'd like to be able to reorganize my code and then verify that I didn't change any functionality. That is, the old and new code have precisely the same meaning. Also, I'd like to be able to change a function and verify that efficiency was the only thing affected. Are either of these possible in Haskell or any language? Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Refactoring recklessly
Hi I'd like to be able to reorganize my code and then verify that I didn't change any functionality. That is, the old and new code have precisely the same meaning. Also, I'd like to be able to change a function and verify that efficiency was the only thing affected. Are either of these possible in Haskell or any language? They are possible in any language, just in some they might have a lot of work to do the proofs. In Haskell they are pretty easy: http://haskell.org/haskellwiki/Haskell_Equational_Reasoning_Assistant (More one function at a time, not publically available, as far as I can tell) http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html (Global refactorings, a nice tool) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
On 12/12/06, Alfonso Acosta [EMAIL PROTECTED] wrote: So it would be great to be able to use unsafeCoerce. It would be great -- but Typeable is the only way to get *safe* typecasts of this type. Otherwise, you may as well run without a typechecker. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Refactoring recklessly
Greg Fitzgerald on 2006-12-12 11:24:58 -0800: I'd like to be able to reorganize my code and then verify that I didn't change any functionality. That is, the old and new code have precisely the same meaning. Also, I'd like to be able to change a function and verify that efficiency was the only thing affected. Are either of these possible in Haskell or any language? Use QuickCheck to generate parameters and compare return values for the old and the new functions. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell and .NET
I am learning Haskell, and I really want to be able to use .NET libraries from it. I've found the Hugs98.NET binary available from Galois, but it seems very, very stale. Is there anything more recent available? Or did I miss something? My motivation for this email is a recent series of posts[1] I saw on creating games using F# and XNA Express. If F# can do it, Haskell should be able to also. Any pointers are much appreciated! Justin [1] Part 1 - http://grammerjack.spaces.live.com/blog/cns!F2629C772A178A7C!156.entry Part 2 - http://grammerjack.spaces.live.com/blog/cns!F2629C772A178A7C!157.entry Part 3 - http://grammerjack.spaces.live.com/blog/cns!F2629C772A178A7C!158.entry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Refactoring recklessly
Hi, Am Dienstag, den 12.12.2006, 11:24 -0800 schrieb Greg Fitzgerald: I'd like to be able to reorganize my code and then verify that I didn't change any functionality. That is, the old and new code have precisely the same meaning. Also, I'd like to be able to change a function and verify that efficiency was the only thing affected. Are either of these possible in Haskell or any language? Yes, just create an instance (Eq a, Eq b) = Eq (a - b) then you can use == to compare your definitions. Sorry, could not resist, Joachim -- Joachim Breitner e-Mail: [EMAIL PROTECTED] Homepage: http://www.joachim-breitner.de ICQ#: 74513189 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Refactoring recklessly
On 12/12/2006, at 20:31, Alec Berryman wrote: Greg Fitzgerald on 2006-12-12 11:24:58 -0800: I'd like to be able to reorganize my code and then verify that I didn't change any functionality. That is, the old and new code have precisely the same meaning. Also, I'd like to be able to change a function and verify that efficiency was the only thing affected. Are either of these possible in Haskell or any language? Use QuickCheck to generate parameters and compare return values for the old and the new functions. That is a great suggestion which works extremely well in my experience, but only for the second of Greg's requests. In the first case you don't need the additional validation, and probably you don't want to keep your unrefactored code around. ___ 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] Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
On 12/11/06, Andrew Wagner [EMAIL PROTECTED] wrote:
I think there are some great ideas here, and it would be a fantastic
project to do as a community, via a wikibook.
..
On 12/11/06, Kirsten Chevalier [EMAIL PROTECTED] wrote:
there's not really a way to get a publisher to publish something that's
already released under a free documentation license --
but correct me if I'm wrong.)
I have on my shelf, copies of SICP, Thinking Forth, The Icon
Programming Language, and Programming with Unicon, just to name the
ones that I can think of and all of them are available on line. I
like someone at the beginning of the thread, said I just like the
feel of paper...no ink. I read what I have to in online docs, but I
do like to have to sit back with a book. There is, I believe a book
publishing entity on the net that will publish, on demand, so to
speak, any book submitted to them. I can't for the life of me
remember the name of that resource, but it makes the idea of turning a
wikibook into a hard copy feasible... no matter what the topic. I
would surmise that due to the somewhat limited audience of even the
already TOP Haskell books, such as Craft and Hudak's book {title
has slipped my mind}, that most high volume publishers would have
never picked even those up. Getting rich by publishing any book on
Haskell is probably not a good motivation for writing it. But I do
believe that people like myself are out there, and ready to buy a good
book, especially about an at time dense subject, in hard copy. I for
one just like to get away from the whine of the box fan, that is the
cooling device right now on my computing machine, sitting 22 from my
ear canal, and read a good book that is potentially this useful.
happy computing,
gene
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type problem with simple takusen code (was: Trivialdatabase access in Haskell)
On 12/12/06, Taral [EMAIL PROTECTED] wrote: On 12/12/06, Paul Moore [EMAIL PROTECTED] wrote: Can I somehow force PostgreSQL to be disabled? If I need to rebuild to do so (grumble) then how do I uninstall the current version of takusen (it's not in Add/Remove programs and runhaskell Setup.hs doesn't seem to offer an uninstall option... There should be a README or INSTALL file in the original tarball that explains how to do that. I suspect it is a flag you have to pass to runhaskell Setup.lhs configure. Should be, but isn't, unfortunately. The Setup.hs file includes some code defining configPG etc, but there's nothing I can see for the user control how it works. Maybe something in the cabal infrastructure handles this, but I've not had time yet to dive into the cabal documentation on the hope of finding something. Paul. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Micro-contributions to MissingH
Hi, I'm at the moment writing a very simple function, spanM (a la mapM). I realize that this is a rather general-purpose function, so I'm wondering if I should submit this as a patch for MissingH. If so, where in the new hierarchy should this be placed? Thanks in advance. Yang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
On 12/12/06, Louis J Scoras [EMAIL PROTECTED] wrote: I have some IO actions that I want to map over a list of pairs -- these are just directory names and their down-cased versions. It wasn't difficult to actually get the right behavior by just doing mapM twice. -- putDirs just outputs something like mv fst snd mapM_ putDirs pairs mapM_ (uncurry renameFile) pairs This bothered me though, because I suspected that this could be done in one pass. Naively I proceeded to this. mapM_ (putDirs (uncurry renameFile)) pairs Which didn't work. I thought about it a little more before realizing that putDirs wouldn't get any parameters this way: I needed some way to distribute the pair over both operations. Here's the higher-order function I needed: foo h f g i = h (f i) (g i) which could then be curried and we get: mapM_ (foo () putDirs $ uncurry renameFile) pairs Works great. So my question: is there a established name for foo? What about foo partially applied to ()? This was a fun exercise, but I'd like to use the standard implementations if they exist. Before we get too far down the obfuscation road, I'd like to offer what I think is more readable than a liftM2 solution: mapM_ (\p - putDirs p uncurry renameFile p) pairs I haven't tested it, but I hope that does the same thing. To me, this explicitely shows what each is doing, moreso than with a point-free 'foo' combinator. The way my mind worked to get to this solution: mapM_ putDirs pairs mapM_ (uncurry renameFile) pairs == mapM_ (\p - putDirs p) pairs mapM_ (\p - uncurry renameFile p) pairs == mapM_ (\p - putDirs p uncurry renameFile p) pairs Is that a reasonable solution? Bryan Burgers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
This rewrite changes the order of execution. The old version did all of the putDirs and then all of the renameFile calls. The new one interleaves putDirs renameFile calls. In general, is not commutative, though in this case you may be as happy with either order. - Conal On 12/12/06, Bryan Burgers [EMAIL PROTECTED] wrote: On 12/12/06, Louis J Scoras [EMAIL PROTECTED] wrote: I have some IO actions that I want to map over a list of pairs -- these are just directory names and their down-cased versions. It wasn't difficult to actually get the right behavior by just doing mapM twice. -- putDirs just outputs something like mv fst snd mapM_ putDirs pairs mapM_ (uncurry renameFile) pairs This bothered me though, because I suspected that this could be done in one pass. Naively I proceeded to this. mapM_ (putDirs (uncurry renameFile)) pairs Which didn't work. I thought about it a little more before realizing that putDirs wouldn't get any parameters this way: I needed some way to distribute the pair over both operations. Here's the higher-order function I needed: foo h f g i = h (f i) (g i) which could then be curried and we get: mapM_ (foo () putDirs $ uncurry renameFile) pairs Works great. So my question: is there a established name for foo? What about foo partially applied to ()? This was a fun exercise, but I'd like to use the standard implementations if they exist. Before we get too far down the obfuscation road, I'd like to offer what I think is more readable than a liftM2 solution: mapM_ (\p - putDirs p uncurry renameFile p) pairs I haven't tested it, but I hope that does the same thing. To me, this explicitely shows what each is doing, moreso than with a point-free 'foo' combinator. The way my mind worked to get to this solution: mapM_ putDirs pairs mapM_ (uncurry renameFile) pairs == mapM_ (\p - putDirs p) pairs mapM_ (\p - uncurry renameFile p) pairs == mapM_ (\p - putDirs p uncurry renameFile p) pairs Is that a reasonable solution? Bryan Burgers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell and .NET
Hi Justin, I've runned a research project about this topic (in fact, it was the subject of my MSc dissertation). Please see the Haskell.NET Project (http://www.cin.ufpe.br/~haskell/haskelldotnet). We have compiled a subset of the Haskell language to .NET, but we still don't have an available release (we don't support the full Haskell prelude yet). The compiler is an extension to GHC. In the future, we intend to provide full interoperability with .NET in this way. There are some interesting references in the website about our compilation strategies. If you need further information about the project's status, please contact Prof. André Santos ([EMAIL PROTECTED]) and/or Guilherme Avelino ([EMAIL PROTECTED]). Best regards, -- _ Monique Monteiro, MSc http://www.cin.ufpe.br/~mlbm http://thespoke.net/blogs/moniquelouise/default.aspx [EMAIL PROTECTED] +55 81 34198137 Project Manager Recife Microsoft Innovation Center ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
Ok, instead of pushing about why I want to use unsafeCoerce (which I
know it's not a good thing) I decided (as suggested by Taral) to paste
a simplified example of my code.
If anyone finds a way of implementing something equivalent to this code without
unsafeCoerce# and ...
* Not changing chooseDesc or finding an equivalent
* Not splitting or changing Descriptor type (I already found an
equivalent way which uses existentials and in which the type is
splitted in two)
... I'll give up on my risky campaign on unsafeCoerce and you won't
won't have to stand my questions about it again ;)
-
{-# OPTIONS_GHC -fglasgow-exts #-}
import Data.Dynamic
import Foreign
-- Fake instantiation Data
-- To make it simple, lets assume it doesn't need to be marshaled from C
type InstanceInitData = Int
-- Descriptor, equivalent to a C struct with function pointers
-- hd is the handler of the callbacks (void *) in C
data Typeable hd = Descriptor hd =
Descriptor { -- create a new instance and return its handler
instantiate:: InstanceInitData - hd,
-- Run and return a new handler
run:: hd - IO hd}
deriving Typeable
descInt:: Descriptor Int
descInt = Descriptor (\_ - 1)
(\hd - putStrLn (show hd) (return $ hd*2))
descChar :: Descriptor Char
descChar = Descriptor (\_ - 'a')
(\hd - putStrLn (show hd) (return $ succ hd))
descList :: [Dyn]
descList = [toDyn descInt, toDyn descChar]
-- Choose a descriptor, (called from C)
chooseDesc :: Int - IO (StablePtr (Descriptor a))
chooseDesc n = newStablePtr (fromDyn (descList !! n))
foreign export ccall chooseDesc
chooseDesc :: Int - IO (StablePtr (Descriptor hd))
-- Descriptor functions called from C
-- once the descriptor is obtanied through chooseDesc
cInstantiate ::
StablePtr (Descriptor hd) - InstanceInitData - IO (StablePtr hd)
cInstantiate ptr iid = do desc - deRefStablePtr ptr
(newStablePtr.(instantiate desc)) iid
cRun ::
StablePtr (Descriptor hd) - StablePtr hd - IO (StablePtr hd)
cRun dptr hdptr = do desc - deRefStablePtr dptr
hd- deRefStablePtr hdptr
newhd - (run desc) hd
newStablePtr newhd
-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic types through unsafeCoerce
Ignore the previous message, wrong code, here I come again
Ok, instead of pushing about why I want to use unsafeCoerce (which I
know it's not a good thing) I decided (as suggested by Taral) to paste
a simplified example of my code.
If anyone finds a way of implementing something equivalent to this code without
unsafeCoerce# and ...
* Not changing chooseDesc or finding an equivalent
* Not splitting or changing Descriptor type (I already found an
equivalent way which uses existentials and in which the type is
splitted in two)
... I'll give up on my risky campaign on unsafeCoerce and you won't
won't have to stand my questions about it again ;)
-
{-# OPTIONS_GHC -fglasgow-exts #-}
import GHC.Base
import Foreign
-- Fake instantiation Data
-- To make it simple, lets assume it doesn't need to be marshaled from C
type InstanceInitData = Int
-- Descriptor, equivalent to a C struct with function pointers
-- hd is the handler of the callbacks (void *) in C
data Descriptor hd =
Descriptor { -- create a new instance and return its handler
instantiate:: InstanceInitData - hd,
-- Run and return a new handler
run:: hd - IO hd}
descInt:: Descriptor Int
descInt = Descriptor (\_ - 1)
(\hd - putStrLn (show hd) (return $ hd*2))
descChar :: Descriptor Char
descChar = Descriptor (\_ - 'a')
(\hd - putStrLn (show hd) (return $ succ hd))
data Dyn = Dyn
toDyn :: Descriptor hd - Dyn
toDyn = unsafeCoerce#
fromDyn :: Dyn - Descriptor hd
fromDyn = unsafeCoerce#
descList :: [Dyn]
descList = [toDyn descInt, toDyn descChar]
-- Choose a descriptor, (called from C)
chooseDesc :: Int - IO (StablePtr (Descriptor a))
chooseDesc n = newStablePtr (fromDyn (descList !! n))
foreign export ccall chooseDesc
chooseDesc :: Int - IO (StablePtr (Descriptor hd))
-- Descriptor functions called from C
-- once the descriptor is obtanied through chooseDesc
cInstantiate ::
StablePtr (Descriptor hd) - InstanceInitData - IO (StablePtr hd)
cInstantiate ptr iid = do desc - deRefStablePtr ptr
(newStablePtr.(instantiate desc)) iid
cRun ::
StablePtr (Descriptor hd) - StablePtr hd - IO (StablePtr hd)
cRun dptr hdptr = do desc - deRefStablePtr dptr
hd- deRefStablePtr hdptr
newhd - (run desc) hd
newStablePtr newhd
---
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Aim Of Haskell
Claus Reinke schrieb: but on the Pascal note: is there anything in Pascal that Haskell doesn't provide, and improves on (nested procedures, procedure parameters, distinguishing in and out parameters, types, ..)? it has been too long since my Pascal days, I don't remember.. Nothing that I'm aware of. You'd have to be careful which version of Pascal you mean, there were lots of dialects around. In general, however, I'm not sure whether contrasting Haskell to Pascal is a fruitful exercise. Pascal and C are nearer to each other than Haskell is to either of them after all. (Type classes, anonymous functions, type inference, just to name the first three that occurred to me...) apart from the communication problem of understanding Haskell as Pascal: if you're talking to someone who knows Pascal, it might not be a bad idea to position Haskell as a drastically modernized version of Pascal, to get the discussion of real merits going? No, not at all. IMHO. I think that Haskell is a step ahead of OO. The connection is a bit tenuous, but if you carry the Liskov Substitution Principle to its logical consequence, you end up disallowing any semantic changes in subclasses... and that means you don't need interface subclassing at all. And to implement those inhomogenous lists and iterators and whatnot, you show how you can do that in a functional language without the subclassing baggage. ... it might be useful to show how the design patterns from the Gang-of-Four book can be done in a functional language. And with less restrictions. Such a side-by-side comparison might help convince library writers and system architects (and these are among the more important people to win over anyway). Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Aim Of Haskell
Andreas Rossberg schrieb: Claus Reinke wrote: but on the Pascal note: is there anything in Pascal that Haskell doesn't provide, and improves on (nested procedures, procedure parameters, distinguishing in and out parameters, types, ..)? Subrange types, maybe? But I'm sure Oleg will show us that Haskell already has them. :-) Assigning to subrange types often requires a runtime check, so they can't be that easily mapped. (Unless you wrap them in Maybe or Exception, which I'd consider cheating.) Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Aim Of Haskell
Kirsten Chevalier schrieb: I think that it would serve this community well if somebody was able to achieve a better understanding of the social reasons why some programming languages are adopted and some aren't. I think all of us already know that the reason isn't because some are better than others, but it might be time for someone to go beyond that. Actually, it's quite simple: following the ideology de jour and teaching-relevant support. Teachers will teach what's mainstream ideology (I'm using ideology in a strictly neutral sense here). Pascal was popular because teachers felt that structured programming should be taught to the masses, and you couldn't abuse goto in Pascal to make a program unstructured. Later, universities shifted more towards economic usefulness. Which made C (and, later, Java) much more interesting ideologically. Teaching-relevant support means: readily available tools. I.e. compilers, debuggers, editor support, and all of this with campus licenses or open sourced. I don't think that Haskell can compete on the ideological front right now. That domain is firmly in the area of C/C++/Java. Erlang isn't really winning here either, but it does have the advantage of being connected to success stories from Ericsson. To really compete, Haskell needs what people like to call industrial-strength: industrial-strength compilers, industrial-strength libraries, industrial-strength IDEs. In other words, seamless Eclipse and Visual Studio integration, heaps and heaps of libraries, and bullet-proof compilers, all of this working right out of the box. (I see that this all is being worked on.) Teaching-relevant support is already in place, I think - there are several open-source interpreters and compilers available, and Haskell doesn't place an special requirements on editors, nor does it require a specialized environment (the bane of Smalltalk and Lisp). Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
On Tue, Dec 12, 2006 at 11:29:11AM -0500, Louis J Scoras wrote: Which didn't work. I thought about it a little more before realizing that putDirs wouldn't get any parameters this way: I needed some way to distribute the pair over both operations. Here's the higher-order function I needed: foo h f g i = h (f i) (g i) foo is a special case of Control.Monad.liftM2. import Control.Monad import Control.Monad.liftM2 mapM_ (liftM2 () print print) [2,3,4,5] 2 2 3 3 4 4 5 5 (This is using the Monad ((-) a) instance) HTH, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Aim Of Haskell
Benjamin Franksen schrieb: Joachim Durchholz wrote: These activities are among the major reasons why I'm finally prepared to get my feet wet with Haskell after years of interested watching. I'll probably fire off a set of newbie questions for my project, though it might still take a few days to get them organized well enough to do that (and to find the time for setting up the text). Hi Jo! Welcome to the club. It remains to be seen what proportion of my contributions belongs to problem space and what belongs to solution space ;-P (I think I did my share, now and then, on c.l.f to keep up your interest... ;-) Actually, I found out about Haskell-cafe only after comp.lang.haskell was set up - else I might have joined far earlier. Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Arie Peterson schrieb: He wrote the manuscript and it was 'aus einem Guss' (casted as one). The literal meaning of aus einem Guss is cast all at once. This has overtones of it is seamless, has no internal structural bounds which may cause the final product to fracture under stress. This is one of the highest praises that you can sing for software in German, so it's not an uncommon idiom in the field over here. Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Aim Of Haskell
Hi, On 13 Dec 2006, at 00:17, Joachim Durchholz wrote: Kirsten Chevalier schrieb: I think that it would serve this community well if somebody was able to achieve a better understanding of the social reasons why some programming languages are adopted and some aren't. I think all of us already know that the reason isn't because some are better than others, but it might be time for someone to go beyond that. Actually, it's quite simple: following the ideology de jour and teaching-relevant support. Teachers will teach what's mainstream ideology (I'm using ideology in a strictly neutral sense here). Pascal was popular because teachers felt that structured programming should be taught to the masses, and you couldn't abuse goto in Pascal to make a program unstructured. Later, universities shifted more towards economic usefulness. Which made C (and, later, Java) much more interesting ideologically. Since the rise of Java, our university has been teaching almost nothing else. A short course in C, the FP course is being phased out. Some teachers had an interest in having Java knowledgeable kids graduating. I guess the industry also asked for Java knowledge in general. I think it's sad for the students. A language is sometimes more than just syntax, the paradigms it uses should be known, and I've seen too many students who have no clue what a pointer is, who cannot apply simply things such as map and filter ... I'm no haskell wizard, but the very basics I do grok. Teaching-relevant support means: readily available tools. I.e. compilers, debuggers, editor support, and all of this with campus licenses or open sourced. I don't think that Haskell can compete on the ideological front right now. That domain is firmly in the area of C/C++/Java. Erlang isn't really winning here either, but it does have the advantage of being connected to success stories from Ericsson. To really compete, Haskell needs what people like to call industrial-strength: industrial-strength compilers, industrial- strength libraries, industrial-strength IDEs. In other words, seamless Eclipse and Visual Studio integration, heaps and heaps of libraries, and bullet-proof compilers, all of this working right out of the box. (I see that this all is being worked on.) Having a(n important) company backing Haskell in a platform- independent way would certainly help, IMHO. But to convince people to use it, they need to be taught before they go out to find a job. -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Writing Haskell For Dummies Or At Least For People Who Feel Like Dummies When They See The Word 'Monad'
Ketil Malde schrieb: I generally manage to absorb just enough to get by, but I think there is a niche for a book (coupled to practical problems and complete with excercises etc) that is waiting to be filled. Agreed. Something along the lines of The Art of Functional Programming. HSoE is great as a starting textbook. However, it just scratches the surfaces - and after that, trying to grok monads keeps you occupied for a year or longer, keeping you distracted from developing other skills (such as writing and reading point-free code, or developing an intuition for curried code, or digging into a combinator library). Regards, Jo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name that function =)
On 12/12/06, Conal Elliott [EMAIL PROTECTED] wrote: This rewrite changes the order of execution. The old version did all of the putDirs and then all of the renameFile calls. The new one interleaves putDirs renameFile calls. In general, is not commutative, though in this case you may be as happy with either order. - Conal Right. That's really why I wanted to change it. It should do both actions for each element in one pass over the list. On 12/12/06, Bryan Burgers [EMAIL PROTECTED] wrote: Before we get too far down the obfuscation road, I'd like to offer what I think is more readable than a liftM2 solution: mapM_ (\p - putDirs p uncurry renameFile p) pairs I haven't tested it, but I hope that does the same thing. To me, this explicitely shows what each is doing, moreso than with a point-free 'foo' combinator. The way my mind worked to get to this solution: mapM_ putDirs pairs mapM_ (uncurry renameFile) pairs == mapM_ (\p - putDirs p) pairs mapM_ (\p - uncurry renameFile p) pairs == mapM_ (\p - putDirs p uncurry renameFile p) pairs Is that a reasonable solution? That works too. I don't know if I consider the liftM2 solution obfuscated yet, but you're right, it could be leaning that way. Thanks for the alternative suggestion. -- Lou. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
