[m-rev.] for review: Use a better algorithm for unwinding version_arrays.

[Julien Fischer]

On Tue, 9 Sep 2014, Paul Bone wrote:

> On Tue, Sep 09, 2014 at 03:17:15PM +1000, Julien Fischer wrote:
>>
>>
>> On Tue, 9 Sep 2014, Paul Bone wrote:
>>
>>> On Tue, Sep 09, 2014 at 02:47:58PM +1000, Julien Fischer wrote:
>>>> Hi Paul,
>>>>
>>>> On Tue, Sep 9, 2014 at 2:24 PM, Paul Bone <paul at bone.id.au> wrote:
>>>>
>>>>> On Thu, Aug 07, 2014 at 12:49:52PM +1000, Paul Bone wrote:
>>>>>> On Wed, Aug 06, 2014 at 02:27:37PM +1000, Peter Wang wrote:
>>>>>>> I think it would be better to update the C# backend at the same time.
>>>>>>> If you can't test it then make a best effort and post an updated patch,
>>>>>>> then I can fix any minor compilation problems.
>>>>>>>
>>>>>>
>>>>>> Right now I can't even run the mono compiler.  So I'll have to fix this
>>>>>> before I can make any reasonable amount of progress.
>>>>>>
>>>>>
>>>>> The RTS for the C# backend is organised differently from the other
>>>>> backends.
>>>>> It seems to be contained within one file runtime/mercury_dotnet.cs.  Or is
>>>>> it? is this file used by the C# backend or just the old .net backend?
>>>>>
>>>>
>>>> The runtime modules for the C# grade are included directly in the stdlib,
>>>> From library/Mmakefile:363:
>>>>
>>>>     # For C# we include the runtime module directly into mer_std.dll.
>>>>     ifneq ("$(filter csharp%,$(GRADE))","")
>>>>     LINK_LIB_OPTS :=
>>>>     MLOBJS += ../runtime/mercury_dotnet.cs
>>>>     endif
>>>>
>>>
>>> Would anyone object to me putting MercuryBitmap at
>>> library/csharp/MercuryBitmap.cs and adding it to MLOBJS here?
>>
>> Yes, I object.  If we are going to end up with multiple C# modules
>> forming part of the runtime / stdlib then they should be separated out
>> as per the Java backend.  Relying on developers to always update the
>> assignment to MLOBJS is very brittle.
>
> What's the difference between having to add an extra line to a Makefile or
> an :- import_module directive in a .m file?

I don't understand what you're trying to ask with that question.

> Since we use GNU make we could also avoid this totally by saying:
>
>    MLOBJS += ../runtime/mercury_dotnet.cs $(wildcard csharp/*.cs)

If you're going to do that you might as well build the C# version of the
runtime as a separate assembly (much as we build a separate .jar file
for Java backend.)

Also, under your scheme we now have (non-generated) C# source files
scattered through multiple directories.

>>> Other shared code that's not exactly runtime code could go into the same
>>> location.
>>>
>>> It seems to me that MercuryBitmap isn't runtime code because not all/most
>>> modules need it.
>>
>> The bitmap code for C backends lives in runtime/mercury_bitmap.[ch]; I
>> don't see that this situation is any different.  Just put it in
>> runtime/mercury_dotnet.cs.
>>
>
> Putting all the code in one file doesn't seem right to me.  MercuryBitmap
> doesn't call code in mercury_dotnet.cs, or vice-versa.  This is why I'd
> prefer seperate files.

Most of the code in mercury_dotnet.cs doesn't call other code in that
file.  The contents of that file are for the use of the standard library /
generated code.  I agree it would be cleaner to have it an separate
file, but things are not currently set up in such a way that will work.

Cheers,
Julien.