[m-rev.] for review: parsing .used files

[Julien Fischer]

Hi Zoltan,

On Wed, 21 Apr 2021, Zoltan Somogyi wrote:

> 2021-04-20 17:02 GMT+10:00 "Julien Fischer" <jfischer at opturion.com>:
>> I suggest using a representation of timestampe based on Java's Instant
>> type (java.time.Instant).  That should cover all of the points above,
>> except readability.
>
> The documentation of java.time.Instant provided by the first few hits
> in ddg was spectacular in its uselessness.  My guess is that the getLong
> method gets the seconds since the epoch, but "documentation" such as
> "getLong(TemporalField field)	This method gets the value of the specified
> field from this instant as along (sic)" does not do anything to confirm this
> in my mind: what field is specified, what it is specified by, and what is
> the f*cking *meaning* of this field?

The word field has a different meaning in this context, namely:

     Date and time is expressed using fields which partition the time-line
     into something meaningful for humans

Examples of such fields are the year, epoch second, era, month and a bunch
of other things.
(See: https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoField.html)
You can also define your own fields if you invent your own calander or
something strange like that.

You do not need to use getLong() to retrieve the components of an
Instant; the methods getEpochSecond() and getNano() will suffice.

All of this is not particularly relevant to the question of how we
represent timestamps in Mercury and .used files.

>> In Mercury, that would be something like the following:
>>
>>     :- type timestamp
>>          --->   timestamp(
>>                     seconds :: int64,  % Seconds from the epoch.
>>                     nanos   :: uint32  % [0, 999,999,999]
>>                 ).
>>
>> where nanos is the number of nanoseconds further along the time line
>> from the seconds field.
>>
>> This will work with clocks of resolutions from a second down to
>> nanosecond resolution clocks (i.e it will be portable).
>> (I think ISO 8601 has readable represention of this format, e.g.
>> 2021-04-20T11:07:22.956087, but for this use case you could probably
>> just write the raw components of the timestamp and be done with it.)
>
> What I propose to do is to switch the timestamp representation
> to the one you have above *with* an additional field containing
> the current string representation of yyyy mm dd hh mm ss.
> For now, to make the transition simpler, the seconds and nanos
> will always be zeroes, and the checking code will pay attention
> to the string, as it does now. Then we can start writing out
> meaningful seconds and nanos (for which I think I will need help
> from you or Peter for the non-Unix, non-C backends), and later
> still, switch to using them to make decisions, keeping the string
> representation only as an aid to debugging the smart recompilation
> system itself.
>
> Any objections to this plan?

No, I think that's fine.

Julien.