Jan Ingvoldstad wrote:
On Sun, Apr 25, 2010 at 00:46, Darren Duncan <dar...@darrenduncan.net>wrote:
All details specific to any calendar, including Gregorian, including
concepts like seconds or hours or days, should be left out of the core and
be provided by separate modules. Said modules can be self-contained, just
say using Perl's ordinary numeric and string types for internal
representation, and Perl's single core now() routine they can use to
determine the current datetime, and the module can introspect its result or
calendar() and figure out how to map that to the internal representation or
API it wants to use, as well as figure out the proper way to invoke sleep().
I think you're taking minimalism at least two steps too far; your bikeshed
has become too small to contain a bike.
A standard library can and should provide reasonable functionality.
We _know_ that the North-Western civilizations' common understanding of time
(calendars and time-of-day), as defined in various standards, are
fundamental to how we handle a lot of programming problems.
I don't see any good reason not to provide the basic functionality needed,
and especially not when it's already there.
Mark J. Reed wrote:
Absolutely ridiculous. The Gregorian calendar is in universal use for
civil purposes and definitely belongs in the core.
Just because things are practically universal or commonly used doesn't
necessarily mean they belong in the Perl 6 core.
Granted, many things that are commonly used do belong in the Perl 6 core, when
they are relatively simple such as basic generic numbers and strings and
collections.
But the Gregorian calendar and related matters are sufficiently complex that
they should be a non-core component, because both they are sufficiently complex
and because their definitions change frequently enough over time, and so they
should be free to be developed and updated independently of the Perl 6 core.
Case in point, see the Perl 5 DateTime module. This module is frequently
updated just for reasons of giving it an updated time-zone database or a
database of leap-seconds. It is also updated for other reasons.
Keeping these details out of the core frees them up to be easier to keep up to
date on a schedule independent of the Perl 6 core.
If anything, your argument about Gregorian being universal or common should be
an argument for Perl packagers to bundle Gregorian-knowledgeable temporal
modules, so that users get them by default. But then there would also be a
package-managing system for more easily keeping those non-core components
updated as new time-zone databases or leap-second measurements are made.
My argument still stands; it is better to not have Gregorian et al in the
language core, and rather it should be a recommended module for bundlers.
-- Darren Duncan
