Re: Standard Haskell

[Hans Aberg]

At 17:24 97/08/21, Wolfgang Beck wrote:
>Does Haskell really need the features that will be part of
>a Research Haskell? Or is it better to freeze Haskell development
>now and start developing systems u s i n g Haskell? Languages look
>very ugly if too overloaded with new concepts (look at C++).
>
>If Haskell still lacks important features it is no use to
>make a Standard Haskell now.

  It certainly so that Standard Haskell is going to need the features being
developed in Research Haskell, as I see it, and some of those features have
been mentioned here: Better (more general) typing system, a more secure
foundation for monads, parallel threads, standards for GUI and perhaps
multimedia, perhaps support for distributed programming, ability to combine
Haskell code with that of other languages.

  On the other hand, there seems to be no reason to require Standard
Haskell to have all that from the outset; it seems best to put that in
Standard Haskell when successful solutions have been made in Research
Haskell.

At 01:16 97/08/22, Fergus Henderson wrote:
>I think you really have to stop and think very carefully about
>what you would gain from an ISO/ANSI standard for Haskell,
>and about what you would lose.  I can see only two benefits:
>prestige, and ability to use Haskell on certain rare government contracts.
>But the latter is not an significant issue, since I don't think anyone
>is considering using Haskell for those sort of government contracts
>anyway.  There are certainly some potentially significant drawbacks.

  I saw an industrial problem that I think a language like Haskell would do
very well _if_combined_with_an_imperative_language, like C++ perhaps,
namely a complicated spec for a program simulating a RISC CPU. Such a spec
could easily be handled by Haskell, reading it from a file; then the
circuit components of the simulator might be implemented using C++. Wadler
mentioned telecom applications of Haskell combined with Erlang.

  So I think that there are several very exiting industrial uses of
Haskell. The point with an ISO/ANSI standard would be that people would
find it secure to invest time and money in writing such Haskell code. With
a language like C++, the emergence of an ISO/ANSI draft standard helped to
get improved compilers, too (most C++ compilers are buggy and incomplete).

  Hans Aberg
  * AMS member: Listing 
  * Email: Hans Aberg <[EMAIL PROTECTED]>

Re: Standard Haskell

[Frank Christoph]

> >>  Standardizing a language tends to make it obsolete, due to lack of
> >>creativity. Perhaps it is time to start discussing the successor of
> >>Haskell then.
> >
> >Please not yet! Let us finish Haskell first!
> 
>   Well, what I tried to say is that once one starts to standardize Haskell,
> then, in effect, one is finishing it; this is not really something
> negative, but has to do with the natural life cycle of computer languages.

All this talk about laying Haskell to rest is starting to put tears in
my eyes...



I remember Haskell.  If he seemed ascetic and overly functional at times,
once you got close to him you could see he was not strict at all.  Some
say he was lazy, but I say that those men did not see his purity.

Let us observe a moment of silence to mourn the passing of a good friend.
of whom no man could say wrong, one who opened our eyes and taught us many
things, and now seeks a new home in that great big heap of bits in the sky...












-- FC


P.S.: All in jest, of course... hopefully standardization would extend
Haskell's life rather than quicken (prolong?) its death as some people are
suggesting.  SML seems to have benefited from the process.

RE: how about main :: IO Int

[R.S. Nikhil]

