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

[Zoltan Somogyi]

On Tue, 9 Sep 2014 21:20:48 +1000, Mark Brown <mark at mercurylang.org> wrote:
> > 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.

If the second argument of the obsolete pragma is optional, as I think
it should be, then we are not asking them to; we are merely giving them
the ability to do so, if they wish.

> 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).

That is actually an argument for the greater flexibility of Julien's original
proposal: a human-written purpose-specific message could tell you EXACTLY
what the difference between "between" and "substring" was.

Peter: just because it is logical to look there, does not mean that people
actually will :-( If I had a dollar for every time I have watched as a student
in a lab class (for 252, 297 etc) looked at an error message from the
compiler that told him/her exactly what was wrong with their code,
but instead asked me, I would be a rich man. Granted this could
be taken as an argument that trying to enhance the error message
from obsolete pragmas would be futile, but I think we may be justified
in asking a *bit* more from Mercury programmers than from second
year students.

My vote is that we should support both (1) and (3). In answer to Paul's
question: it is quite easy for the parser to handle things which can be
either strings or lists.

As for what subset of format_components would be useful here:
I think we can start with words, fixed, quote, symname_and_arity,
suffix and nl. We can translate them to the error_util equivalents
when parsed, and if we ever find a need for format component
we don't yet support in obsolete declarations, it should be simple
to add one more arm to the string switch on the component name.

Internally, we could also store string second args of obsolete pragmas
using a words() wrapper, making the internal representation
uniform.

Zoltan.