Slashdot Mirror
Haskell 2010 Announced
paltemalte writes "Simon Marlow has posted an announcement of Haskell 2010, a new revision of the Haskell purely functional programming language. Good news for everyone interested in SMP and concurrency programming."
← Back to Stories (view on slashdot.org)
I admit that a function with no side effects can ease making things thread safe, but are recursive style functional programming languages really used that much in "SMP and concurrency programming" nowadays. I wrote some code in that category but I never envisioned a functional programming language would suit the job. Am I the only one ? ;-))
Thanks for your replies,
Everything I write is lies, read between the lines.
And all three of its users are overjoyed.
"The current committee is still discussing how to go about finding a new committee"
A fitting name for this Haskell programming language might have been "Python" hadn't it all ready been taken.
Some of my favourite people are from th US; Vonnegut, Chomsky, Bill Hicks.
So I don't think I'll look at the article until I actually need to program in Haskel....
Test your net with Netalyzr
Haskell! Haskell! Every geek's favorite mental masturbation toy!
Please do not read this sig. Thank you.
They figure if they make it good enough, more than one person will code in it at a time.
Well, pure functional languages are (potentially) good for concurrency in general. Because they have no mutable variables in the usual sense, it doesn't actually matter what order functions are evaluated in (other than the fact that callers cannot continue until their callees return). You can't do this in C or Java because it might be necessary for one function to see a variable modified by another. In a functional language, any dependencies are explicit call-return relationships (well, ish, they typically do have some non-functional constructs otherwise it's hard to do IO!), so in principle it's quite easy to split up a program's work across multiple CPUs (or machines) and not worry about whether they need to talk to each other.
Haskell, along with the ML family of languages, also has an amazing type checker that is waaay more sophisticated than most other languages. I think most people who've played around with these languages do start to feel that often "If it compiles, it's bug-free". Obviously that's not something you can rely on, since the compiler can't know what you meant to do. But it is true that the type system is *way* more useful at detecting bugs at compile-time than for any conventional language I've used.
The fact that union types can have no values explains a lot about Jimmy Hoffa.
Well, pure functional languages are (potentially) good for concurrency in general. Because they have no mutable variables in the usual sense, it doesn't actually matter what order functions are evaluated in (other than the fact that callers cannot continue until their callees return).
Maybe you can help me get past one of my mental stumbling-blocks with Haskell, which seems like a really cool language, but which I clearly have no clue about because I don't get a very fundamental thing. As I understand it there are two fundamental claims about Haskell:
1) it is a "pure functional" language, which is therefore entirely and completely and "purely" side-effect-free. I appreciate the immense potential value of this for things like program verification, and I'd love to learn more about it.
2) there is a Haskell construct that is part of the Haskell language called a "monad" that can have side-effects.
I'm a deeply pedantic guy, and I'm unable to reconcile these two claims, and it puts me off looking more deeply into the language every time I read about it because there's clearly something I don't get. It seems to me that either:
a) Haskell is not actually purely functional: it is a purely functional core sub-language with extremely well controlled additional side-effect-producing parts
b) Monads are not actually considered "part" of the Haskell language, in the same way that pre-standardization STL was not "part" of the C++ language.
c) I'm completely missing something.
Enlightenment would be greatly appreciated.
Blasphemy is a human right. Blasphemophobia kills.
EmptyDataDeclarations allows for data types without a constructor... but to be perfectly honest I haven't quite figured out what practical benefit they have :). I'm sure there is a reason, but I don't think it's as trivial or obvious as you make out.
Consider the tag struct idiom in C++:
struct open_read_t {};
struct open_read_write_t {};
class File { // Open for reading. // Open for writing.
File(const string& name, open_read_t);
File(const string& name, open_read_write_t);
};
The tag structs are not used to carry data; their only purpose for existing is to disambiguate the two constructors.
Similarly, in the STL, tag structs are also used to mark iterator categories, to make sure that when you could use more than one algorithm for a container, the most appropriate one is selected.
This is essentially what empty data declarations are for in Haskell, except that by having no constructors, you can guarantee that they will never be instantiated. The most common use is in conjunction with phantom types.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Let's see if I can explain this simply.
The Haskell language, like any other language, needed constructs like "read" and "write", but to implement them as simple functions would have broken the underlying assumptions of purity and lazy evaluation.
Haskell happened to have monads. A monad is essentially a typeclass for containers, that allow you to do certain things to combine containers of the same type, without having to worry about what kind of container it is. Most (all?) of the containers in the standard library are instances of Monad.
The Haskell language designers came up with (or perhaps borrowed) an idea. They would create a new container type, called IO, and make it an instance of Monad. However, unlike other containers, it would not have any accessor functions. You can pass around an object around of type IO in pure code all you want, but you can't ever examine the contents of the IO container from within "pure" code. The only thing you can do with it is combine it with other IO objects. Combining two IO objects is equivalent to evaluating the file operation or what have you inside one IO object and passing it's result to and executing whatever is inside the second IO object. The actions within an IO object, however, are free to invoke pure code if they like.
Every haskell program has a main() function, which is an IO action. This allows you do do any necessary file IO your program needs to do, and it can also call out to pure functions. Pure function cannot invoke IO actions. Most Haskell programmers try to keep the IO actions as simple as possible and rely on pure code for the bulk of the program.
As a concrete example, I wrote a ray tracer, which parsed a text file and generated an image. As I was writing it, I got to the part where I needed to write the file parser. I thought "oh, no, this whole thing has to execute within the IO monad and it'll be a big mess". However, it was not so. After scratching my head a bit, I ended up writing a pure function that takes a simple text string and converts it to my internal representation of a scene, ready to be ray traced. Within main (within the IO monad), I would read the text file in with a lazy function "hGetContents", which returns a string which is the contents of the file. I would pass that string to the parser, and then trace a grid of rays (one per pixel) against the parsed scene. The list of pixels with their calculated color values was returned to the IO monad, where I used OpenGL to plot them to the screen.
The interesting bit about this is that hGetContents is lazy. In a strict (i.e. non-lazy) implementation, the whole string would be read at once. This is inefficient, and may cause problems for text files that won't fit in memory. Due to laziness, however, the string is passed into the parser without being fully evaluated. As the parser needs more data, the run-time system will cause hGetContents to read another block. So, here we have an example of a pure function that's indirectly triggering IO, and it's doing it all without violating the constraints of the type system.
Actually hGetContents cheats by using unsafeInterleaveIO. It's a cool hack, but lazy IO is an inherently risk business. For instance, if your program later wrote back changes to your scene file, the result is undefined. There's no guarantee of when the program is done reading the file. If you keep this in mind it's no problem, but if all IO worked this way you'd go insane. (Also consider the problem of error handling if there's a disk error.)