> From: Christian Sievers[SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, August 21, 1997 6:59 PM
> To:   [EMAIL PROTECTED]
> Subject:  how about   main :: IO Int
> 
> Hello, I just wondered if it was ever considered to let the main
> function
> have the type IO Int, in order to let the haskell programm be able to
> return an exit code to the calling environment, as C's  int main(...)
> does. I think real programms sometimes want to  exit(1)  in some
> cases. 
> 
> Christian Sievers

-
Isn't this a Unix-specific convention, to treat the value returned by
main()
as the exit value of the process?

Nikhil

how about main :: IO Int

[Christian Sievers]

Hello, I just wondered if it was ever considered to let the main function
have the type IO Int, in order to let the haskell programm be able to
return an exit code to the calling environment, as C's  int main(...)
does. I think real programms sometimes want to  exit(1)  in some
cases. 

Christian Sievers

what's wrong with instance C a => D a

[Christian Sievers]

The report says explicit that instance declarations like
instance C (a,a) where ...,  or for (Int,a) or for [[a]] are not
allowed. I tried to understand this by thinking these types are too
complex, but I had to learn that a type may also be too simple,
i.e. just writinginstance D ais not allowed either.
I had to look at the grammar to believe it. At least with a context as
in the subject line, this should be useful. However, I don't suggest
(only) this should be added, I rather hope that the people arguing for
multi parameter type classes will make it (if not in Standard Haskell,
then maybe in Curry:).
I now only would like to know why this design decission was made,
are there any problems with the instance declarations I have in mind?

Christian Sievers

Re: simplicity and seriousness and efficiency

[Zooko Journeyman]

Someone wrote:

> Honestly, would you use a language which does not allow to program a
> depth-first graph traversal in O(n).


Ah.  I didn't realize it was that bad.  My understanding of 
Haskell is quite rudimentary.


And yet, now that I think about it, I have never implemented a
depth-first graph traversal except in university classes!


I admit that I am not a very experienced programmer-- I have 
worked for about three years in the industry doing 
multiplatform GUI apps in C++, Internet utilities in C, C++ and
Perl, cryptography and e-commerce in C and C++, some generic 
utility classes in C++ (doesn't _everyone_ do generic utilities
for C++?  :-) ), and intranet/internet management software in 
Perl for the banking industry.  Also I've written a couple of 
games for my own amusement (including one in Turbo Pascal and 
one in an old 16-bit BASIC), and probably sundry other small 
projects.


But I've yet to implement a graph structure of any sort (as far
as I can remember) and then try to traverse it efficiently.


For that matter I've never implemented a sorting algorithm 
except in University...  Oh wait-- yes I did but it was a waste
of time because it turned out that "n" was so small that O(n^2)
was acceptable.



Of course, graph traversal, sorting and such algorithms are 
extremely important to a lot of work, and in fact were 
necessary for some of what _I've_ done (specifically a GUI 
app which enabled the user to mark-up a bitmap image) but
in those cases I used a pre-existing library, or a library 
developed by a co-worker.



I suppose if my C++ utilities had evolved for long enough they
would have soon included some computationally intensive 
algorithms, but as it was they consisted only of reference-
counting utilities, string-manipulation utilities, unsorted 
arrays and so forth.


I hope that my contributions to this forum are helpful.  My
understanding of Haskell is woefully primitive, but since the 
discussion had turned to "making it useful for the world's 
programmers" I thought my perspective might be useful.



Regards,

Zooko

Re: Standard Haskell

[Wolfgang Beck]

Hans Aberg writes:
> 
>   I would rather think that the reason that functional languages are not
> used is the lack of an ISO/ANSI standard, plus the lack of standard ways of
> making cooperation with other, imperative languages.
> 
This is true. The Haskell community has to decide wether Haskell
should be a quickly changing research language or a stable but slowly
evolving tool for developing real world systems.

Its a common problem in our business: users want stable and upward
compatible systems, designers want to integrate new concepts and
drop the whole thing if something better comes across ('when there
is a Haskell standard, its time to develop a new language').

Does Haskell really need the features that will be part of
a Research Haskell? Or is it better to freeze Haskell development
now and start developing systems u s i n g Haskell? Languages look
very ugly if too overloaded with new concepts (look at C++).

If Haskell still lacks important features it is no use to
make a Standard Haskell now.


Wolfgang Beck

Re: Is Standard Haskell a serious language?

[Heribert Schuetz]

Ralf Hinze writes:
> [...]
> To turn Haskell into a serious language, several
> *extensions* are absolutely necessary:
> [...]

Another area that should be standardized in order to make Standard
Haskell more serious is the interaction with other programming
languages. However, I don't know whether the Haskell implementors are
already at a stage where they feel comfortable with fixing some
particular solution in a standard.

Heribert.

simplicity and seriousness

[Zooko Journeyman]

If I may interject...


It seems that you are considering the alternatives of "simple"
versus "useful for serious work".  This is highly ironic to me,
because I first discovered Haskell a couple of months ago when
I said "I want a simple language with _fewer_ _features_ to do
my serious work in.", and someone replied to me "You can have 
a simple language which is also powerful.  See 'Haskell'.".


So I came to Haskell looking for neither cutting-edge language
advances nor for something to teach to students, but for a
_simple_ language to do normal old hacking in.


See what I mean?


Simplicity _is_, for me, one of the most important features of
a serious, workaday, professional language.


I think that to scientists and language researchers the value
of a language is largely determined by the mix of features and
capabilities, but to a software engineer those things need to
be just sufficient so that the language doesn't "get in the 
way".  After that, simplicity, consistency, maintainability, 
and so forth are most important.


In my mind, at least.


Perhaps I'm just scarred from memorizing too many stupid C++ 
quirks and their side effects.  :-)


