Andrew Butterfield writes:

...

I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language)

No - Clean is pure and lazy like Haskell,

But it uses explicit strictness annotations a lot, and provides strict and/or unboxed versions of various fundamental types (e.g. tuples), with some implicit coercions. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

Peter Achten writes:

...

But it uses explicit strictness annotations a lot, and provides strict and/or unboxed versions of various fundamental types (e.g. tuples), with some implicit coercions.

It is of course not the language that uses strictness annotations.

But the language encourages to use them much more often than in Haskell. They can be declared in types, there is a short syntax for "strict let", and various builtin types have strict variants. These are properties of the language. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

On 08/10/2004, at 2:57 PM, karczma wrote:

...

But the language encourages to use them much more often than in Haskell. They can be declared in types, there is a short syntax for "strict let", and various builtin types have strict variants. These are properties of the language.

Marcin, are you playing 'kogut', or you want to prove something, and if yes, than what?

I believe that Marcin wishes to prove the same point that I want to: namely, Clean encourages use of strictness by making it easier to use (via language annotations). At the risk of sounding ignorant and arrogant, I think the Haskell community in general does not understand the importance of syntactic sugar to make such tasks easier. -- % Andre Pang : trust.in.love.to.save

Fergus Henderson comments the comment of Andre Pang concerning my nasty comment addressed to Marcin Kowalczyk.

On 08-Oct-2004, Andre Pang wrote:

...

I believe that Marcin wishes to prove the same point that I want to: namely, Clean encourages use of strictness by making it easier to use (via language annotations). At the risk of sounding ignorant and arrogant, I think the Haskell community in general does not understand the importance of syntactic sugar to make such tasks easier.

I think the Haskell community understands well the importance of syntactic sugar; witness the use of syntactic sugar for monads, the `infix` operator syntax, the layout rules, etc.

I think the Haskell community has just been a bit slower in understanding the importance of strictness :) But that seems to be gradually changing.

What are you, both, or all three of you suggesting? That the world of programming is evolving, people invent new, wonderful programming tools, nice and easy, and Haskell remains stagnant, old, conservative, user-unfriendly, whatever? This is nonsense. NOW, I will tell you what is *really* changing! Haskell which began as an academic language, implementing a certain number of paradigms, laziness in particular, and a specific vision of controlled polymorphism, whose ambition was to show the power of computing with abstractions, finally reaches the layers of computing irremediably polluted by the 'mainstream' atmosphere. You want to convert Haskell into a "super-C" language?? OK, I admit that I will never understand these complaints about the inefficiency of non-strict computations, since what I *require* in most of my work is laziness. Had I needed strictness for the sake of efficiency, I would use a different language instead of throwing dirt at Haskell. Why don't you the same? This mythical Haskell community which "slowly begins to understand the role of strictness" is simply an *enlarged* community, with people who want to adapt Haskell to their own, old, conservative, "standard" needs. Those people don't care about the progress in the implementation of types, and about thingies which go beyond the theory of types, such as mathematical attributes with their hierarchies and subsumptions. Actually, they don't care at all about the cost of modifying an existent, well defined language. I think that it would be good to invent some new practical functional languages, which would answer their demands. Any takers? ? Yes, I thought so. On the positive side of such discussions I see the following. * Despite the dirt thrown at Clean because of their distribution policy, you see the importance of another, sibling language, which may be used as a comparison gauge. Concerning strickness: Clean has not only those ubiquitous !annotations, but has a powerful strickness analyzer, which alleviates their use. I have the impression that Haskell strickness analyzer is less aggressive, and I would like to know why, or - perhaps - to hear that this is not true. Clean compiler produces *automatically and globally* human-readable type headers for all the definitions (at least in the main module). I would like to see such a compilation option in Haskell as well; it should be fairly easy and cheap, since all this information is anyhow available. Hm., can hi -ddumping and --show-iface etc. be useful here? I never tested that... * The user-friendliness seem - because of this enlarged community - gaining in importance. We have witnessed the birth of the 'do' syntax, continued by the 'proc' stuff of Ross Paterson, but there is a mileage to go. GHC rewrite rules are still quite weak. * I began to respect more and more all the really new and fascinating ideas in computing paradigms, as far from the superficial quarrels here, as possible. Genericity/polytyping, arrows, co-monads (which don't seem dead yet, although not too many people speak about them). THIS IS HASKELL. If you want Cobol disguised in Haskell, use simply Cobol. Jerzy Karczmarczuk

