Language change proposal

[Shawn Pearce]

Vlad Dumitrescu <vlad_dumitrescu@REDACTED> wrote:
> > It might also be nice to define other dependencies such as:
> >
> > -require(stdlib, "5.3").
> >
> > to indicate that this module would need a version of stdlib that understand
> > the calls available in version 5.3 of stdlib.
> 
> Mmm, wouldn't there be confusions with the stdlib application's version? After
> all, as user of stdlib, I don't care what it's using inside, just what
> interfaces it has. So in this case i'd expect to check stdlib's version - but if
> things are going to be added and deprecated and removed, after 3-4 passes it
> might become quite difficult to find out which versions will work and which ones
> don't.


I think what I was trying to point out was the version number concept being
tossed about is used to specify what _interface_ version this module requires
to compile and run properly.

If we were to state that a module required ERTS 5.3, and the language
support that was available in 5.3, surely we would also expect the stdlib
module to have all functions which were documented in the 5.3 release manuals.
Now fast foward 3 years, a function has been removed from stdlib.  stdlib in
ERTS 8.3 no longer fully implements the interface which was available in
5.3.

The code server should refuse to load my module which depends on stdlib 5.3
as my module might not work properly.  However, who makes the decision that
stdlib no longer supports the 5.3 interface is up to stdlib's developers,
not me or my module.  stdlib should be queried by the code server to see if
it can handle interface 5.3, which is associated with the module by the
'require' attribute.

I think this might get coded as something like this:

-module(stdlib, "8.3").	  % Needs 8.3 ERTS.

module_interface_version(Major, Minor) ->
	if
		Major >= 8 and Minor <= 3	-> ok;

		% Version 7.6 introduced kill_foo, a bad idea now gone.
		% All other 7.x is ok.
		Major = 7 and Minor = 6		-> {not_supported, [kill_foo]};
		Major = 7					-> ok;

		% Version 6.8 introduced kill_pid, replaced by exit_pid in 6.9.
		% All other 6.x is still supported.
		Major = 6 and Minor = 8		-> {not_supported, [kill_pid]};
		Major = 6					-> ok;

		% We're amazingly still compatible with 5.0 and 5.1.
		Major = 5 and Minor =< 1	-> ok;

		% No other interface version is supported.
		true						-> not_supported;
	end.


This is better, IMHO, to putting the required VSN in the app release file
as the API required is used in this module.  The compiler, code loader
or linter can check to see who is using the deprecated (or flat out
removed) API and lead the developer in the right direction.  When
a module is modified to be brought current, its VSN can be updated at
the same time its API usage sites are updated and tested.  Now if there
is a good linter that can determine what is deprecated/removed (or not
available in an older version), and do this by reading the VSN from the
app release file, maybe that's an acceptable way to go.

-- 
Shawn.