Frankly, though I consider myself to be a pretty smart cookie,
I'll probably get around to fully comprehending all of the 
subtleties that a full-fledged "Haskell 1.5++" might contain.


I'm looking for an elegant and powerful language that I can use
_without_ first completing months of study of highly abstract
language concepts.


I know that I am opening myself up for scorn by saying that, 
but please consider as the sincere perspective of a 
professional software developer.


Anyway...  All this came out because I saw someone saying "We 
need to add all these features in order to make Haskell useful
for serious programming!".  That may well be true, depending on
what the features actually are, but it strikes me as ironic
since I came here in search of "fewer features, for serious 
programming".  :-)


Regards,

Zooko, Journeyman Hacker

Is Standard Haskell a serious language?

[Ralf Hinze]

John Hughes writes 

> (...)
> encountered all too many students with the impression that functional
> languages are OK for toy programs, but for real work you need
> C/C++/Java/whatever. They can easily get that impression, paradoxically,
> because of the success we functional programmers have had in introducing
> functional languages early in the curriculum! Students believe functional
> languages are good for toy programs because they learned them when they could
> only write toy programs. If they gradually discover that, in fact, the very
> language they have learned is also used for very serious applications then
> there's a chance of countering that impression. If instead they discover that
> they were quite right, the language they have learned is considered a toy even
> by functional language researchers, then I don't think we have much chance. So
> personally I am dead against designing a `Noddy Haskell' which is clean enough
> for teaching; let Standard Haskell be clean instead!

In essence this sounds to me like `let us design a serious language
which is simple to teach *and* which is worth learning'. I strongly
support this point of view. The goals of the Standard Haskell
committee, however, only reflect the aim of simplifying the current
Haskell design. [As Will Partain puts it `The "make it easy for
students" people are running amok (...)']. While simplicity is
certainly a desirable goal it is not nearly as important as developing
a serious language. To turn Haskell into a serious language, several
*extensions* are absolutely necessary:

o Haskell's type system must be improved: multiple parameter type classes
  are a must (*). It is currently not possible to develop a *clean* library
  of data structures (collection classes) and computational structures
  (monad transformers). A well-developed library would certainly contribute
  to Haskell's seriousity. [This point has already been made, I just
  wanted to stress its importance.]
  (*) One should even consider to adopt each of the recommended extensions
  in the Haskell workshop paper "Type classes: an exploration of the
  design space".

o Lazy state threads with mutable variables and mutable arrays are a must.
  There are a couple of algorithms and data structures for which no purely
  functional solution is known to exist. Efficiency is at a premium, so
  students will certainly classify Haskell as a toy language if the
  complexity gap cannot be bridged by means of an imperative sublanguage.
  [Furthermore it is not possible to develop an *efficient* library of data
  structures.] If the adoption of lazy state threads means that explicit
  quantification is also desirable, adopt it too!

o Perhaps primitives for concurrency should be standardized,
  but I'm not an expert here. A language which does not support GUI
  programming is probably considered toy, as well.

o Types such as Packed Strings or Packed Booleans (ie bitlist) are missing
  in the Standard Library.

Could one otherwise convince students that Haskell is not an academic
playground? I believe not.

Ralf Hinze

Re: Irrefutability

[Philip Wadler]

Stefan,

Something like your proposal for `irrefutable cases' was tried out
by Friedman and Wise a long time ago.  I hope I'm remembering that
correctly -- I have an even more vague memory that the original
idea was proposed by McCarthy.  You should follow this up by
contacting Friedman and Wise to check the original sources.

The basic idea was that

if e0 then e1 else e2

evaluates by evaluating both e1 and e2.  Only at the point where
e1 and e2 differ is e0 evaluated.  Thus

if bottom then e else e  ==  e

holds.

However, I don't think this idea is of sufficiently general utility
to be included in Haskell.  If this sort of behaviour is required,
it is possible, if laborious, for the user to define it explicitly.

-- P

Re: Standard Haskell

[Hans Aberg]

At 11:54 97/08/21, John Hughes wrote:
>>Is it not possible to make the versions upwards compatible, so that
>>  Haskell 1.4 code somehow can be run on Haskell 1.5? Does "being stable"
>>  need to mean unchangeable?
>
>Well, that's really been the aim all along, but things haven't turned out that
>way. Rather the committee has had debates about whether `many' programs will
>break, or whether there are `easy fixes'. In practice I think true upwards
>compatibility is hard to achieve, and maybe not even desirable if it leads to
>a more baroque design.

  Could this not have to do with the experimental nature of Research
Haskell? For a Standard Haskell, dealing with only well-established
features, the problems ought to be less severe.

>>  It seems me that this increased complexity is the result of that
>>people start to find the language useful. An idea to handle this might
>>be to opt for a more condensed kernel, based on logically clean
>>principles
>
>Yes, some people favour this approach. I'm strongly against it, because I've
>encountered all too many students with the impression that functional
>languages are OK for toy programs, but for real work you need
>C/C++/Java/whatever.

  What I have in my mind is more of a structured design: A criterion for a
feature inclusion in Standard Haskell would be that it is of fundamental
nature and coexists well with other fundamental features, or can be derived
from such fundamental features. The casual programmer would probably not
bother too much about what this kernel really is. (A picture that comes to
my mind is a microkernel, like Mach: A UNIX user on a Mach kernel based
computer would recognize an imporoved performance in say POSIX threads
programming, but would normally not bother about direct Mach programming.)
Not qualifying features would end up in Research Haskell, until they have
stabilized.

>>  Standardizing a language tends to make it obsolete, due to lack of
>>creativity. Perhaps it is time to start discussing the successor of
>>Haskell then.
>
>Please not yet! Let us finish Haskell first!

  Well, what I tried to say is that once one starts to standardize Haskell,
then, in effect, one is finishing it; this is not really something
negative, but has to do with the natural life cycle of computer languages.
But with a well focused approach with a Standard Haskell and a Research
Haskell, a good strategy on how those two should communicate, and a well
stalked out upgrade path for Standard Haskell, the Haskell life cycle might
be extended.

  Hans Aberg
  * AMS member: Listing 
  * Email: Hans Aberg <[EMAIL PROTECTED]>

Re: Standard Haskell

[Chris Burdorf]

Please pardon me if I come across as a smug outsider, but it seems
like a Catch-22 situation:

  1. Designers would like more people to program in Haskell.
  2. The industry prefers to use standards.
  3. Designers realize that a standard will more or less put them out
 of business.


This is why we are stuck with C++ these days, because, for
example,  the Lisp community
couldn't really settle on a standard (eg. Standard Lisp, Common Lisp,
ISO Lisp, EuLisp, Scheme, ...).AS a result, the gap between
what researchers know about programming languages and what us poor
slobs in industry use continues to widen.   Java may take over, but
not because it's a wonderfully elegant language.

