Erlang language issues

[Thomas Lindgren]

>Not sure what you mean here. Of course, the compiler does those things
>internally, when translating to Core Erlang: on that level, guards are
>plain boolean expressions composed of 'and' and 'or', with 'catch'
>blocks inserted as necessary to preserve the Erlang guard semantics. No
>confusion there.

There you go then. One could use your tool to automatically rewrite
as much of the code as possible, carefully telling the programmer what
it has done, and also let the Erlang compiler flag obsolete
constructs (much like it does today with some operations) when put in
"migration mode".

>It's the source level backwards compatibility that's the problem. The
>not entirely unimportant category called "customers" do not want to
>change a single thing in their source code unless it is a bug - and
>preferably not even recompile anything. They won't switch to a new
>version of the compiler if that means new bugs in old code.

Since I am working for a company using Erlang, I took the opportunity to
hear how
things are done. Cellpoint is a pretty small firm, with roughly
20 developers and 10 testers. So what does the project management
think about non-backwards compatible changes to Erlang?
I asked our project leader, who supervises the
whole shebang and who has been doing project supervision for a decade
or so.

[I paraphrase and summarize a short conversation here:]
--
In order to move to a new release of Erlang, (1) the system has to be
re-tested; (2) Cellpoint also has made a number of internal patches to
Erlang,
which have to be migrated to a new release. Doing _this_ migration work
is needed regardless of whether Erlang-the-language is backwards compatible
or not, obviously.

There is also (3) installed base. The basic problem is that some customers
are unwilling to migrate to a new product release, but still want you to
patch the code. If so, you have to work with two language versions until
you can persuade customers to switch.

(In Cellpoint's case this is not a big problem; perhaps AXD301 would find
it more painful.)

The actual porting problem is deemed to be minor, as
long as the language changes are minor.
--

So that's one data point (which I hope I summarized fairly). Anybody else
want to comment, please do.

In closing, I'd like to say that I do _not_ propose continuing changes
to the language in this way. Not at all. But I do think we need an orderly
way to change things when the language is getting hairy.

Best,
Thomas