[m-dev.] proposal: extension to pragma obsolete

[Mark Brown]

On Tue, Sep 9, 2014 at 6:20 PM, Julien Fischer <jfischer at opturion.com> wrote:
>
> On Tue, 9 Sep 2014, Paul Bone wrote:
>
>> On Tue, Sep 09, 2014 at 05:52:20PM +1000, Peter Wang wrote:
>>>
>>> On Tue, 9 Sep 2014 17:18:16 +1000 (EST), Julien Fischer
>>> <jfischer at opturion.com> wrote:
>>>>
>>>>
>>>> The main question I have is what should the second argument actually be.
>>>> There
>>>> are three proposals below: (1) use a string literal, (2) use a list of
>>>> string
>>>> literals or (3) make (some of) the functionality of the error_util
>>>> library
>>>> available so we can mark up the warning messages.
>>>>
>>>>      (1) :- pragma obsolete(bar.baz/2, "Use predicate `bar.baz_to_int'/2
>>>> instead.").
>>>>      (2) :- pragma obsolete(bar.baz/2, ["Use predicate",
>>>>           "`bar.baz_to_int'/2 instead"]).
>>>>      (3) :- pragma obsolete(bar.baz/2, [words("Use predicate"),
>>>> sym_name_and_arity("bar.baz_to_int", 2),
>>>>         words("instead.")]).
>>>
>>>
>>> I think it's unnecessary, as a comment on the predicate declaration is
>>> fine.  Otherwise my vote is for (1) literal string.
>>>
>>
>> Oh, I should have said.  I agree with Peter 1 is best as it's the easiest
>> to
>> use.
>
>
> My only issue with (1) is that while it's fine for short messages, it's
> going to get a bit messy for longer ones.

I think it's a lot to ask that users write consistent error messages.

Looking through a recent version of the library, there seems to be two
main cases for pragma obsolete: where a predicate or function is
replaced by something with identical semantics, and where it is
superseded by something with better semantics. Perhaps the pragmas
could be written with optional attributes covering these cases?
Name/arity references could then use the same syntax as in the first
argument. For example:

:- pragma obsolete(hash_table.new/3, [replaced_by(hash_table.init/3)]).
:- pragma obsolete(string.substring/3, [superseded_by(string.between/3)]).

These may well be more informative than the existing library comments
(I had to look closely to see that substring was *not* the same as
between).

Cheers,
Mark.