(These are my own opinions and not those of my employer)

Re: Standard Haskell

[Hans Aberg]

John Hughes writes:
>>  If now the language should be standardized, why not make it an
>>ISO/ANSI standard?
>>
>I don't think this is the time. Look at Pascal. After the revised definition
>was published many years passed before it became an ISO standard, during which
>the language did not change one jot. The final standardization just made one
>or two small revisions; the language itself was already largely in its final
>form. Let's jump through these hoops in five years time, when Haskell has been
>fixed for so long that language researchers aren't interested in it any
>more...

  I do not think that the Pascal standardizing model is being used anymore;
instead one schedules a new revision, say every five years (this is used
for C++). There is already an application put in for ISO/ANSI standardizing
of Java, and I think Java is younger than Haskell. So I think the question
should at least be investigated; perhaps it is the developed Standard
Haskell that should be made ISO/ANSI.

>Students believe functional
>languages are good for toy programs because they learned them when they could
>only write toy programs.

  I would rather think that the reason that functional languages are not
used is the lack of an ISO/ANSI standard, plus the lack of standard ways of
making cooperation with other, imperative languages.

  Hans Aberg

Re: Standard Haskell

[Hans Aberg]

At 17:26 97/08/20, John Whitley wrote:
>Perhaps what is needed are two tracks of language development,
>"Standard Haskell" and "Research Haskell". The research community
>continues to develop, distribute, and test new language concepts with
>less fear of disrupting existing users.  After sufficient time the
>lessons from Research Haskell can be folded back into Standard
>Haskell.

  This is a model that comes to my mind. It would answer the question posed
