[m-dev.] IL standard library problems

[Julien Fischer]

On Thu, 8 Nov 2007, Jonathan Morgan wrote:

> On Nov 7, 2007 7:35 PM, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>> On Wed, 7 Nov 2007, Jonathan Morgan wrote:
>>
>>> On Nov 7, 2007 4:42 PM, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>>> On Wed, 7 Nov 2007, Jonathan Morgan wrote:
>>>>> I have been trying to build the standard library in the IL grade
>>>>> again.  A few problems that I found:
>>>>>
>>>>> 1. There was a warning that variables weren't referenced for io.do_make_temp/3.
>>>>
>>>> A warning from what?  mmc, gcc ...?
>>>
>>> Sorry, that wasn't clear at all.  It was due to variables not being
>>> used in the foreign code, as the error below shows.  Easy to fix, but
>>> does halt the compilation of the standard library.
>>>
>>> io.m:9915: In the C# code for predicate `io.do_make_temp'/8:
>>> io.m:9915:   warning: variables `Dir, Prefix' do not occur in the C# code.
>>
>> As you say, easy to fix.
>>
>>>>> 2. Building the new pretty printer fails, because IL does not support
>>>>> mutable variables.  Is it necessary to support the new pretty printer
>>>>> for anything?
>>>>
>>>> The debugger uses it, but that doesn't work with the IL backend anyway.
>>>
>>> Should it be not included at all for grades without mutables, or
>>> should I just ignore this and fix the mutable problem when I have
>>> time?
>>
>> It depends on how you intend to fix it?
>
> Implement mutables for ILs.

I don't think implementing mutables for other backends, like the IL
backend, is worth it with the current implementation of mutables.

Mutables were originally intended to provide trailed global variables
with impure access methods for implementing constraint stores for
solvers.  Since the original implementation they have
been extended to support non-trailed mutables, attached to the
I/O state mutables, thread-local mutables, "constant" mutables,
atomic access in parallel grades etc.

The source-to-source transformation currently used to implement the
above is becoming increasingly creaky, e.g. trailed mutables that are
floats or non-word sized foreign types don't work properly in the hlc grades,
thread local mutables cannot be trailed, etc.

A better approach would be to support mutables directly in the HLDS,
MLDS, LLDS and not have the compiler implicitly generate foreign procs
all over the place.   In short, I think future work on mutables should
be directed in this direction rather than extending what is rapidly
becoming an unmaintainable mess, i.e. the current implementation.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------