[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