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 <http://www.ams.org/cml/>
* Email: Hans Aberg <[EMAIL PROTECTED]>
