Foreign.destructArray

[Simon Marlow]

> I'm not for a number of reasons:
>=20
> - The libraries that come with GHC are huge and very few of them are
>   completely stable.  Even the H98 libraries change as H98 is refined.
>=20
> - The statement that 'deprecated' means 'will not change=20
> until the next
>   major release' isn't very satisfactory because:
>=20
>   1) People might disagree about what a major version is.  The second
>      sentence in this quote from SimonM suggests that the ':-)' is
>      a typo and SimonM really doesn't regard 5.02->5.04 as a minor
>      version change. =20

Ok, we define a major release to be anything that isn't a patchlevel
release.  They have been happenning at roughly 6-12 month intervals
recently.

The "major version number" (i.e the "5") doesn't correspond to a major
release; we use it to indicate when the compiler gets a major overhaul
or significant components are rewritten (so that you have a good idea
when things might be unstable).  eg. in 5.00 we introduced GHCi, in 4.00
we completely re-wrote the RTS, etc.  It was debatable whether 5.04
should have been 6.00 since we introduced hierarchical libraries, but in
the end we decided it didn't really constitute a significant rewrite,
just a re-organisation of existing bits.

6.00 is on the horizon though: it will probably include Template
Haskell, possibly Optimistic Evaluation, and a redesign of parts of the
RTS and evaluation model that Simon & I are working on.

>   2) The timing of GHC releases is unlikely to be a useful measure to=20
>      people relying on GHC in their project.  Much more=20
> useful would be
>      'will not change before the POPL deadline' or 'will not change
>      before our IPO'.  That is, entities should be deprecated for
>      a time period not a release cycle.

If you don't want things to change, don't upgrade!

We're keeping releases stable for quite a long time these days: the 5.02
cycle lasted nearly 10 months, during which time we didn't break
*anything* between releases.  I wish we had the resources to maintain
releases from two branches simultaneously, but sadly we don't. =20

> To fix this situation (which I believe is common), we probably need
> something like:
>=20
> 1) Every entity in the API (type, function, module, etc.) should be
>    assigned a 'stable period' such as 'stable until Jan 1st 2003'.

Do you know about the stability assignment for each module in the
hierarchical libraries?  Each module is classified as either 'stable',
'provisional', or 'experimental'.  These terms are defined more
precisely in=20

	http://www.haskell.org/~simonmar/libraries/libraries.html

I think that's about the right level of rigour, given our current
resources.  The scheme you're proposing is, IMHO, unrealistic at the
moment (although it may be the right thing in the future when things
have settled down some more).

> 3) GHC's flag to warn about deprecated functions would take an
>    optional expiry date as an argument.  GHC would warn about use of
>    entities which will expire before then.  Probably on by default.

This is a good idea.  Volunteers?

> 5) Each release would include a list of any entities removed ahead of
>    schedule.
>=20
>    [It's open to debate whether this would do anything other than
>    increase the motivation to keep the list small.]

I agree we ought to do a better job here.  I'm sure there's a way to
automate this at least partially: compare the library interfaces against
the previous release's and document (or fix) any changes.

Cheers,
	Simon