...

...

...

...

"Don" == Don Stewart writes:

>> Let me explain. >> >> "Haskell is an advanced purely functional programming language." >> >> Good start, if only the "advanced" were replaced with something >> more characteristic, like "lazy", or "statically typed". Which, >> BTW, both do not Don> "lazy" and "statically typed" don't mean much to other Don> people. They are buzz words that mean nothing to many people. And "purely functional programming language"? If they mean anything to many people, it's that the language works (i.e. functions). What language wouldn't work? I think Ben has a strong point here. -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On 16 October 2010 09:02, Stephen Tetley wrote:

On the main topic - I think the blurb is fine. If Python and Ruby want to do proselytization and value judgements please leave them to it.

PS - Were it me, I would drop the third sentence of the Haskell.org blurb, to me it is a value judgement - "easier" than what?

On Sat, Oct 16, 2010 at 3:02 AM, Stephen Tetley wrote:

If a "functional language" doesn't mean anything significant then Haskell probably isn't the language you should be choosing.

People who don't know what 'functional language' means can still get all the benefits of functional programming if they choose to learn Haskell (and thereby learn what a functional language is). The blurb on the homepage can not be all things to all men. If the goal of the blurb is to get more people using Haskell then it needs to be targeted towards the largest group of people who have a need which can be fulfilled by Haskell, who are willing and able to use Haskell if it can solve their problem, and who do not already know how Haskell can help them. Now, I am guessing that the group of people who: 1. know what a lazy, statically type, functional program languages is 2. do not already know about Haskell is pretty small. So, targeting them seems rather futile. There is also a large group of people who ought to be able to benefit from Haskell, but for whatever reason, can't or won't use it. Clearly they are not of interest either. So, we are left with the (rather large?) group of people who do not know what Haskell is and probably do not really know what 'statically typed' or 'purely functional' really mean. In fact, I think that most non-haskell/ocaml/etc programmers view 'statically typed' as meaning 'C/C++ / java' style type systems -- and that is often considered a negative thing. You don't really know what it means to use Haskell's static type system unless you have used one of the other languages with a sane type system. And then, you are probably already in the group who knows what Haskell is... How can we present Haskell to these people in a way that they will think it *might* provide a solution worth investigating to a problem that is bothering them. The blurb is not going to completely enlighten people. It just needs to convince them that Haskell is something worth investigating, and get them to click the link that will get them investigating the part that is potentially useful to them. For some people the problem that pains them is the need to learn "cool", "advanced" stuff that will make them feel "smarter" than their peers. For these people, seeing unfamiliar terms like, "monads", "lazy", "purely functional", etc. will be exciting -- because it promises them the opportunity to learn something new, and potentially interesting, that other people do not know. So, for those people, those words are great! (I am one of those people -- perhaps many current Haskeller's are?) Other people may care about specific benefits of using Haskell which can be applied to their particular needs. Someone frustrated with parallel on concurrent programming might be really interested to find out that Haskell provides solutions in those domains that are (hopefully) better than what they have been dealing with. But, the claim that Haskell is better than what they already know needs to be back up with something that will make them want to dig deeper. If we simply say, "We do parallelism and concurrency better", people will respond, "yeah whatever, I've heard that before." If we say, "Haskell offers new and better ways of dealing with parallelism and concurrency that are only possible because Haskell is purely functional and has an advanced type system." -- then people might at least have the question, "What does purely functional mean? How could that result in better ways of writing parallel and concurrent code?" And, from there, they would hopefully be able to click on links which would address those questions in more detail, and convince them to invest the time to learn Haskell. I think value judgments are incredibly valuable. People are not going to be interested in learning more about Haskell unless they believe it is more valuable than what they are already using. I believe that is the #1 question in people's mind when they visit the site is, "Is this language in anyway more valuable to me than what I am already using." And they want to spend as little time as possible making that initial judgment. Once they have decided that it could be more valuable, then they will be willing to invest more time to determine if it really is or not. I think the key is that we need to provide a reason for each value judgment. In the blurb, the 'reason' does not need to be a proof, nor does the reader need to be able to fully comprehend it. They initially just want to see that we have some basis for making the claim. And, having a link that can more fully explain the value judgment will add further trust. - jeremy

Don Stewart wrote:

