Slashdot Mirror

Some languages already encourage alternate markup styles. For example, literate programming in Haskell uses LaTeX-formatted source files. Some Haskell compilers also support unicode syntax so you can do "" instead of "->".

    Data Parallel Haskell

According to this, Haskell generates HC files (which are stylized C files) when it compiles GHC (the Haskell compiler). You then get the HC running with GCC, and you have a working Haskell compiler.

I hate to break the news to you, but your proposed "silver bullet" is hardly something new. Synchronous dataflow has been with us at least since the 1970s. It's great for designing hardware, DSP software and other simple kinds of algorithms, but as a panacea for all the diseases of the software world? I wish I had some of the stuff that you're smoking. :)

Now, asynchronous dataflow (with the appropriate support for dealing with complex data structures) might actually be helpful to slash some of the complexities of developing efficient software for massively parallel computers, and in fact there has been renewed interest in such techniques since the 1990s, especially in functional programming circles (see, e.g., the work on "functional reactive programming" by Yale's Haskell group and others, http://www.haskell.org/frp/).

But, as others have already pointed out, there's still billions of lines of "legacy" code to support if you want to go to market with such a system. So even if modern dataflow models prove useful for multicore architectures, they will still be confined to special niches for quite some time, IMHO.

I couldn't find anything related to procedurally-generated textures, not that I really looked. I could find a few games written in Haskell though. I mean they're not as advanced as a spinning sphere or anything like that...

Frag which was done for an undergrad dissertation using yampa and haskell to make an FPS.
Haskell Doom which is pretty obvious.
A few more examples.

I dunno if that satisfies your requirements or not. Though I don't quite get how this is relevant to the GP's post. This seems like more of a gripe with Haskell than anything. But if I've missed something, please elaborate.

http://slashdot.org/
http://lambda-the-ultimate.org/
http://planet.haskell.org/
then I usually head back to slashdot and start all over again, grumbling about the lack of new posts before I give up and read from the firehose and rinse, wash, repeat.

Like a compiler? If your functions don't fit the model, change your functions, not your model. Functional programing makes errors reproducible, tractable, and fixable. And you can do it any language.

http://haskell.org/ No side effects and it has a great way of dealing with IO. Plus the newest version of GHC has some great new features for writing parallel programs.

http://haskell.org/ No side effects and it has a great way of dealing with IO. Plus the newest version of GHC has some great new features for writing parallel programs.

Bah.

http://haskell.org/

A lot of the support for Haskell *used* to be in Academia. But #haskell is full of people using it for every day real-world purposes it seems. I was especially impressed after talking to Cliff Beshers of Linspire who are doing all of their distro-specific coding such as the installer etc. in Haskell. I have now seen IRC bots in haskell, web servers and web application servers in haskell, and video games in haskell. Heck, the only existing implementation of Perl 6 is written in Haskell. It seems like it has escaped Academia and has been looking for a problem to solve for a few years now. And it looks like this multi-core business may well be it. Especially since haskell has a parallelizing compiler.

A lot of the support for Haskell *used* to be in Academia. But #haskell is full of people using it for every day real-world purposes it seems. I was especially impressed after talking to Cliff Beshers of Linspire who are doing all of their distro-specific coding such as the installer etc. in Haskell. I have now seen IRC bots in haskell, web servers and web application servers in haskell, and video games in haskell. Heck, the only existing implementation of Perl 6 is written in Haskell. It seems like it has escaped Academia and has been looking for a problem to solve for a few years now. And it looks like this multi-core business may well be it. Especially since haskell has a parallelizing compiler.

A lot of the support for Haskell *used* to be in Academia. But #haskell is full of people using it for every day real-world purposes it seems. I was especially impressed after talking to Cliff Beshers of Linspire who are doing all of their distro-specific coding such as the installer etc. in Haskell. I have now seen IRC bots in haskell, web servers and web application servers in haskell, and video games in haskell. Heck, the only existing implementation of Perl 6 is written in Haskell. It seems like it has escaped Academia and has been looking for a problem to solve for a few years now. And it looks like this multi-core business may well be it. Especially since haskell has a parallelizing compiler.

We could also start to use languages that don't have side effects .

Then, the compiler can multi-thread our programs for us.

But NULL is a good thing. Not having NULL, or its equivalent would put us back in the hideous world of the old BASIC programs I grew up on, where all kinds of "signal" values were hardcoded in. Returning an integer? But what if the computation failed? No problem: just return 100. Or maybe 0. Or good old -999. And what happens if you use the last, and someone comes along ten years later and changes the datatype to unsigned ints?

Related concepts to NULL are ternary logic and Haskell's Maybe monad.

Tim Bray is right, and he couldn't have put it better: W3C XML Schemas (XSD) suck. The reason Relax NG is so much cleaner and more powerful than committee-designed XML Schemas, is that it's based on a sound mathematical foundation (tree regular expressions, or "hedge automata theory"). While XML-Schemas suffer from ad-hoc design, committee-burn, lack of focus, and half-baked attempts to solve too many unrelated problems.

Here's some interesting stuff from my blog about the design and development of Relax NG.

-Don

James Clark wrote about maximizing composability:

First, a little digression. In general, I have made it a design principle in TREX to maximize "composability". It's a little bit hard to describe. The idea is that a language provides a number of different kinds of atomic thing, and a number different ways to compose new things out of other things. Maximizing composability means minimizing restrictions on which ways to compose things can be applied to which kinds of thing. Maximizing composability tends to improve the ratio between functionality on the one hand and simplicity/ease of use/ease of learning on the other.

Clark describes the derivative algorithm's lazy approach to automaton construction:

I don't agree that <interleave> makes automation-based implementations impossible; it just means you have to construct automatons lazily. (In fact, you can view the "derivative"-based approach in JTREX as lazily constructing a kind of automaton where states are represented by a canonical representative of the patterns that match the remaining input.)

The Relax NG derivative algorithm is implemented in a few hundred elegent declarative functional lines of Haskel, and also in tens of thousands of lines and hundreds of classes of highly abstract complex Java code.

Clark's Java implementation of Relax NG is called "jing", which is a Thai word meaning truthful, real, serious, no-nonsense, and ending with "ng".

Comparing the Java and Haskell implementations of Relax NG illustrates what a wicked cool and powerful language Haskell really is. The Java code must explicitly model and simulate many Haskel features like first order functions, memoization, pattern matching, partial evaluation, lazy evaluation, declarative programming, and functional programming. That requires many abstract interfaces,, concrete classes and brittle lines of code.

While the Java code is quite brittle and verbose, the Haskell code is extremely flexible and concise. Haskell is an excellent design language, a vehicle for exploring complex problem spaces, designing and testing ingenious solutions, performing practical experiments, weighin

Indeed, most of the new techniques for constructing embedded domain specific languages are being stolen from, or at least are completely explicable in terms of category theory.

There are quite a number of completely practical techniques for structuring programs -- monads being the star player at the moment, and of course, their dual, comonads, as well as applicative functors, and Hughes' Arrows which have their foundations in category theory. One doesn't need to understand category theory in order to understand the way in which these abstractions apply to programming, but it certainly helps. I certainly don't think that even these things have been completely mined -- for instance, we only have a few ideas so far about how comonads help programming, but what's there is interesting. Essentially comonads abstract certain kinds of dataflow programming languages. There's a lot of possible interesting research for people who know both category theory and computer science.

If you want to try some of it out and see, have a look at Haskell. :) The community around Haskell is taking these abstractions and turning them into practical libraries which basically anyone can learn to use, regardless of their background. Of course it will take more or less work to learn depending on what that background is, how old you are, etc. It's certainly no harder than learning your first imperative programming language was, and it's definitely worthwhile. With monads in particular, you'll wonder what you ever did without them.

