Hans Aberg writes:
> After all, a lot of work has been spent making personal computers
> upwards compatible, so why not computer languages?
The (perhaps obvious) reason to make anything backwards compatible is
to support a legacy user base. Clearly, there is a tension between
freezing the language to support growth of the user base and between
the desire of the research community to continue development of the
language.
Haskell began its existence as a unified research language for a large
segment of the functional programming language community. Now Haskell
has grown sufficiently, in both design and implementation, to gain a
user base large enough to have stability concerns. I fully support
the growth of this user base, as it will serve a number of important
purposes. Some benefits of an active user base are:
to reveal good idioms of Haskell programming style,
to drive creation and refinement of Haskell development environments,
and to provide examples and motivation for Haskell compiler refinements.
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.
In fact, I remember hearing that intent around the time of Haskell 1.3
-- that the next language release wouldn't be until Haskell 2.0. That
would permit interim stability and sufficient time for certain "big
picture" problems (especially the module system) to be addressed.
What happened here?
Perhaps what is really required is just an enforced moratorium on new
language releases for a specified time. A complete split bewteen
Standard and Research Haskell groups may present a division-of-labor
problem.
In any case, it is time to again ask several basic questions:
-- 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.
-- In what ways must Haskell be simplified/changed/expanded in order
to achieve the desired Ultimate Purpose?
As an example, I would wish to see the power of Haskell brought to
bear on systems programming. Moreover, I want powerful abstraction
tools made available to the operating system designer and implementor.
OS entities are usually untyped (i.e. just bits), or have an ad-hoc
typing notion at best. Thus the issues that interest me most strongly
are persistence, support for programming in the large, and dynamic
typing.
I would suggest some agreement be made on the appropriate big picture
issues. Then a pact should be sealed between the Haskell research
community and the user community that prevents a language release
until good answers are found to the big picture issues.
-- John Whitley
