I'm a Haskell newbie, and this post began as a scream for help. Having slept on it I find myself thinking of Simon Peyton-Jones' recent request for good use cases. Perhaps a frustrated - and doubting - newbie can also provide a data point. If my worries are unfounded (and I hope they are), I think it's significant that to me, today, they seem real enough. Please understand that I'm not being negative for the sake of it - rather I'm describing what Haskell looks like from the outside.
Let me put it this way. Imagine that two weeks ago my forward-thinking and risk-embracing boss asked me to evaluate Haskell for the upcoming Project X. Further imagine that she ensured I was able to sit in the corner emitting curses for the whole two weeks, and on Monday I have to provide my report.
At this point, two weeks in, I would be forced to say that I have no reason to believe that Haskell is useful for real world tasks. ghc is an industrial strength compiler for a toy language. While remarkable claims are made for it, in practice even the experts are often unable to implement the most basic behaviours, and where they are able to implement, they find that their program has become so complex that they are unable to describe or discuss the result. Likely this is a deep problem, not a shallow one. The Haskell community is in denial over this, leading to phenomenal time wasting as one goes round and round in circles playing word games with documentation. This risks a return of the chronic embuggerance that we thought we'd escaped when Vista appeared and the set of people who would have to write Windows device drivers reduced to Hewlett Packard employees, Joanna Rutkowska and criminals. When people enthuse about Haskell, we should run a program called Cat.hs from the haskell.org website, throw fruit at them and laugh.
Strong words, but in all honesty I *want* to believe, and if I would make such a report I imagine hundreds if not thousands would say the same thing. I'm hoping I'm wrong about this, and what's actually needed is some work on communication (perhaps from a production programming point of view, which I'd be keen to help with).
What got me started with Haskell was the video of an Intel employee holding a Teraflops in his hand. I still remember the very silly September 1991 edition of Scientific American, which asked if a Teraflops would *ever* be built. What a stupid question! Stack up enough VIC20s and eventually you'll get a Teraflops. The question should have been "when". Now it's the size of a CD, and only 80 cores are needed. Unfortunately keeping 80 cores running is tricky. I know this from writing some heavy parallel stuff in the mid-90s. It was all quite clever in it's day. Chuck bloated and unguessable CORBA, do something light with TCP/IP (Beuwolf took that to extremes). Neat linkage like rpcgen gave C, so that I could run fast on an SMP Sequent with 30 cores or on a floorfull of about 70 Sun pizza boxen at night.
Unfortunately despite having a nice framework, tracing rays is still hard (the rays and medium were... interesting). Making a problem parallel required a sneaky and dedicated person's sincere skull-sweat. Worse, the solutions so produced had a horrible structural instability about them. Just a small change to the requirement could require a computed value where it wasn't needed before, so that it resulted in big changes to the implementation. The skull-sweating would be needed all over again. (Remember that the big point about objects, which e.g. Booch always emphasized, was that a well chosen set of classes maps well to the domain and so reduces such structural instability.) Even then, it was devilish hard to keep 70 "cores" busy.
So watching the Intel guy got my klaxons going. We now need to be able to do parallel with ease. Functional programming just got really important. It's years since I last played with Scheme, but I quickly moved on because I could see the "which Scheme" problem becoming a millstone round everyone's necks outside of research contexts. Ditto Lisp. So Haskell. Grown-up compiler, one standard and (apparently) a decent corpus of example code and tutorials. I might be an imperative programmer, but I do lapse - for example I find it very easy to generate swathes of cross referenced documentation using m4. My head goes kind of weird after a few hours, such that m4 seems sane and it's the rest of the world that's ungainly, so maybe it should be banned like DMT, but I like it. I felt able to enter the functional world.
I'll omit the first week of suffering, which I see is a well documented rite of passage. (Although most evaluators will have left the building by the end of week one so it's not helping popularity. Perhaps there could be Squires of the Lambda Calculus who haven't done the vigil, mortification of flesh and so on?) Eventually a 3 page introduction on the O'Reilly website together with a good document called "Haskell for C Programmers" got me to the point where I could access "Yet Another Haskell Tutorial", and I was away... for a bit.
After a while I'd written some malformed horrors as answers to exercises, and was telling myself that it's probably just an edge effect - deep within a real Haskell program the ugliness would be invisible, tucked away in Ugly.hs. Then I discovered wxHaskell and got very excited. I really like wxWidgets, and I know it well. If I could play with some Haskell which manipulates wxWidgets I'd progress very quickly! I even have a recent C++ wxWidgets program which was annoying me as I wrote it because of the boilerplate. Great! I can play with type inference and mutter "about bloody time" with a smile on my face. Eventually I got a mix of wxWidgets 2.6.3, wxHaskell from darcs, ghc 6.6 running on my Mac, almost exactly as that permutation was described on the website, and I was off.
Within a few hours I had a nice frame, with 10 text controls and legends populating it. It already took less lines than C++, and then I discovered how to bundle all the text controls into a tuple to pass them around, and define some "getters" to access the tuple. My line count shrunk to what it "should" be - that is, something Kolmogorov wouldn't laugh at but is unattainable in C++. I had an onOpen which popped up a dialog and got a filename from the user, with all the properties filled in right. I proved that I could update the values in the text controls from the onOpen. Great. Next, translate the bit that says (pseudocode):
if(attempt_file_open) if(attempt_file_read) process
That's it. No fancy, complex error messages. Just check the error returns and only proceed if I have something to proceed with. Like grown-ups do. I *will* check my error returns. I have tormented too many newbies to *ever* consider doing anything else. If I cannot check my error returns I will not write the program. This is production programming 101, and I suspect that there's a real issue with priorities between the traditional Haskell community and production programmers.
So the time of madness began. I could find examples which did:
if(attempt_file_open) attempt_file_read process
Which is useless. Other examples did:
attempt_file_open if(attempt_file_read) process
Which is also useless. So I'm looking through the wxHaskell examples. They're all contrived, using very high level functions to (for example) read a complete image structure from a named file, which as one function had one possible source of errors. I go back to scanning and Googling like crazy. Eventually I notice a bit in "Yet Another Haskell Tutorial" - page 65 - which introduces "bracket", immediately explains that it is useless for my (very common) need, and refers the reader to Section 10 - "Advanced Techniques". The author of this excellent document hasn't yet written Section 10. I wonder why. I pause to examine bracket some more. I really can't tell if the "always" clause gets called if the initialization fails. From the use with file opening it looks like it isn't (or the handle to be closed would be invalid) but that wouldn't help if the initializer had two steps, e.g. called socket(2) and bind(2). This is the kind of thing good production programmers get really het up about.
I'm still grovelling through reams of stuff, trying to find out how to open *and* read a file in a grown up way, and I find various programs on haskell.org. There's an implementation of cat(1)! That's the thing! A file concatenator must be able to open *and* read it's file. Eagerly I download it. Curiously there doesn't seem to be any error handling. I compile it and point it at a non-existent file. The program crashes. Horribly. So much for Cat.hs. I feel glad I hadn't been able to cope with the video of Simon Peyton-Jones OSCON talk, because the camera operator kept filming his face while he's gesturing at the specific line of code he's talking about with a pointer! After seeing Cat.hs do essence of FAIL just opening a file, claims that Haskell could serve as a scripting language suitable for the crew of the Black Pearl in yonder corner to use would pain me.
Now I'm getting cross and turned off the whole business. I've been here before, grovelling through reams of stuff, trying to find something out while each example is contrived to side-step the problem, half-baked and useless, evasive or referencing non-existent documentation. All I need to make the experience complete is a certain firm's trademarks gratuitously embedded in the text at least once on every line. Then I'd be nauseous by now too.
Finally I found an uncommented example with no discussion called Hedi. This seems to be doing exception handling, but what it is doing, how, why, what can raise them, so on and so forth would presumably be covered in the "too complex to describe" bit of "Yet Another Haskell Tutorial". I tried to understand it from first principles, looking at the Type theology for the exceptions
...
This reminds me of a 1976 article written by David Parnas and Harald Würges: Response to undesired events in software systems. Since it's old, it is harder to find, but here are a few things to try:
(If not, you can still see the full citation, the abstract, etc.)
The paper is also collected in this book full of Parnas's papers: Software Fundamentals: collected papers by David L. Parnas. Edited by Daniel M. Hoffman and David M. Weiss.
On 16/02/2008, Alan Carter <alangcar...@gmail.com> wrote:
> Then when all this was going on, question number five appeared: What > the hell are these "lightweight Haskell threads"? Are they some kind > of green threads running non-preemptively inside a single OS thread? > Are they OS threads that could run concurrently on multi-core > hardware? If they are green threads (and it sounds like they are) then > this is all an academic exercise which has no production application > yet.
> Best wishes - and still hoping I'm wrong after all
> Alan Carter
Sorry for missing this question in my first response. The answer of course depends on the Haskell implementation in question, but of course, we're talking about GHC here.
Haskell threads, in the sense of Control.Concurrent.forkIO, are essentially a sort of green thread which is scheduled by the Haskell runtime system. Threads can either be bound to a particular OS thread, or (as is default), not be bound to a particular OS thread, allowing the scheduler to manage n Haskell threads with m OS threads, where usually you want to set m to something like the number of processors in your machine.
I'm a little hazy on the details, and perhaps someone more familiar with the GHC runtime can fill in some more details for you if you'd like.
Aside from Concurrent Haskell (which was originally designed for single-processor concurrency and later extended to allow for scheduling threads to execute in multiple OS threads), there is Parallel Haskell, which is used to annotate pure computations for parallelism (but since they're pure, there is no concurrency). At its core, Parallel Haskell has an extremely simple programmer interface:
par :: a -> b -> b
Evaluation of an expression of the form (par x y) will cause x to be put in a queue of expressions to be evaluated by a worker on some OS thread, if there is free time, before resulting in y. If there is no time to evaluate x on some processor before it is eventually needed, then evaluation just proceeds normally, but if there is, then it won't need evaluation later, due to the usual sharing from lazy evaluation.
>From this extremely simple form of parallel annotation, it's possible
to build lots of interesting mechanisms for carrying out evaluation in parallel. You can read more about that in a paper titled "Algorithm + Strategy = Parallelism" by PW Trinder, K Hammond, H-W Loidl and Simon Peyton Jones, or check out the documentation for Control.Parallel.Strategies.
On Sat, Feb 16, 2008 at 06:50:03PM -0500, Cale Gibbard wrote: > On 16/02/2008, Alan Carter <alangcar...@gmail.com> wrote: > > Then when all this was going on, question number five appeared: What > > the hell are these "lightweight Haskell threads"? Are they some kind > > of green threads running non-preemptively inside a single OS thread? > > Are they OS threads that could run concurrently on multi-core > > hardware? If they are green threads (and it sounds like they are) then > > this is all an academic exercise which has no production application > > yet.
> > Best wishes - and still hoping I'm wrong after all
> > Alan Carter
Yes, they are green threads. But not the stupid kind you are used to.
Consider an operating system. You are running hundreds of threads in a typical system. You don't have hundreds of processors - let's be generous and say you have 8. Obviously these threads are in some sense 'green'. But they are still being run with (limited) parallelism! There is no reason to expect anything less of user-level 'green threads', and if all the systems you have been using are incapable of running threads in paralell, then all the systems you have been using are toys or broken. GHC is not a toy (in this regard), and contains a mini-operating system that schedules how ever many millions of threads you have onto a number of OS threads specified with the +RTS -N<x> option.
Since everyone's been focusing on the IO so far, I wanted to take a quick stab at his mention of "green" vs. OS threads... I like the term "green", actually, as it's what my grandmother calls decaffeinated coffee, owing to the fact that decaf taster's choice has a big green plastic lid. Distrust all coffee that comes in a plastic lid, folks. Life is better that way...
However, Haskell very much has real, caffeinated parallelism mechanisms. There is explicit concurrency, which says that things can happen at the same time (see Control.Concurrent) and there is the whole question of Glasgow Parallel Haskell and Data Parallel Haskell, which I won't really begin to cover, as Manuel Chakravarty and Simon Peyton Jones will do TONS better at explaining these than I can. I will however mention Control.Parallel and Control.Parallel.Strategies, because they're my personal favorite way of being parallel.
The Haskell thread is semantically much like the Java thread, it's green, in other words, but you can control the number of real OS threads that Haskell threads are executed on at the command line. Thus you might call them "half caffeinated" But, at least with Control.Parallel.Strategies, they're SO much easier to use. There are a couple of caveats, but I'll give an example first. Let's say you're doing some heavy computer graphics, but you're doing it all in spherical coordinates (I do this all the time, which is why I'm using it as an example) and before you go to OpenGL, you need to transform everything into Carteisan coordinates.
vertices :: [GL.Vertex3] -- a list of oh, say, 150,000 vertices or so in spherical coordinates
sphericalToCart :: GL.Vertex3 -> GL.Vertex3 sphericalToCart (GL.Vertex3 r a z) = (GL.Vertex3 (r * cos a * sin z) (r * sin a * sin z) (r * cos a))
Now to convert them all, you'd just do a
map sphericalToCart vertices
and that would do a lazy conversion of everything, but since you know you're going to use all the vertices, strictness is just as well, and you can do strict things in parallel this way:
On Sat, Feb 16, 2008 at 5:05 PM, Alan Carter <alangcar...@gmail.com> wrote: > Greetings Haskellers,
> I'm a Haskell newbie, and this post began as a scream for help. Having > slept on it I find myself thinking of Simon Peyton-Jones' recent > request for good use cases. Perhaps a frustrated - and doubting - > newbie can also provide a data point. If my worries are unfounded (and > I hope they are), I think it's significant that to me, today, they > seem real enough. Please understand that I'm not being negative for > the sake of it - rather I'm describing what Haskell looks like from > the outside.
> Let me put it this way. Imagine that two weeks ago my forward-thinking > and risk-embracing boss asked me to evaluate Haskell for the upcoming > Project X. Further imagine that she ensured I was able to sit in the > corner emitting curses for the whole two weeks, and on Monday I have > to provide my report.
> At this point, two weeks in, I would be forced to say that I have no > reason to believe that Haskell is useful for real world tasks. ghc is > an industrial strength compiler for a toy language. While remarkable > claims are made for it, in practice even the experts are often unable > to implement the most basic behaviours, and where they are able to > implement, they find that their program has become so complex that > they are unable to describe or discuss the result. Likely this is a > deep problem, not a shallow one. The Haskell community is in denial > over this, leading to phenomenal time wasting as one goes round and > round in circles playing word games with documentation. This risks a > return of the chronic embuggerance that we thought we'd escaped when > Vista appeared and the set of people who would have to write Windows > device drivers reduced to Hewlett Packard employees, Joanna Rutkowska > and criminals. When people enthuse about Haskell, we should run a > program called Cat.hs from the haskell.org website, throw fruit at > them and laugh.
> Strong words, but in all honesty I *want* to believe, and if I would > make such a report I imagine hundreds if not thousands would say the > same thing. I'm hoping I'm wrong about this, and what's actually > needed is some work on communication (perhaps from a production > programming point of view, which I'd be keen to help with).
> What got me started with Haskell was the video of an Intel employee > holding a Teraflops in his hand. I still remember the very silly > September 1991 edition of Scientific American, which asked if a > Teraflops would *ever* be built. What a stupid question! Stack up > enough VIC20s and eventually you'll get a Teraflops. The question > should have been "when". Now it's the size of a CD, and only 80 cores > are needed. Unfortunately keeping 80 cores running is tricky. I know > this from writing some heavy parallel stuff in the mid-90s. It was all > quite clever in it's day. Chuck bloated and unguessable CORBA, do > something light with TCP/IP (Beuwolf took that to extremes). Neat > linkage like rpcgen gave C, so that I could run fast on an SMP Sequent > with 30 cores or on a floorfull of about 70 Sun pizza boxen at night.
> Unfortunately despite having a nice framework, tracing rays is still > hard (the rays and medium were... interesting). Making a problem > parallel required a sneaky and dedicated person's sincere skull-sweat. > Worse, the solutions so produced had a horrible structural instability > about them. Just a small change to the requirement could require a > computed value where it wasn't needed before, so that it resulted in > big changes to the implementation. The skull-sweating would be needed > all over again. (Remember that the big point about objects, which e.g. > Booch always emphasized, was that a well chosen set of classes maps > well to the domain and so reduces such structural instability.) Even > then, it was devilish hard to keep 70 "cores" busy.
> So watching the Intel guy got my klaxons going. We now need to be able > to do parallel with ease. Functional programming just got really > important. It's years since I last played with Scheme, but I quickly > moved on because I could see the "which Scheme" problem becoming a > millstone round everyone's necks outside of research contexts. Ditto > Lisp. So Haskell. Grown-up compiler, one standard and (apparently) a > decent corpus of example code and tutorials. I might be an imperative > programmer, but I do lapse - for example I find it very easy to > generate swathes of cross referenced documentation using m4. My head > goes kind of weird after a few hours, such that m4 seems sane and it's > the rest of the world that's ungainly, so maybe it should be banned > like DMT, but I like it. I felt able to enter the functional world.
> I'll omit the first week of suffering, which I see is a well > documented rite of passage. (Although most evaluators will have left > the building by the end of week one so it's not helping popularity. > Perhaps there could be Squires of the Lambda Calculus who haven't done > the vigil, mortification of flesh and so on?) Eventually a 3 page > introduction on the O'Reilly website together with a good document > called "Haskell for C Programmers" got me to the point where I could > access "Yet Another Haskell Tutorial", and I was away... for a bit.
> After a while I'd written some malformed horrors as answers to > exercises, and was telling myself that it's probably just an edge > effect - deep within a real Haskell program the ugliness would be > invisible, tucked away in Ugly.hs. Then I discovered wxHaskell and got > very excited. I really like wxWidgets, and I know it well. If I could > play with some Haskell which manipulates wxWidgets I'd progress very > quickly! I even have a recent C++ wxWidgets program which was > annoying me as I wrote it because of the boilerplate. Great! I can > play with type inference and mutter "about bloody time" with a smile > on my face. Eventually I got a mix of wxWidgets 2.6.3, wxHaskell from > darcs, ghc 6.6 running on my Mac, almost exactly as that permutation > was described on the website, and I was off.
> Within a few hours I had a nice frame, with 10 text controls and > legends populating it. It already took less lines than C++, and then I > discovered how to bundle all the text controls into a tuple to pass > them around, and define some "getters" to access the tuple. My line > count shrunk to what it "should" be - that is, something Kolmogorov > wouldn't laugh at but is unattainable in C++. I had an onOpen which > popped up a dialog and got a filename from the user, with all the > properties filled in right. I proved that I could update the values in > the text controls from the onOpen. Great. Next, translate the bit that > says (pseudocode):
> if(attempt_file_open) > if(attempt_file_read) > process
> That's it. No fancy, complex error messages. Just check the error > returns and only proceed if I have something to proceed with. Like > grown-ups do. I *will* check my error returns. I have tormented too > many newbies to *ever* consider doing anything else. If I cannot check > my error returns I will not write the program. This is production > programming 101, and I suspect that there's a real issue with > priorities between the traditional Haskell community and production > programmers.
> So the time of madness began. I could find examples which did:
> if(attempt_file_open) > attempt_file_read > process
On Feb 16, 2008, at 3:46 PM, Philippa Cowderoy wrote:
> On Sat, 16 Feb 2008, Alan Carter wrote:
>> I'm a Haskell newbie, and this post began as a scream for help.
> Extremely understandable - to be blunt, I don't really feel that > Haskell > is ready as a general-purpose production environment unless users are > willing to invest considerably more than usual. Not only is it not as > "batteries included" as one might like, sometimes it's necessary to > build > your own batteries!
Ironically, the simple task of reading a file is more work than I expect precisely because I don't want to bother to handle exceptions. I mean, in some applications it's perfectly OK to let an exception go to the top.
But in Haskell, you cannot read a file line by line without writing an exception handler, because end of file is an exception! as if a file does not normally have an end where the authors of these library functions came from?
For the author of the original post ... can't make out what you actually found and tried, so you should know about "catch" in the Prelude, the basic exception handler.
> On Feb 16, 2008, at 3:46 PM, Philippa Cowderoy wrote:
>> On Sat, 16 Feb 2008, Alan Carter wrote:
>>> I'm a Haskell newbie, and this post began as a scream for help.
>> Extremely understandable - to be blunt, I don't really feel that >> Haskell >> is ready as a general-purpose production environment unless users are >> willing to invest considerably more than usual. Not only is it not as >> "batteries included" as one might like, sometimes it's necessary >> to build >> your own batteries!
> Ironically, the simple task of reading a file is more work than I > expect > precisely because I don't want to bother to handle exceptions. I > mean, > in some applications it's perfectly OK to let an exception go to > the top.
> But in Haskell, you cannot read a file line by line without writing an > exception handler, because end of file is an exception! as if a > file does > not normally have an end where the authors of these library functions > came from?
I agree 100%; to make life tolerable around Haskell I/O, I usually end up binding the moral equivalent of
tryJust (\ exc -> case exc of IOException e | isEOFError e -> return () _ -> Nothing) $ getLine
somewhere at top level and then calling that where it's needed.
> For the author of the original post ... can't make out what you > actually > found and tried, so you should know about "catch" in the Prelude, the > basic exception handler.
Also, you might need to know that bracket nests in various ways:
apfelmus> Colin Paul Adams wrote: >> Left? Right? >> >> Hardly descriptive terms. Sounds like a sinister language to >> me.
apfelmus> The mnemonics is that Right x is "right" in the sense of apfelmus> correct. So, the error case has to be Left err .
As I said, this is sinister (i.e. regarding left-handed people as evil).
And left is not the opposite of correct. That would be incorrect.
Also, it is not clear to me that a failure to read a file (for instance) is incorrect behaviour. If the file doesn't exist, then I think it ought to be considered correct behaviour to fail to read the file.
So Success and Failure seem to be much better. Certainly they make the program far more readable to my eyes. -- Colin Adams Preston Lancashire _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
> apfelmus> Colin Paul Adams wrote: >>> Left? Right?
>>> Hardly descriptive terms. Sounds like a sinister language to >>> me.
> apfelmus> The mnemonics is that Right x is "right" in the sense of > apfelmus> correct. So, the error case has to be Left err .
> As I said, this is sinister
You do know what `sinister' means, no?
> (i.e. regarding left-handed people as > evil).
Sheesh, it's just a mnemonic...
> And left is not the opposite of correct. That would be incorrect.
No, Left is the opposite of Right. Right is the constructor modified by fmap (due to the design of Haskell type classes); therefore return = Right. Therefore any computation in Either that is not the result of a return is an application of Left.
> Also, it is not clear to me that a failure to read a file (for > instance) is incorrect behaviour.
Then don't think of Left as `incorrect behavior'. Left isn't incorrect, or Parsec's parse function wouldn't return it on parse errors.
> If the file doesn't exist, then I > think it ought to be considered correct behaviour to fail to read the > file.
> So Success and Failure seem to be much better. Certainly they make the > program far more readable to my eyes.
But the program succeeded in doing what I expected it to do when if failed...
jcc
Besides, these decisions were made 15 years ago, they're not going to change now...
On Sun, 17 Feb 2008, Anton van Straaten wrote: > Is there a benefit to reusing a generic Either type for this sort of thing? > For code comprehensibility, wouldn't it be better to use more specific > names? If I want car and cdr, I know where to find it.
It's Haskell's standard sum type, with a pile of instances already written. There's an instance of MonadError such that you only need to see an Either when you run the computation for example (and then you get an Either whatever the actual error monad was!). If we had appropriate language extensions to map an isomorphic Success/Failure type onto it then I'd probably use them - as it is, the level of inertia around Either is great enough to mean that's only worth doing if I'm expecting to roll a third constructor in at some point.
That said, generally I'll wrap it up pretty fast if I have to handle Either directly. Not that that's necessarily any different to cons, car and cdr of course, but there's plenty of library support for doing so.
"I think you mean Philippa. I believe Phillipa is the one from an alternate universe, who has a beard and programs in BASIC, using only gotos for control flow." -- Anton van Straaten on Lambda the Ultimate _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Feb 17, 2008, at 1:12 AM, Colin Paul Adams wrote:
> And left is not the opposite of correct. That would be incorrect.
> Also, it is not clear to me that a failure to read a file (for > instance) is incorrect behaviour. If the file doesn't exist, then I > think it ought to be considered correct behaviour to fail to read the > file.
Well, of course correct behavior is to cope with both cases in the most appropriate way.
If it's any consolation to those of the left handed persuasion, I guessed it wrong - I have used Either in this way, but Left was Success and Right was Failure. I don't enjoy puns, and mapped to an A/B form it seemed obvious that Success is A.
Donn Cave writes: > On Feb 17, 2008, at 1:12 AM, Colin Paul Adams wrote: >> And left is not the opposite of correct. That would be incorrect. .. > If it's any consolation to those of the left handed persuasion, I guessed > it wrong - I have used Either in this way, but Left was Success and > Right was Failure. I don't enjoy puns, and mapped to an A/B form > it seemed obvious that Success is A.
Weellll, for those who don't enjoy puns, but feel that the life and everything is one enormous pun, a political reminder.
For many years, the world is composed of Leftists and Rightists (let's for the moment forget the normal people). Those from the Left always felt that they were right, and that those from the Right should not be left unpunished, while those from the Right thought that those from the Left should be left to die. Even if it seems right to consider that these deviations should be left to historians, we should not forget that at the beginning of the glorious Soviet country there was a proposal to change the meaning of traffic lights. Red would mean "Forward!!".
On the other hand, in France nowadays the difference between Right and Left is more or less the same as between "Immediate failure" and "Delayed failure". Choose yourselves which is which.
On Sat, Feb 16, 2008 at 05:04:53PM -0800, Donn Cave wrote: > But in Haskell, you cannot read a file line by line without writing an > exception handler, because end of file is an exception! as if a file does > not normally have an end where the authors of these library functions > came from?
Part of it is that using 'getLine' is not idiomatic haskell when you don't want to worry about exceptions. Generally you do something like
doMyThing xs = print (length xs)
main = do contents <- readFile "my.file" mapM_ doMyThing (lines contents)
which will call 'doMyThing' on each line of the file, in this case printing the length of each line.
or more succinctly:
main = readFile "my.file" >>= mapM_ doMyThing . lines
Am Sonntag, 17. Februar 2008 10:12 schrieb Colin Paul Adams:
> The mnemonics is that Right x is "right" in the sense of > correct. So, the error case has to be Left err .
> As I said, this is sinister (i.e. regarding left-handed people as > evil).
I hardly can believe that you mean this seriously. Do you really think that the Haskell architects wanted to offend left-handed people? What does assure you that the names of the Either constructors are about handedness? Are you really so sensitive that you want to make people think about all kinds of misinterpretations the usage of an everyday word may cause before they use it? I’d propose that people don’t search for non-existent defamation so that productivity doesn’t get buried under the search for “politically correct” words.
Actually, I wouldn’t have dreamed of Left being related to left-handedness. To me, it has long been very clear that Left and Right were assigned its meaning this way round because otherwise you wouldn’t get Functor and Monad instances. A pure technical reason, having nothing to do with hands, politics and whatever you might think of.
(I'm copying the list on this, since my reply contains a tutorial which might be of use to other beginners.)
On 19/02/2008, Alan Carter <alangcar...@gmail.com> wrote:
> Hi Cale,
> On Feb 19, 2008 3:48 PM, Cale Gibbard <cgibb...@gmail.com> wrote: > > Just checking up, since you haven't replied on the list. Was my > > information useful? Did I miss any questions you might have had? If > > you'd like, I posted some examples of using catch here:
> Thanks for your enquiry! My experiment continues. I did put a progress > report on the list - your examples together with a similar long an > short pair got me over the file opening problem, and taught me some > things about active whitespace :-) I couldn't get withFile working > (says out of scope, maybe 'cos I'm ghc 6.6 on my Mac)
> but it turned out the line I was looking for (collapsed from the examples) > was:
> text <- readFile "data.txt" `catch` \_ -> return ""
> This ensures the program never loses control, crashing or becoming > unpredictable by attempting to use an invalid resource, by yielding an > empty String if for any reason the file read fails. Then an empty > String makes it very quickly through parsing. I guess that's quite > "functiony" :-)
> Amazing how easy once I knew how. Even stranger that I couldn't find a > "bread and butter" example of it.
> Then I was going very quickly for a while. My file is dumped from a > WordPress MySql table. Well formed lines have 4 tab separated fields > (I'm using pipes for tabs here):
> line id | record id | property | value
> Line IDs are unique and don't matter. All lines with the same record > ID give a value to a property in the same record, similar to this:
let cutUp = tail (filter (\fields -> (length fields) == 4) (map (\x -> split x '\t') (lines text)))
This should almost certainly be a function of text:
cutUp text = tail (filter (\fields -> (length fields) == 4) (map (\x -> split x '\t') (lines text)))
> I found a split on someone's blog (looking for a library tokenizer), > but I can understand it just fine. I even get to chuck out ill-formed > lines and remove the very first (which contains MySql column names) on > the way through!
Sadly, there's no general library function for doing this. We have words and lines (and words would work here, if your fields never have spaces), but nobody's bothered to put anything more general for simple splitting into the base libraries (though I'm sure there's plenty on hackage -- MissingH has a Data.String.Utils module which contains split and a bunch of others, for example). However, for anything more complicated, there are also libraries like Parsec, which are generally really effective, so I highly recommend looking at that at some point.
> I then made a record to put things in, and wrote some lines to play > with it (these are the real property names):
> data Entry = Entry > { occupation :: String > , iEnjoyMyJob :: Int > , myJobIsWellDefined :: Int > , myCoworkersAreCooperative :: Int > , myWorkplaceIsStressful :: Int > , myJobIsStressful :: Int > , moraleIsGoodWhereIWork :: Int > , iGetFrustratedAtWork :: Int > } > ... > let e = Entry{occupation = "", iEnjoyMyJob = 0} > let f = e {occupation = "alan"} > let g = f {iEnjoyMyJob = 47} > putStrLn ((occupation g) ++ " " ++ (show (iEnjoyMyJob g)))
> Then I ran into another quagmire. I think I have to use Data.Map to > build a collection of records keyed by record id, and fill them in by > working through the list of 4 item lists called cutUp. As with the > file opening problem I can find a few examples that convert a list of > tuples to a Data.Map, one to one. I found a very complex example that > convinced me a map from Int to a record is possible, but gave me no > understanding of how to do it. I spent a while trying to use foldl > before I decided it can't be appropriate (I need to pass more values). > So I tried a couple of recursive functions, something like:
> type Entries = M.Map Int Entry > ... > let entries = loadEntries cutUp > ... > loadEntries :: [[String]] -> Entries > loadEntries [] = M.empty Entries > loadEntries [x : xs] = loadEntry (loadEntries xs) x
-- Possible common beginner error here: [x:xs] means the list with one element which is a list whose first element is x and whose tail is xs. Your type signature and the type of cutUp seems to confirm that this is the right type, but you don't seem to have a case to handle a longer list of lists. If you want just a list with first entry x, and with tail xs, that's just (x:xs). If you want to handle lists of lists recursively, you'll generally need two cases: ([]:xss) and ((x:xs):xss). We'll end up doing something different instead of recursion in a moment.
> Trying to create an empty map at the bottom of the recursion so later > I can try to fiddle about checking if the key is present and crating a > new record otherwise, then updating the record with a changed one (a > big case would be needed deep in to do each property update). If I'm > on the right track it's not good enough to get better, so now I'm just > throwing bits of forest animals into the pot at random again :-(
> So I certainly would be grateful for a clue! The bits I can do (I got > a non-trivial wxHaskell frame sorted out quite easily, the tokenizing > and record bit were OK) I think show I'm not *totally* stupid at this, > I'm putting loads of time investment in (it's an experiement in > itself) but there do seem to be certain specific things that would be > ubiquitous patterns in any production or scripting environment, which > are not discussed at all and far from obvious. The more I see of > Haskell the more I suspect this issue is the gating one for popular > uptake.
> I couldn't help thinking of this bit, from the Wikipedia entry on the > Cocteau Twins:
> "The band's seventh LP, Four-Calendar Café, was released in late 1993. > It was a departure from the heavily-processed, complex and layered > sounds of Blue Bell Knoll and Heaven or Las Vegas, featuring clearer > and more minimalistic arrangements. This, along with the record's > unusually comprehensible lyrics, led to mixed reviews for the album: > Some critics accused the group of selling out and producing an > 'accessible album,' while others praised the new direction as a > felicitous development worthy of comparison with Heaven or Las Vegas."
> Best wishes,
> Alan
I woke up rather early, and haven't much to do, so I'll turn this into a tutorial. :)
Okay. The most common ways to build a map are by using the fromList, fromListWith, or fromListWithKey functions. You can see them in the documentation here:
fromListWith :: (Ord k) => (a -> a -> a) -> [(k,a)] -> Map k a
fromListWithKey :: (Ord k) => (k -> a -> a -> a) -> [(k,a)] -> Map k a
They take a list of (key,value) pairs, and build a map from it. Additionally, the fromListWith function takes a function which specifies how the values should be combined if their keys collide. There is also a fromListWithKey function which allows the means of combination to depend on the key as well.
At this point we realise something interesting about the way the data is being represented: if there is a field in someone's record with no row in the database, what should the resulting field contain? In C, they often use some integer which is out of range, like -1 for this.
How about for a missing occupation field? Well, that's a String, you could use some generic failure string, or an empty string, but I'll show you another possibility that just might be convenient.
If t is any type, then the type (Maybe t) consists of the values Nothing, and Just x, whenever x is a value of type t. This is another convenient way to represent the idea that a computation might fail.
Let's start by changing your record type so that each field is a Maybe value, that is, either the value Nothing, or the value Just x, where x is the value it would have been.
data Entry = Entry { occupation :: Maybe String , iEnjoyMyJob :: Maybe Int , myJobIsWellDefined :: Maybe Int , myCoworkersAreCooperative :: Maybe Int , myWorkplaceIsStressful :: Maybe Int , myJobIsStressful :: Maybe Int , moraleIsGoodWhereIWork :: Maybe Int , iGetFrustratedAtWork :: Maybe Int }
There's a very general function in the module Control.Monad which I'd like to use just for the Maybe type here. It's called mplus, and for Maybe, it works like this:
mplus (Just x) _ = Just x mplus Nothing y = y
So if the first parameter isn't Nothing, that's what you get, otherwise, you get the second parameter. Of course, this operation has an identity element which is Nothing.
So this lets you combine partial information expressed by Maybe types, in a left-biased way.
It's about to become obvious that record types are less convenient than perhaps they could be in Haskell, and this is absolutely true -- I'd actually probably use a somewhat different representation myself (possibly something involving a Map from Strings (field names) to Int values), but I can't really be sure what you intend with this data, and how much type safety you want.
I'll elide the field names just because I can here. It's not necessarily good
...
On Feb 20, 2008 10:58 AM, Cale Gibbard <cgibb...@gmail.com> wrote:
> (I'm copying the list on this, since my reply contains a tutorial > which might be of use to other beginners.)
Thank you so much for this - I've just started playing with it so few intelligent responses yet. I'm sure it will be of *huge* use to others, right in the middle of the "gap" I fell into.
The experiment continues - I'll be back :-)
Many thanks,
Alan
-- .. the PA system was moaning unctuously, like a lady hippopotamus reading A. E. Housman ..." -- James Blish, "They Shall Have Stars" _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
A quick note here. This is a *really* excellent tutorial on a variety of subjects. It shows how monad operators can be used responsibly (to clarify code, not obfuscate it), it shows how chosing a good data structure and a good algorithm can work wonders for your code, and on a simplistic level, it shows how to build a database in Haskell.
Would it be possible to clean this up and put it in the wiki somewhere?
> (I'm copying the list on this, since my reply contains a tutorial > which might be of use to other beginners.)
> On 19/02/2008, Alan Carter <alangcar...@gmail.com> wrote: >> Hi Cale,
>> On Feb 19, 2008 3:48 PM, Cale Gibbard <cgibb...@gmail.com> wrote: >>> Just checking up, since you haven't replied on the list. Was my >>> information useful? Did I miss any questions you might have had? If >>> you'd like, I posted some examples of using catch here:
>> Thanks for your enquiry! My experiment continues. I did put a >> progress >> report on the list - your examples together with a similar long an >> short pair got me over the file opening problem, and taught me some >> things about active whitespace :-) I couldn't get withFile working >> (says out of scope, maybe 'cos I'm ghc 6.6 on my Mac)
>> but it turned out the line I was looking for (collapsed from the >> examples) >> was:
>> text <- readFile "data.txt" `catch` \_ -> return ""
>> This ensures the program never loses control, crashing or becoming >> unpredictable by attempting to use an invalid resource, by yielding >> an >> empty String if for any reason the file read fails. Then an empty >> String makes it very quickly through parsing. I guess that's quite >> "functiony" :-)
>> Amazing how easy once I knew how. Even stranger that I couldn't >> find a >> "bread and butter" example of it.
>> Then I was going very quickly for a while. My file is dumped from a >> WordPress MySql table. Well formed lines have 4 tab separated fields >> (I'm using pipes for tabs here):
>> line id | record id | property | value
>> Line IDs are unique and don't matter. All lines with the same record >> ID give a value to a property in the same record, similar to this:
>> I found a split on someone's blog (looking for a library tokenizer), >> but I can understand it just fine. I even get to chuck out ill-formed >> lines and remove the very first (which contains MySql column names) >> on >> the way through!
> Sadly, there's no general library function for doing this. We have > words and lines (and words would work here, if your fields never have > spaces), but nobody's bothered to put anything more general for simple > splitting into the base libraries (though I'm sure there's plenty on > hackage -- MissingH has a Data.String.Utils module which contains > split and a bunch of others, for example). However, for anything more > complicated, there are also libraries like Parsec, which are generally > really effective, so I highly recommend looking at that at some point.
>> I then made a record to put things in, and wrote some lines to play >> with it (these are the real property names):
>> data Entry = Entry >> { occupation :: String >> , iEnjoyMyJob :: Int >> , myJobIsWellDefined :: Int >> , myCoworkersAreCooperative :: Int >> , myWorkplaceIsStressful :: Int >> , myJobIsStressful :: Int >> , moraleIsGoodWhereIWork :: Int >> , iGetFrustratedAtWork :: Int >> } >> ... >> let e = Entry{occupation = "", iEnjoyMyJob = 0} >> let f = e {occupation = "alan"} >> let g = f {iEnjoyMyJob = 47} >> putStrLn ((occupation g) ++ " " ++ (show (iEnjoyMyJob g)))
>> Then I ran into another quagmire. I think I have to use Data.Map to >> build a collection of records keyed by record id, and fill them in by >> working through the list of 4 item lists called cutUp. As with the >> file opening problem I can find a few examples that convert a list of >> tuples to a Data.Map, one to one. I found a very complex example that >> convinced me a map from Int to a record is possible, but gave me no >> understanding of how to do it. I spent a while trying to use foldl >> before I decided it can't be appropriate (I need to pass more >> values). >> So I tried a couple of recursive functions, something like:
>> type Entries = M.Map Int Entry >> ... >> let entries = loadEntries cutUp >> ... >> loadEntries :: [[String]] -> Entries >> loadEntries [] = M.empty Entries >> loadEntries [x : xs] = loadEntry (loadEntries xs) x > -- Possible common beginner error here: [x:xs] means the list with one > element which is a list whose first element is x and whose tail is xs. > Your type signature and the type of cutUp seems to confirm that this > is the right type, but you don't seem to have a case to handle a > longer list of lists. If you want just a list with first entry x, and > with tail xs, that's just (x:xs). If you want to handle lists of lists > recursively, you'll generally need two cases: ([]:xss) and > ((x:xs):xss). We'll end up doing something different instead of > recursion in a moment.
>> loadEntry entries _ rid fld val = entries
>> Trying to create an empty map at the bottom of the recursion so later >> I can try to fiddle about checking if the key is present and >> crating a >> new record otherwise, then updating the record with a changed one (a >> big case would be needed deep in to do each property update). If I'm >> on the right track it's not good enough to get better, so now I'm >> just >> throwing bits of forest animals into the pot at random again :-(
>> So I certainly would be grateful for a clue! The bits I can do (I got >> a non-trivial wxHaskell frame sorted out quite easily, the tokenizing >> and record bit were OK) I think show I'm not *totally* stupid at >> this, >> I'm putting loads of time investment in (it's an experiement in >> itself) but there do seem to be certain specific things that would be >> ubiquitous patterns in any production or scripting environment, which >> are not discussed at all and far from obvious. The more I see of >> Haskell the more I suspect this issue is the gating one for popular >> uptake.
>> I couldn't help thinking of this bit, from the Wikipedia entry on the >> Cocteau Twins:
>> "The band's seventh LP, Four-Calendar Café, was released in late >> 1993. >> It was a departure from the heavily-processed, complex and layered >> sounds of Blue Bell Knoll and Heaven or Las Vegas, featuring clearer >> and more minimalistic arrangements. This, along with the record's >> unusually comprehensible lyrics, led to mixed reviews for the album: >> Some critics accused the group of selling out and producing an >> 'accessible album,' while others praised the new direction as a >> felicitous development worthy of comparison with Heaven or Las >> Vegas."
>> Best wishes,
>> Alan
> I woke up rather early, and haven't much to do, so I'll turn this into > a tutorial. :)
> Okay. The most common ways to build a map are by using the fromList, > fromListWith, or fromListWithKey functions. You can see them in the > documentation here:
> fromListWith :: (Ord k) => (a -> a -> a) -> [(k,a)] -> Map k a
> fromListWithKey :: (Ord k) => (k -> a -> a -> a) -> [(k,a)] -> Map k a
> They take a list of (key,value) pairs, and build a map from it. > Additionally, the fromListWith function takes a function which > specifies how the values should be combined if their keys collide. > There is also a fromListWithKey function which allows the means of > combination to depend on the key as well.
> At this point we realise something interesting about the way the data > is being represented: if there is a field in someone's record with no > row in the database, what should the resulting field contain? In C, > they often use some integer which is out of range, like -1 for this.
> How about for a missing occupation field? Well, that's a String, you > could use some generic failure string, or an empty string, but I'll > show you another possibility that just might be convenient.
> If t is any type, then the type (Maybe t) consists of the values > Nothing, and Just x, whenever x is a value of type t. This is another > convenient way to represent the idea that a computation might fail.
> Let's start by changing your record type so that each field is a Maybe > value, that is, either the value Nothing, or the value Just x, where x > is the value it would have been.
> data Entry = Entry > { occupation :: Maybe String > , iEnjoyMyJob :: Maybe Int > , myJobIsWellDefined :: Maybe Int > , myCoworkersAreCooperative :: Maybe Int > , myWorkplaceIsStressful :: Maybe Int > , myJobIsStressful :: Maybe Int > , moraleIsGoodWhereIWork :: Maybe Int > , iGetFrustratedAtWork :: Maybe Int > }
> There's a very general function in the module Control.Monad which I'd > like to use just for the Maybe type here. It's called mplus, and for
Many thanks for the explanations when I was first experimenting with Haskell. I managed to finish translating a C++ wxWidgets program into Haskell wxHaskell, and am certainly impressed.
I've written up some reflections on my newbie experience together with both versions, which might be helpful to people interested in popularizing Haskell, at:
-- .. the PA system was moaning unctuously, like a lady hippopotamus reading A. E. Housman ..." -- James Blish, "They Shall Have Stars" _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Alan Carter wrote: > I've written up some reflections on my newbie experience together with > both versions, which might be helpful to people interested in > popularizing Haskell, at:
On the lack of simple examples showing, for example, file IO: I seem to recall a Perl book (maybe it was Edition 1 of the Camel Book) which had lots of very short programs each illustrating one typical job. Also the Wiki does have some pages of "worked example" programs. But I agree, we could do better.
I'm surprised you found the significant whitespace difficult. Yes, the formal rules are a bit arcane, but I just read them as "does the Right Thing", and it generally works for me. I didn't know about the significance of comments, but then I've never written an outdented comment.
I had a look through your code, and although I admit I haven't done the work, I'm sure that there would be ways of factoring out all the commonality and thereby reducing the length.
Finally, thanks for that little story about the BBC B. I had one of those, and I always wondered about that heatsink, and the stonking big resistor next to it. They looked out of scale with the rest of the board.
Paul Johnson <p...@cogito.org.uk> writes: > I'm surprised you found the significant whitespace difficult.
I wonder if this has something to do with the editor one uses? I use Emacs, and just keep hitting TAB, cycling through possible alignments, until things align sensibly. I haven't really tried, but I can imagine lining things up manually would be more painful, especially if mixing tabs and spaces.
-k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-C...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
|