For the unfamiliar, monads, and even more specifically, monad transformers, basically give you really effective ways to quickly construct embedded domain-specific languages. You can very quickly create an EDSL which is the perfect language in which to solve your problem, and you get really nice maintainable code, and lots of correctness guarantees for free or almost free, and you get to borrow all the control structures which people have written for other monadic languages already.

The toy example I like to give people of this is of constructing an EDSL for solving Sudoku puzzles (of course nothing special about Sudoku, any combinatorial constraint problem will do). With a couple of monad transformers, you get a language with state for maintaining the current state of the board, and nondeterminism, allowing you to say in your language "x is one of this list of values", and having the language try all possibilities, in the end performing a depth-first search. You can then, in about as much code as it takes to program the Sudoku constraints, restrict access to the state, so that attempting to make a move which would invalidate the solution causes backtracking to occur right away. In this EDSL, you can write a Sudoku solver like this (the rest of the code is here):

solve = forM [(i,j) | i <- [1..9], j <- [1..9]] $ \(i,j) -> do

v <- valAt (i,j) -- ^ for each board position
when (v == 0) $ do -- if it's empty (we represent that with a 0)

a <- option [1..9] -- pick a number
place (i,j) a -- and try to put it there

(Jeez, it's hard to post properly formatted code on slashdot. Isn't this supposed to be a site for nerds? For those interested, I ended up using blockquotes and explicit line breaks, as well as having to escape the less-than symbols.)

