[m-rev.] diff: exploit the new capability of switch detection

Mark Brown mark at cs.mu.OZ.AU
Tue Sep 20 13:21:36 AEST 2005


On 20-Sep-2005, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:
> 
> On Tue, 20 Sep 2005, Mark Brown wrote:
> 
> > On 19-Sep-2005, Julien Fischer <juliensf at cs.mu.OZ.AU> wrote:
> > >
> > > On Mon, 19 Sep 2005, Zoltan Somogyi wrote:
> > >
> > > > The change to switch detection has now been installed on all our machines.
> > > >
> > > > Zoltan.
> > > >
> > > > compiler/dupelim.m:
> > > > 	Factor out some common code using the new capability of switch
> > > > 	detection.
> > > >
> > > Assuming that Mark's laptop has been updated then that's fine ;-)
> >
> > My laptop has been updated, but that's not entirely the point.  This issue
> > would affect any users who want to keep an installed copy of the latest
> > compiler from CVS instead of having to download a source distribution each
> > time.  I don't know if we have such users, but if we did then we would
> > probably lose them quickly if we too often make changes that break forwards
> > compatibility.
> >
> > The question is, how often are users required to install from CVS in order
> > to still be able to compile the latest source?  That is, how long do we have
> > to wait between adding a new feature to the language and putting something
> > in the compiler that depends on it?  Do we ever tell the users what this
> > interval is?
> >
> No, mainly because we don't know what it is ourselves.

The question should have been how often _should_ users be required to install
from CVS.  Without an explicit minimum in our procedures the minimum is
effectively zero, although in practice we will (usually) wait until the new
feature is installed on all our machines.  This is too short for almost anyone
outside the research group.

> Anyway, isn't
> this the point of the unstable part of unstable rotd - things may break/be
> broken.

That serves as an excuse for breaking forwards compatibility, but not a
reason.  IMHO, we should avoid these (and any other) sort of problems as much
as possible, even for "unstable" ROTDs.

As a basic courtesy to users present or future who want to make use of the
cutting edge compiler, I think we should set in our procedures a minimum
amount of time after introducing a new language feature before it can be
used, even at some inconvenience to ourselves.  At minimum one week, but a
month would be better.  I don't plan to argue this point too vehemently,
though -- but I did want to make this point.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list