ben.franksen: > "Haskell is an advanced purely functional programming language." > > Good start, if only the "advanced" were replaced with something more > characteristic, like "lazy", or "statically typed". Which, BTW, both > do not

"lazy" and "statically typed" don't mean much to other people. They are buzz words that mean nothing to many people.

I imagine a list of 'bullet points' following the blurb, listing the main features with a small explanation and a link to further details.

> appear in the whole blurb, even though they are *the* > characteristics of Haskell, lazyness being even something that sets > it apart from most other languages. I hear the marketeers crying > "but the average visitor has no idea what lazyness means". So what? > Give them a link to the wiki with an explanation. So, a better > introductory sentence would be > > -> "Haskell is a lazily evaluated, purely functional programming > language with a very flexible and powerful static type system."

What are the benefits of laziness?

It is difficult to explain lazy evaluation and why it helps to make programs more concise in one sentence. But it still is *the* most distinguishing feature. And let us be honest: it has benefits and it also has disadvantages. The most prominent disadvantage being that it makes reasoning about runtime behaviour, i.e. performance, much more difficult.

> Next sentence: > > "An open source product of more than twenty years of cutting edge > research, it allows rapid development of robust, concise, correct > software."

It is open source, and was born open source. It is the product of research.

How can a language be open source, or rather, how can it *not* be open source? The point of a (programming) language is that it has a published ('open') definition. Nothing prevents anyone from creating a proprietary compiler or interpreter for Haskell, AFAIK. I do not dispute that Haskell is a reasult of research and I agree that this should be stated. It is still not a 'product'. Have you ever heard someone characterising TCP/IP as a 'product'? Or HTML? Or even C? The term 'product', as it is used in the blurb, implies or at least suggests some specific implementation, not a written and published standard.

> This really gets me every time I read it. How can anyone write such > a nonsense? Haskell is not an "open source product"! It is no > product at all. That most (maybe all) implementations are opens > source is certainly an interesting fact, but IMO not something that > should appear at the top of the page right under the header "The > Haskell Programming Language". The second and third sentences > deliberately conflate language and implementation(s). This is a well > known falacy and I am ashamed that it

As Python, Ruby, C and every other language do.

Exactly my point. They all have only one relevant implementation. And in practice this implementation has a great tendency to be taken as the *definition* of the language, at least w.r.t. its semantics. Do I really have to explain why this is bad and why specification of a language should be clearly separate from its implementation? (Hint: how can you ever hope to prove something about a piece of code if all the semantics you have is "whatever the implementation does"?) I *love* it that there *do* exist other implementations for Haskell, and I dearly hope UHC, JHC etc will soon get to the point where they can be used and recommended for practical programming.

> That cutting edge research is done for Haskell as well as for its > implementations is of course good to know, but just stating it is > not nearly enough: such a statement must be corroberated with > evidence, otherwise it is just idle marketing. (Not that there > wouldn't be evidence amass, it's just that none is given.)

You literally want evidence that research played a part in Haskell, in its opening statement? Why??

I reject this objection. I let myself get carried away here. Still I think that further down some links can be given to papers about Haskell and its implementation.

> On we go: > > "With strong support for integration with other languages, built-in > concurrency and parallelism, debuggers, profilers, rich libraries > and an active community, Haskell makes it easier to produce > flexible, maintainable high-quality software." > > Let us take that apart: > > (1) Fact: Haskell has a good and very easy to use FFI. To the C > language. I have never heard of integration with any other langauge > being directly supported.

It is OK to contest these, but consider the FFI of our competition: Python, Ruby, Erlang. Woeful FFIs. You are not at risk using Haskell, as you can always call out to your favorite $language library.

You misunderstand: I *love* Haskells FFI. It is the best I have ever seen in any langauage. It is far superior to the competition. And I agree that this is a strong selling point for Haskell. BUT: it is still (currently) to C only. We cannot offer something like the tight integration of e.g. C# and F# in .NET or similar language independent runtimes.

> (2) Fact: Built-in concurrency and parallelism is not exactly part > of the langauage, although purity makes it possible to support them > in a more precise and less error-prone way; which is exploited by > ghc's concurrency and parallelism extensions.

Haskell since 1990 has been a bed for trying out new parallelism and concurrency ideas. Current implementations, particularly GHC and GPH/GDH support forms of parallelism the combination of which is available nowhere else.

I agree completely. Why not say so?

