Phil Wadler writes:

   I bumped into Matthias Felleisen at ECOOP, and he offered the
   following advice regarding Standard Haskell, based on his
   experience with Scheme:

   1.  Don't standardize Haskell until it is useful to the
   run-of-the-mill programmer.  A minimum set of libraries should include
           - URLs [Jon's favorite]
           - TCP/IP
           - ODBC/SQL interface
           - COM interface

   2.  Make it an ISO Standard

   3.  ``Scheme standardized two years too soon.''

   There is no hope of doing 1 or 2 in the current time frame
   envisioned for Standard Haskell, but there might be in two years
   (see 3).  The reason for creating Standard Haskell was that some
   people, especially some textbook authors, cannot adopt Haskell
   while it remains a rapidly moving target, and delaying for two
   years will make that worse, not better.  Nonetheless, I think there
   might be good reason to delay Standard Haskell until we can deal
   with point 1; consider how Algol 60 and Pascal faired because of
   their lack of useful libraries.  The best of both worlds might be
   achieved if we release Standard Haskell now and commit to releasing
   libraries in two years; but who will have the energy to keep
   libraries up to date for both Standard Haskell and Haskell 2?  -- P

There are various levels of standards.  If we are talking about formal
standardization (as in ISO or IEEE) then I agree completely; however,
this is not what is meant by "Standard Haskell" according to my
understanding.  "Standard Haskell" is a name for an agreement by the
overall community to support this version for a good long time into
the future, possibly by compiler switches and the like.  I see no
benefit yet to attempting to standardize Haskell through one of the
formal mechanisms.  This can wait a while (as Phil said).

So I agree: don't do it now.  But I disagee: we don't need to hold up
the Standard Haskell process.  When the time comes, the venue can be
decided then; I will volunteer to get it started in the IEEE process,
if nowhere else (since I have a lot of experience there).  But let's
agree on a single version that will assure some sort of
transportability between tools.

                                        Dave Barton <*>
                                        [EMAIL PROTECTED] )0(
                                        http://www.intermetrics.com/~dlb


Reply via email to