[m-rev.] for review: compile time evaluation of string.count_codepoints

[Julien Fischer]

On Tue, 17 Sep 2013, Peter Wang wrote:

>>> I don't like how brittle the recognition of known procedures is,
>>> so I suggest not adding to it without good reason.
>>>
>>
>> It isn't all that brittle is it?  I don't remember it being particularly
>> troublesome in the past.
>
> Ok, maybe not *so* brittle, but kind of brittle.  I mainly don't like
> that mode numbers could go out of sync by making a trivial change like
> reordering mode lines (fortunately rare).

I suppose if you really wanted to make it less brittle you could match
directly against the modes of the arguments.  Given that most of the
things we evaluate a compile time only have one mode (modulo
uniqueness), that's almost certainly overkill.

> In this case someone might decide to swap the function and predicate
> implementations for some unknown reason and that would break the
> optimisation, I think.

Swapping the order of the function and predicate implementations would
not affect anything.  The thing that would get you in trouble is if the
argument order of the predicate version were swapped, i.e. it became:

      count_codepoints(int::out, string::in)

For count_codepoints/2 I don't imagine we would ever make such a swap.
(The problem is of couse an issue for all non-unary functions that
also have a predicate version handled by compiler/const_prop.m.)

> Can you give an example of the code that benefits from the change?

That depends how you define "benefit".  My motivation for this was the
last branch of the switch in the body of the following function:

     locn_to_length(Locn) = Length
         (
             Locn = file_line_column(File, Line, Column),
             Length = ...
         ;
             Locn = file_line(File, Line),
 	    Length = ...
         ;
 	    Locn = non_specific,
             Length = 0
         ;
             Locn = builtin,
             Length = string.count_codepoints("(builtin)")
         ).

Cheers,
Julien.