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 find a sponsoring organiztion and to
donate the considerable amount of time that it takes, than they may go
ahead and do so. The relationship between the Haskell committee and
the standardization working group would have to be worked out, but the
two certainly need not be identical.
Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb
