[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