Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core.
On Saturday, April 24, 2010, Darren Duncan <dar...@darrenduncan.net> wrote: > I want to clarify that I currently believe that the Perl 6 core should only > include temporal roles and *no* temporal classes. So the Perl 6 core could > provide, say, 3 roles, Instant, Duration, and Calendar (or use some other > name for the last one). It would also provide now(), sleep(), and calendar() > routines that have signatures of Instant, Duration, and Calendar, > respectively, without necessarily being more specific. > > And so, what now() returns would then be entirely implementation-defined; all > Perl 6 guarantees is that now() would return some object that does Instant > but not what class that object is nor what any of its capabilities are. Each > Perl 6 implementation would be responsible for bundling at least one non-core > module of its own choice that provides a class for each of the 3 core roles, > such that now() can return something on that system. Or alternately, now() > doesn't actually have to work at all, say if this Perl is to run say on some > embedded system all of whose programs don't need a clock, in which case no > implementing classes are bundled. > > The Calendar role would be the role composed by values that you get from > introspecting the return value of now() so that you know in a more generic > sense what that Instant-doing object is capable of. You could consult > calendar() to introspect what classes now() and sleep() use and know about > how to interpret them. > > 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(). > > -- Darren Duncan > > Darren Duncan wrote: > > Jon Lang wrote: > > We _should_ define a "default calendar", which is the one that Perl > uses when returning values from now(), etc. That is, Perl 6.0.0 > should define the Instant and Duration roles as you outlined above, > plus a set of classes that implement those roles according to the > Gregorian calendar system. If you want to replace that with another > calendar system in your implementation of Perl, the language already > has the means of allowing you to do so (e.g., replacing &now with a > variant that returns a different type of Instant). > > > I am more on the fence in regards to default implementations of the roles. > > But I think that all the messy details of particular calendars, such as > Gregorian leap seconds and timezones etc, should not be bundled with Perl, > and be separate, where users can upgrade them separately independent of Perl > as the measurements and political declarations come in. > > I still suggest just letting Perl itself be minimalist as far as providing > classes go, just say have a class representing a Unix et al timestamp that > directly corresponds to the implementation's time system, which differs per > OS, plus a means for a program to ask what the current OS's calendar is, and > then let separately distributed DateTime et al modules examine this and take > care of all the mapping. > > For example, Perl 6 should include the analogy of Perl 5's "time" but not an > analogy to "gmtime" or "localtime"; implementing the latter should be left > exclusively to separate modules. > > This fits in with a Perl philosophy of mainly sticking to being grammar and > letting CPAN/etc be the language, especially where complexity comes in. > > It also means that temporal modules can be bundled with Perl, but that is a > choice made by the Perl packagers, not the Perl core, same as deciding what > templating or networking or database or whatever modules to bundle. > > > -- Mark J. Reed <markjr...@gmail.com>