> (3) Fact: Traditional debuggers are practically useless in Haskell, > due to lazy evaluation. But, oh, we forgot to mention the small fact > that Haskell is lazy. Too bad. Profiling is supported by ghc only > (AFAIK), but is supposed to be very useful (never seriously used it, > so I can't judge.)

GHC has a built-in debugger. You should not be scared of Haskell's support for finding bugs.

First, Haskell's strong point is *avoiding* bugs. A very large portion of the research on Haskell is about leveraging the type system to get more static guarantees. One of the main selling points of Haskell, to me at least but I have heard others saying similar things, is that you spend a lot less time in debugging. It is the famous "once it compiles it typically just works" (which is of course quite a crude approximation of reality). Second, how many people are actually using the ghci debugger to find bugs in their code? Is it just me being slow to adopt this feature?

> (4) Fact: there are libraries. Some of them are good, others are not > so good. Most leave a lot to be desired, but I would be hard pressed > to come up with something better myself. What really distinguishes > Haskell libraries from what is found in other languages is the level > of abstraction. I know no other language where stuff like Monad, > (Applicative) Functor, Monoid, Category etc. is *at the heart* of > all the libraries. But, oh, I forgot, we don't want to scare people > off, so better not talk about this in public. > > (5) Fact: Haskell has an active community. No question. > > (6) Fact: Haskell makes certain things easier (than other > languages). Other things that are easy in other langauges are hard > in Haskell. Or at least very non-obvious. Whether Haskell programs > are more flexible, when compared with dynamically typed OO languages > like Python, I seriously doubt. Maintainable high-quality software > is the real selling point, IMO; or rather *reliably correct* > software. However, I cannot see how this dirtectly follows from the > previous points, which is what the sentence is saying. What has an > FFI do to with high quality? What has the supposed availability of > debuggers (where? which?) to do with it?

These are precisely the reason that e.g. Galois uses Haskell. Maintainable, concise, correct software.

I am not disputing this.

> Enough. I think I have made my point.

What's your point?

My point is that Haskell should be represented honestly and in a language that reflects its main characteristics: Elegance, precision, abstraction. Learning Haskell is hard. The benefits, once you get over the initial hurdle, are enormous, but to get there can mean lots of frustration. Learing to master it is a life long task (or it seems to me, at least). And that is a *good* thing: there is always more to disvover. It is one of the reasons I am still mostly interested in Haskell and haven't moved on to something else.

What alternative do you suggest?

I am not yet ready to present an alternative proposal but I am working on it. Cheers Ben

On 10/16/10 10:48 AM, Ben Franksen wrote:

Don Stewart wrote:

...

It is open source, and was born open source. It is the product of research.

How can a language be open source, or rather, how can it *not* be open source? The point of a (programming) language is that it has a published ('open') definition. Nothing prevents anyone from creating a proprietary compiler or interpreter for Haskell, AFAIK.

Miranda[TM] is/was a proprietary language, quite definitively so. If nothing else, this should be apparent by the fact that every reference to it in research papers of the era (a) included the TM sigil, and (b) had footnotes indicating who the IP holders are. That was before my time, but I was under the impression that Haskell was open from the beginning ---by express intention--- in order to enable work on lazy functional languages without being encumbered by Miranda[TM]'s closed nature. For that matter, until rather recently Java was very much a closed language defined by the runtime system provided by Sun Microsystems and not defined by the sequence of characters accepted by that system, nor by the behavior of the system when it accepts them. Sun even went through some trouble to try to shut out competitive development of runtime systems such as SoyLatte, IcedTea, and the like. Even the venerable C language has a long history of companies making proprietary extensions to the language in order to require you to buy their compiler, and they would most certainly pursue legal action if someone else copied the features. This is why GCC is as big a coup for the free/open-source movement as Linux is--- long before GCC changed its name and focus to being a compiler collection. The languages which are open-source are in close correspondence with the languages which have a free/open-source implementation. There are a lot of them, including the vast majority of recent languages. But don't be seduced into thinking that a language is a predicate on acceptable strings, a transducer from those strings into computer behaviors, or that such predicates and transducers are public domain. -- Live well, ~wren

On 17/10/10 12:03, Ben Franksen wrote:

wren ng thornton wrote:

...

On 10/16/10 10:48 AM, Ben Franksen wrote:

...

Don Stewart wrote:

...

It is open source, and was born open source. It is the product of research.

How can a language be open source, or rather, how can it *not* be open source? The point of a (programming) language is that it has a published ('open') definition. Nothing prevents anyone from creating a proprietary compiler or interpreter for Haskell, AFAIK.

Miranda[TM] is/was a proprietary language, quite definitively so. If nothing else, this should be apparent by the fact that every reference to it in research papers of the era (a) included the TM sigil, and (b) had footnotes indicating who the IP holders are. That was before my time, but I was under the impression that Haskell was open from the beginning ---by express intention--- in order to enable work on lazy functional languages without being encumbered by Miranda[TM]'s closed nature.

For that matter, until rather recently Java was very much a closed language defined by the runtime system provided by Sun Microsystems and not defined by the sequence of characters accepted by that system, nor by the behavior of the system when it accepts them. Sun even went through some trouble to try to shut out competitive development of runtime systems such as SoyLatte, IcedTea, and the like.

Even the venerable C language has a long history of companies making proprietary extensions to the language in order to require you to buy their compiler, and they would most certainly pursue legal action if someone else copied the features. This is why GCC is as big a coup for the free/open-source movement as Linux is--- long before GCC changed its name and focus to being a compiler collection.

The languages which are open-source are in close correspondence with the languages which have a free/open-source implementation. There are a lot of them, including the vast majority of recent languages. But don't be seduced into thinking that a language is a predicate on acceptable strings, a transducer from those strings into computer behaviors, or that such predicates and transducers are public domain.

Sigh. Yes, you are right, of course. All this is true, sadly. There are stupid people who think that they can own a programming language. I hope they will go the way all the other mis-adapted creatures have gone and just die out.

Still, "Haskell is an open source product" doesn't sound right to me. Even "Haskell is open source" (without the "product") has a bad ring because "source" is short for "source code" and source code is not something a programming language has.

I agree that "non-proprietary" is a valid and important characterization of the language. This should be mentioned where we speak about libraries and community, since the active and friendly community is the motor behind the growing set of libraries, and you get this sort of participation only with a free/non-proprietary language. This applies not only to individuals but to companies as well, maybe even more.

I anticipate the objection that potential commercial users might be scared off by the terms "non-proprietary" or "free", whereas the term "open source" has been coined to (and probably actually does) sound more commerce friendly. To countermand such an effect, we can point out that most libraries have non-copyleft licenses and that there are a number of companies who have done and still do a lot to support and advance Haskell.

Cheers Ben

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I am somewhat sympathetic to your argument, but I care far less overall. Nevertheless, perhaps this would appease: "Haskell is an open standard with a robust open source implementation." -- Tony Morris http://tmorris.net/

Don Stewart writes:

...

Good start, if only the "advanced" were replaced with something more characteristic, like "lazy", or "statically typed". Which, BTW, both do not

"lazy" and "statically typed" don't mean much to other people. They are buzz words that mean nothing to many people.

But they /are/ defining characteristics of the language, still. I think they should be mentioned, ideally as links to separate pages (or pop-ups or a "live" sidebar?) that explain what they mean, and why you'd want them. -k -- If I haven't seen further, it is by standing in the footprints of giants

Ketil Malde writes:

Don Stewart writes:

...

...

Good start, if only the "advanced" were replaced with something more characteristic, like "lazy", or "statically typed". Which, BTW, both do not

...

"lazy" and "statically typed" don't mean much to other people. They are buzz words that mean nothing to many people.

But they /are/ defining characteristics of the language, still. I think they should be mentioned, ideally as links to separate pages (or pop-ups or a "live" sidebar?) that explain what they mean, and why you'd want them.

-k

I agree that it is important to highlight the features that are characteristic of the language. However, I would add that "statically typed" is a turn-off for some people, so I think it is important to add "with type inference".

Vo Minh Thu schrieb:

Every once in a while, a discussion about the top-level text on Haskell.org pops in this list. Without paying much attention to this thread, and without digging the older threads, it occurs to me that different people have very different opinion on this subject. I think this is not a problem at all, because of the following thought:

When someone is interested enough in a programming language to land on its homepage (i.e. haskell.org here), that someone has enough resources at her disposal to make a somewhat informed choice, and those resources can't be only a top-level text on the homepage.

When thinking about "What would I like to see when judging a programming language?", I found that I most like a gallery of small example programs.

Heinrich Apfelmus wrote:

Henning Thielemann wrote:

...

Vo Minh Thu schrieb:

...

Every once in a while, a discussion about the top-level text on Haskell.org pops in this list. Without paying much attention to this thread, and without digging the older threads, it occurs to me that different people have very different opinion on this subject. I think this is not a problem at all, because of the following thought:

When someone is interested enough in a programming language to land on its homepage (i.e. haskell.org here), that someone has enough resources at her disposal to make a somewhat informed choice, and those resources can't be only a top-level text on the homepage.

When thinking about "What would I like to see when judging a programming language?", I found that I most like a gallery of small example programs.

I started such a gallery in the style of a restaurant menu some years ago, but never got around to finishing it:

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

Very nice. Definitely worth linking to from the main page, even incomplete. Cheers Ben

Christopher Done wrote:

On 16 October 2010 05:52, Ben Franksen wrote:

...

what marketing idiot has written this inclonclusive mumble-jumble of buzz-words? [...] How can anyone write such a nonsense? Haskell is not an "open source product"! [...] I am ashamed that it appears on the front page of my favourite programming language. [...] But no, I forgot, we don't want to explain anything or even be logical, dear reader, we want to pound slogans into your head!

Stand back everyone, Bill Hicks is back and he's got an axe to grind, and it looks rusty!

I am sorry about the wording of these sentences, especially teh first one. I let myself get carried away. I stand by the critique, though. The blurb mixes up too many things that should be clearly separated.

On 16 October 2010 07:49, Donn Cave wrote:

...

" Haskell is a computer programming language. In particular, it is a polymorphically statically typed, lazy, purely functional language, quite different from most other programming languages. The language is named for Haskell Brooks Curry, whose work in mathematical logic serves as a foundation for functional languages. Haskell is based on the lambda calculus, hence the lambda we use as a logo."

This most succinctly expresses the points I tried to convey to him about Haskell, and I don't think it would be out of place on the main page.

This description is similar to Wikipedia's description of the Joy language, with samples from the blurb above spliced in:

"The Joy programming language is a purely functional programming language[, quite different from other programming languages.] It was produced by Manfred von Thun of La Trobe University in Melbourne, Australia. Joy is based on composition of functions rather than lambda calculus[, hence the composition operator we use as a logo.]"

These descriptions are fine, but they don't note how Haskell really is any different from other languages, like Joy.

It states very clearly how Haskell is very different from Java, C, C++, Perl, Python, Ruby, etc. Distinguishing it from exotic languages like Joy is important but can be done in a later paragraph.

It doesn't include the fact that Haskell is a very serious language: it has a comprehensive and stable implementation, growing community, growing and already large library set, is being used seriously in industry, is the focus of cutting edge parallelism and concurrency research, has many yearly conferences, hackathons, etc. The original blurb does mention these things.

All these things should be mentioned, but not before we say what Haskell actually *is*.

On 16 October 2010 09:09, Colin Paul Adams wrote:

...

And "purely functional programming language"?

If they mean anything to many people, it's that the language works (i.e. functions). What language wouldn't work?

I think Ben has a strong point here.

To solve this ambiguity that phrase is a link that people can click to find out what it means. "Object oriented", "dynamically typed", "stack-based" are about as meaningful.

The difference may be that everyone thinks he knows what 'object oriented' means. But 'lazyness', 'polymorphic type system', what the heck is that? I just think there is nothing we can do about that. These concepts are not as well known as others. We can link to an explanation and we should, but let's face it, if someone come to Haskell and expects to see only stuff he already knows about he will be disappointed, no matter how well we hide these things on the front page. Cheers Ben

Donn Cave wrote:

Quoth Ben Franksen ,

...

Enough. I think I have made my point.

Yes, though possibly a little overstated it. While it's easy to share your distaste for the blurb, if you take a generous attitude towards it, most of it is "true enough."

Sorry. I was not in a generous mood, when I wrote this yesterday night. I am more so now, and I agree that I have overstated soem points. It was not my intention to attack the people who wrote the blurb, though it may have sounded like I did. Again, sorry for that. I agree with the "most of it is true enough". Certainly, but that is not my problem with it. My problem with it is how it is expressed and that it misses out on important characteristics.

The implementation specific features are at least widely available to anyone who wants to use the language on the most popular computing platforms, so it's expedient, if a little cheesy, to say that Haskell supports those features.

I hate this sort of expediency. And it doesn't become the front page of a language that excells in being principled. Haskell did *not* give in to expedience when it came to IO and side effects. And what would we have now it it had done so? Something far inferior and less interesting, I am sure. That said, I have no problem with mentioning the excellent properties of existing implementations, even in the first (or maybe second) paragraph. But I want the text to be explicit and honest about this.

We agree about "strong support for integration with other languages", but I wouldn't like to say "strong support for integration with C", either. The FFI is mostly independent of C, per se - outside of the hsc macros, it just addresses a sort of platform standard for exposed library functionality, which happens to be commonly implemented in C. Someone might be able to think of a better way to put that.

Yes, this is difficult to state w/o going into details. Maybe talk about 'binding to system libraries' or something like that.

The point I liked best is the one you started with:

...

This blurb should, IMO, give a concise description of what Haskell, the programming language, is, what makes it different from other languages, and why I should be interested in it.

... and, we understand, you don't find that in this blurb. "Lazy" and "statically typed" may not be universally understood, but they aren't buzz words. Whether that's the right way to shed some light on what Haskell is like, it sure says a lot more on a technical level than "advanced purely functional programming language." And while that phrase is linked to a longer exposition of "Functional programming", the latter is set in language-independent terms and is at best ambiguous about whether it's talking about Haskell or not.

Yes, we have to be careful what we directly link to from the front page, and especially from the blurb. These documents are almost as important as the blurb itself. They should concisely explain the main features for someone unfamiliar with them, maybe contain some small examples. They definitely should be about Haskell, not something more general, and also not something more specific, like ghc, except if explicitly stated.

I'm trying to picture someone who might find Haskell useful, but would be spooked by description of the language in unfamiliar technical terms. Forget Python, this is a little different proposition. A couple days ago I was talking to a friend about Haskell, turned out he hadn't heard of it. I suppose he may have found this blurb. I hope he found the blurb that appears at the top of the Introduction page:

" Haskell is a computer programming language. In particular, it is a polymorphically statically typed, lazy, purely functional language, quite different from most other programming languages. The language is named for Haskell Brooks Curry, whose work in mathematical logic serves as a foundation for functional languages. Haskell is based on the lambda calculus, hence the lambda we use as a logo."

This most succinctly expresses the points I tried to convey to him about Haskell, and I don't think it would be out of place on the main page.

Much better. Though I *do* think mentioning the main implementations and their qualities is a good thing to o, right after this: "Haskell can be interpreted or compiled. It has high quality, mature implementations [link to a list of implementations], including optimizing compilers, interactive interpreters, profilers and tools for debugging, and a large and rapidly growing body of libraries [link to hackage]. The most important Haskell implementation, ghc [like to ghc page], has served as a test bed for practical application of cutting egde research into the language as well as its compilation to efficiently executable code." The text should go on and mention concurrency, parallelism, ffi, and whatnot. Cheers Ben

wren ng thornton wrote:

On 10/16/10 11:22 AM, Ben Franksen wrote:

...

Much better. Though I *do* think mentioning the main implementations and their qualities is a good thing to o, right after this:

"[...]The most important Haskell implementation, ghc [like to ghc page], has served as a test bed for practical application of cutting egde research into the language as well as its compilation to efficiently executable code."

Objection to calling GHC the most "important". The most mature, most fully featured, most common, or even the standard implementation,, sure. But saying GHC is more important than the rest implies that (among others) the work on JHC and UHC is "unimportant". To the contrary, I think JHC and UHC are, perhaps, more important than GHC precisely because they are treading new waters that the standard implementation cannot afford to explore.

Right on all accounts. Can one say "most mature and full-featured" ? Cheers Ben

On Sun, Oct 17, 2010 at 1:32 PM, Stefan Monnier wrote:

AFAIK laziness is a property of the major implementations of Haskell, but not really of the language itself.  All I see in the Haskell report points at it being "applicative", "call by name", but nowhere does the report seem to mandate a lazy strategy.  It's just that being purely functional implies that the compiler is free to use laziness.

Yes. The rumor I heard is that Haskell is non-strict: http://www.haskell.org/haskellwiki/Lazy_vs._non-strict - jeremy