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

Julien Fischer jfischer at opturion.com
Sun Nov 30 18:36:55 AEDT 2014

Hi Zoltan,

On Sun, 30 Nov 2014, Zoltan Somogyi wrote:

> On Sun, 30 Nov 2014 17:31:37 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>>> 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?
>> I think what you have in this diff is fine.  The only issue, as I understand
>> it, is that you may unnecessarily implicitly import the above modules into a
>> module that defines its own predicates or functions named 'format'.  That seems
>> as though it would be (1) fairly rare and (2) harmless.
> I did it the way I did because it was the closest "cultural" fit to the
> other code that discovers the need for implicit imports. Actually, there
> is an argument against it. The cost of scanning for the need for implicit
> imports used to be checking a small and bounded number of things
> per item, but we now have to traverse every part of every clause, which
> (for large clauses) can be an arbitrarily higher amount of work.
> I would actually prefer the second solution, but post-processing the
> import list is tricky, since the code that handles imports is currently
> a mess.
>> I've had a look through the code that I have that uses streams and could not
>> find anything that would be useful as a test.  Even if such code existed I
>> don't think it would tell you anything useful anyway.  Code using streams is
>> almost always intended to be generic in the underlying stream and in the
>> absence of information about the relative costs of appending strings versus
>> method calls to 'put' for the _specific_ instance stream in question you cannot
>> decide between the two alternatives above.
> Do you have code that I can use as a more substantial test of correctness,
> even if it doesn't help decide which implementation approach to pick?

Looking through the libraries I have written that use streams I only
found two calls to string_writer.format.  I can construct an artifical
test case based on the tests we already have for string.format which
will probably more useful here.

One other thing: do you specialize format calls in debugging grades?


More information about the reviews mailing list