Time Resolution

[Seth Kurtzberg]

Ashley Yakeley wrote:

>In article <eg1xc2ovdt.fsf at frynseeik.ii.uib.no>,
> Ketil Malde <ketil+haskell at ii.uib.no> wrote:
>
>  
>
>>It would be nice if the interface was such that it didn't matter to
>>the user.  Couldn't it be an opaque type?  And does the resolution
>>have to be standardized?  Standardizing on picoseconds is probably
>>safe, but I think it would be better to be able to query about the
>>underlying clock resolution, instead of getting a long sequence of
>>non-significant digits.
>>    
>>
>
>Bear in mind that the time type might be used for time calculations 
>unrelated to the system clock. Whether or not we hide the constructor, I 
>think its internal resolution and general behaviour ought to be known 
>and platform-independent.
>  
>
I understand what Ashley is saying, but that type of calculation is very 
different from a calculation related to the system clock.

The choices that seem to be on the table here are flawed.  To force all 
time calculations to be no better than the system clock resolution is 
not sensible, for the reasons that Ashley states.  However, it is also 
not acceptable for a function to return an incorrect value for 
calculations involving the system clock.

If, say, I make two calls to read the current time, and both return the 
same value, what does that mean?  Clearly it doesn't mean that no time 
has passed.  It means that the clock hasn't ticked, but it provides no 
information about exactly what that means.  Does it mean that the 
elapsed time is less than a second?  A millisecond?  A microsecond?  
Without knowledge about the resolution of the system clock, there is no 
way to find out.

I think that this particular pair of birds can't be killed with one 
stone.  The system clock resolution is platform dependent, and this fact 
must be dealt with in a way that doesn't produce incorrect answers.  
Time values whose source is the system clock are different not only in 
resolution but also in kind.  As presented, the choice is between having 
a cripled library that is a slave to the system clock resolution, or 
having a useful computational capability for time but returning 
incorrect answers w.r.t. the system clock.

Clearly these are two different things.  The core of the time 
calculation can be shared by these two different types of time, but at 
the user level it needs to be clear whether a value is derived from the 
system clock, or is not.  I don't see any way around the need for a 
different interface for each.  The alternatives are unacceptable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/libraries/attachments/20050131/1926ba2a/attachment.htm