That's actual code -- it's a rather naive algorithm to use, essentially equivalent to brute force search with backtracking, but more clever ones could again easily be written in the same monad. The nice thing is that whatever algorithm you use, if it manages to fill the whole board, must fill the board correctly. The 'forM' in that code is a function implementing a foreach loop which works in any monad, similarly 'when' is another such function, and 'option' is a function which works in

``Also though it is slightly off-topic I also think that Java under GPL would not benefit as much because the model of contribution is really not as easily understood as the OS world.''

With all the complaints about the Java community process being slow and bureaucratic, and the free Java implementations lagging behind in features, I think having a good, open source Java implementation is a Good Thing in it's own right.

Also, I don't know what you mean by the model of contribution for Java not being as easily understood as the OS world. It's not like there aren't any successful open source programming language implementations yet.

Actually, you can use braces and semicolons if you want to.

This functional language is so interesting, there should be more talk about it.

There are many research languages and abstractions focusing specifically on this task.

If a problem can be broken down into a list-processing problem on lists with size powers of two, you can get parallelism essentially for free. (See this paper on powerlist.)

This may sound extremely specialized, but it's crucial to realize that several of the most fundamental functions in functional programming -- filter, map, sort, etc. -- can take advantage of this fact, immediately, for free in any case where the evaluation of the filter/map/sort/etc. expression has no side-effects. (Or in all cases, if the language is referentially transparent. Heard of Haskell?)

Further functions -- such as foldl, foldr, etc. -- can also take advantage of this construct if the function being applied is associative. So this is useful for addition, multiplication, gcd, matrix multiplication, ...

If someone were to frame boolean satisfiability in these terms, they might discover something interesting...

At any rate, remember that if a problem looks difficult from one angle, it often pays to look at it from another. That a problem seems hard to solve with imperative languages does not imply that a problem is hard to solve in general.

I tried to get into LISP. I tried so hard. I ended up falling for Scheme and Haskell instead, Haskell more so. If you find some time and want to try your groove at functional programming again, and just can't get into LISP, give Haskell a shot. Something about the way Haskell is put together, I found it more intuitive. Although Haskell's syntax is, to quote Tim Sweeny of Epic Megagames, "scary", it's a really straight-forward language, and I like that. I did struggle with the severe type restrictions at first, they are especially severe if you're coming from C where everything can be anything else so long as you cast it, but it's nothing that can't be overcome with a bit of practice.

