Hello Malcolm,
Friday, November 24, 2006, 8:26:11 PM, you wrote:
>> i think that we should require H' compatibility instead of H98 one, so
>> require to not use fundeps, but allow MPTC. this means that NHC should
>> be ruled out as non-H' compliant compiler instead of these libs
> Why pick on nhc98? Today, there are absolutely _no_ haskell-prime
> compliant implementations, because there is no haskell-prime standard
> yet. As and when the standard is fixed, implementations will catch up.
that was started as internal GHC initiative, now seems to also have
support from you and Ross Paterson and that's great. i hope we can
consider this as initiative to define modern set of standard libraries
which should be available with any modern Haskell compiler. because
nowadays Haskell-prime standard also developed i hope that these two
initiatives will come together, probably we can develop libraries part
of this standard (or, to be exact, describe current state of widely
used libs as Library Report part of this standard)
the next question to consider is that a "modern" compiler? may be it's
only ghc? or ghc/hugs which has a lot of common extensions? or
ghc/hugs/nhc which is declared as supporting Base lib? or maybe all 5
compilers whose authors present here?
in the light of forthcoming Haskell' standard, i propose to consider
compatibility with H' as a mark that library may be standardized. it
is especially important if we want to continue live of this proposal
in the H' world instead of reinventing the wheel again
yes, this means that some "standard" libraries will be available only
for hugs/ghc now, but we have the same situation even for parts of
Base library (Data.Array.*, at least)
>> but when other problems
>> arrives, this may be a stop-mark, because these problems will not be
>> fixed in future NHC versions
> Who says? nhc98 is not dead. Yhc is a very active project, and it is
> basically just a re-branding of nhc98.
i tried to say that problems which probably will be not fixed in
future nhc versions, should be a stop-mark for inclusion library in
standard set
so, my proposal now is to require that libraries going to Core should
obey H' standard in its current proposed form and for non-language
features (if such exists) it should be compatible with ghc/hugs/nhc
(i hope that yhc is compatible with nhc in this aspect)
this will allow, when H' arrives and nhc will be updated to support
this standard, to have standard libraries readily available on these 3
or 4 platforms
of course, it's rather speculative to test on compatibility with non
yet fixed standard. on the other hand, such tests may influence the
standard itself, requiring inclusion of some language features that is
required for some great lib (like mine ;)
--
Best regards,
Bulat mailto:Bulat.Ziganshin at gmail.com