| Author |
Message |
|
| joe at sics.se |
 Posted: Wed Oct 22, 2003 11:26 am |
 |
|
|
Guest
|
Hi everybody - I'd like to propose the following language change:
(It's *very* easy to implement)
I want all Erlang modules to be tagged with a "language version"
Like this ...
------------------------------------------------------------------------
Suppose the next version of Erlang is 5.3 then:
1) All modules *must* start
-module(XXXX).
-vsn("5.3").
2) Any module *without* a version is assumed to be "5.2"
3) If there is no version the compiler should complain like hell
with a warning that cannot be turned off that an explicit language
version is not present.
4) There should be files called "depreciated_5.3.{erl,txt}"
that tell the user what language language features and library
routine have been depreciated in version 5.3
The text file should describe the depreciated features.
The Erlang file can be used by the compiler to provide warnings about
depreciated features.
Then - somewhat later - when we change to version 5.4
The same rules apply - with one exception - warnings issued about
depreciated constructs in 5.3 now become hard errors - and there is no
way to turn off this behaviour.
-------------------------------------------------------------------------
Versions should be numbered X.Y.Z
Bumping X is done for syntax changes to Erlang, or changes in the
semantics if BIFs etc. (serious things).
Bumping Y is done for depreciated library functions bug fixes in libraries
Bumping Z is done for cosmetic reasons
--------------------------------------------------------------------------
*******
* Why *
*******
We need enforceable mechanisms to *remove* things from the Erlang
libraries and from the language.
Erlang is getting bigger and things are not being removed.
As regards customers who crave backwards compatibility tell them that
if they want to use the new stuff they will have to change their code.
The version that they used in their products should always be
supported into the future - but the cost of doing so should increase
as you bump the version numbers.
This is *exactly* what the chip manufacturers do - have you ever
tried to buy "old" memory chips - they cost a fortune !!!!
IMHO their should be no language changes until it can be
realistically demonstrated that we can remove things from the
language.
/Joe
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| nick at erix.ericsson.se |
| Posted: Wed Oct 22, 2003 11:44 am |
|
|
|
Guest
|
Hello!
Xref supplies a very flexible solution. See ('-deprecated(...)'):
http://www.erlang.org/doc/r9c/lib/tools-2.3/doc/html/xref.html
/Nick
> Hi everybody - I'd like to propose the following language change:
>
> (It's *very* easy to implement)
>
> I want all Erlang modules to be tagged with a "language version"
>
> Like this ...
>
> ------------------------------------------------------------------------
>
> Suppose the next version of Erlang is 5.3 then:
>
> 1) All modules *must* start
>
> -module(XXXX).
> -vsn("5.3").
>
> 2) Any module *without* a version is assumed to be "5.2"
>
> 3) If there is no version the compiler should complain like hell
> with a warning that cannot be turned off that an explicit language
> version is not present.
>
> 4) There should be files called "depreciated_5.3.{erl,txt}"
> that tell the user what language language features and library
> routine have been depreciated in version 5.3
>
> The text file should describe the depreciated features.
>
> The Erlang file can be used by the compiler to provide warnings about
> depreciated features.
>
>
> Then - somewhat later - when we change to version 5.4
>
> The same rules apply - with one exception - warnings issued about
> depreciated constructs in 5.3 now become hard errors - and there is no
> way to turn off this behaviour.
>
> -------------------------------------------------------------------------
>
> Versions should be numbered X.Y.Z
>
> Bumping X is done for syntax changes to Erlang, or changes in the
> semantics if BIFs etc. (serious things).
>
> Bumping Y is done for depreciated library functions bug fixes in libraries
>
> Bumping Z is done for cosmetic reasons
>
> --------------------------------------------------------------------------
>
> *******
> * Why *
> *******
>
> We need enforceable mechanisms to *remove* things from the Erlang
> libraries and from the language.
>
> Erlang is getting bigger and things are not being removed.
>
> As regards customers who crave backwards compatibility tell them that
> if they want to use the new stuff they will have to change their code.
>
> The version that they used in their products should always be
> supported into the future - but the cost of doing so should increase
> as you bump the version numbers.
>
> This is *exactly* what the chip manufacturers do - have you ever
> tried to buy "old" memory chips - they cost a fortune !!!!
>
> IMHO their should be no language changes until it can be
> realistically demonstrated that we can remove things from the
> language.
>
> /Joe
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| fredrik.linder at cellpoi |
| Posted: Wed Oct 22, 2003 12:13 pm |
|
|
|
Guest
|
This sounds like an excellent proposal!
/Fredrik
> -----Original Message-----
> From: owner-erlang-questions_at_erlang.org
> [mailto:owner-erlang-questions_at_erlang.org]On Behalf Of Joe Armstrong
> Sent: den 22 oktober 2003 13:27
> To: erlang-questions_at_erlang.org
> Subject: Language change proposal
>
>
>
> Hi everybody - I'd like to propose the following language change:
>
> (It's *very* easy to implement)
>
> I want all Erlang modules to be tagged with a "language version"
>
> Like this ...
>
> ------------------------------------------------------------------------
>
> Suppose the next version of Erlang is 5.3 then:
>
> 1) All modules *must* start
>
> -module(XXXX).
> -vsn("5.3").
>
> 2) Any module *without* a version is assumed to be "5.2"
>
> 3) If there is no version the compiler should complain like hell
> with a warning that cannot be turned off that an explicit
> language
> version is not present.
>
> 4) There should be files called "depreciated_5.3.{erl,txt}"
> that tell the user what language language features and library
> routine have been depreciated in version 5.3
>
> The text file should describe the depreciated features.
>
> The Erlang file can be used by the compiler to provide
> warnings about
> depreciated features.
>
>
> Then - somewhat later - when we change to version 5.4
>
> The same rules apply - with one exception - warnings issued about
> depreciated constructs in 5.3 now become hard errors - and there is no
> way to turn off this behaviour.
>
> -------------------------------------------------------------------------
>
> Versions should be numbered X.Y.Z
>
> Bumping X is done for syntax changes to Erlang, or changes in the
> semantics if BIFs etc. (serious things).
>
> Bumping Y is done for depreciated library functions bug fixes
> in libraries
>
> Bumping Z is done for cosmetic reasons
>
> --------------------------------------------------------------------------
>
> *******
> * Why *
> *******
>
> We need enforceable mechanisms to *remove* things from the Erlang
> libraries and from the language.
>
> Erlang is getting bigger and things are not being removed.
>
> As regards customers who crave backwards compatibility tell them that
> if they want to use the new stuff they will have to change their code.
>
> The version that they used in their products should always be
> supported into the future - but the cost of doing so should increase
> as you bump the version numbers.
>
> This is *exactly* what the chip manufacturers do - have you ever
> tried to buy "old" memory chips - they cost a fortune !!!!
>
> IMHO their should be no language changes until it can be
> realistically demonstrated that we can remove things from the
> language.
>
> /Joe
>
>
>
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| D.WILLIAMS at csee-transp |
| Posted: Wed Oct 22, 2003 12:27 pm |
|
|
|
Guest
|
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.
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).
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.
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]).
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.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| lennart.ohman at st.se |
| Posted: Wed Oct 22, 2003 12:38 pm |
|
|
|
Guest
|
Not a bad idea. But I suggest another attribute since "vsn" is
already in use by OTP release handler.
-erts_vsn("5.3")
/Lennart
Fredrik Linder wrote:
> This sounds like an excellent proposal!
>
> /Fredrik
>
>
>>-----Original Message-----
>>From: owner-erlang-questions_at_erlang.org
>>[mailto:owner-erlang-questions_at_erlang.org]On Behalf Of Joe Armstrong
>>Sent: den 22 oktober 2003 13:27
>>To: erlang-questions_at_erlang.org
>>Subject: Language change proposal
>>
>>
>>
>>Hi everybody - I'd like to propose the following language change:
>>
>>(It's *very* easy to implement)
>>
>>I want all Erlang modules to be tagged with a "language version"
>>
>>Like this ...
>>
>>------------------------------------------------------------------------
>>
>> Suppose the next version of Erlang is 5.3 then:
>>
>> 1) All modules *must* start
>>
>> -module(XXXX).
>> -vsn("5.3").
>>
>> 2) Any module *without* a version is assumed to be "5.2"
>>
>> 3) If there is no version the compiler should complain like hell
>> with a warning that cannot be turned off that an explicit
>>language
>> version is not present.
>>
>> 4) There should be files called "depreciated_5.3.{erl,txt}"
>> that tell the user what language language features and library
>> routine have been depreciated in version 5.3
>>
>> The text file should describe the depreciated features.
>>
>> The Erlang file can be used by the compiler to provide
>>warnings about
>> depreciated features.
>>
>>
>> Then - somewhat later - when we change to version 5.4
>>
>> The same rules apply - with one exception - warnings issued about
>>depreciated constructs in 5.3 now become hard errors - and there is no
>>way to turn off this behaviour.
>>
>>-------------------------------------------------------------------------
>>
>> Versions should be numbered X.Y.Z
>>
>> Bumping X is done for syntax changes to Erlang, or changes in the
>>semantics if BIFs etc. (serious things).
>>
>> Bumping Y is done for depreciated library functions bug fixes
>>in libraries
>>
>> Bumping Z is done for cosmetic reasons
>>
>>--------------------------------------------------------------------------
>>
>> *******
>> * Why *
>> *******
>>
>> We need enforceable mechanisms to *remove* things from the Erlang
>>libraries and from the language.
>>
>> Erlang is getting bigger and things are not being removed.
>>
>> As regards customers who crave backwards compatibility tell them that
>>if they want to use the new stuff they will have to change their code.
>>
>> The version that they used in their products should always be
>>supported into the future - but the cost of doing so should increase
>>as you bump the version numbers.
>>
>> This is *exactly* what the chip manufacturers do - have you ever
>>tried to buy "old" memory chips - they cost a fortune !!!!
>>
>> IMHO their should be no language changes until it can be
>>realistically demonstrated that we can remove things from the
>>language.
>>
>> /Joe
>>
>>
>>
>
>
--
-------------------------------------------------------------
Lennart Ohman phone : +46-8-587 623 27
Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735
Sehlstedtsgatan 6 fax : +46-8-667 8230
SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman_at_st.se
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joe at sics.se |
| Posted: Wed Oct 22, 2003 2:02 pm |
|
|
|
Guest
|
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
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mine. |
| Posted: Wed Oct 22, 2003 4:27 pm |
|
|
|
Guest
|
On Wed, 22 Oct 2003 13:26:30 +0200 (CEST)
Joe Armstrong <joe_at_sics.se> wrote:
>
> Hi everybody - I'd like to propose the following language change:
>
> (It's *very* easy to implement)
>
> I want all Erlang modules to be tagged with a "language version"
>
> Like this ...
>
> ---------------------------------------------------------------------
> ---
>
> Suppose the next version of Erlang is 5.3 then:
>
> 1) All modules *must* start
>
> -module(XXXX).
> -vsn("5.3").
It's a good idea, but wouldn't it be easier to write code that works on
different versions if it was done with macros, e.g.
-ifdef(?ERLANG_5_3).
% some code that uses bleeding-edge features here
-else.
-ifdef(?ERLANG_5_2).
% some code that uses 5.2-isms here
-else.
% some code that is dangerously language-version-unspecific here
-endif.
-endif.
I think this would be the way to go if you wanted to write code that
takes advantage of new features while still being able to compile and
run on older installations.
Even slicker would be if there was a single ?ERLANG_VERSION predefined
macro, and a way to check its value with conditional compilation.
Nothing earthshatteringly new, of course (are we finally catching up to
cpp? :)
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| thomasl_erlang at yahoo.c |
| Posted: Wed Oct 22, 2003 7:23 pm |
|
|
|
Guest
|
--- Joe Armstrong <joe_at_sics.se> wrote:
>
> Hi everybody - I'd like to propose the following
> language change:
>
> (It's *very* easy to implement)
>
> I want all Erlang modules to be tagged with a
> "language version"
>
> Like this ...
>
>
------------------------------------------------------------------------
>
> Suppose the next version of Erlang is 5.3 then:
>
> 1) All modules *must* start
>
> -module(XXXX).
> -vsn("5.3").
>
> 2) Any module *without* a version is assumed
> to be "5.2"
Since -vsn is already in use, as Lennart noted, how
about introducing
-module(XXXX, ERL_VSN).
with a release-dependent macro ?LATEST for
convenience, e.g.,
-module(lists, ?LATEST).
The advantage: if all future Erlang versions agree to
begin all modules with a -module(..., ...)
attribute, then the system can select the parser and
tokenizer to be used at that point.
Having a floating -vsn attribute is less convenient,
or so it seems to me.
Also, I think it would be a good thing to have a
language release, ie, a definition of what things
mean, associated with each language version.
<http://www.erlang.org/ml-archive/erlang-questions/200310/msg00118.html>
Best,
Thomas
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joachim.durchholz at web. |
| Posted: Wed Oct 22, 2003 11:03 pm |
|
|
|
Guest
|
Chris Pressey wrote:
> It's a good idea, but wouldn't it be easier to write code that works on
> different versions if it was done with macros, e.g.
>
> -ifdef(?ERLANG_5_3).
> % some code that uses bleeding-edge features here
> -else.
> -ifdef(?ERLANG_5_2).
> % some code that uses 5.2-isms here
> -else.
> % some code that is dangerously language-version-unspecific here
> -endif.
> -endif.
Most definitely *no*.
I have maintained C code that went like this; it was a nightmare. The
reason was that it offered too many opportunities for "clever writing"
like this:
if (normal condition) {
...
#ifdef VERSION = xxx
...
} else {
...
#else
...
} else {
...
#endif
...
}
You can't even properly do indentation...
However, there's one thing that /could/ be done: add an erlang_version
predicate that's guaranteed to be evaluated at compile time. Also, add
some rules about compile-time evaluation for expressions "known to be
constant" (these can be very simplicistic, look at the rules for Turbo
Pascal, for example).
With that, you can write stuff like (excuse the non-Erlang syntax here,
I've still not gotten around to making my ankles wet...)
if erlang_version = "5_3"
% some code that uses bleeding-edge features here
else
if erlang_version = "5_2"
% some code that uses 5.2-isms here
else
some code that is dangerously language-version-unspecific here
endif
endif
Regards,
Jo
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| spearce at spearce.org |
| Posted: Thu Oct 23, 2003 12:19 am |
|
|
|
Guest
|
Although a very slick idea, I think it would lead to much confusion
about why code was eliminated from the if statement. Reading that
code one might reasonably expect to be able to compile it with version
5_3 and have it run the first group on 5_3, but the same module binary
would use different code on 5_2. Too confusing.
If an application really MUST split into different code based on
different language versions, use different 'inner' modules.
Define functions in those modules which implement the given required
feature X on each language version, or have feature X throw/exit an error if
the platform cannot perform it.
Each 'inner' module can get compiled with the proper version(s) of
language, runtime, 3rd party libs, etc. The more generic code
which doesn't care about versions can be compiled with the most
current, and get warnings/deprecation errors as necessary.
I liked the
-module(mod, "5.3").
syntax, as it offers a nice way to determine the "format" of the file before
any other attributes might be set. This might help an attribute linter, etc.
It would also be nice to be able to do:
-module(mod).
and:
erlc -assume_version 5.3 *.erl
to compile across an entire project without needing to set the version in
every header. But really I think that putting the version number in all
new files, and having the compiler assume 5.2 for those that don't have a
version number is reasonable. How hard is it really to put the version
number of the langauge / runtime you are targeting into the header of a module
when you write that module? It certainly makes it clear what might be the
required version to make the silly thing work properly.
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. If version 6.8 of stdlib is
loaded, but it understands the 5.3 calls, then all is good. If however
the currently loaded version of stdlib (6. does not understand 5.3 calls
then the code server should refuse to load this module. (It might have
loaded it, checked M:module_info/1, then unloaded it when discovering
this problem.)
This would let a developer concisely code his expectations about the
versions of things he/she is using within their code, and make that
available to the OTP release handler, as well as linters, etc.
Joachim Durchholz <joachim.durchholz_at_web.de> wrote:
> However, there's one thing that /could/ be done: add an erlang_version
> predicate that's guaranteed to be evaluated at compile time. Also, add
> some rules about compile-time evaluation for expressions "known to be
> constant" (these can be very simplicistic, look at the rules for Turbo
> Pascal, for example).
>
> With that, you can write stuff like (excuse the non-Erlang syntax here,
> I've still not gotten around to making my ankles wet...)
>
> if erlang_version = "5_3"
> % some code that uses bleeding-edge features here
> else
> if erlang_version = "5_2"
> % some code that uses 5.2-isms here
> else
> some code that is dangerously language-version-unspecific here
> endif
> endif
>
> Regards,
> Jo
>
--
Shawn.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mine. |
| Posted: Thu Oct 23, 2003 12:59 am |
|
|
|
Guest
|
On Thu, 23 Oct 2003 01:03:23 +0200
Joachim Durchholz <joachim.durchholz_at_web.de> wrote:
> Chris Pressey wrote:
> > It's a good idea, but wouldn't it be easier to write code that works
> > on different versions if it was done with macros, e.g.
> > [...]
>
> Most definitely *no*.
> I have maintained C code that went like this; it was a nightmare. The
> reason was that it offered too many opportunities for "clever writing"
> like this:
>
> if (normal condition) {
> ...
> #ifdef VERSION = xxx
> ...
> } else {
> ...
> #else
> ...
> } else {
> ...
> #endif
> ...
> }
Well, you don't have to worry about that, since you can't write that
kind of code in Erlang. -ifdef() and friends cannot appear inside a
function definition.
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vlad_dumitrescu at hotmai |
| Posted: Thu Oct 23, 2003 6:37 am |
|
|
|
Guest
|
From: "Shawn Pearce" <spearce_at_spearce.org>
> If an application really MUST split into different code based on
> different language versions, use different 'inner' modules.
> Define functions in those modules which implement the given required
> feature X on each language version, or have feature X throw/exit an error if
> the platform cannot perform it.
I think this might be nicest, but it is a matter of taste.
> 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.
regards,
Vlad
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Chandrashekhar.Mullaparth |
| Posted: Thu Oct 23, 2003 12:21 pm |
|
|
|
Guest
|
Hi,
> -----Original Message-----
> From: Joe Armstrong [mailto:joe_at_sics.se]
> Sent: 22 October 2003 12:27
> To: erlang-questions_at_erlang.org
> Subject: Language change proposal
>
>
>
> Hi everybody - I'd like to propose the following language change:
>
> (It's *very* easy to implement)
>
> I want all Erlang modules to be tagged with a "language version"
>
> Like this ...
>
> --------------------------------------------------------------
> ----------
>
> Suppose the next version of Erlang is 5.3 then:
>
> 1) All modules *must* start
>
> -module(XXXX).
> -vsn("5.3").
I don't know how useful this will be. Isn't it enough if we extend the
syntax of the .app file to specify this. After all, the smallest component
which is *shipped* is an application.
{application, Application,
[{description, Description},
{vsn, Vsn},
{id, Id},
{modules, [Module1, .., ModuleN]},
{maxT, MaxT},
{registered, [Name1, .., NameN]},
{applications, [Appl1, .., ApplN]},
{included_applications, [Appl1, .., ApplN]},
{env, [{Par1, Val1}, .., {ParN, ValN}]},
{mod, {Module, StartArgs}},
{start_phases, [{Phase1, PhaseArgs1}, .., {PhaseN, PhaseArgsN}]}]}.
We can include an extra tag here which specifies the version of ERTS
required. This should be optional.
As in
{erts_vsn, ErtsVsn}
where ErtsVsn = {minimum, "5.3"} | {only, "5.3"} ??
The .rel file already requires that the version of ERTS be specified and is
strictly enforced when a system is being built.
In another email, you wrote:
> 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 ...
I can't comment about clear case, but in CVS, if the version in the module
is specified as
-vsn('$Id: $ ').
When the code is checked in, the $Id: $ is translated to
-vsn('$Id: dl_parse.erl,v 1.10 2003/06/19 10:58:32 chandru Exp $ ').
which is visible in dl_parse:module_info().
5> dl_parse:module_info().
[{exports,[{is_vcard,1},
{parse_vcard,1},
{parse_command,1},
{many_to_rest,1},
{module_info,0},
{module_info,1}]},
{imports,[]},
{attributes,[{author,[chandru_at_tiger]},
{vsn,['$Id: dl_parse.erl,v 1.10 2003/06/19 10:58:32 chandru
Exp $ ']}]},
{compile,[{options,[v3]},{version,"4.1"},{time,{2003,10,23,11,54,5}}]}]
cheers
Chandru
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| spearce at spearce.org |
| Posted: Fri Oct 24, 2003 12:01 am |
|
|
|
Guest
|
Vlad Dumitrescu <vlad_dumitrescu_at_hotmail.com> 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.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| ok at cs.otago.ac.nz |
| Posted: Fri Oct 24, 2003 2:43 am |
|
|
|
Guest
|
Chris Pressey <cpressey_at_catseye.mine.nu> suggested:
It's a good idea, but wouldn't it be easier to write code that works on
different versions if it was done with macros, e.g.
-ifdef(?ERLANG_5_3).
[snip]
-endif.
I think this would be the way to go if you wanted to write code that
takes advantage of new features while still being able to compile and
run on older installations.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH!
Someone please tell me this was a late April Fools' joke?
If would be nice if people finally understood why the Ada requirements
explicitly required that there *NOT* be a preprocessor or conditional
compilation facility...
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
|
|
All times are GMT
Page 1 of 4
Goto page 1, 2, 3, 4 Next
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
