Front page | perl.perl6.language |
Postings from April 2010
Jan Ingvoldstad wrote: > On Sun, Apr 25, 2010 at 00:46, Darren Duncan <darren@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 DuncanThread Previous | Thread Next