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

[Paul Bone]

On Tue, Sep 09, 2014 at 05:18:16PM +1000, Julien Fischer wrote:
>
> Hi,
>
> I think that it would be useful if obsolete pragmas optionally allowed a second
> argument that contained a user-defined message that could extend the warning
> message that they generate.  For example, instead of just:
>
>     foo.m: 561: Warning: call to obsolete predicate `bar.baz'/2.
>
> We could instead generate:
>
>     foo.m: 561: Warning: call to obsolete predicate `bar.baz'/2.
>     foo.m: 561: Use predicate `bar.baz_to_int'/2 instead.
>
> The extended variant of the pragma would look something like:
>
>     :- pragma obsolete(bar.baz/2, "Use predicate `bar.bat_to_int'/2 instead.").
>
> 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.")]).
>
> (3) obviously provides more control over the eventual output, but is also more
> complicated for users.  (For (1) and (2) the strings would just be turned into
> error_util words/1 components.)
>
> Comments?

We could support multiple options so that you have the flexability of
option 3.  But so that users can trivially just put a string there and move
on with their lives.  For example.  first try parsing the argument as a
string, and if that fails then try parsing it as a list of error_util items.

I"m not farmiliar with how the front end of the compiler works so parsing a
token into one of two types may be easier said than done.


-- 
Paul Bone