[m-rev.] diff: fix .module_dep files
jonmmorgan at gmail.com
Wed Jul 23 00:59:29 AEST 2008
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
>>>>> was written out directly with `io.write', so the renaming changed the
>>>>> format, but the parser still expected the old spelling
>>>>> `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
>>>>> Fix the bug.
>>>>> Try to avoid a similar bug in another field.
>>>> That looks great; thanks Peter. However, "grep -w io.write make*.m"
>>>> five matches even after applying this diff. Will you please fix those as
>>>> And does anyone else know of any other cases where the compiler is
>>>> in the exact spelling of a function symbol to define part of a file
>>> 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).
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