n Mon, Oct 11, 2004 at 12:22:13PM +0100, Malcolm Wallace wrote:

"karczma" writes:

...

...

I think the Haskell community has just been a bit slower in understanding the importance of strictness :)

OK, I admit that I will never understand these complaints about the inefficiency of non-strict computations, since what I *require* in most of my work is laziness.

Indeed, I have to agree. I have spent some time fiddling with programs for the Language Shootout which started this conversation, and by far most of the effort was spent in deliberately making code /slower/ by introducing strictness.

For instance, the shootout often requires that a task be carried out N times, to make the timings large enough to measure. In all the naive Haskell implementations of these tasks, Haskell wins by a mile. Why? Because the language quite reasonably says that if you multiply a matrix by itself N times, but only use the result of the last multiplication, well it is jolly well not going to bother computing the first (N-1) identical multiplications - what a waste of time!

So is it fair to compare the default lazy Haskell solution with all the eager solutions out there that laboriously do all this unnecessary work? Apparently not, so we have gone to all kinds of trouble to slow the Haskell solution down, make it over-strict, do the work N times, and thereby have a "fair" performance test. Huh.

I think the naive way is perfectly fair. If haskell has to live with the disadvantages of lazy evaluation, it only makes sense we should be able to take advantage of the advantages. The fact that haskell doesn't have to compute those intermediate values is a real advantage which should be reflected in the results IMHO. John -- John Meacham - ⑆repetae.net⑆john⑈

Malcolm Wallace wrote:

For instance, the shootout often requires that a task be carried out N times, to make the timings large enough to measure. In all the naive Haskell implementations of these tasks, Haskell wins by a mile. Why? Because the language quite reasonably says that if you multiply a matrix by itself N times, but only use the result of the last multiplication, well it is jolly well not going to bother computing the first (N-1) identical multiplications - what a waste of time!

So is it fair to compare the default lazy Haskell solution with all the eager solutions out there that laboriously do all this unnecessary work? Apparently not, so we have gone to all kinds of trouble to slow the Haskell solution down, make it over-strict, do the work N times, and thereby have a "fair" performance test. Huh.

Well, the shootout appears to have two types of tests. Each individual test is labeled as either being implemented in the "Same Way" or doing the "Same Thing". I agree that the "Same Way" test are usually too synthetic and too geared toward measuring artifacts of imperative programming which aren't appropriate in Haskell. But there are also the "Same Thing" tests that are free to be coded in any style at all. And of the "Same Thing" tests, the largest slowdown in the GHC programs is caused by lazy I/O (I think using better I/O routines would fix "Reverse a File" and "Statistical Moments"). To get GHC to come out on top of the CRAPS Scorecard, we need to emphasize the "Same Thing" tests and downplay the "Same Way" tests as well as properly weighting lines of code vs. memory consumption and speed. Here's one way to do it... http://makeashorterlink.com/?O5BD42089 What we probably need to do is create some new tests which aren't as phony and convince the powers-that-be to drop some of the synthetic tests or convert them to "Same Thing" tests (I think the "Sum a Column of Integers" and "Spell Checker" would be good candidates to convert). Just for reference, here's a list of the "Same Thing" tests: Simple TCP/IP Server Matrix Multiplication Statistical Moments Process Instantiation Reverse A File Ring of Messages Count Lines/Words/Chars Word Frequency Greg Buchholz