[m-rev.] for review: Define behaviour of string.to_char_list (and rev) on ill-formed sequences.
Julien Fischer
jfischer at opturion.com
Wed Oct 23 10:41:33 AEDT 2019
On Wed, 23 Oct 2019, Peter Wang wrote:
> On Wed, 23 Oct 2019 05:04:20 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>> This diff implements my proposal, and is for post commit review by Peter.
>>
>
>> diff --git a/NEWS b/NEWS
>> index 82bcaa356..a5e1c887a 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -231,6 +231,13 @@ Changes to the Mercury language:
>> predicates and/or functions that programmers should consider using
>> instead of the obsolete predicate or function.
>>
>> +* We have added an `obsolete_proc' pragma. While the `obsolete' pragma
>> + declares all modes of a predicate or function to be obsolete, the
>> + `obsolete_proc' pragma declares only one mode of a predicate or function
>> + to be obsolete. Like the updated version of the `obsolete' pragma,
>> + the `obsolete_proc' pragma may have a second argument naming one or more
>> + suggested replacements.
>> +
>> * The Java backend now supports defining foreign types as primitive Java
>> types.
>
> The way I understood your proposal was that `pragma obsolete' would
> accept either a NAME/ARITY specification or a NAME(MODES) specification,
> like `pragma type_spec' and the undocumented `pragma require_tail_recursion'.
While the inconsistency is not particularly desirable, I think that it's
preferable to move to the names obsolete_{proc,pred} as we should
probably also support obsolescenece pragmas for other entities aside
from predicates / procedures.
Julien.
More information about the reviews
mailing list