[m-rev.] for review: specialize all calls to {string,io}.format

Zoltan Somogyi zoltan.somogyi at runbox.com
Fri Nov 21 10:59:45 AEDT 2014


For review by anyone.

I would like the review to look at the following issues in particular,
each marked by an XXX in the code.

Should we implicitly import string.format.m and string.parse_util.m
(the two modules needed by the specialization of calls to string.format
and io.format) in all modules? In all modules that import string.m?
Or just the modules that may call a format predicate, as in this diff?

We didn't specialize calls to stream.string_writer.format before
this diff, and we don't after. I think it should be simple to implement,
but I don't want to do it without meaningful tests. At the moment,
the test suite has only one test of that function, and it is trivial.
Does anyone have any code that could be used as a more substantial test?

Should we add a nonempty_list type to library/list.m? We already have
such an inst, and we have the equivalent type one_or_more in the compiler.
Or should we add a version of maybe_error in which the error alternative
lists one or more errors?

As for whether the compiler should , by default,print more than one
error message for one call to a format predicate, I think we will need
to see the second (and maybe later) messages from real, non-test errors
to see whether they are useful or misleading.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.format_call
Type: application/octet-stream
Size: 6989 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20141121/7d43963e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.format_call
Type: application/octet-stream
Size: 210124 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20141121/7d43963e/attachment-0001.obj>


More information about the reviews mailing list