While we are on this bit, I would recommend an ML, either SML or OCaml, perhaps even in place of Haskell (Haskell's syntax can be easily argued to be either better than or worse than ML's, and anything you can so in Haskell (including type-classes and lazyness) can be done in ML, so while I do use Haskell, I generally recommend one of the MLs as a well-typed, type-inferring functional language to know (OCaml if they are more systems/applications oriented, and SML if they are more theory oriented or just curious).

Comparing a Java compiler to a Haskell compiler, say, is like comparing a toddler's first steps to running ultramarathons.

Personally, I like monadic parser combinators, like those provided by the Parsec library for Haskell. You can parse arbitrary context free grammars, and even many sensible context-sensitive ones with little difficulty, you get to write your parsers in the language (Haskell) and you get meaningful parse error reports for free.

A major downside to the approach is that Parsec itself lacks a symmetric choice combinator, having only left-biased conjunction, together with a combinator which causes a parser not to consume input when it fails. Though other libraries, like Koen Claessen's ReadP rectify this, the associated performance costs tend to be higher.

I tend to use Parsec even for some tasks where many people would use regular expressions. It might not be quite as fast as statically building your parser, but it's possible to get really quite decent performance out of it, and the convenience level is quite high.

Another interesting thing to look at are arrow-based parser combinators, like PArrows -- these allow for a greater level of optimisation at runtime, so you can get really good performance while allowing for things like symmetric choice. They also can allow for cool features like the ability to inspect the parser and emit code in various languages for that parser. (The one I linked to has the ability to compile parsers to JavaScript code in fact.) The downside is that arrows tend to be a little more inconvenient to program with than monads.

Coincidentally, I discovered today that Linspire/Freespire are standardizing on Haskell for core OS development. I'm still blinking a bit about that one, but you have to give them marks for chutzpah.

You want to know the latest trends for Java-based web development? Fewer and fewer people are going to be doing Java-based web development in the future.

Fuck trends. They're wrong. Every day the industry continues to stay with its current ridiculous technologies when vastly superior ones were invented decades ago infuriates me further. If it doesn't infuriate you, you're not paying close enough attention.

My advice: read Lambda the Ultimate and Steve Yegge's blog. Endeavor to learn what the lambda calculus and referential transparency are. If you are sincerely interested in bettering yourself as a programmer and don't go find out who Alonzo Church was then so help me God I will kick you in the balls. Learn about SML and type inference. Learn about Haskell and monads. Learn about process calculi and Erlang. Learn about Lisp and code generation and domain-specific languages. Learn about Scheme and lexical closures and continuations. Learn about Smalltalk and what OO was really supposed to be. Learn about type theory and formalism and the Curry-Howard correspondence. Learn about Forth and Joy and how you can have a powerful, expressive language without even so much as a grammar. Learn about Intercal and Befunge and just how badly your choice of programming language can torture you. Learn about UML and Ruby on Rails and Seaside and agile programming and Java generics and Python generators. Learn about aspect-oriented programming, context-oriented programming and concept programming. Learn about multi-paradigm languages like OCaml or Oz. Learn about weird Lisp dialects with syntax like Rebol or Dylan.

Realize that library design is language design. Realize that asynchronous programming with callbacks and explicit state in a world where lightweight coroutines were around in the days of fucking Simula in the 60s for Christ's sake is cruel and unusual torture. (Sorry, pet programming construct.) Realize that the programming language research community, while considering systems programming a solved problem and generally not interested in talking about human factors, is doing some genuinely promising work. Did you know that there are conc

I suggest you try Haskell or another language with type deduction. You don't normally have to declare the type for any function you write, but you can add explicit type declarations to help catch errors or as a form of documentation (which is checked by the compiler, of course).

What you're talking about is very close to CPS.

There are some ways to convert normal function calls to CPS.

And there is something called monads used to convert imperative algorithms to functional style.

And yes, continuations can be a very powerful technique.

However, CPS functional code is still coding an algorithm. Any way to compute something is an algorithm. May be you should name your critic "I dislike imperative algorithms, and I like CPS functional algorithms."

Paul.

Sure, your algorithm would count as functional programming, but part of the point about functional programming is that entire programs, not just individual functions, consist of nothing but the composition of pure mathematical functions. Which means that a lot of what you do is "normal" languages just isn't allowed. Point 2.1 in the comp.lang.functional FAQ, which gives a simple comparison between imperative and functional style, although to really understand it you'd need to learn a bit more about at least one of the functional languages.

Just about any language allows you to implement simple pure mathematical functions - as you say, "a simple equation would have unlimited portablity" - but very few languages allow you to construct entire programs that way. None of the mainstream languages (PHP, Perl, Python, Ruby, Java, C, C++, BASIC, etc.) support functional programming to that extent. The languages which do support it are ones like Haskell, ML, OCaml, and Scheme. The reason I say that functional programming is not commercially applicable is not because there aren't commercial applications of it, but because these languages are hardly being used at all commercially. There's a bit of a catch-22 there, because people don't know them because they aren't being used, and they aren't being used because people don't know them.

Here's your algorithm implemented in the Haskell language. If you want to try running it, download and install Glasgow Haskell (on Debian, you can do "apt-get install ghc6"), and run "ghci" to get an interactive Haskell prompt.

-- define a list of p values
let ps = [0.825, 0.8868, 1, 0.8542, 0.8889, 0.8, 0.9118, 0.95, 0.9487, 1, 1, 0.8333, 0.8197, 0.6383, 1, 0.8727, 0.875, 0.7879, 0.8667, 0.8636]

-- define a function which averages a list of numbers.
-- The 'fromIntegral' is needed because Haskell is a strongly, statically typed language
let avg xs = sum xs / fromIntegral (length xs)

-- work out the average of all the p's
let avgP = avg ps

-- define the function, f(p)
-- this would usually be written on multiple lines, but the interactive shell doesn't allow that (?)
let z p = x / y - 1 where x = p - avgP; y = 1 - avgP

-- Finally, "map" the function f over the list ps, giving a list of results.
map z ps

The output from this is:

[-1.4721965172036693,-0.9523008328426015,0.0,-1.22 65500126188285,-0.9346344746361576,-1.682510305375 6212,-0.7419870446706487,-0.4206275763439058,-0.43 156389332884704,0.0,0.0,-1.4023723395305803,-1.516 783040296123,-3.0428198872718117,0.0,-1.0709178093 715828,-1.0515689408597635,-1.7843021788508464,-1. 1213931185328516,-1.1474720282661737]

The above is oriented towards experimenting with it at the command line. For a real program, you'd probably ultimately package it into a single function that takes an input list and produces an output list, e.g.:

-- repeating the avg definition for the sake of completeness
let avg xs = sum xs / fromIntegral (length xs)

let f ps = map z ps
where avgP = avg ps;
z p = x / y - 1
where x = p - avgP;
y = 1 - avgP

("f" is defined over multiple lines for readability, the way it would be written in a program file, although the indentation didn't make it through Slashdot; to enter it interactively, you'd have to do it on one line.)

This last version defines your entire formula quite clearly, for anyone who knows functional programming. That's one answer to your question of how to express these things mathematically: if you express them using high-level programming languages, it has the benefit being concise and unambiguous, but also checked by the compiler, so if it works you know you haven't made any mistake

I'm sorry, I don't understand your point? Haskell is a programming language, like C++.

http://www.haskell.org/haskellwiki/Haskell

That's quite true: Haskell's notion of pattern matching is much more powerful and extensible than mere regular expressions.

Jim Clark's Haskell implementation of the derivative algorithm for validating Relax NG is a wonderful example of how powerful, elegant and concise Haskell is. Relax NG is all about tree structured regular expressions over "hedges" (mixed trees of XML elements and text). It's based on the same automata theory as regular expressions, extended to describe "hedges" (XML documents).

An Algorithm for RELAX NG Validation By James Clark, January 07, 2001. Author's note to XML-DEV: 'I have written a paper describing one possible algorithm for implementing RELAX NG validation. This is the algorithm used by Jing, which I believe has also been adopted by MSV... If you try to use this to implement RELAX NG and something isn't clear, let me know and I'll try to improve the description.' From the introduction: "This document describes an algorithm for validating an XML document against a RELAX NG schema. This algorithm is based on the idea of what's called a derivative (sometimes called a residual). It is not the only possible algorithm for RELAX NG validation. This document does not describe any algorithms for transforming a RELAX NG schema into simplified form, nor for determining whether a RELAX NG schema is correct. We use Haskell to describe the algorithm. Do not worry if you don't know Haskell; we use only a tiny subset which should be easily understandable." Jing is a validator for RELAX NG implemented in Java;

Another interesting Haskell library for XML is HaXml:

Consider Haskell in lieu of DOM, SAX, or XSLT for processing XML data. The library HaXml creates representations of XML documents as native recursive data structures in the functional language Haskell. HaXml brings with it a set of powerful higher order functions for operating on these "datafied" XML documents. Many of the HaXml techniques are far more elegant, compact, and powerful than the ones found in familiar techniques like DOM, SAX, or XSLT. Code samples demonstrate the techniques.

Here's some more stuff about Relax NG, comparing the Haskell implementation to the Java implementation (jing): Maximizing Composability and Relax NG Trivia:

Here's some interesting stuff about the design and development of Relax NG:

James Clark wrote about maximizing composability:

First, a little digression. In general, I have made it a design principle in TREX to maximize "composability". It's a little bit hard to describe. The idea is that a language provides a number of different kinds of atomic thing, and a number different ways to compose new things out of other things. Maximizing composability means minimizing restrictions on which ways to compose things can be applied to which kinds of thing. Maximizing composability tends to improve the ratio between functionality on the one hand and simplicity/ease of use/ease of learning on the other.

Clark describes the derivative algorithm's lazy approach to automaton construction:

I don't agree that <interleave> makes automation-based implementations impossible; it just means you have to construct automatons lazily. (In fact, you can view the

l = 3:5:7:9:[]
 
addList::(Num a)=>[a]->a
addList [] = 0
addList n:r = n + addList r
 
m = addList l

pop::Stack a -> Stack a
pop Push(r,_) = r
 
top::Stack a -> a
top Push(_,n) = n
 
isEmpty::Stack a->bool
isEmpty EmptyStack = True
isEmpty Push(_._) = False

Haskell is neither a scripting language nor dynamic. It is compiled (first to C and then to machine code)

A language is not "compiled (first to C and then to machine code)". A given Haskell compiler might do that, but certainly not all of them do. And there are Haskell interpreters, as well (eg, hugs).

The best resource for this sort of things is, as usual, haskell.org.

Haskell is neither a scripting language nor dynamic. It is compiled (first to C and then to machine code)

A language is not "compiled (first to C and then to machine code)". A given Haskell compiler might do that, but certainly not all of them do. And there are Haskell interpreters, as well (eg, hugs).

The best resource for this sort of things is, as usual, haskell.org.

The site is slashdotted at the moment, so I can't read the article.

A good example of people writing complex but bug-free software under time pressure is the annual ICFP Programming Contest. This contest runs over three days, the tasks are complex enough that you usually need to write 2000 - 3000 lines of code to tackle them, and the very first thing the judges do is to throw corner-cases at the programs in an effort to find bugs. Any incorrect result or crash and you're out of the contest instantly. After that, the winner is generally the highest-performing of the correct programs.

Each year, up to 90% of the entries are eliminated in the first round due to bugs, usually including almost all the programs written in C and C++ and Java. Ocassionally, a C++ program will get through and may do well -- even win, as in 2003 when you didn't actually submit your program but ran it yourself (so it never saw data you didn't have a chance to fix it for). But most of the prize getters year after year seem to use one of three not-yet-mainstream languages:

