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

Jonathan Morgan jonmmorgan at gmail.com
Tue Jul 22 23:16:15 AEST 2008


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,
and it means that all these strings need only be written in one place
rather than two.

In the same way, formatting of string literals, numbers, etc. are
fairly standard across languages, so it seems to me it makes sense to
reuse it rather than writing it all over again.

I will admit that there may be some problems in general by using
io.write() for serialisation, but I think that there are also
significant advantages, especially in cases like ilasm.  It should
probably not be used as a serialisation mechanism, but can be used for
making the job of writing out text simpler and limiting duplication.

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
--------------------------------------------------------------------------



More information about the reviews mailing list