chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Remove deprecations


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Remove deprecations
Date: Mon, 24 Sep 2012 21:09:27 +0200
User-agent: Mutt/1.4.2.3i

On Mon, Sep 24, 2012 at 08:44:49PM +0200, Felix wrote:
> > I thought kept stuff deprecated for one release and removed it the next.
> > When will we be able to remove this stuff?
> 
> Yes, you are of course totally right. I'm just a bit reluctant to
> remove what might still be used somewhere. We all know how it is when
> things break suddenly, just because an egg or the base system has been
> updated. The longer something is kept, the lower is the chance of
> breakage. I just think we should decide on a case by case basis,
> whether something is truly ancient, or whether it was still in use in
> compiled code, whether something just hurts in the eye and has to go,
> or wether it is obscure enough to be left in or a while.

This is tricky.  I basically agree with this approach, but I also think
it's clearer towards our users if we have rules for how deprecations are
handled.  This way, we can more easily defend taking out a particular
feature at a particular date.  Otherwise, there's always bound to be
someone who disagrees and thinks the feature should've been left in
just a *little* longer.

Anyway, in the interest of preventing future breakage, concretely we
can already prepare for the removal of direct lambdas in macros by
fixing those cases where core doesn't use a macro transformer wrapper.
Attached is a patch for just that bit.  I've also added a patch to
remove from the types database those deprecated procedures that had
already been removed earlier.

The thing with such deprecations is that if you don't generate warnings,
this stuff tends to stay in until it's really removed.  We could
generate deprecation warnings at macro expansion time when a direct
lambda is detected, but I remember this idea getting shot down last time:
http://lists.gnu.org/archive/html/chicken-hackers/2012-02/msg00065.html

I sort of agree with your point in that post, but if there's no way to
see that you're still relying on deprecated things it will be harder
to fix your program once you upgrade; it'll just break down.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: 0001-Wrap-remaining-bare-lambda-macro-transformers-in-er-.patch
Description: Text document

Attachment: 0002-Remove-deprecated-procedures-which-were-already-remo.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]