by John Whitley:

>-- What is the Ultimate Purpose of Haskell?
>What are the community's long-term goals, the collected hopes and
>dreams, for the language?  In The Beginning, that seemed to be as a
>focus for research into functional programming languages.  Haskell was
>born and has since matured greatly.  Now the decision must be made as
>to its desired role in human computing endeavors.

  There would be two objectives, one to continue the research development,
and another to standardize the features which are considered stable and
reliable.

  The question is how to make the two Haskell variations communicate;
clearly the ideal would be to have one compiler that understands both.
Perhaps one could agree that code that is not specially marked is
considered to be "Standard Haskell", and "Research Haskell" code is name
space marked so.

  Otherwise, the idea of marking code with version numbers is not new; it
is used in the LaTeX project (which sports a rather large number of
non-expert users). One would mark the code in the style "requires Haskell
1.4", with name, version, and optional version date (but one is not
required using this feature). It is like importing a module with a version
number attached to it.

  Hans Aberg

Re: Standard Haskell

[John Hughes]

Let me try to give my answers to some of the points that have come up since
yesterday.

Hans Aberg says:

  If now the language should be standardized, why not make it an 
ISO/ANSI standard?

I don't think this is the time. Look at Pascal. After the revised definition
was published many years passed before it became an ISO standard, during which
the language did not change one jot. The final standardization just made one
or two small revisions; the language itself was already largely in its final
form. Let's jump through these hoops in five years time, when Haskell has been
fixed for so long that language researchers aren't interested in it any
more... (:-)

  Is it not possible to make the versions upwards compatible, so that
Haskell 1.4 code somehow can be run on Haskell 1.5? Does "being stable"
need to mean unchangeable?

Well, that's really been the aim all along, but things haven't turned out that
way. Rather the committee has had debates about whether `many' programs will
break, or whether there are `easy fixes'. In practice I think true upwards
compatibility is hard to achieve, and maybe not even desirable if it leads to
a more baroque design. It's important also to remember that even extensions
that don't change the meaning of correct programs may transform programs that
fail for a simple reason into programs which fail for a complex one; we've
seen examples of that. "Being stable" should also include producing
predictable and understandable error messages!

  It seems me that this increased complexity is the result of that
people start to find the language useful. An idea to handle this might
be to opt for a more condensed kernel, based on logically clean
principles

