Language change proposal

[Joe Armstrong]

On Wed, 22 Oct 2003, WILLIAMS Dominic wrote:

> From: Joe Armstrong
> > 
> > I want all Erlang modules to be tagged with a "language version"
> > 
> 
> I wholeheartedly share the concern for managing language and library
> evolutions. Doing this properly would be another major strength of
> Erlang over many other environments.

  This is *not* a proposal for library management/evolution only
a *minimal* way of getting rid of stuff from the language.

<<aside>>

For a long time I though about much stricter versioning information.

There is a spectrum of annotations, from

	-import(lists, ....)

Meaning "the latest lists in the libraries"

To being very specific

	-import(lists, {version,"2.1.2"}, ...

...

I'd like to be able to say that a particular version of modules was tested
together and works etc.

I also *hate* stuff that is hidden away in version control software -
I much prefer explicit versioning in the code where I can read it -
Stuff which is hidden in CVS/clearcase etc. often prevents a module
from having a life of it's own outside the versioning tool ...

<</aside>>


> As to the details, I would prefer that whatever mechanism is used to
> deprecate libraries (modules, functions) be designed to serve the same
> purpose for external libraries (not only those provided as part of the
> Erlang/OTP distribution) and application development in general.
> 
> Also, I am not very keen on having to add a vsn attribute to every
> module I develop. I would prefer these issues to be manageable in one
> place for an entire build tree (i.e. in an (E)makefile).
> 

  The problem is that then the code will get detached from the makefile
and the version information will be lost.

> I would therefore (respectfully) suggest an alternative scheme:
> 
> 1) The compiler would by default assume the latest version of the
>    language is being used. When a language feature becomes deprecated,
>    the compiler rejects code using this feature unless a specific
>    compiler directive has been used to allow it.

This doesn't work - suppose we *don't* do as I have suggested - the following
*will* happen.

   - A new version of the language turns up - with the 'try' statement.
   - I write a program using 'try' and use the latest compiler
   - I post my program to the net
   - I get mail saying that my program is ****ed up because it
     won't go through some old version of the compiler that was released
     before version numbering was introduced.

This has already happened to me on several occasions - I have sent people
program that use binaries - only to find that they are using a 
"pre-binaries" Erlang.


> 
> 2) Functions would be deprecated by adding an obsolete attribute that
>    would list obsolete functions in the same format as export/import:
> 
> -module(my_module).
> -export([a/1,b/2,c/3]).
> -obsolete([b/2]).
> 

Ummm ... why not - A while back I made a little system for patching
modules.

Example:

	Suppose we have
	
     mod.erl

	-module(mod).
	-export [p/7, j/3, a/2, b/4, x/9]).

and   mod.1.patch

	-module(mod1).            %% my new module name
	-inherit(mod).            %% based on
	-remove([a/2, b/4]).      %% These calls in mod1 will not be available
	-add([c/2]).              %% c/2 is added to mod1
	-replace([p/7,j/3]).      %% p/7 and j/3 are in mod1 but are being 
				     redefined 

	c(_, _) -> ...
	
	p(...)

Then both mod and mod1 can co-exist, old programs can use mod and new
ones can use mod1

This can be implemented with some very simple munging

mod1.erl looks like

	-module(mod2).
	-export([p/7, j/3, x/9, c/2]).

	%% set up the old calls

	p(....) -> mod:p(....)  use the old definitions of p/7 ...  
	
        x(...) -> mod:x(...)

	%% and add the new code

        c(..., ...) -> ...     

Then you could issue a series of files

	mod.erl
	mod.1.patch
	mod.2.patch

etc.

This is how programs used to done when I started off in the 'good 'ol days
- when the "program" weighed about 15 Kg and was 4 trays of punched cards.

The "patch" was only a few hundred cards and didn't need a fork lift truck
to get it to the computer center :-)


> This could be used (by the Erlang development team) for core
> libraries, as well as (by the rest of us) for our own libraries,
> frameworks and applications...
> 
> Regards,
> 
> Dominic Williams.
> 

/Joe