Re: Proposal for a new Temporal time-measurement paradigm
Darren Duncan wrote: I think that the most thorough solution is to just take it for granted that there are multiple reference timelines/calendars and that in general it is impossible to reconcile them with each other. Taking this to its logical extreme, there might be a few (admittedly fringe) cases where someone might want a calendar that, even in principle, cannot be reconciled with anything else: consider someone who's writing an application that tracks events in a fantasy setting, such as the Lord of the Rings or the Wheel of Time. (Something like this actually occurred with a friend of mine, who's hobby is pen-and-paper roleplaying games; he wanted to build a database to track the events in his campaign, but ran into the problem that nothing allowed for the creation of a custom calendar such as the one in his fictional setting.) And so, what we can do in general is simply have an Instant role and a Duration role, and pairs of types where each member composes one of those, and then all that needs to exist for temporal routines is an independent collection for each pair that is closed within that pair. This is what I was trying to say. And where you _can_ convert between calendars, you can always write a type-casting routine that takes, say, a Julian Instant as an input and produces a Gregorian Instant as the output. Incidently, it might be possible for two calendar systems to share the same Duration implementation; IIRC, the Julian and Gregorian calendars both use the same concept of seconds, minutes, hours, etc. Likewise, a calendar system might end up with more than one type of Duration: it's always possible to convert between seconds, minutes, hours, days, and weeks; and its also always possible to convert between months, years, decades, centuries, and millenia; but it isn't always so easy to convert between days and years. I could see the Gregorian implementation having two kinds of Durations: short Durations that deal with everything from seconds to weeks, and long Durations that deal with everything from months to millennia. Similarly, there would be a calendar for I don't know what calendar, or varying degrees of such, which is often the case for dated historical records. With this, I'm not quite following you. Could you give an example of what you mean? What calendars/timelines are supported can be implementation-defined and/or provided by modules. Each Perl 6 implementation can be minimalist as far as composing classes go; just provide some programmatically readable way to discover what calendar the system uses so then modules can use that to decide how to make a particular calendar work on any system as possible. 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). -- Jonathan Dataweaver Lang
Re: Proposal for a new Temporal time-measurement paradigm
Jon Lang wrote: Darren Duncan wrote: I think that the most thorough solution is to just take it for granted that there are multiple reference timelines/calendars and that in general it is impossible to reconcile them with each other. Taking this to its logical extreme, there might be a few (admittedly fringe) cases where someone might want a calendar that, even in principle, cannot be reconciled with anything else: consider someone who's writing an application that tracks events in a fantasy setting, such as the Lord of the Rings or the Wheel of Time. (Something like this actually occurred with a friend of mine, who's hobby is pen-and-paper roleplaying games; he wanted to build a database to track the events in his campaign, but ran into the problem that nothing allowed for the creation of a custom calendar such as the one in his fictional setting.) Yes, and in a middle ground between fiction and modern records that we are reasonably confident about are historical records. For example, such-and-such happened during the wet season in the 14th year of so-and-so's reign. Often-times we don't know exactly when that was, or even if it was a true account, and so using a distinct reference calendar, say so-and-so's reign (actually further qualified), means we have a way of recording exactly what we know without degrading the information by forcing a conversion based on not well known information at the entry stage. And so, what we can do in general is simply have an Instant role and a Duration role, and pairs of types where each member composes one of those, and then all that needs to exist for temporal routines is an independent collection for each pair that is closed within that pair. This is what I was trying to say. And where you _can_ convert between calendars, you can always write a type-casting routine that takes, say, a Julian Instant as an input and produces a Gregorian Instant as the output. Yes, we seem to see eye-to-eye here. Incidently, it might be possible for two calendar systems to share the same Duration implementation; IIRC, the Julian and Gregorian calendars both use the same concept of seconds, minutes, hours, etc. Likewise, a calendar system might end up with more than one type of Duration: it's always possible to convert between seconds, minutes, hours, days, and weeks; and its also always possible to convert between months, years, decades, centuries, and millenia; but it isn't always so easy to convert between days and years. I could see the Gregorian implementation having two kinds of Durations: short Durations that deal with everything from seconds to weeks, and long Durations that deal with everything from months to millennia. Similarly, there would be a calendar for I don't know what calendar, or varying degrees of such, which is often the case for dated historical records. With this, I'm not quite following you. Could you give an example of what you mean? There are several variants of this. See also my first reply paragraph about the reign. For example, you could say that such-and-such happened in Summer of 1406, and you want to record it that way because that's exactly what you know the record says, and having to change this to a specific Gregorian month or day would actually be losing information because you would be claiming more detail as being a recorded fact when it actually isn't; so if someone just records in Summer ... then someone looking at it can know better how sure we are or aren't about something. This isn't to say that we couldn't also record July of 1406 as a separate related datum, but then the latter would be explicitly annotated as being a shoehorning guess to make some kinds of operations easier, but the other Summer ... is all that we actually know. Or, say we have a date saying this was at 6:37am on March 1st of 1887; however, we may not know if they are talking about the Julian or the Gregorian calendar, and so we can't just fix the date into one of those calendars; rather we have to fix it to I believe it is either Julian or Gregorian but I don't know which, which is a distinct calendar. Ultimately a system for handling data should be accurate in clarifying what it does or doesn't know, and only claim exactly what it knows and no more. It needs to be able to distinguish knowing for a fact that something occurred at a specific hour and minute of a specific day on a specific calendar, with considering that information to be more of a guess that they aren't so sure about. Then, say if one wants to compile records and solve a problem, they can give greater weight regarding details to the records that claim to be more certain about what they are saying versus those that claim to be guesses. It can be possible to represent degrees of certainty using different calendars. I'm not really talking about significant figures here like with measuring; what I'm talking about goes a lot deeper than that.
Re: Proposal for a new Temporal time-measurement paradigm
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.
Re: Proposal for a new Temporal time-measurement paradigm
On Sun, Apr 25, 2010 at 00:46, Darren Duncan dar...@darrenduncan.netwrote: 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. -- Jan
Re: Proposal for a new Temporal time-measurement paradigm
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
Re: Proposal for a new Temporal time-measurement paradigm
Jan Ingvoldstad wrote: On Sun, Apr 25, 2010 at 00:46, Darren Duncan dar...@darrenduncan.netwrote: 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
Re: Proposal for a new Temporal time-measurement paradigm
At 21:09 -0700 4/23/10, Darren Duncan wrote: I think that the most thorough solution is to just take it for granted that there are multiple reference timelines/calendars and that in general it is impossible to reconcile them with each other. At 15:46 -0700 4/24/10, Darren Duncan 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(). At 19:25 -0400 4/24/10, Mark J. Reed wrote: Absolutely ridiculous. The Gregorian calendar is in universal use for civil purposes and definitely belongs in the core. Please accept a plug for Darren. With all of the political and religious problems associated with calendars I would really like to see perl step aside and do ALL of that in modules or perhaps with use of libraries and methods provided by the operating system in which perl is a current process. Atomic seconds per mean solar day is not a constant and might be changed by political action. Mean solar days per year is determined by your God who tells the earth how fast to spin. Ditto for atomic seconds per year. Days in a month is so screwed up that folks argue about age of children when qualifying for benefits. Please just give up and get perl 6 running without trying to lead the world. Make it easy to set up optional schemes as particular users require. Use the epoch as defined in the operating system or, if undefined, use the start of 1970. You could take the instant of perihelion in what Gregorian people think was 1970 years after some important instant. Well, perhaps is was 1969 years if was Roman numeral I. Do everything in a way totally independent of earthly coordinates of the computer in use. But do assume it's motionless with respect to Earth in a 1 g field perhaps at Greenwich UK or Fort Collins CO. Agree on a format for storing fractional atomic seconds. There are proposals for two word integers with one of them being micro or nano seconds and the other seconds. I prefer IEEE floating point with atomic seconds as the unit of measure. That's a bit like MS Excel where days are used for the unit. The Excel scheme is not as clean because it assumes 86400 seconds in a day and it's a day off between what it thinks was Feb 29, 1900 and its epoch at the start of 1900. In any case users need a time value that can be negative or large positive. It's OK to lose precision for time points a long way from the current epoch. Floating point handles that nicely. We really don't care what day of the week the big bang started on but we really would like to use whatever time system is standard to perl. We'd also like to record time differences between collisions in the new CERN accelerator or the arrival times of entangled photons. Easter is the first Sunday after the first full moon after the vernal equinox - - - except. Some pope ordered a calculation of the date for some 3000 years in advance. He blessed the result. So the rule holds except for the mistakes made 1000 years ago. I learned that in 1961 which is the only year of error in my lifetime. Please don't ask perl 6 to pontificate on things like that. -- -- If you are presented a number as a percentage, and you do not clearly understand the numerator and the denominator involved, you are surely being lied to. --