Yes, some people favour this approach. I'm strongly against it, because I've
encountered all too many students with the impression that functional
languages are OK for toy programs, but for real work you need
C/C++/Java/whatever. They can easily get that impression, paradoxically,
because of the success we functional programmers have had in introducing
functional languages early in the curriculum! Students believe functional
languages are good for toy programs because they learned them when they could
only write toy programs. If they gradually discover that, in fact, the very
language they have learned is also used for very serious applications then
there's a chance of countering that impression. If instead they discover that
they were quite right, the language they have learned is considered a toy even
by functional language researchers, then I don't think we have much chance. So
personally I am dead against designing a `Noddy Haskell' which is clean enough
for teaching; let Standard Haskell be clean instead!

  Standardizing a language tends to make it obsolete, due to lack of
creativity. Perhaps it is time to start discussing the successor of
Haskell then.

Please not yet! Let us finish Haskell first!

Sergey Mechveliani says:

To my mind, the 1.4 version is still very "intermediate".
The language needs badly the multiple class parameters and other
important extensions - to fit better CA.

Agreed, the restriction to single parameter classes has become
severe. Dropping the restriction (that is, allowing multi-parameter classes)
could be considered a simplification, and this will be considered for Standard
Haskell --- see the web pages.

John Whitley says:

But surely as the above benefits accrue, further areas for refinement
of the language will be revealed, and wholly new research areas will
emerge and mature.  The research community centered around Haskell has
done much to create a language in which powerful abstraction tools can
be brought to bear on real world problems.  This research environment
should continue, and requires a focused research forum for the same
reasons Haskell was created in the first place.

Perhaps what is needed are two tracks of language development,
"Standard Haskell" and "Research Haskell". The research community
continues to develop, distribute, and test new language concepts with
less fear of disrupting existing users.  After sufficient time the
lessons from Research Haskell can be folded back into Standard
Haskell.

I think this is essentially what is being proposed, with two exceptions:

* Since `Standard Haskell' and `Research Haskell' are expected to diverge, the
  proposal is to use more different names for them.

* When a new stable design is reached, rather than change the definition of
  Haskell, it should be given a new name. This could be `Haskell 2001', it
  could be `Curry', or who knows it might be `Alonzo'! That will be a question
  for whoever designs it.

Of course, nobody is proposing to freeze research on functional languages!
Just to fix the meaning of the word 

Re: Standard Haskell

[David Barton]

Fergus Henderson writes:

   ISO is the same.  But standards don't get updated every five years.
   Rather, each standard must be _reconsidered_ every five years.  One of
   the possible results is for the standard to be reapproved unchanged.
   If the standards committee does decide that the standard should be
   changed, then it will start a new project to produce a revised version
   of the standard.  This process itself takes years.  So typically
   language standards get updated less than once every ten years.

   Fortran: 66, 77, 90.
   COBOL: 74, 85
   Ada: 83, 95.
   C: 89, 9X.  
  (Original standard in '89, currently undergoing revision;
   revised standard, tentatively titled "C9X" due in 99, but
   might not happen until 2000 or later.)

True.  Others have a greater velocity of change, particularly if they
are newer; VHDL, for example.

   However, standards committees can publish normative amendements
   in the intervening periods.  For example, there have been some
   normative amendments to the C standard since 89 (relating to
   internationalization and numerical extensions).

There are actually several options here.  A "normative amendment" is
essentially (in IEEE land) the same as a reballot; it just doesn't
require the document to be reprinted.  The VHDL committee produced a
"sense of the working group" report that, while not officially
normative, gave the resolution to several ambiguities and the like.

   This is not _necessarily_ true.  For example, the ISO Ada 95 standard
   is freely available on the net.

It all depends on who gets the money.  In this case, the AJPO *paid*
for the free availability.

   However, convincing ISO of this would be a significant hurdle to
   overcome.

Agreed; perhaps impossible.

   In any case, I agree with Dave Barton that ISO standardization for
   Haskell should not be considered until after the current effort
   at defining "Standard Haskell" is complete.

Even if then.


Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb

Freezing Haskell?

[Klaus Georg BarthelmannypHhgMxU:/home/barthel/nsmail/]

Hi!

The wish to freeze Haskell with the next version came as a complete
surprise to me (only an occasional user). Isn't the present state very
unsatisfactory?
- Monads were introduced but, in my opinion, aren't yet fully
  integrated. They should be more pervasive. (Those who don't like
  further developments probably disagree here.)
- Everybody needs multi-parameter constructor classes, as I learned from
  this discussion list.
- There are nice features like existential types ready to be included.
- As a matter of fact, nobody really likes the module system.
- The n+k pattern controversy isn't settled. It seems to me that
  freezing the language is an unfair attempt to cut off the discussion.
- ...
If all these questions should be resolved until version 1.5, will they
be frozen then without further testing?

I guess that version 1.4 prompted most of this discussion. Has there
ever been a new version with so little improvements? As was suggested
by others, perhaps the Minimum Time Between Updates should be bounded
below. This would serve programmers better. I see no difference between
naming an improved version "Haskell 1.6" or completetly differently.

Best regards,
  Klaus

