[m-dev.] shims
Mark Brown
mark at mercurylang.org
Mon Sep 15 15:25:25 AEST 2014
On Mon, Sep 15, 2014 at 12:05 PM, Paul Bone <paul at bone.id.au> wrote:
> Another option, although I think this is less acheiveable in the short term,
> is to require that all libraries provide semantic versioning, and that when
> you :- import_module you may specify a specific version, or use conditional
> compilation that's predicated on a library's version.
>
> :- if.
> :- import_module set ver(1.1).
>
> ... use the new feature in set 1.1
> :- else if.
> :- import_module set ver(1.0).
>
> ... write slower/longer code due to the unavailable feature.
> :- else.
> :- end if.
>
>
> About semantic versioning: http://semver.org/
>
This could already be done with the above proposal. The library author
exports some dummy definitions, e.g. for version 2.3:
:- type version_major_2.
:- type version_minor_1.
:- type version_minor_2.
:- type version_minor_3.
(You keep the earlier minor versions since these represent backwards
compatible changes, but you remove the earlier major version.)
Then the library user writes:
:- import_module set.
:- if.
:- type set.version_major_2.
:- then.
:- if.
:- type set.version_minor_3.
:- then.
% Use features added in 2.3.
:- else.
% Use features present in 2.0.
:- end_if.
:- else.
% Error if we don't have version 2.x.
:- end_if.
The version names don't have to follow any particular scheme.
If conditional compilation is adopted, it might make sense to allow items like:
:- feature feature_name.
which do nothing except add declare a name, but you could test for it
in the above fashion, and could even extend pragma require_feature_set
to look for these module qualified names.
Another useful item would be error/1, to provide a detailed compiler
message for unsupported branches.
Cheers,
Mark.
More information about the developers
mailing list