seth at cql.com
Mon Jan 31 05:06:55 EST 2005
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
>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
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...
More information about the Libraries