[erlang-questions] lists:reverse/1 as a built-in function

[Mats Cronqvist]

Richard Carlsson wrote:
> I'm pretty sure that [non-backwards-compatible changes] are
> not seen as much of a problem (compared to the advantages of getting an
> improved language) by individual users and hobby programmers, but those
> professionals out there who are maintaining large systems might have
> completely different opinions about it, and I'd really like to hear
> what they have to say. Any takers?

   for us (the AXD, an ericsson product with +1MLOC erlang) just recompiling the 
entire system is a pretty big deal. handling changes that requires editing of 
our source code is of course even worse.

   OTOH, it's not in our best interest for the language to stagnate, or to 
squander OTP resources on demanding support for every mis-feature/bug ever 
introduced.

   as i see it, the solution is not in avoiding obsoletion, but in having a 
(shudder) process for it. a brief sentence in the release notes is not enough. 
perhaps something like this;

   institution of Erlang Workgroup for Obsoletion Control (EWOC), consisting of 
paying customers, OTP people and independent eminent computer scientists (i.e. 
richard carlsson :>).
   feature X is proposed to EWOC for obsoletion.
   following an (archived) discussion in EWOC, feature X is decided be obsoleted 
in release R.

   in release R-1 you get;
  a discussion about X in the release notes.
  a description about how to remove X and replace it with spiffy new feature Y.
  if possible, a tool/script/emacs macro to automatically replace X with Y.
  a compiler warning.
  a compiler flag to abort if X is found.

   in release R you get;
  a compiler that aborts if X is found.
  a compiler flag to allow X.

   EWOC would consider things like;
   how will removal of X affect performance?
   how hard would it be to SAFELY remove/replace usage of X?
   how strong is the case for replacing X?

   given something like this, i think the paying users could accept almost anything.

   mats

p.s. most of this is probably already used in, say, python. it was also 
discussed at the 2006 user conference.

p.p.s. my choice for first obsoletion; the parts of the pre-processor that's 
incompatible with epp_dodger. the permissiveness of the pre-processor is a show 
stopper for erl_syntax based refactoring tools.