[m-rev.] diff: fix .module_dep files

[Jonathan Morgan]

On Wed, Jul 23, 2008 at 12:25 AM, Julien Fischer
<juliensf at csse.unimelb.edu.au> wrote:
> On Tue, 22 Jul 2008, Jonathan Morgan wrote:
>
>> On Tue, Jul 22, 2008 at 9:46 PM, Julien Fischer
>> <juliensf at csse.unimelb.edu.au> wrote:
>>>
>>> On Tue, 22 Jul 2008, Zoltan Somogyi wrote:
>>>
>>>> On 22-Jul-2008, Peter Wang <novalazy at gmail.com> wrote:
>>>>>
>>>>> The recent renaming of the constructor `no_foreign_export' to
>>>>> `contains_no_foreign_export' broke `.module_dep' files.  The offending
>>>>> field
>>>>> was written out directly with `io.write', so the renaming changed the
>>>>> file
>>>>> format, but the parser still expected the old spelling
>>>>> "no_foreign_export".
>>>>>
>>>>> `mmc --make' would then try to remake all the `.module_dep' files it
>>>>> couldn't parse, including modules whose source files we don't have at
>>>>> hand.
>>>>>
>>>>> compiler/make.module_dep_file.m:
>>>>>       Fix the bug.
>>>>>
>>>>>       Try to avoid a similar bug in another field.
>>>>
>>>> That looks great; thanks Peter. However, "grep -w io.write make*.m"
>>>> gives
>>>> five matches even after applying this diff. Will you please fix those as
>>>> well?
>>>> And does anyone else know of any other cases where the compiler is
>>>> depending
>>>> in the exact spelling of a function symbol to define part of a file
>>>> format?
>>>
>>> Extending the above search to the all the compiler modules shows that we
>>> are calling io.write in a bunch of other places as well, e.g. in ilasm.m
>>> I think we should avoid calling it in the compiler except in debugging
>>> code.  I suggest we add something along those lines to coding standard.
>>
>> I know the problems caused by io.write with formats changing, but I
>> suspect that they don't apply to ilasm.  As far as I can tell, ilasm
>> is using io.write for constants, string literals, and similar, all of
>> which can save work without problems, since it is writing it out to an
>> external format that isn't going to change on a whim.
>>
>> It seems to me that things like
>>
>> :- type call_kind
>>   --->    default
>>   ;       vararg
>>   ;       unmanaged_cdecl
>>   ;       unmanaged_stdcall
>>   ;       unmanaged_thiscall
>>   ;       unmanaged_fastcall.
>>
>> ...
>>
>> io.write(CallKind, !IO)
>>
>> make sense, since these types of things aren't ever going to change,
>
> One change that may be made types like this is to add a prefix to
> each constructor (this has been done for many other types in the
> compiler in the recent past; it makes tools like mtags work
> better).  Such a change applied here would break this code.

True.  However, I still think that functionality should come before
tools, and if I have functionality that is working now, why should I
change it to conform to a tool? (I hold this radical notion that tools
should conform to our needs rather than vice versa, though I'm aware
it can't always happen nicely).

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