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@gmail.com