[m-dev.] questions about grades

[Julien Fischer]

Hi,

On Tue, 23 Feb 2016, Peter Wang wrote:

> On Tue, 23 Feb 2016 11:10:29 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:

>> I know the .pregen grade component is not applicable to target languages
>> other than C. Which of the C#, Java and Erlang backends support .spf?
>
> None of them.
>
> As an aside, we can consider removing .spf.  64-bit platforms are much
> more common now, and on 32-bit platforms we reduce some of the overhead
> of boxed floats with float registers, and storing doubles unboxed in
> cells.

I'd support removing the .spf grades entirely -- the fact that floats
map down to different C types causes more complication than it's worth.
If we are to support single-precision floats in Mercury, they should be
present as an addtional builtin type.

>> 
>> Autoconfiguration detects whether we can use 0, 2, 3 or 4 low tag bits.
>> Does anyone we know of any platforms on which it detects 0 or 4? I don't.
>
> I don't.
>
>> The version of the grade we use for the link time check also records whether
>> --enable-new-mercuryfile-struct was given to configure, while user-visible
>> grades do not. (I expect this would make it difficult to do cross-compilation
>> when only one of the host and target want to specify it, with the current
>> system that is.)
>> 
>> What exactly do new mercuryfile structs do? The log message of the initial
>> commit is not that informative, and anyway, I expect that the capabilities
>> it enables would have changed, since the initial commit was in 2000.
>> Given that long history, why isn't it the default way to handle files,
>> or even the only way? Does anyone ever use it? If not, do we want to keep
>> supporting it?
>
> It is a vtable that allows the user to override the C functions called
> by the predicates in the io module, rather than always using the C stdio
> functions.
>
> I don't know if MC use it still.  extras/logged_output/logged_output.m
> uses it.
>
> Sometimes I have wanted such a facility but it needs to be the default,
> and I would change the implementation slightly.  The only downside I can
> think of is that it adds an extra level of indirection.

When it was last discussed (in 2005), the issue preventing it being made
the default was the nature of the performance impact (and the lack of
measurement thereof!)
See this thread: <http://www.mercurylang.org/list-archives/developers/2005-December/013894.html>

For me, the functionality of new-mercuryfile-struct has been mostly
subsumed by the new stream type classes anyway.

Julien.