- Dylan
- Haskell
- OCaml

You can argue about why, and about which of these three is the best, or which of them is more usable by mortals (I pick Dylan), but all of them are very expressive languages with uncluttered code (compared to C++ or Java), completely type-safe, produce fast compiled code, and use garbage collection.

A little different from what you're used to? You've been programming for years so you'd like something that gives you a different perspective on old problems? But you don't want to go out on a limb - you'd like to use tools that are well documented and well supported with a large user base. The answer is simple: Haskell. Everything else is just the same old same old.

Cool sig.

If you learn Haskell first then when you eventually learn C, or Python, or whatever, you'll think they're trivial Mickey Mouse languages and master them quickly. If you start with something like C you'll have a ton of conceptual barriers that will make it hard to move to Haskell.

You clearly have the luxury of not having to learn a language just because you need it to interoperate with your colleagues. So learn a language that's fun, intellectually stimulating, designed (as opposed to accreted like most languages), beautiful and functional (in at least two sense of the word).

Things to Avoid: The Haskell Wiki

Perhaps mind-share rather than market share should be the consideration here. Joy is a research language, exploring new ways (paradigms?) of programming, in the same space as languages such as Haskell (functional) or Factor (concatenative).

However, it's quite unforgiving. If you make small compilation mistakes, the error messages you get with the current compilers/interpreters can be hard to decypher. And small mistakes are very common because if the nature of the type system used. Similarly, there are some runtime bugs that can be quite insidios to track down due to the functional nature of the language.

