[erlang-questions] Strings - deprecated functions

Joe Armstrong erlang@REDACTED
Fri Nov 24 16:21:09 CET 2017

On Fri, Nov 24, 2017 at 3:40 PM, Loïc Hoguin <essen@REDACTED> wrote:
> On 11/24/2017 03:07 PM, Eric des Courtis wrote:
>>  From my perspective, we want the following things:
>>   * The libraries to stay simple, small and clean (that means throwing
>>     away things)
>>   * Our old code to continue to work without modifications (that means
>>     having a mechanism for compiling old code targetting new versions of
>>     Erlang)
> That can work in many cases but not in the general case. This only works for
> a specific set of changes where an equivalent still exists in the code base.
> For example removing ciphers or hashes in crypto requires human intervention
> on every code bases that require them.
> Another issue comes from old code requiring syntax or VM features that have
> been removed.
> Then you have issues where it is technically still possible to do the old
> functionality, but the performance or memory aspects are not equivalent.
>>   * To mix old and new Erlang code together
> If it's maintained, no problem. If not, even if it compiles and runs you
> should probably make sure to have a good set of tests to know it still works
> as intended.
> You'll want to do this even if OTP team go out of their way to make sure
> everything stays compatible forever.
>> I see no reason why we can't have both. What I am not okay with is:
>>   * Endlessly growing libraries of functions that are there for legacy
>>     reasons (wasting space and confusing new developers)
>>   * Fixing libraries over and over again because something got marked
>>     deprecated
>> So how do we get both?
> You don't.
> In fact your second point is incorrect: there's absolutely no reason to fix
> a library because something got marked deprecated.
> Zero.
> Developers should not "fix" libraries when something gets marked deprecated.
> Developers should *take notice* that something has been deprecated.
> There's nothing to fix to begin with! Check your OCD levels and stop trying
> to get rid of all the deprecation warnings with obscure parse transforms or
> version-specific defines...
> The time to fix comes when the feature gets *removed* or is rendered
> *incompatible*. (Or soon before that actually happens, anyway.)
> As far as the string module is concerned, there's absolutely no need to
> spend efforts to make your code run for both the old and the new string
> module because the functions will not be removed for a very long time. And
> until they are, chances are you will stop supporting OTP versions before the
> new functions were introduced. You can do the changes THEN.
> I am baffled every time someone opens a ticket telling me that I have
> deprecation warnings. I know! But they're harmless and the code works on all
> supported versions, so why would I spend efforts to remove it?
> Your question can be reframed to be about an endlessly growing library +
> having to fix libraries when things get removed, which is more of a choice,
> you can't really have both. Either you have an endlessly growing library, or
> you remove functions and fix libraries (manually or otherwise).

You are quite right - what I'd like is a garbage collector for code.
Given a root query  and a set of modules remove all code that can
never be reached.

Actually the way Knuth did things was pretty good TeX provides
a great example.

The version numbers were the digits of Pi
TeX is currently at version 3.14159265

Knuth offered a reward of $2.56 for the first error in TeX to be
doubled for each new error

TeX was implemented as an initial program, followed by a set of patch files)
to get to version you take the first version then apply a set of
patches to get to the
version you want.

We could do this in erlang - some syntax like:

    -remove([func1/4, func4/3]).

    func7() ->


This might create a module called string_10.erl and would be a copy of
all the code in string_9.erl
the remove declaration just removes code from string_9.erl

Any additional functions in the module are just added to the new module.

This way the old and new code could happily co-exist.

For developers there could be a "window" of code they might maintain say from
string_7 to string_10 and this would migrate forwards with time,

This scheme worked well for Knuth but assumes a single thread of
development with
no branches.



> --
> Loïc Hoguin
> https://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list