[m-rev.] for review: parsing .used files
Julien Fischer
jfischer at opturion.com
Tue Apr 20 17:09:24 AEST 2021
On Tue, 20 Apr 2021, Julien Fischer wrote:
>
> Hi Zoltan,
>
> On Mon, 19 Apr 2021, Zoltan Somogyi wrote:
>
>> 2021-04-19 16:35 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
>
>>>> + % Alternatively, the .used file could contain two terms, the
>>>> version
>>>> + % number info, and everything else. We could then select the
>>>> predicate
>>>> + % we use to read in everything else based on the version number.
>>>
>>> Using a separate initial term for the version number would be my
>>> preference.
>>
>> OK. This happens to be relevant right now, because since I sent that diff,
>> I have started work on changing how recompilation.usage.m works.
>> It has traditionally also interleaved (a) figuring out what information
>> should go into the .used file, and (b) actually writing it out. My current
>> incomplete diff changes this so that it first constructs a single term
>> that represents the information to be written out, and then just writes it
>> out.
>> This incomplete diff now bootchecks with one obvious exception:
>> since the code writing out .used files has switched to a new format
>> but the code reading them in hasn't, all the recompilation tests fail.
>>
>> The type that defines my proposed new file format is attached.
>> I think it is a reasonable compromise between the our needs
>> as compiler writers for expressive function symbol names,
>> without making those names too long when we have to look at
>> .used files themselves. (Neither of which users have to do.)
>> I look forward to your feedback on this design.
>
> I think that's fine. I would reorder the definitions so that
> the type used_classes/0 occurs immediately after used_file_items/0.
Nevermind that, I see the logic behind the ordering now.
Julien.
More information about the reviews
mailing list