Mon, 16 Jun 2003 16:42:53 +0100
I finally took a look at the earlier discussions, and find that I stand by
the broad view I expressed before .
I think it is not the role of a "standard library" to be all applications,
but rather that it should aim to provide functionality that is useful to a
wide range of applications. Specialized applications are, well, special,
and their raison d'etre is to embody specialized domain knowledge in
executable form, while a general purpose language and libraries aims to
provide the means for expressing such embodiment. (This may be a
simplification, but I think the principle is fair.)
In particular, I think that calendar based scheduling (6:00PM local time on
the second Thursday of every month) is a specialized, if widely used, kind
of application. I don't think the common library should be trying to
support such functionality, if only because whatever semantics you choose,
you can be pretty certain it will be wrong for a signifcant number of
would-be users. What the standard library *can* do is provide tools that
specialized applications can use: for example, functions to convert
between Gregorian calendar dates and Julian dates are well-defined, and can
make a range of other, more specialized functions much easier to code. In
a similar vein, I think it's quite usual for people and applications to
deal with a day as a consistent time interval without concern for possible
leap seconds, so dealing with days as intervals of 24*60*60 seconds is
useful for a majority of applications that deal with such intervals. Thus,
allowing intervals to be expressed using days and sub-intervals, or seconds
and sub-intervals have roles in a supporting framework that can be used by
a variety of applications. In any redesign, I would suggest dropping the
redundant day-of-year and day-of-week values, replacing them with functions.
I assume there's no burning need for a redesign of this. There should come
a time, hopefully not too far away, when I'll be designing Haskell support
for aspects of RFC 2445-based calendar information expressed in RDF
. That would probably be a good time for me to consider a concrete
design and implementation. If there's consensus on a design, I think the
only tricky part of its implementation will be a dependable
Gregorian/Julian date conversion function, and I expect that already exists.
At 14:08 02/06/03 +0200, Ketil Z. Malde wrote:
>"Simon Peyton-Jones" <firstname.lastname@example.org> writes:
> >> I understand there's some history here, of which I'm not properly
> >> aware, so if this is merely rehashing old ground, please ignore.
>As someone who got entangled in this last time it was discussed (and
>the time before that), I can inform you that it has indeed been
>discussed a bit, and that you could probably search the archives
>profitably for ideas and thoughts on the matter.
>and (same thread, but broken up, due to broken mail headers):
> > Rather than try to fix it incrementally, I think it'd be most productive
> > if the interested parties simply got together and agreed an interface
> > for a new Time module, even if it's incompatible with the old one.
>Yes, definitely. Useful time/data module is probably best designed by
>somebody who actually *have* use for it.
>If I haven't seen further, it is by standing in the footprints of giants
PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E