[m-dev.] shims

[Mark Brown]

On Tue, Sep 16, 2014 at 10:43 AM, Paul Bone <paul at bone.id.au> wrote:
> On Mon, Sep 15, 2014 at 03:25:25PM +1000, Mark Brown wrote:
>> 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.
>>
>
> Eww.  Well I understand that this would be possible in this way but if I
> actually expect people to use it I think a nicer syntax would be best.
>
> Such as making it an (optional) part of module declrations.
>
> :- module my_module (2.3.1).

I also suggested 'feature' items, which might look nicer.

Versions are not always ordered linearly. You can get a version with
patch A, a version with patch B, then a version with both patches.

>
>
>> (You keep the earlier minor versions since these represent backwards
>> compatible changes, but you remove the earlier major version.)

... and in so doing, you indicate directly what changes are backwards
compatible without relying on any conventions regarding numbering
schemes.

Cheers,
Mark.