[m-rev.] for review: reporting stats NOT to stderr

[Zoltan Somogyi]

On Mon, 8 Mar 2021 14:52:25 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > This diff makes the change only for the C backend. Would anyone
> > volunteer to make the change to for the C# and Java backends?
> 
> I will take a look at them.

Thanks for that, but you should wait until we resolve the issue below.

> > As long as the output is done by C code (as opposed to the C code
> > constructing a big string containing all the stuff to be output),
> > directing the output to a user-supplied io.text_output_stream requires
> > converting that text_output_stream to a value of the C "FILE *" type.
> > This requires access to the actual definition of the io.text_output_stream
> > type, which is private to io.m. We could export it to benchmarking.m,
> > but that is undesirable.
> 
> MR_file(*MR_unwrap_output_stream(Stream)) should do it.
> (That's what we currently do in a similar situation in browser/listing.m.)

I didn't know about that. This macro makes it feasible to keep the foreign
language code for report_*stats in benchmarking.m.

I will definitely add a comment to the private definition of the input_stream
and output_stream types about these macros.
 
> That said, I don't have any objections to do it the way you've done here
> either.

The current situation, where we have report_*stats defined in both
benchmarking.m (in impure form) and in io.m (in pure form) is *clearly*
not ideal. While report_*stats is not an *exact* fit for benchmarking.m,
since the info it provides can be used for purposes other than benchmarking
(especially when printing tabling stats), the fit is clearly better in benchmarking.m
than in io.m, so if we want to confine the report_*stats predicates to just
one library module, benchmarking.m gets my vote, which the macro above
makes possible, but only for C. Is there something that does the same
for C# and Java? (browser/listing.m of course does not use either.)

> Aside: perhaps we should consider deleting the impure versions of these
> operations?  They've not really been necessary since trace goals were
> added to the language.

I did add obsolete pragmas for them, though I commented them out
until the C# and Java versions could print to a non-stderr stream.
 
Thanks for the review.

Zoltan.