[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