-- 
Klaus Barthelmann, Johannes Gutenberg-Universit"at, Institut f"ur
Informatik,
Postfach 3980, D-55099 Mainz, Germany
[EMAIL PROTECTED]

Re: Standard Haskell

[David Barton]

Hans Aberg writes:

   I do not think that the Pascal standardizing model is being used
   anymore; instead one schedules a new revision, say every five years
   (this is used for C++). There is already an application put in for
   ISO/ANSI standardizing of Java, and I think Java is younger than
   Haskell. So I think the question should at least be investigated;
   perhaps it is the developed Standard Haskell that should be made
   ISO/ANSI.

Having been through the standardization wars many times, perhaps I
should interject here.  Virtually all of my experience has been within
the IEEE process, although IEEE standards are often upgraded to ANSI
and ISO standardization fairly quickly, with only an "up/down" vote
(it is *not* automatic, however; Verilog was rejected).

The IEEE *requires* restandardization every five years.  If another
ballot is not taken, than the standard is dropped.

Standardization does not particularly guarantee stability.  It does
guarantee three things:

1) A certain process has been followed.  ANSI and ISO have rules about
the process to be followed by organizations that submit standards to
them for approval, such as the IEEE and the EIA.  This includes
openness (anyone wishing to particpate in the process and the ballot
may) and a certain level of approval.

It also assures *lots* of bureaucracy.  And I mean lots.  More than
that.  No, even more than that.  Lots more.

2) The final result is independent, and non-proprietary.  This can be
more or less true; Verilog is, again, a good counterexample.  This is
not a worry with Haskell; I don't know *anyone* who thinks that
Haskell is the result of a single university or company.

3) It also means (cynically) that the standardization organization
makes money off of the standard's publication.  If we were to
standardize Haskell, the copyright of the document would have to be
transferred to the standardization organization.  This means that we
could no longer distribute the Haskell Report free on the net, and
with every download.

Think about this.  Really.  No more free downloads of the Report.
(The Library is a sticky issue, which we are fighting within the IEEE
now with respect to the standard VHDL packages for some of the related
standards.  If anyone is interested in the result, I'll start posting
what I hear on this list.)

   I would rather think that the reason that functional languages are
   not used is the lack of an ISO/ANSI standard, plus the lack of
   standard ways of making cooperation with other, imperative
   languages.

I must disagree here.  After having been in the standardization
business for a while, I don't think that standardization means that
much to widespread usage.  WAVES is a good counterexample in the field
of digital CAD.  It does have *some* positive effect, but this really
is limited.  There are *lots* of standards that are nothing more than
pieces of paper on the IEEE's bookshelves.

I don't want to sound too pessimistic here.  I wouldn't spend so much
of my professional time in standardization efforts if I didn't think
it was worth while.  There are some things that standardization
brings.  In particular, don't look for widespread use of Haskell on
government software without an officially recognized standard in
place.  It also does give commercial vendors some feeling that there
may be a market there, or at least some interest.  And, frankly, it
would make my life a whole lot easier; I am creating a standard that
is based in Haskell and defined by a series of Haskell files.  At this
point I am planning on simply referring to the Haskell report as
prior, and existing, art; however, I am expecting to take some flak on
that.  It would be vastly easier for me if I could point to a standard
instead.

But standardization is a two edged sword.  It does take up a *lot* of
time.  The common mode of standard creation these days is to go to a
standardization body with something close to ready, and hope for few
changes and a relatively painless ballot.  Haskell is certainly ready
for this kind of effort.  But expect some change, and a two to two and
half year process before the ballot comes in.

I would be happy to answer further questions about the IEEE
standardization process if it is relevant, and what I know about other
standardization processes.  But I don't want to get too bogged down in
it.  Certainly we should not approach a standardization organization
until the present effort for creating Standard Haskell is complete.
Therefore, it should not take up much of our time.

One more note: frankly, you (the members of this list) don't entirely
control the question.  Given that the Haskell report is freely
available, *anyone* can submit it to one of the standardization
organizations to start the process if they wish.  Of course, this need
not affect what the compiler builders here do (and probably wouldn't).
Nevertheless, the question need not necessarily concern us here; if
someone feels strongly enough to f