Recently, the team that develops the most popular Haskell compiler completed a survey that has lots of interesting info about strengths and shortcomings.

You've clearly gotten a lot of feedback so I hope you'll get to this reply at some point!

Functional programming languages have been mentioned. There biggest advantage is that they offer an elegant approach to programming, that can have a lot of aesthetic and intellectual appeal to students. But the most exciting example of such languages, Haskell (http://www.haskell.org/), does not seem to have been mentioned. The website has a lot of useful information about the language, and I know that some people at Yale have been using it for high school instruction, with promising results.

Walid.

Functional programming greatly simplifies the task of the programmer by removing execution order from the things that programmers have to keep track of. Just as garbage collection in Java got rid of the need to recycle memory manually, so in Haskell the execution order is a matter for the compiler to optimise rather than for the programmer to worry about.

Historically functional programming has had problems doing IO: languages have had to admit impure side effects to do IO. Haskell has a wonderful solution to this problem, which unfortunately this post is too small to contain (really: go see!).

Paul.

when you don't have the abstraction offered by lazy lists/streams.

SERIES 2000 has been a free download for a long time now. Series was in CLTL2, f.f.s.

Haskell syntax is very minimal

Come off of it. It just plain isn't. Let's look at the spec, shall we? "Dear lord", he said with remembered horror, "Layout? Haskell syntax is FREAKING 2-DIMENSIONAL".

Now, maybe it's a good fit for your brain, it takes all sorts.

I don't want to extend Lisp, I want to write a program!

Writing idiomatic programs in lisp IS extending lisp. If you're not, you're doing it, well, not wrong as such, but rather suboptimally.

Can you possibly think of a more HLL than Java?

Um, how about Haskell?

What is the lowest cost handheld device on which I could do Haskell development? Presumably the most sensible thing would be to try a Linux device as Haskell might be tricky to build for any other handheld OS. Would this device be a good option?

I keep seeing this assertion, but never any evidence. A functional programming is no more or less descriptive than C++.

Check out e.g. "Four-fold Increase in Productivity and Quality" (pdf link). Erlang is freely available. Regarding C++ vs. functional programming being 'less descriptive' there's Haskell vs. Ada vs. C++ vs. Awk vs. ..., An Experiment in Software Prototyping Productivity(PS link). Now that doesn't directly address your question about what the compiler can do, there's about a metric ton of stuff about the higher level optimisations you can do with a declarative language compared to a messy one such as C++; riddled with aliasing problems etc. I haven't got any links handy, but some googling should turn them up (you could start by checking out Urban Boquist's, now quite old, PhD thesis). Plese note though that the Erlang references demonstrate that even while they may be slower on micro benchmarks, they always win in the end. Much like C beat out assembler in the eighties.

Your argument basically boils down to "the languages under discussion are all turing complete". While that's true, that's not really what we're saying. We're saying that given a declarative language the potential (and nowadays practice) for optimisation is much improved compared to e.g. Fortran or C.