[m-rev.] for review: clean up string.m

[Zoltan Somogyi]

On Sun, 09 Nov 2014 15:24:55 +1100, Michael Day <mikeday at yeslogic.com> wrote:
> The sprintf comment was just wondering whether it might be useful to 
> keep a binding to the platform native sprintf call, and the new 
> string.format variant that is interpreted at compile-time could have an 
> entirely different format string syntax, as there would be no need to 
> maintain compatibility with printf, and indeed other popular languages 
> in common use today do not.

The basic problem with printf in C, and similar constructs in
other languages, has always been the potential for mismatches
between the format string and the supplied arguments.

Some recent languages have printing constructs that
make such mismatches intrinsically impossible. That is indeed
a worthwhile thing to aim for, but I don't think it would be worth it
for Mercury, for two reasons. First, in many cases where the format
string is statically visible to the compiler, we already check
for such mismatches and tell the user about them, and
with the work I am proposing, we should be able to do this
in ALL such cases. Second, these new printing constructs
can be better because they are built into the language;
they are NOT treated as just a call to a builtin function.
Adding such a construct to Mercury would be a huge
amount of work, for very little gain. In practical terms,
I don't see enough upside to adopting a different printing
mechanism to make it worthwhile. However, I could be
convinced if someone showed me a compelling use case
that cannot be handled with (simple extensions of) the
current Mercury formatting mechanism.

While Mercury picked printf format strings because
the original platform used printf, we now target several
platforms (Java, Erlang) that use different native
printing mechanisms. We already have code to
implement Mercury's format mechanisms over these;
changing the Mercury format specification would require
these to be reimplemented.

However, we could have predicates with names such as
string.format_compiled io.format_compiled that the compiler
would treat the same as string.format and io.format in terms of
generating warnings and compiling away the format string,
but whose implementations would do nothing except throw
an exception, and for which the compiler would generate
a compiler error if it couldn't compile them away.
Programmers could use these if they wanted to be sure that
their code did not incur any format string interpretation
overhead at runtime.

Zoltan.