[perl6/specs] 1735a4: [S32::Temporal] Change added Duration info to Inte...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 1735a4652b3885a13ce14c654af2a5b90c915bd0 https://github.com/perl6/specs/commit/1735a4652b3885a13ce14c654af2a5b90c915bd0 Author: lue rnd...@gmail.com Date: 2013-11-30 (Sat, 30 Nov 2013) Changed paths: M S32-setting-library/Temporal.pod Log Message: --- [S32::Temporal] Change added Duration info to Interval. Yes, we just made a brand new object. Some new issuess, including the start/end form of ISO 8601 intervals, Duration - Interval conversion (potentially), and describing Interval in other locations (such as S02) need to be taken care of. But it's a bit late for that for me :) . Also, Instant and Duration still need documenting in S32::Temporal, and what to do with the start/duration and duration/end interval forms (if anything).
[perl6/specs] b414bc: Revert [S32::Temporal] Expand valid ISO 8601 form...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: b414bc8681bd9cb5fcd9c1c220b751c12b590122 https://github.com/perl6/specs/commit/b414bc8681bd9cb5fcd9c1c220b751c12b590122 Author: Carl Masak cma...@gmail.com Date: 2013-12-01 (Sun, 01 Dec 2013) Changed paths: M S32-setting-library/Temporal.pod Log Message: --- Revert [S32::Temporal] Expand valid ISO 8601 formats. ISO 8601 is a good thing, but that does not mean *all* of it is a good thing. Specifiacally, allowing week specifications in the DateTime core will make the logic even more complicated than it already is, with extremely little benefit. This reverts commit 97c5bc4e47b819b640fc5f815b861d753ed8aa9c.
[perl6/specs] c32379: [S32::Temporal] Add Duration object.
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: c32379ef139b153bc380557935f87b09310cb98a https://github.com/perl6/specs/commit/c32379ef139b153bc380557935f87b09310cb98a Author: lue rnd...@gmail.com Date: 2013-11-30 (Sat, 30 Nov 2013) Changed paths: M S32-setting-library/Temporal.pod Log Message: --- [S32::Temporal] Add Duration object. Allows creation similar to DateTime objects and provides some accessor methods (the Duration in years, or days, etc.). Commit: 97c5bc4e47b819b640fc5f815b861d753ed8aa9c https://github.com/perl6/specs/commit/97c5bc4e47b819b640fc5f815b861d753ed8aa9c Author: lue rnd...@gmail.com Date: 2013-11-30 (Sat, 30 Nov 2013) Changed paths: M S32-setting-library/Temporal.pod Log Message: --- [S32::Temporal] Expand valid ISO 8601 formats. Temporal now specs support for almost the entire ISO 8601 range of formats. It almost feels like there should be a separate ISO 8601 header in this document :) . The only unmentioned piece of ISO 8601 is the interval specifiers, of which durations are a part. My suspicion is that: format... is usable in... begin/duration DateTime constructor duration/endDateTime constructor begin/end Duration constructor Where each constructor calculates the missing piece and uses that as a result (end date, start date, and duration, respectively.) Also missing is CInstant documentation, though I'm not sure what to do with that. Compare: https://github.com/perl6/specs/compare/2e989c7e21a9...97c5bc4e47b8
[perl6/specs] 5692ce: Updated Temporal reflecting Int-only Timezones.
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 5692ced3331ab763601c760572caa0febb650639 https://github.com/perl6/specs/commit/5692ced3331ab763601c760572caa0febb650639 Author: Timothy Totten 2...@huri.net Date: 2013-04-24 (Wed, 24 Apr 2013) Changed paths: M S32-setting-library/Temporal.pod Log Message: --- Updated Temporal reflecting Int-only Timezones.
[perl6/specs] 9d8bc5: [S32/Temporal] spec DateTime.delta and Date.delta
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 9d8bc5fe62dd38805d791c0351c85185d351290e https://github.com/perl6/specs/commit/9d8bc5fe62dd38805d791c0351c85185d351290e Author: Carl Masak cma...@gmail.com Date: 2013-01-24 (Thu, 24 Jan 2013) Changed paths: M S32-setting-library/Temporal.pod Log Message: --- [S32/Temporal] spec DateTime.delta and Date.delta Clarify the .truncated-to method as well; it also uses the CTimeUnit enum, instead of named parameters.
[perl6/specs] 331a25: [S32::Exception] make X::Temporal a role
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 331a251bbe1345f1916c548cdbe34674fd82e09f https://github.com/perl6/specs/commit/331a251bbe1345f1916c548cdbe34674fd82e09f Author: Moritz Lenz mor...@faui2k3.org Date: 2012-08-24 (Fri, 24 Aug 2012) Changed paths: M S32-setting-library/Exception.pod Log Message: --- [S32::Exception] make X::Temporal a role
[perl6/specs] 5994eb: [S32/Temporal] Graduated out of draft state and co...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 5994eb031d6d4da5f30aa7ecfd95d146944320b0 https://github.com/perl6/specs/commit/5994eb031d6d4da5f30aa7ecfd95d146944320b0 Author: Kodi Arfer hi...@thoth.(none) Date: 2010-11-29 (Mon, 29 Nov 2010) Changed paths: M S32-setting-library/Temporal.pod Log Message: --- [S32/Temporal] Graduated out of draft state and corrected my description of the offset method.
r31835 -[S32/Temporal] Specified how DateTime.new(Int) should interpret ambiguous input.
Author: Kodi Date: 2010-07-26 15:57:17 +0200 (Mon, 26 Jul 2010) New Revision: 31835 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Specified how DateTime.new(Int) should interpret ambiguous input. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-26 12:05:05 UTC (rev 31834) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-26 13:57:17 UTC (rev 31835) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 -Last Modified: 24 Jul 2010 -Version: 18 +Last Modified: 26 Jul 2010 +Version: 19 The document is a draft. @@ -75,7 +75,10 @@ my $now = DateTime.new(time); These two statements are equivalent except that Ctime doesn't know about -leap seconds or fractions of seconds. +leap seconds or fractions of seconds. Ambiguous POSIX times (such as +915148800, which could refer to 1998-12-31T23:59:60Z or +1999-01-01T00:00:00Z) are interpreted as non-leap seconds (so in this case, +the result would be 1999-01-01T00:00:00Z). Or you can use named arguments:
r31820 -[S32/Temporal] Fixed an inconsistency and uniquified a section title to avoid confusing smartlinks.pl.
Author: Kodi Date: 2010-07-25 01:41:01 +0200 (Sun, 25 Jul 2010) New Revision: 31820 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Fixed an inconsistency and uniquified a section title to avoid confusing smartlinks.pl. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-24 23:21:46 UTC (rev 31819) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-24 23:41:01 UTC (rev 31820) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 -Last Modified: 21 Jul 2010 -Version: 17 +Last Modified: 24 Jul 2010 +Version: 18 The document is a draft. @@ -199,14 +199,14 @@ The method Cwhole-second returns the second truncated to an integer. The CDate method returns a CDate object, and is the same as -CDate.new(|$dt.ymd). +CDate.new($dt.year, $dt.month, $dt.day). The method Coffset returns the object's current offset from UTC: if C$dt.timezone does CCallable, C$dt.offset is equivalent to C$dt.timezone($dt, True); otherwise, C$dt.offset returns C$dt.timezone as is. -=head1 Date +=head1 CDate CDate objects represent a day without a time component. Like CDateTime objects, they are immutable. They allow easier manipulation by assuming @@ -227,7 +227,7 @@ The constructors die with a helpful error message if month or day are out of range. -=head2 Accessors +=head2 Instance methods CDate objects support all of the following accessors, which work just like their CDateTime equivalents:
r31776 -[S32/Temporal] Make DateTime immutable.
Author: dolmen
Date: 2010-07-20 23:51:26 +0200 (Tue, 20 Jul 2010)
New Revision: 31776
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Make DateTime immutable.
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-20 21:11:32 UTC
(rev 31775)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-20 21:51:26 UTC
(rev 31776)
@@ -15,8 +15,8 @@
Created: 19 Mar 2009
-Last Modified: 15 Jul 2010
-Version: 14
+Last Modified: 20 Jul 2010
+Version: 15
The document is a draft.
@@ -67,7 +67,11 @@
=head1 CDateTime
A CDateTime object describes the time as it would appear on someone's
-calendar and someone's clock. You can create a CDateTime object from an
+calendar and someone's clock.
+
+CDateTime objects are immutables.
+
+You can create a CDateTime object from an
CInstant or from an CInt; in the latter case, the argument is
interpreted as POSIX time.
@@ -94,7 +98,11 @@
Another multi exists with CDate :date instead of C:year, C:month and
C:day (and the same defaults as listed above).
-All four of the aforementioned forms of Cnew accept two additional named
+A CDateTime can also be created by modifying an existing object:
+
+my $moonlanding_anniv = DateTime.new($moonlanding, :year(2010));
+
+All five of the aforementioned forms of Cnew accept two additional named
arguments. C:formatter is a callable object that takes a CDateTime and
returns a string. The default formatter creates an ISO 8601 timestamp (see
below). C:timezone is a callable object that takes a CDateTime to
@@ -178,38 +186,11 @@
C$dt.timezone($dt, True); otherwise, C$dt.offset returns
C$dt.timezone as is.
-=head2 Set methods
+The Ctruncate method returns a new object where a number of time values
+have been cleared below a given resolution:
-To set the the day of a CDateTime object to something, just assign to
-its public accessor:
+$dt2 = $dt.truncate( :tohour ); # clears minutes and seconds
-$dt.day = 15;
-
-The same methods exists for all the values you can set in the
-constructor: Cyear, Cmonth, Cday, Chour, Cminute, Csecond,
-Ctimezone and Cformatter. Also, there's a Cset method, which
-accepts all of these as named arguments, allowing several values to be
-set at once:
-
-$dt.set( :year(2014), :month(12), :day(25) );
-
-Just as with the Cnew method, validation is performed on the resulting
-values, and an exception is thrown if the result isn't a sensible date
-and time.
-
-If you use the Ctimezone public accessor to adjust the time zone, the
-local time zone is adjusted accordingly:
-
-my $dt = DateTime.new('2005-02-01T15:00:00+0900');
-say $dt.hour;# 15
-$dt.timezone = 6 * 60 * 60; # 6 hours ahead of UTC
-say $dt.hour;# 12
-
-The Ctruncate method allows you to clear a number of time values
-below a given resolution:
-
-$dt.truncate( :tohour ); # clears minutes and seconds
-
The time units are cleared in the sense that they are set to their
inherent defaults: 1 for months and days, 0 for the time components.
@@ -217,9 +198,6 @@
Monday of the week in which it occurs, and the time components are all
set to 0.
-For the convenience of method chaining, Cset and Ctruncate return the
-calling object.
-
=head1 Date
CDate objects are immutable and represent a day without a time component.
@@ -268,6 +246,8 @@
$d + 3 # Date.new('2010-12-27')
3 + $d # Date.new('2010-12-27')
+As temporal objects are immutable, += -= ... do not work.
+
=head1 Additions
Please post errors and feedback to Cperl6-language. If you are making
@@ -290,3 +270,4 @@
Daniel Ruoso dan...@ruoso.com
Dave Rolsky auta...@urth.org
Matthew (lue) rnd...@gmail.com
+Olivier Mengué dol...@cpan.org
Re: r31776 -[S32/Temporal] Make DateTime immutable.
On Tue, Jul 20, 2010 at 5:51 PM, pugs-comm...@feather.perl6.nl wrote: +CDateTime objects are immutables. + I think just the adjective works better here (are immutable)... but more to the point: +A CDateTime can also be created by modifying an existing object: It's mildly confusing to say they're immutable and then turn around and talk about modifying them. How about just saying that A new CDateTime can also be based on an existing CDateTime object: ? -- Mark J. Reed markjr...@gmail.com
r31777 -[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just implemente
Author: Kodi
Date: 2010-07-21 02:12:24 +0200 (Wed, 21 Jul 2010)
New Revision: 31777
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to
make a big change like this only after reaching some kind of consensus to do
so, not least because I just implemented a lot of mutating methods!
Note that += and friends need only the *container* on the LHS to be mutable,
not the value?\226?\128?\148'$x += 1' should be allowed whether $x holds an
Int, a Date, or a DateTime.
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-20 21:51:26 UTC
(rev 31776)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-21 00:12:24 UTC
(rev 31777)
@@ -16,7 +16,7 @@
Created: 19 Mar 2009
Last Modified: 20 Jul 2010
-Version: 15
+Version: 16
The document is a draft.
@@ -67,11 +67,7 @@
=head1 CDateTime
A CDateTime object describes the time as it would appear on someone's
-calendar and someone's clock.
-
-CDateTime objects are immutables.
-
-You can create a CDateTime object from an
+calendar and someone's clock. You can create a CDateTime object from an
CInstant or from an CInt; in the latter case, the argument is
interpreted as POSIX time.
@@ -98,11 +94,7 @@
Another multi exists with CDate :date instead of C:year, C:month and
C:day (and the same defaults as listed above).
-A CDateTime can also be created by modifying an existing object:
-
-my $moonlanding_anniv = DateTime.new($moonlanding, :year(2010));
-
-All five of the aforementioned forms of Cnew accept two additional named
+All four of the aforementioned forms of Cnew accept two additional named
arguments. C:formatter is a callable object that takes a CDateTime and
returns a string. The default formatter creates an ISO 8601 timestamp (see
below). C:timezone is a callable object that takes a CDateTime to
@@ -186,11 +178,38 @@
C$dt.timezone($dt, True); otherwise, C$dt.offset returns
C$dt.timezone as is.
-The Ctruncate method returns a new object where a number of time values
-have been cleared below a given resolution:
+=head2 Set methods
-$dt2 = $dt.truncate( :tohour ); # clears minutes and seconds
+To set the the day of a CDateTime object to something, just assign to
+its public accessor:
+$dt.day = 15;
+
+The same methods exists for all the values you can set in the
+constructor: Cyear, Cmonth, Cday, Chour, Cminute, Csecond,
+Ctimezone and Cformatter. Also, there's a Cset method, which
+accepts all of these as named arguments, allowing several values to be
+set at once:
+
+$dt.set( :year(2014), :month(12), :day(25) );
+
+Just as with the Cnew method, validation is performed on the resulting
+values, and an exception is thrown if the result isn't a sensible date
+and time.
+
+If you use the Ctimezone public accessor to adjust the time zone, the
+local time zone is adjusted accordingly:
+
+my $dt = DateTime.new('2005-02-01T15:00:00+0900');
+say $dt.hour;# 15
+$dt.timezone = 6 * 60 * 60; # 6 hours ahead of UTC
+say $dt.hour;# 12
+
+The Ctruncate method allows you to clear a number of time values
+below a given resolution:
+
+$dt.truncate( :tohour ); # clears minutes and seconds
+
The time units are cleared in the sense that they are set to their
inherent defaults: 1 for months and days, 0 for the time components.
@@ -198,6 +217,9 @@
Monday of the week in which it occurs, and the time components are all
set to 0.
+For the convenience of method chaining, Cset and Ctruncate return the
+calling object.
+
=head1 Date
CDate objects are immutable and represent a day without a time component.
@@ -246,8 +268,6 @@
$d + 3 # Date.new('2010-12-27')
3 + $d # Date.new('2010-12-27')
-As temporal objects are immutable, += -= ... do not work.
-
=head1 Additions
Please post errors and feedback to Cperl6-language. If you are making
Re: r31777 -[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just implem
pugs-comm...@feather.perl6.nl wrote: Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just implemented a lot of mutating methods! Note that += and friends need only the *container* on the LHS to be mutable, not the value?\226?\128?\148'$x += 1' should be allowed whether $x holds an Int, a Date, or a DateTime. Types representing temporal artifacts should *not* be mutable; they should be value types. If you want to derive a DateTime from another, say, then just have the pseudo-mutator method return a new object with the differences. -- Darren Duncan
Re: r31777 -[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to make a big change like this only after reaching some kind of consensus to do so, not least because I just impl
Well, then, let's start building that consensus. I firmly believe
DateTimes should definitely be value types, immutable. Otherwise you
can't use them for hash keys, for one thing.
Note that timestamps in Perl have always been values; it's just that
they used to be specifically integers, whose value-ness comes
automatically. You can't change the value of 1279682340; you can
change a variable to hold a different value instead of 1279682340, but
the integer itself hasn't changed. This may sound like a
philosophical point, but it's fundamental to the operation of
mathematics.
When you get into reference types you have to work harder to make an
object act like a value, but I think the effort is worth it in the
case of datelike objects. Even in languages that have mutable dates,
like Java, there are best practices guidelines that suggest using an
immutable representation instead (e.g.
http://www.javapractices.com/topic/TopicAction.do?Id=81). With Perl6
I'd rather get it right in the first place.
On Tue, Jul 20, 2010 at 8:12 PM, pugs-comm...@feather.perl6.nl wrote:
Author: Kodi
Date: 2010-07-21 02:12:24 +0200 (Wed, 21 Jul 2010)
New Revision: 31777
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Reverted DateTime back to being mutable. I think we ought to
make a big change like this only after reaching some kind of consensus to do
so, not least because I just implemented a lot of mutating methods!
Note that += and friends need only the *container* on the LHS to be mutable,
not the value?\226?\128?\148'$x += 1' should be allowed whether $x holds an
Int, a Date, or a DateTime.
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-07-20 21:51:26
UTC (rev 31776)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-07-21 00:12:24
UTC (rev 31777)
@@ -16,7 +16,7 @@
Created: 19 Mar 2009
Last Modified: 20 Jul 2010
- Version: 15
+ Version: 16
The document is a draft.
@@ -67,11 +67,7 @@
=head1 CDateTime
A CDateTime object describes the time as it would appear on someone's
-calendar and someone's clock.
-
-CDateTime objects are immutables.
-
-You can create a CDateTime object from an
+calendar and someone's clock. You can create a CDateTime object from an
CInstant or from an CInt; in the latter case, the argument is
interpreted as POSIX time.
@@ -98,11 +94,7 @@
Another multi exists with CDate :date instead of C:year, C:month and
C:day (and the same defaults as listed above).
-A CDateTime can also be created by modifying an existing object:
-
- my $moonlanding_anniv = DateTime.new($moonlanding, :year(2010));
-
-All five of the aforementioned forms of Cnew accept two additional named
+All four of the aforementioned forms of Cnew accept two additional named
arguments. C:formatter is a callable object that takes a CDateTime and
returns a string. The default formatter creates an ISO 8601 timestamp (see
below). C:timezone is a callable object that takes a CDateTime to
@@ -186,11 +178,38 @@
C$dt.timezone($dt, True); otherwise, C$dt.offset returns
C$dt.timezone as is.
-The Ctruncate method returns a new object where a number of time values
-have been cleared below a given resolution:
+=head2 Set methods
- $dt2 = $dt.truncate( :tohour ); # clears minutes and seconds
+To set the the day of a CDateTime object to something, just assign to
+its public accessor:
+ $dt.day = 15;
+
+The same methods exists for all the values you can set in the
+constructor: Cyear, Cmonth, Cday, Chour, Cminute, Csecond,
+Ctimezone and Cformatter. Also, there's a Cset method, which
+accepts all of these as named arguments, allowing several values to be
+set at once:
+
+ $dt.set( :year(2014), :month(12), :day(25) );
+
+Just as with the Cnew method, validation is performed on the resulting
+values, and an exception is thrown if the result isn't a sensible date
+and time.
+
+If you use the Ctimezone public accessor to adjust the time zone, the
+local time zone is adjusted accordingly:
+
+ my $dt = DateTime.new('2005-02-01T15:00:00+0900');
+ say $dt.hour; # 15
+ $dt.timezone = 6 * 60 * 60; # 6 hours ahead of UTC
+ say $dt.hour; # 12
+
+The Ctruncate method allows you to clear a number of time values
+below a given resolution:
+
+ $dt.truncate( :tohour ); # clears minutes and seconds
+
The time units are cleared in the sense that they are set to their
inherent defaults: 1 for months and days, 0 for the time components.
@@ -198,6 +217,9 @@
Monday of the week in which it occurs, and the time components are all
set to 0.
+For the convenience of method chaining, Cset and Ctruncate return the
+calling object.
+
=head1 Date
CDate objects are immutable and represent a day without a time
r31696 -[S32/Temporal] Permit day-of-month on Dates.
Author: Kodi Date: 2010-07-15 14:18:15 +0200 (Thu, 15 Jul 2010) New Revision: 31696 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Permit day-of-month on Dates. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-15 12:12:31 UTC (rev 31695) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-15 12:18:15 UTC (rev 31696) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 -Last Modified: 14 Jul 2010 -Version: 13 +Last Modified: 15 Jul 2010 +Version: 14 The document is a draft. @@ -246,6 +246,7 @@ year month day +day-of-month day-of-week week week-year
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
By analogy, I'd say week-of-year should work as well. On Thu, Jul 15, 2010 at 8:18 AM, pugs-comm...@feather.perl6.nl wrote: Author: Kodi Date: 2010-07-15 14:18:15 +0200 (Thu, 15 Jul 2010) New Revision: 31696 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Permit day-of-month on Dates. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-07-15 12:12:31 UTC (rev 31695) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod 2010-07-15 12:18:15 UTC (rev 31696) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 - Last Modified: 14 Jul 2010 - Version: 13 + Last Modified: 15 Jul 2010 + Version: 14 The document is a draft. @@ -246,6 +246,7 @@ year month day + day-of-month day-of-week week week-year -- Mark J. Reed markjr...@gmail.com
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
On Thu, Jul 15, 2010 at 9:21 AM, Mark J. Reed markjr...@gmail.com wrote: By analogy, I'd say week-of-year should work as well. Oof, is there a generally accepted for numbering weeks within a year? A month's boundaries' always coincides with a day's boundary, but a year only occasionally begins/ends on a week boundary. Come to think of it, there isn't even consensus on what day of the week constitutes a week start, even if Perl 6 has chosen a convention. On the other hand, I won't complain about a week-of-year with a good definition of how it handles weeks 0/1, 52/53. End user can choose to use it or not. And I'm not too anxious to open up the whole calendar choice can of worms.
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
I was just proposing an alias for week it that clarifies what it is the week *of*. The rest of what you ask is already established in Temporal.pm. 1. week returns the week number in the ISO 8601 week calendar. You can find the spec by Googling, but in summary: a. weeks begin on Monday b. weeks are numbered 1 to 52 or 53 c. week 1 is the first week containing at least four days of the new calendar year 2. week-year returns the year number, based on boundaries defined by the above principle. For instance, week 1 of this year began on January 4th, 2010, so on January 3rd, 2010, week-year would still return 2009. These are the same values returned by the %V and %G strftime(3) conversion specifications, e.g. date +%GW%V on Unixlike systems. By analogy, I'd say week-of-year should work as well. Oof, is there a generally accepted for numbering weeks within a year? A month's boundaries' always coincides with a day's boundary, but a year only occasionally begins/ends on a week boundary. Come to think of it, there isn't even consensus on what day of the week constitutes a week start, even if Perl 6 has chosen a convention. On the other hand, I won't complain about a week-of-year with a good definition of how it handles weeks 0/1, 52/53. End user can choose to use it or not. And I'm not too anxious to open up the whole calendar choice can of worms. -- Mark J. Reed markjr...@gmail.com
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/15/10 12:21 , Mark J. Reed wrote: By analogy, I'd say week-of-year should work as well. Wasn't the week stuff punted to a non-core module because there are too many differences in how it's handled (week starts on Sunday in the US and Israel and Monday elsewhere, differing notions of what first week of the year means, etc.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw/eegACgkQIn7hlCsL25UjvQCgn2pBiV9738xD3pw3UHna15/C vW8An2GrniNl9AWg//l/Jx4foXqOXDMF =RbhI -END PGP SIGNATURE-
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
On Thu, Jul 15, 2010 at 2:13 PM, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/15/10 12:21 , Mark J. Reed wrote: By analogy, I'd say week-of-year should work as well. Wasn't the week stuff punted to a non-core module because there are too many differences in how it's handled (week starts on Sunday in the US and Israel and Monday elsewhere, differing notions of what first week of the year means, etc.) I had the same thought but as Mark pointed out, there is an ISO standard for numbering weeks within a year, which is also implemented by Unix-y systems. So that portion is defensible. -y
Re: r31696 -[S32/Temporal] Permit day-of-month on Dates.
More importantly, it's already in the spec! All I proposed was an alias to an existing attribute name. If it gets dropped out of core, that's fine, too. But I'd like to see the longer name available, in whatever module it shows up in... On Thu, Jul 15, 2010 at 5:36 PM, yary not@gmail.com wrote: On Thu, Jul 15, 2010 at 2:13 PM, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/15/10 12:21 , Mark J. Reed wrote: By analogy, I'd say week-of-year should work as well. Wasn't the week stuff punted to a non-core module because there are too many differences in how it's handled (week starts on Sunday in the US and Israel and Monday elsewhere, differing notions of what first week of the year means, etc.) I had the same thought but as Mark pointed out, there is an ISO standard for numbering weeks within a year, which is also implemented by Unix-y systems. So that portion is defensible. -y -- Mark J. Reed markjr...@gmail.com
r31678 -[S32/Temporal] DateTime.new(Numeric) - DateTime.new(Int), since time no longer returns fractional seconds.
Author: Kodi Date: 2010-07-14 16:02:34 +0200 (Wed, 14 Jul 2010) New Revision: 31678 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] DateTime.new(Numeric) - DateTime.new(Int), since time no longer returns fractional seconds. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-14 12:50:51 UTC (rev 31677) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-14 14:02:34 UTC (rev 31678) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 -Last Modified: 12 Jul 2010 -Version: 10 +Last Modified: 14 Jul 2010 +Version: 11 The document is a draft. @@ -57,7 +57,7 @@ =head1 Ctime -Returns the current POSIX time as an Int. Use the Cnow function for an +Returns the current POSIX time as an CInt. Use Cnow for an epoch-agnostic measure of atomic seconds (i.e., an CInstant). Note that both Ctime and Cnow are not functions, but terms of the pseudo-constant variety; as such they never take an argument. @@ -68,15 +68,14 @@ A CDateTime object describes the time as it would appear on someone's calendar and someone's clock. You can create a CDateTime object from an -CInstant or from any object that does the CNumeric role; in the latter -case, the argument is interpreted as POSIX time. +CInstant or from an CInt; in the latter case, the argument is +interpreted as POSIX time. my $now = DateTime.new(now); -my $now = DateTime.new(time); # same thing (usually) +my $now = DateTime.new(time); -Note that a CDateTime based on Cnow can return a CDateTime -that cannot be produced using Ctime, since Ctime doesn't know -about leap seconds. +These two statements are equivalent except that Ctime doesn't know about +leap seconds or fractions of seconds. Or you can use named arguments:
r31680 -[S32/Temporal] Added to Date: There are also Cweek, Cweek-year, Cweek-number, Cweekday-of-month, and Cday-of-year methods, which work just like their DateTime equivalents.
Author: Kodi
Date: 2010-07-14 16:35:46 +0200 (Wed, 14 Jul 2010)
New Revision: 31680
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Added to Date: There are also Cweek, Cweek-year,
Cweek-number, Cweekday-of-month, and Cday-of-year methods, which work
just like their DateTime equivalents.
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-14 14:35:21 UTC
(rev 31679)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-14 14:35:46 UTC
(rev 31680)
@@ -16,7 +16,7 @@
Created: 19 Mar 2009
Last Modified: 14 Jul 2010
-Version: 11
+Version: 12
The document is a draft.
@@ -244,6 +244,9 @@
$d.days-in-month# 31
$d.Str # '2010-12-24'
+There are also Cweek, Cweek-year, Cweek-number, Cweekday-of-month,
+and Cday-of-year methods, which work just like their DateTime equivalents.
+
=head2 Arithmetics
$d.succ # Date.new('2010-12-25')
r31689 -[S32/Temporal] Permit days-in-month and is-leap-year on DateTimes, too.
Author: Kodi
Date: 2010-07-14 23:18:42 +0200 (Wed, 14 Jul 2010)
New Revision: 31689
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Permit days-in-month and is-leap-year on DateTimes, too.
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-14 20:35:20 UTC
(rev 31688)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-14 21:18:42 UTC
(rev 31689)
@@ -16,7 +16,7 @@
Created: 19 Mar 2009
Last Modified: 14 Jul 2010
-Version: 12
+Version: 13
The document is a draft.
@@ -157,9 +157,17 @@
month, the day itself included. For example, June 9, 2003 is the second
Monday of the month, and so this method returns 2 for that day.
+The Cdays-in-month method returns the number of days in the current
+month of the current year. So in the case of January, Cdays-in-month
+always returns 31, whereas in the case of February, Cdays-in-month
+returns 28 or 29 depending on the year.
+
The Cday-of-year method returns the day of the year, a value between 1
and 366.
+The method Cis-leap-year returns a CBool, which is true if and only
+if the current year is a leap year in the Gregorian calendar.
+
The method Cwhole-second returns the second truncated to an integer.
The CDate method returns a CDate object, and is the same as
@@ -232,20 +240,23 @@
=head2 Accessors
-The following accessors are pretty obvious, and are defined by example only.
-See the test suite for more formal definitions.
+CDate objects support all of the following accessors, which work just
+like their CDateTime equivalents:
-my $d = Date.new('2010-12-24');
-$d.year # 2010
-$d.month# 12
-$d.day # 24
-$d.day-of-week # 5 # Friday
-$d.is-leap-year # Bool::False
-$d.days-in-month# 31
-$d.Str # '2010-12-24'
+year
+month
+day
+day-of-week
+week
+week-year
+week-number
+day-of-week
+weekday-of-month
+days-in-month
+day-of-year
+is-leap-year
-There are also Cweek, Cweek-year, Cweek-number, Cweekday-of-month,
-and Cday-of-year methods, which work just like their DateTime equivalents.
+The Str method returns a string of the form '-mm-dd'.
=head2 Arithmetics
Re: r31627 -[S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal.
On Sun, Jul 11, 2010 at 12:56 PM, pugs-comm...@feather.perl6.nl wrote: Author: Kodi Date: 2010-07-11 19:56:33 +0200 (Sun, 11 Jul 2010) New Revision: 31627 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-11 17:09:44 UTC (rev 31626) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-11 17:56:33 UTC (rev 31627) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 -Last Modified: 8 Apr 2010 -Version: 7 +Last Modified: 11 July 2010 +Version: 8 The document is a draft. @@ -88,11 +88,12 @@ All four of the aforementioned forms of Cnew accept two additional named arguments. C:formatter is a callable object that takes a CDateTime and returns a string. The default formatter creates an ISO 8601 timestamp (see -below). C:timezone is a callable object that takes a CDateTime and -returns a two-element list giving the difference from UTC in (possibly both -negative, but not of opposite signs) hours and minutes. Alternatively, -C:timezone can be a two-element list, which is interpreted as a static -offset from UTC. The default time zone is C(0, 0) (i.e., UTC). +below). C:timezone is a callable object that takes a CDateTime to +convert and a CBool that specifies the direction of the conversion: to +UTC if true, from UTC if false. Perhaps it's just me, but a boolean value to specify the direction of conversion seems wrong-ish. An enum with two values TO_UTC and FROM_UTC would be a little more self-documenting. -Scott
Re: r31627 -[S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal.
Scott (): Perhaps it's just me, but a boolean value to specify the direction of conversion seems wrong-ish. It's not just you. :) // Carl
r31652 -[Temporal] time is now a pseudo-constant like now, rand, etc
Author: lwall Date: 2010-07-13 02:06:01 +0200 (Tue, 13 Jul 2010) New Revision: 31652 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [Temporal] time is now a pseudo-constant like now, rand, etc Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-12 23:59:37 UTC (rev 31651) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-13 00:06:01 UTC (rev 31652) @@ -15,8 +15,8 @@ Created: 19 Mar 2009 -Last Modified: 11 July 2010 -Version: 8 +Last Modified: 12 Jul 2010 +Version: 9 The document is a draft. @@ -57,6 +57,10 @@ Returns the current POSIX time. Use the Cnow function for an epoch-agnostic measure of atomic seconds (i.e., an CInstant). +Note that both Ctime and Cnow are not functions, but terms +of the pseudo-constant variety; as such they never take an argument. +Saying Ctime() doesn't work unless you happen to have a function +of that name defined. =head1 CDateTime
r31627 -[S32/Temporal] Changed to use a different way of specifying time zones, which is hopefully saner than my last proposal.
Author: Kodi
Date: 2010-07-11 19:56:33 +0200 (Sun, 11 Jul 2010)
New Revision: 31627
Modified:
docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
[S32/Temporal] Changed to use a different way of specifying time zones, which
is hopefully saner than my last proposal.
Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-11 17:09:44 UTC
(rev 31626)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-11 17:56:33 UTC
(rev 31627)
@@ -15,8 +15,8 @@
Created: 19 Mar 2009
-Last Modified: 8 Apr 2010
-Version: 7
+Last Modified: 11 July 2010
+Version: 8
The document is a draft.
@@ -88,11 +88,12 @@
All four of the aforementioned forms of Cnew accept two additional named
arguments. C:formatter is a callable object that takes a CDateTime and
returns a string. The default formatter creates an ISO 8601 timestamp (see
-below). C:timezone is a callable object that takes a CDateTime and
-returns a two-element list giving the difference from UTC in (possibly both
-negative, but not of opposite signs) hours and minutes. Alternatively,
-C:timezone can be a two-element list, which is interpreted as a static
-offset from UTC. The default time zone is C(0, 0) (i.e., UTC).
+below). C:timezone is a callable object that takes a CDateTime to
+convert and a CBool that specifies the direction of the conversion: to
+UTC if true, from UTC if false. The C:timezone signifies the necessary
+conversion by returning an integer giving the difference from UTC in
+seconds. Alternatively, C:timezone can be a number, which is interpreted
+as a static offset from UTC. The default time zone is C0 (i.e., UTC).
A shorter way to send in date and time information is to provide a
single string with a full ISO 8601 date and time. The example from above
@@ -100,14 +101,16 @@
my $moonlanding = DateTime.new( '1969-07-16T20:17:00Z' ); # UTC time
-The general form is C[date]T[time][offset], with [date] given as
-C-MM-DD and [time] given as Chh:mm:ss. The final CZ is a short
+The general form is C[date]T[time][offset], with C[date] given as
+C-MM-DD and C[time] given as Chh:mm:ss. The final CZ is a short
form for C+, meaning UTC. (Note that while this form of Cnew
accepts all of C+, C-, and CZ, the default formatter for
-CDateTime always expresses UTC as CZ.) The general notation for the C
-offset is C+hhmm or C-hhmm. As before, a C:formatter argument is
-permitted. The C:timezone, if not supplied, is assumed to be a static
-offset equal to the offset in the given timestamp.
+CDateTime always expresses UTC as CZ.) The general notation for the
+C[offset] is C+hhmm or C-hhmm. The time zone of the new object is
+assumed to be a static offset equal to the C[offset]. The C[offset] is
+optional; if omitted, a C:timezone argument is permitted; if this too is
+omitted, UTC is assumed. Finally, the constructor also accepts a
+C:formatter argument.
With all the above constructors, if you attempt to pass in values that
are outside of the ranges specified in the list above, you'll get an
@@ -155,8 +158,8 @@
The method Coffset returns the object's current offset from UTC: if
C$dt.timezone does CCallable, C$dt.offset is equivalent to
-C$dt.timezone($dt); otherwise, C$dt.offset is equivlent to
-C@($dt.timezone).
+C$dt.timezone($dt, True); otherwise, C$dt.offset returns
+C$dt.timezone as is.
=head2 Set methods
@@ -181,9 +184,9 @@
local time zone is adjusted accordingly:
my $dt = DateTime.new('2005-02-01T15:00:00+0900');
-say $dt.hour; # 15
-$dt.timezone = (6, 0);
-say $dt.hour; # 12
+say $dt.hour;# 15
+$dt.timezone = 6 * 60 * 60; # 6 hours ahead of UTC
+say $dt.hour;# 12
The Ctruncate method allows you to clear a number of time values
below a given resolution:
@@ -197,6 +200,9 @@
Monday of the week in which it occurs, and the time components are all
set to 0.
+For the convenience of method chaining, Cset and Ctruncate return the
+calling object.
+
=head1 Date
CDate objects are immutable and represent a day without a time component.
r31598 -[S32/Temporal] Clarified the distinction between time and now, specified what formatters and time zones should actually do, and dropped some formatting methods.
Author: Kodi Date: 2010-07-09 19:43:53 +0200 (Fri, 09 Jul 2010) New Revision: 31598 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Clarified the distinction between time and now, specified what formatters and time zones should actually do, and dropped some formatting methods. Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-09 17:12:58 UTC (rev 31597) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-09 17:43:53 UTC (rev 31598) @@ -48,31 +48,32 @@ are the aspects of time that are felt to be stable enough to belong in the core. +Note that in this document, the term POSIX time means the number of +seconds since midnight UTC of 1 January 1970, not counting leap seconds. +This is the same as the output of the ISO C Ctime function except that it +includes a fractional part. + =head1 Ctime -Returns an CInstant representing the current time as measured in -atomic seconds since the Unix epoch, suitable for feeding to some of the -CDateTime constructors. +Returns the current POSIX time. Use the Cnow function for an +epoch-agnostic measure of atomic seconds (i.e., an CInstant). =head1 CDateTime A CDateTime object describes the time as it would appear on someone's -calendar and someone's clock. You can create a CDateTime object from -the CInstant returned by the Ctime function: +calendar and someone's clock. You can create a CDateTime object from an +CInstant or from any object that does the CNumeric role; in the latter +case, the argument is interpreted as POSIX time. -my $now = DateTime.from-epoch(time); +my $now = DateTime.new(now); +my $now = DateTime.new(time); # same thing -This is such a common use case, that there's a CDateTime.now -constructor that does this for you: +Or you can use named arguments: -my $now = DateTime.now(); - -General dates can be specified through the Cnew constructor: - my $moonlanding = DateTime.new( :year(1969), :month(7), :day(16), :hour(20), :minute(17) ); # UTC time -The full list of named arguments is as follows: +This form allows the following arguments: :year required :month defaults to 1 range 1..12 @@ -80,25 +81,34 @@ :hour defaults to 0 range 0..23 :minute defaults to 0 range 0..59 :second defaults to 0 range 0.0..^62.0 -:timezone defaults to '+' (UTC) -:formatter defaults to an iso8601 formatter, see below -Another multi exists with CDate :date -instead of C:year, C:month and C:day (and the same defaults as listed -above). +Another multi exists with CDate :date instead of C:year, C:month and +C:day (and the same defaults as listed above). -A shorter way to send in date and time information to is providing a -single string with a full ISO8601 date and time. The example from above +All four of the aforementioned forms of Cnew accept two additional named +arguments. C:formatter is a callable object that takes a CDateTime and +returns a string. The default formatter creates an ISO 8601 timestamp (see +below). C:timezone is a callable object that takes a CDateTime and +returns a two-element list giving the difference from UTC in (possibly both +negative, but not of opposite signs) hours and minutes. Alternatively, +C:timezone can be a two-element CSeq, which is interpreted as a static +offset from UTC. The default time zone is C(0, 0) (i.e., UTC). + +A shorter way to send in date and time information is to provide a +single string with a full ISO 8601 date and time. The example from above would then be my $moonlanding = DateTime.new( '1969-07-16T20:17:00Z' ); # UTC time -The general form is C[date]T[time][offset], with [date] given -as C-MM-DD and [time] given as Chh:mm:ss. +The general form is C[date]T[time][offset], with [date] given as +C-MM-DD and [time] given as Chh:mm:ss. The final CZ is a short +form for C+, meaning UTC. (Note that while this form of Cnew +accepts all of C+, C-, and CZ, the default formatter for +CDateTime always expresses UTC as CZ.) The general notation for the C +offset is C+hhmm or C-hhmm. As before, a C:formatter argument is +permitted. The C:timezone, if not supplied, is assumed to be a static +offset equal to the offset in the given timestamp. -The final CZ is a short form for C+, meaning UTC time. The -general notation for the C offset is C+hhmm or C-hhmm. - With all the above constructors, if you attempt to pass in values that are outside of the ranges specified in the list above, you'll get an exception. An exception will also be thrown if the particular day @@ -107,12 +117,19 @@ done against leap seconds. This class also explicitly does not check against ambiguous or invalid local times caused by Daylight Saving Time. +There's one additional
r31600 -[S32/Temporal] Prose edit; CSeq - list
Author: Kodi Date: 2010-07-09 21:47:34 +0200 (Fri, 09 Jul 2010) New Revision: 31600 Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod Log: [S32/Temporal] Prose edit; CSeq - list Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod === --- docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-09 19:09:30 UTC (rev 31599) +++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2010-07-09 19:47:34 UTC (rev 31600) @@ -51,7 +51,7 @@ Note that in this document, the term POSIX time means the number of seconds since midnight UTC of 1 January 1970, not counting leap seconds. This is the same as the output of the ISO C Ctime function except that it -includes a fractional part. +also includes a fractional part. =head1 Ctime @@ -91,7 +91,7 @@ below). C:timezone is a callable object that takes a CDateTime and returns a two-element list giving the difference from UTC in (possibly both negative, but not of opposite signs) hours and minutes. Alternatively, -C:timezone can be a two-element CSeq, which is interpreted as a static +C:timezone can be a two-element list, which is interpreted as a static offset from UTC. The default time zone is C(0, 0) (i.e., UTC). A shorter way to send in date and time information is to provide a
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
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. --
Re: Proposal for a new Temporal time-measurement paradigm
Jon Lang wrote: Why do I find myself thinking of roles and classes here? IMHO, we should have a role that represents abstractly a moment in time. This role should, in and of itself, not be tied to any particular calendar; its purpose is so that one can write functions that make reference to instances in time without locking oneself into a particular labeling scheme. We should also have a series of classes that compose that role, each class representing a different calendar scheme. For perl 6.0.0, only one such class need be defined: the one representing the Gregorian calendar. Later on, modules can be written to provide additional classes representing other calendar schemes. Fine in theory; in practice, the big question is: how much can we get the role to do, within the no calendar preference constraint? And a corollary to this: can we get it to do enough to be worthwhile? 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. 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. Each instant simply says, I am this point on this particular timeline/calendar, and not try to imply that it is anything against any other calendar. For example, each instant is only a datetime in the Gregorian or Julian or Muslim or Jewish or TAI-1958 or TAI-1970s or whatever. This may result in a proliferation of calendars, but that can be blunted somewhat anywhere there are multiple measuring systems that are guaranteed to be commonly-defined. 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. So all Perl 6 really needs to define is: 1. There is an Instant role and a Duration role. 2. A Duration is an amount of time that isn't fixed on a timeline; to get something fixed on a timeline, use a Range of Instant. 3. The system routine now()/etc returns a value of some Instant-composing class. 4. The Instant/Duration roles define functions like these: abs Duration - Duration Duration + Duration - Duration Duration - Duration - Duration Duration abs_diff Duration - Duration Duration * Numeric - Duration Duration / Numeric - Duration Instant - Instant - Duration Instant abs_diff Instant - Duration Instant + Duration - Instant Instant - Duration - Instant 5. There are absolutely no attributes defined by the Instant or Duration roles; attributes are defined entirely by the specific implementing classes, or other roles that they compose which compose Instant or Duration etc. There is no concept of years/days/etc in Instant or Duration. We might be counting time on Mars for example, so no Terra-centricity. So, basically like that. It keeps the core very simple and we avoid most of the bikeshedding seen so far. 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. This brings up a new discussion point though: We should come out with a list of distinct timelines/calendars and canonical names for them with respect to Perl 6. So to at least help those who are trying to use the exact same calendar to recognize that they are doing so. -- Darren Duncan
Re: Proposal for a new Temporal time-measurement paradigm
On Wed, 21 Apr 2010, Mark J. Reed wrote: I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendrica, for instance. What he said. Perl is all about good Huffman coding. The _vast_ majority people who need to do stuff with dates and datetimes will be dealing with the modern Gregorian calendar. Therefore, having a correct and simple to use implementation of some minimal Gregorian calendar objects in core makes a lot of sense. For folks who need to get fancier, the day count on the Date class will allow simple conversion between calendars, which they can find on CPAN6, along with modules that do more with the Gregorian calendar. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Proposal for a new Temporal time-measurement paradigm
Minor nit: On Apr 21, 2010, at 04:57 , Richard Hainsworth wrote: If a calendar system, eg., Chinese, Muslim and Jewish, defines days in the same way, eg., starting at midnight and incorporating leap seconds, for a time-zone, then the naming of the days is done by The Jewish, Muslim, and Baha`i (and, technically at least, Christian) religious calendars use sunset as the start of the day. Only Western Christianity and Baha`i use the Gregorian corrections; Orthodox Christianity and the other aforementioned calendars are Julian. (Actually, the Baha`i calendar seems unclear on this; everything I can find suggests that it's still an open issue for them, but for the moment at least it's tied to the Gregorian calendar.) The Jewish calendar doesn't recognize leap seconds; all time measurements are variable, with the day and night separately divided into 12 sha`ot composed of 60 dakot whose lengths vary as the length of the day/night changes throughout the year. Sunrise and sunset are usually defined as when the leading (resp. trailing) edge of the solar disk crosses the horizon. (Some communities use a variation where sunrise is considered to be first light and sunset the end of twilight; *usually* these are taken as the sun being 16° below the eastern horizon and 7.5° below the western. However, there's a lot of variation between communities, and very little of this is fixed; one opinion sets the start of night as 1 1/4 sha`ot *before* sunset!) Islam has some other sticking points in this area: some communities define the start of a new month based on local time, while others base it on observations at Mecca, with the result that the calendar can vary by a day even in the same location. (This got some discussion in the context of Iraqi sectarian violence a few years back.) Additionally, while Jews use a fixed calculation of when the new moon occurs, Muslims still base the start of the month on direct observation of the new moon, so the calendar can again be off by a day. All of which suggests that it may not actually be possible to come up with a mechanism suitable for representing all of these calendars. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: Proposal for a new Temporal time-measurement paradigm
Why do I find myself thinking of roles and classes here? IMHO, we should have a role that represents abstractly a moment in time. This role should, in and of itself, not be tied to any particular calendar; its purpose is so that one can write functions that make reference to instances in time without locking oneself into a particular labeling scheme. We should also have a series of classes that compose that role, each class representing a different calendar scheme. For perl 6.0.0, only one such class need be defined: the one representing the Gregorian calendar. Later on, modules can be written to provide additional classes representing other calendar schemes. Fine in theory; in practice, the big question is: how much can we get the role to do, within the no calendar preference constraint? And a corollary to this: can we get it to do enough to be worthwhile? -- Jonathan Dataweaver Lang
Proposal for a new Temporal time-measurement paradigm
In reading all of the discussion about Temporal, I have the uneasy feeling that the current development work is falling into the same traps as other languages. It seems to me that the underlying time-measurement paradigm of the developers is too tightly focused on the Christian Gregorian calendar. The following proposal concerns the time-measurement paradigm. It shows how DateTime arithmetic can be done in a unified way taking into account: - different timezones (including leap seconds and daylight savings changes); - different calendars; - different calendar systems. The paradigm does not provide any API (role/class/method name or definitions) since I could imagine a number are possible, including ones close to the DateTime module being developed. It is possible that the developers already implicitly use a time-measurement paradigm like the one suggested here. If this is the case, it would be best to make the paradigm more explicit, perhaps by including the paradigm in the 'semi-internal' section of the Temporal Spec. We start with a stream of Instants - already specified for perl6, in reality seconds from a single epoch. This stream is universal (our universe being the computers on Earth) in that in whatever time zone a person is, there is the same number of seconds from the start of the epoch. (I believe we can ignore relativity at present.) Imagine these Instants as a horizontal axis. Now we need to *name* these Instants in a conventional manner. Over the top of the Instants we have what I am calling a filter, or rather a series of filters. A filter groups the periods in the filter below it into longer periods. Hence, the first filter groups Instants into days. The day filter is like a set of windows over the Instant stream. The first - day - filter is defined for a particular jurisdiction and time zone. Eg there is a filter for the Moscow time zone. Each element - RU-Mos-day - knows its start and finish in terms of Instants. Ordinarily, the number of Instants (seconds) is fixed per day, but from time to time leap seconds are added to a day. Note that in each time zone the leap seconds may be added at different times in the universal Instant stream. That is, normally leap seconds and daylight saving changes are implemented at midnight in each time zone. The implementation of a time-zone filter would be the same for all time zones, namely an iterator that generates a new day as a fixed number of Instants after the start of the previous day, plus a list of exceptions when the *end* of a day is extended/contracted by some number of Instants (due to leap seconds of daylight saving). The difference between time zones would be that the start of the filter (the epoch of the filter) is shifted up or down the Instant stream, and the list of exceptions for time zones/jurisdictions would be different, depending on jurisdiction and daylight saving. It is conventional to refer to days in terms of a calendar system. Calendars introduce a variety of problems. Significant numbers of people on the planet use the Chinese, Muslim, Jewish and Baha'i calendars - all of which are very different in structure. In some countries, two calendar systems are used simultaneously, with people switching between them according to the function of the day. For example, in Russia there are two concurrent calendars (the secular and religious) and they are a fixed number of days apart. Hence Christmas - December 25 in both calendars - occurs on December 25 in the secular calendar, but on Jan 5 (I think) according to the secular calendar, but December 25 according to the religious calendar. For perl6 to be universal, it must be clear how these different calendar systems can be integrated. In principle I think all calendars can be adapted using the same filter technique. The description below is for the Christian Gregorian calendar as applied in many secular jurisdictions. We then consider how to adapt the approach to other calendars. Days have two sorts of name: - Day_of_week, which is a simple modulo 7 of the number of days from the start of the epoch. - Calendar_day, which is the year-month-day format. The day filter, eg., Ru-Mos-Day, provides for an arbritary Instant both a day_of_week name (eg. Monday) and an offset in days from the start of the time-zone's epoch. For each day, the filter provides the start and end positions in Instants. Next layer up is a Month filter. Just as there are leap seconds in days, so too there are leap days in Months. The Month filter keeps track of the start and end of each month in days. Just like the day filter, the month filter provides a Month_of_year name and an offset in Months from the start of the epoch. Each month 'knows' its start and end day. Similarly for the Year filter. Consider filters to be windows over the Instant time stream. Looking up from an Instant, the filters provide names for days, months
Re: Proposal for a new Temporal time-measurement paradigm
I whole-heartedly agree that we need to make a system independent of any sort of time measurement system. I think the conclusion reached on IRC was that most of the world uses or is at least familiar with the Gregorian system. Now, I can't help but think how we would define an Instant. The best (reasonable) choice is something like TAI or Unix Epoch (I could argue that seconds are not independent, but don't trust me; I'd suggest tapping into the cosmic timeline :) ). I also hope there aren't going to be any leap Instants. (the filter should take care of leaping, after all the calendar has an issue with leaping.) If there isn't a standard defining how many seconds are in a year (i.e. as defined by TAI or the metric system or some other international standard), I propose it'd be about 365.25 Gregorian days (although I'd much prefer an international standard to my Indo-European ways :) ). Overall, I think you have a great idea. As long as the filters are implemented simply, I think it will prove to be the best option. -- Don't Panic!
Re: Proposal for a new Temporal time-measurement paradigm
I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendrica, for instance. Also, the difference between the secular and religious calendars in Russia is not fixed. It's currently 13 days, but only since 1900, before which it was 12 days, and after 2100 it will be 14 days. Calendar conversion can be tricky - which is another reason to leave it out of core. IMO. On Wednesday, April 21, 2010, Matthew rnd...@gmail.com wrote: I whole-heartedly agree that we need to make a system independent of any sort of time measurement system. I think the conclusion reached on IRC was that most of the world uses or is at least familiar with the Gregorian system. Now, I can't help but think how we would define an Instant. The best (reasonable) choice is something like TAI or Unix Epoch (I could argue that seconds are not independent, but don't trust me; I'd suggest tapping into the cosmic timeline :) ). I also hope there aren't going to be any leap Instants. (the filter should take care of leaping, after all the calendar has an issue with leaping.) If there isn't a standard defining how many seconds are in a year (i.e. as defined by TAI or the metric system or some other international standard), I propose it'd be about 365.25 Gregorian days (although I'd much prefer an international standard to my Indo-European ways :) ). Overall, I think you have a great idea. As long as the filters are implemented simply, I think it will prove to be the best option. -- Don't Panic! -- Mark J. Reed markjr...@gmail.com
Re: A new era for Temporal
On Mon, 12 Apr 2010, Moritz Lenz wrote: Am 12.04.2010 03:47, schrieb Dave Rolsky: On Sun, 11 Apr 2010, Moritz Lenz wrote: I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is that Perl 6 should have such a module out of the box, I'll be happy to spec it. I think that having a standard, minimal API for this defined in core as a Date role would be ideal. I'm curious, why a role and not a class? No reason, really. I don't tihnk I understand the Perl 6 way well enough to make a good distinction. Mostly, I want there to be something simple that classes on CPAN6 can implement and build on. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a higher precedence word-separator than the space (or than its intra-identifier stand-in: the underscore). More is better. It was better to have upper as well as lower case letters in variables. It is better to have - as well as _ The more specialised use of upper case letters, such as SYSTEM identifiers, seems to have evolved over time. Depending on my fancy, I sometimes use variables like OriginalValue and sometimes Starting-value. If the program is just for me, who cares? If the software is for a company, they will set the rules. Communities at large generate their own standards. Where it matters, people obey them. Where rules are set because it is supposed to be a good thing, programmers take delight in breaking them. Personally, the rule use only - or _ consistently throughout a module reeks of a rule for rule's sake, one for the breaking. Damian's suggestion seems to me very useful because (for those that wish to follow it) it imposes an extra precision of thought, which almost always facilitates better programming. Adopting it will, I think, lead to more elegant code, for those that like that sort of thing. Regards, Richard
Re: A new era for Temporal
On Sun, Apr 11, 2010 at 9:47 PM, Dave Rolsky auta...@urth.org wrote: On Sun, 11 Apr 2010, Moritz Lenz wrote: I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is that Perl 6 should have such a module out of the box, I'll be happy to spec it. I think that having a standard, minimal API for this defined in core as a Date role would be ideal. Agreed. In fact, I'd like to see DateTime be defined explicitly as a superset (subrole) of Date, with a method for extracting just the Date portion built in to DateTime. -- Mark J. Reed markjr...@gmail.com
Re: A new era for Temporal
On Mon, Apr 12, 2010 at 6:38 AM, Mark J. Reed markjr...@gmail.com wrote: I think that having a standard, minimal API for this defined in core as a Date role would be ideal. Agreed. In fact, I'd like to see DateTime be defined explicitly as a superset (subrole) of Date, with a method for extracting just the Date portion built in to DateTime. Er, I meant that to read (subrole?). Not sure that inheritance is the way to go here, but I do think that logically a DateTime should be built on top of a Date, rather than having Date be a whittled-down DateTime with too-different an API. -- Mark J. Reed markjr...@gmail.com
Re: A new era for Temporal
Am 12.04.2010 03:47, schrieb Dave Rolsky: On Sun, 11 Apr 2010, Moritz Lenz wrote: I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is that Perl 6 should have such a module out of the box, I'll be happy to spec it. I think that having a standard, minimal API for this defined in core as a Date role would be ideal. I'm curious, why a role and not a class? Moritz
Re: underscores vs hyphens (was Re: A new era for Temporal)
Am I the only one who sees a hyphen and thinks binary minus? Just because the parser can disambiguate this use of it doesn't mean the reader's brain can do so as easily. (I assume we're talking about the same character, 0x2D, and not something from further afield in the Unicode tables, right?) Also, what happens when code gets run through mailers or other programs that think a hyphen is an acceptable place to break a line? Does the code still work after copy and paste with that newline inserted? -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/ http://www.informit.com/store/product.aspx?isbn=0137001274 http://www.oreillyschool.com/courses/perl1/
Re: underscores vs hyphens (was Re: A new era for Temporal)
Peter Scott wrote: Am I the only one who sees a hyphen and thinks binary minus? Just because the parser can disambiguate this use of it doesn't mean the reader's brain can do so as easily. It's all a matter of practice. Since variables begin with sigils, and you should put whitespace around infix operators anyway, it's not really hard. Have you tried looking at actual Perl 6 code that uses hyphens? I have, and I didn't find it hard. (I assume we're talking about the same character, 0x2D, and not something from further afield in the Unicode tables, right?) Yes. Also, what happens when code gets run through mailers or other programs that think a hyphen is an acceptable place to break a line? Does the code still work after copy and paste with that newline inserted? The existence of broken tools shouldn't stop progress -- rather the progress should encourage us to fix broken tools (or replace them with better ones). Cheers, Moritz
Re: underscores vs hyphens (was Re: A new era for Temporal)
Darren Duncan wrote: See http://perlcabal.org/syn/S02.html#Names for your answers. Thanks for the link but nowhere in it does it state tha Perl 6 names are case sensitive. The best the do is this, which implies it is but doesn't state it. Other all-caps names are semi-reserved. We may add more of them in the future, so you can protect yourself from future collisions by using mixed case on your top-level packages. (We promise not to break any existing top-level CPAN package, of course. Except maybe ACME, and then only for coyotes.) So, I'll ask again: Where in the official documentation does it state that Perl 6 names are case sensitive? -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. Eliminate software piracy: use only FLOSS.
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey shawnhco...@gmail.com wrote: Darren Duncan wrote: See http://perlcabal.org/syn/S02.html#Names for your answers. Thanks for the link but nowhere in it does it state tha Perl 6 names are case sensitive. The best the do is this, which implies it is but doesn't state it. Other all-caps names are semi-reserved. We may add more of them in the future, so you can protect yourself from future collisions by using mixed case on your top-level packages. (We promise not to break any existing top-level CPAN package, of course. Except maybe ACME, and then only for coyotes.) So, I'll ask again: Where in the official documentation does it state that Perl 6 names are case sensitive? I think it's more important to ask where it says that they aren't. 1) Perl 5 is case sensitive, and the original Apocalypses ran on the basis of 'if it's not mentioned it's the same as Perl 5' 2) The spec assigns no meaning to identifier characters, it just allows you to use a certain set of them. They mean nothing to the language, therefore it has no concept of case to be insensitive about 3) Most popular programming languages are also case-sensitive Maybe it should be explicitly mentioned somewhere, but I think it's a reasonable default assumption. Programmers know that case-insensitivity is a special form of string comparison which involves lots of extra work, so tend to assume (at least in my experience) that it's not going to happen unless they actually ask for it.
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote: : Damian Conway wrote: : The relevant suggestion regarding hyphens vs underscores is: : : ...to allow both characters, but have them mean the same thing. : : That is, any isolated internal underscore can be replaced with an : isolated internal hyphen (and vice versa), without changing the meaning : of the identifier. : : I am formally opposed to this idea. I see that making underscores : and hyphens to be equivalent is akin to having case-insensitive : identifiers, where Perl,PERL,perl mean the same thing. Rather : what I want is to be everything-sensitive, as AFAIK Perl 6 currently : is; if something looks different, it is different. -- Darren Duncan Well, Perl 6 won't be everything-sensitive, since by default it does string comparisons under some kind of Unicodian Normalization. But I'm inclined to keep - and _ as unique characters, and just let the culture evolve over time; I think the end result will be to require (by convention) official APIs to use hyphens for all normal interfaces; underscores anywhere in a name will come to mean this is private, use at your own risk regardless of where underscores are used, much like current meaning of leading underscores. But I don't think it should be anything tighter than a convention, or we make language interoperability more difficult (particularly with Perl 5). As for the horror of people having to memorize lists again or Risk Using The Wrong Character...I'm afraid I just don't buy it. The standard parser will likely be pointing out spelling errors and conjecturing emendations for near misses. Whole-program analysis can even do this for any method names that look wrongish. The difference between Acme-X and Acme_X is no worse than the difference between Damian and Damien, at least in Levenshtein distance. Larry
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, Apr 12, 2010 at 2:23 PM, Larry Wall la...@wall.org wrote: On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote: : : I see that making underscores : and hyphens to be equivalent is akin to having case-insensitive : identifiers, where Perl,PERL,perl mean the same thing. Rather : what I want is to be everything-sensitive, as AFAIK Perl 6 currently : is; if something looks different, it is different. -- Darren Duncan ... As for the horror of people having to memorize lists again or Risk Using The Wrong Character...I'm afraid I just don't buy it. Larry, I'm curious what you think of this example: A web page of Perl 6 documentation suggests that you should call time-local. Unfortunately, in the font that my browser uses, the height of that single stroke is ambiguous. Of course, we could have no sympathy and just say, get a better font, but this problem will likely creep up over and over, would it not? I agree with you that this doesn't really help the person writing code from scratch, but that's not the same as a developer who is trying to interact with potentially dozens of libraries with various sources of documentation from comments to Web pages. I'd suggest the following in decreasing order of urgency: - Choose a single character (hyphen or underscore) to use in standard library code to separate the component words of an identifier (remember that underscore is only special in C-like code because it's standing in for space). - Never use dash versus underscore notationally (e.g. a-b indicates that the identifier is to be used one way vs a_b indicates otherwise) - Allow only one such character in any given identifier That last item rolls into a whole rant of mine against ambiguity in identifiers. Most often this stems from Unicode that puts the programmer in the position of having to have good enough font support to tell ambiguous names apart (and in cases like Αpple or Рerl or Ρerl, you're just doomed regardless), but dashes and underscores are a good example of the same problem cropping up elsewhere. On the more general point, I really feel that no language should ever allow identifiers to mix Unicode blocks without strong reason. Specifically: - Underscore (or dash or whatever your notational separator is) should be the only exceptional character allowed in all identifiers - Identifiers should never include c̈ombining m̅arks - Upon scanning the first alpha character in an identifier, no further alpha characters should be allowed except as they come from the same code block or related supplemental block (related might be expanded to include first-class blocks in some cases to allow for combinations like Kanji (Chinese in Unicode) + Hirigana, etc.) - Upon scanning the first numeric character in an identifier, no further numeric characters should be allowed except as they come from the same code block (again, there might be some wiggle in some exceptional cases, but the goal is to avoid counting in more than one system at a time). Should all of these be hard errors? Perhaps not, but certainly they should at least yield warnings by default. PS: While I never finished the implementation of Sand, its simplistic guide to Unicode identifiers might be useful in illuminating what I'm describing above: http://www.ajs.com/ajswiki/Sand:_Syntax_and_Structure#Identifiers -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, 2010-04-12 at 11:23 -0700, Larry Wall wrote: The standard parser will likely be pointing out spelling errors and conjecturing emendations for near misses. Whole-program analysis can even do this for any method names that look wrongish. The difference between Acme-X and Acme_X is no worse than the difference between Damian and Damien, at least in Levenshtein distance. Ah yes, I forgot about this feature. Consider my argument for choosing only one separator throughout the standard setting Way Less Adamant -- though I still think it's a good idea. -'f
RE: underscores vs hyphens (was Re: A new era for Temporal)
From: Mark J. Reed [mailto:markjr...@gmail.com]
[...]
Perl borrows vocabulary almost exclusively from English, but it is
not English, and its conventions are not those of English. (And the
conventions around hyphens that people are citing are quite specifically
those of standard written English; other writing systems, even those using
the same alphabet and mostly the same punctuation, have different rules).
Consider s/English/Linux/ for example. :-)
One consideration leading up to allowing - in P6 identifiers (initially in
the context of an optional syntax-tweaking module) involved compatibility with
fairly common usage in {directory and file} names (where spaces are avoided for
cross-platform reasons). I've always thought {Lisp variable names and
Unix/Linux file names} with hyphens (versus underscores) were {more readable
and substantially easier to type (during long typing sessions)}.
http://groups.google.com/group/perl.perl6.language/browse_thread/thread/1625baa7eead0d71/
http://groups.google.com/group/perl.perl6.compiler/browse_thread/thread/e6cc5dc9360ada36/c59f2fb1f49b80f5?lnk=gstq=r28689#c59f2fb1f49b80f5
I would personally like to see hyphens used as the standard word separator,
with underscores available for exceptions - say, naming a Perl interface
method exactly the same as the underlying C function it provides access to.
[...]
++!
Best regards,
Conrad
Conrad Schneiker
www.AthenaLab.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 4:47 AM, Damian Conway dam...@conway.org wrote: And is it really so hard to teach: use underscore by default and reserve hyphens for between a noun and its adjective? Perhaps it *is*, but then that's a very sad reflection on our profession. If anything, it's a sad reflection on humanity. I don't see any special reason that our profession should be an exception to Sturgeon's law. And, IMHO, conventions should be such that every Joe-Coder should to be able to understand and use them, which means they should be as simple as possible. This thread itself proves that the choice of places where hyphen and underscore should be used under this scheme *feels* ambiguous, even if it strictly isn't so. I believe it would be best to have a rule for hyphen-or-underscore that can be mechanically applied. This would enable a perl6critic tool to check its proper usage, and more importantly, make the choice easy for Joe-Coder since he does not like to think much about function names. With such conventions, it is important to cater to mere mortals, since their code would form the bulk, which means a misunderstanding on their part would make their 'convention' the popular one, which is probably not a good thing. We might end up with PHP-ish nightmare of mixed conventions in function naming. I might go so far as to say that we could drop underscores altogether, and embrace the Lispy way of using hyphens everywhere. Easier to type, looks good, and simple to apply. My 2c, Sundar -- ! Knowing others is intelligence; knowing yourself is true wisdom. Mastering others is strength; mastering yourself is true power. ! If you realize that you have enough, you are truly rich.
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:14 AM, Mark J. Reed markjr...@gmail.com wrote: I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. If Temporal is the first setting module to use multiword identifiers, I vote for hyphens. As another data point ... me too. I'd prefer to see hyphens than underscores. -Scott They're easier on the fingers and the eyes; underscores have always felt like an ugly compromise to make the compiler's job easier. On Saturday, April 10, 2010, Carl Mäsak cma...@gmail.com wrote: John (): Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? I'd just like to point out that the current Temporal spec only does methods with underscores, including Cday_of_week. This goes against my personal preferences; I greatly prefer dashes in almost all of the code I write. But I acknowledge that most of the programmers out there seem to expect underscores -- and also, the aim was to produce a small delta from CPAN's DateTime and not change around things ad lib. // Carl -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
Well, if we're not going to try to implement linguistically based
hyphenation/underscoriation rules (and I'd still argue that hyphenating
adjectives to nouns and underscoring everything else isn't exactly
rocket science), then I'd suggest we reconsider a radically different
proposal that was made on this list five years ago:
http://www.mail-archive.com/perl6-language@perl.org/msg22675.html
The relevant suggestion regarding hyphens vs underscores is:
...to allow both characters, but have them mean the same thing.
That is, any isolated internal underscore can be replaced with an
isolated internal hyphen (and vice versa), without changing the meaning
of the identifier.
This would be the death of fine distinctions such as between:
activate_main-sequence_detonator();
and:
activate_main_sequence-detonator();
which would now resolve to the same subroutine...and do so even if
that subroutine had been declared as
sub activate-main-sequence-detonator {...}
But perhaps such distinctions are indeed too fine and subtle, and we
would be better off eliminating the possibility of them entirely.
Hyphen/underscore equivalence would allow those (apparently elite few) who
can correctly use a hyphen to correctly use the hyphen, whilst the
shambling masses can just randomly type underscores or hyphens between
each word, as their atavistic whims dictate.
;-)
Damian
Re: A new era for Temporal
Dave Rolsky wrote: On Thu, 8 Apr 2010, Carl Mäsak wrote: I do want to explicitly credit Dave Rolsky, whose work on the DateTime family of modules on CPAN has informed much of the current spec, sometimes to the point of verbatim copying. Thanks, but I'd hate to see you copy all my mistakes too! One thing I think is really important is to offer a Date-only object without a time component. The lack of such an object in Perl 5's DateTime family is a real problem. If you're only interested in dates and date math, time and time zones just muddies the water. I've now written such a module: http://github.com/moritz/Date It mostly works with Rakudo, except it doesn't yet export the overloaded operators because of http://rt.perl.org/rt3/Ticket/Display.html?id=74104. Some minor features (like the today() constructor) are not yet implemented. It is very much inspired by Date::Simple on CPAN. There's no documentation yet, but the tests pretty much define the behavior. I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is that Perl 6 should have such a module out of the box, I'll be happy to spec it. Cheers, Moritz
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, 2010-04-10 at 17:20 -0700, yary wrote: Adjectives and nouns aren't English-only. So Damian's proposal is multi-culti. One could argue that Perl's identifiers, keywords, etc are based on English so that it is more difficult for a non-English speaker to discern why underscore is used in some places and hyphens in other. The solution to that would be rote memorization of method names, including _ and - in the spelling. Not ideal, but most likely what many English speaking programmers would do too. And would cuss over. And there's the rub for me. One of the goals of Perl 6 is to reduce the amount of rote memorization of special cases that Perl 5 required. Any mixed use of _ and - in the standard setting defies that goal. (FWIW, I don't really care which is used -- I see arguments for both -- but I do firmly believe the standard setting should only use one or the other. Damian's Temporal example in which only one method used a different separator made the rules-versus-exceptions part of my brain scream for mercy.) -'f
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases where even the elite rocket surgeons in their ivory control towers can't agree on which is correct. It's less too subtle for JAPH and more too subtle for consensus even among the cognoscenti.. The edge cases would be back to rote memorization. On Sunday, April 11, 2010, John Siracusa sirac...@gmail.com wrote: On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
I can't help but agree with Damian. I don't see much of a point in making a distinction between - and _. More specifically, if a user were to define a function (say, i-hate-camel-case()), it would not be good to let them be the same. Readability would suffer when examining someone's code and you see i_hate_camel_case() and you can't find that function (in my example there are 8 different possibilities for what the actual function was defined as!) However, in core functionality, such a distinction should be made /if it makes sense/. For example, allowing 3 _ 4 in place of 3 - 4 would not make sense, while obscure commands (the PIR functions in rakudo, for example), would do better to not be so stringent (or at least tell you what you did wrong). This is my best guess based on what I know. I don't know the whole story, and I'm always ready to be convinced otherwise. -- Don't Panic!
Re: underscores vs hyphens (was Re: A new era for Temporal)
Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases where even the elite rocket surgeons in their ivory control towers can't agree on which is correct. It's less too subtle for JAPH and more too subtle for consensus even among the cognoscenti.. The edge cases would be back to rote memorization. On Sunday, April 11, 2010, John Siracusa sirac...@gmail.com wrote: On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: Well, if we're not going to try to implement linguistically based hyphenation/underscoriation rules (and I'd still argue that hyphenating adjectives to nouns and underscoring everything else isn't exactly rocket science), then I'd suggest we reconsider a radically different proposal that was made on this list five years ago: http://www.mail-archive.com/perl6-language@perl.org/msg22675.html The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. I was about to say that if hyphens and underscores mean the same thing, then why are Perl 6's identifiers case sensitive? But, you know what, I haven't found any documentation stating they are. Could someone please give me the URI in the official documentation where this is stated. Thanks. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. Eliminate software piracy: use only FLOSS.
Re: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. That is, any isolated internal underscore can be replaced with an isolated internal hyphen (and vice versa), without changing the meaning of the identifier. I am formally opposed to this idea. I see that making underscores and hyphens to be equivalent is akin to having case-insensitive identifiers, where Perl,PERL,perl mean the same thing. Rather what I want is to be everything-sensitive, as AFAIK Perl 6 currently is; if something looks different, it is different. -- Darren Duncan
Re: underscores vs hyphens (was Re: A new era for Temporal)
Em Dom, 2010-04-11 às 07:54 -0700, Damian Conway escreveu: The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. er... this smells like :: and ' in Perl 5... Which, while I find Acme::Don't amusing, cannot be stated as sane design... daniel
Re: A new era for Temporal
On Sun, 11 Apr 2010, Moritz Lenz wrote: I've planned to add such a module to the Perl 6 spec, but some comments on #perl6 suggested it should be kept out of core to prevent bloat. Still if the overall opinion is that Perl 6 should have such a module out of the box, I'll be happy to spec it. I think that having a standard, minimal API for this defined in core as a Date role would be ideal. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: expression of seconds (was Re: A new era for Temporal)
On Fri, 9 Apr 2010, Darren Duncan wrote: conceptual and a usability and a math point of view. If users only want the integer value, then they can just store the second as an integer in the first place. As for the name, well whole_second can be made shorter, or its Users will not always control how the DateTime object is constructed. Nonetheless, when they want to know what is the value for seconds, I think _most_ users will want an integer, not a floating point number. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, 10 Apr 2010, Mark J. Reed wrote: I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. Ditto! If Perl 6 style is hyphens, use hyphens everywhere. That transition from P5 DateTime to P6 will then be a simple s/_/-/g -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: underscores vs hyphens (was Re: A new era for Temporal)
${A-1} = 3.14159;
$A = $A-1;
$A = $A -1;
$A-=2;
$A = 123E-2;
$A = Pi();
$B = sin ($A-1);
$B = sin (${A}-1);
$B = sin($A -1);
-2**2 = -4 except when it comes out +4 as in MS Excel.
_2**2 = +4 in some other languages that use _ as a unary minus operator.
Will editors be bothered when I try to include - in the list of characters
that are considered words when double clicking? When doing a find and replace
all as words?
Is the unicode equivalent of nbsp; allowed in a variable name?
--
-- Give me liberty or give me Obamacare --
Re: underscores vs hyphens (was Re: A new era for Temporal)
Doug McNutt wrote:
${A-1} = 3.14159;
$A = $A-1;
$A = $A -1;
$A-=2;
$A = 123E-2;
$A = Pi();
$B = sin ($A-1);
$B = sin (${A}-1);
$B = sin($A -1);
-2**2 = -4 except when it comes out +4 as in MS Excel.
_2**2 = +4 in some other languages that use _ as a unary minus operator.
Will editors be bothered when I try to include - in the list of characters
that are considered words when double clicking? When doing a find and replace all as
words?
Is the unicode equivalent of nbsp; allowed in a variable name?
See http://perlcabal.org/syn/S02.html#Names for your answers.
Essentially, I believe that any character at all is allowed in a variable name.
Its just that for most characters, when you use them the variable name has to
be quoted. The common unquoted identifier syntax is much more limited, and is
mainly what was being discussed here.
-- Darren Duncan
Re: underscores vs hyphens (was Re: A new era for Temporal)
John (): Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? I'd just like to point out that the current Temporal spec only does methods with underscores, including Cday_of_week. This goes against my personal preferences; I greatly prefer dashes in almost all of the code I write. But I acknowledge that most of the programmers out there seem to expect underscores -- and also, the aim was to produce a small delta from CPAN's DateTime and not change around things ad lib. // Carl
Re: underscores vs hyphens (was Re: A new era for Temporal)
I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. If Temporal is the first setting module to use multiword identifiers, I vote for hyphens. They're easier on the fingers and the eyes; underscores have always felt like an ugly compromise to make the compiler's job easier. On Saturday, April 10, 2010, Carl Mäsak cma...@gmail.com wrote: John (): Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? I'd just like to point out that the current Temporal spec only does methods with underscores, including Cday_of_week. This goes against my personal preferences; I greatly prefer dashes in almost all of the code I write. But I acknowledge that most of the programmers out there seem to expect underscores -- and also, the aim was to produce a small delta from CPAN's DateTime and not change around things ad lib. // Carl -- Mark J. Reed markjr...@gmail.com
Re: A new era for Temporal
Is Int a proper type? I hope I can use basic operation within Date and hours
in perl6 like:
Date -1/24 + 1/24/60 + Date
On Fri, Apr 9, 2010 at 10:00 PM, Moritz Lenz mor...@faui2k3.org wrote:
Am 09.04.2010 15:33, schrieb Dave Rolsky:
On Thu, 8 Apr 2010, Carl Mäsak wrote:
I do want to explicitly credit Dave Rolsky, whose work on the DateTime
family of modules on CPAN has informed much of the current spec,
sometimes to the point of verbatim copying.
Thanks, but I'd hate to see you copy all my mistakes too!
One thing I think is really important is to offer a Date-only object
without a time component.
The lack of such an object in Perl 5's DateTime family is a real
problem. If you're only interested in dates and date math, time and time
zones just muddies the water.
I fully agree. I found Date::Simple on CPAN to do exactly what I want if I
want date-only arithmetic. Here's a short summary:
* Dates are constructed with today() or date('2010-04-09')
* Operations: Date - Date = Int, Date + Int = Date, Date - Int = Date.
Also ++ and -- are defined for Date objects. (In Perl 6 that would
Date.succ, Date.pred)
* Date objects can be queried for year, month, day, day of week (maybe day
of year too, not sure)
* Date objects stringify in the same format as accepted in the constructor.
That's it.
I hope to find the tuits to add such a type to the spec, and some
additional constructors (like DateTime.Date or so).
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed markjr...@gmail.com wrote: I'd much rather see a single consistent style throughout Yeah, that's was my main point/question. I wanted to know if it was it some intentional convention (e.g., all methods that change the object state use hyphens, and all others use underscores) or if it was just meaningless inconsistency. Perl 6 does need some sort of convention in this area. Since it has a wider range of possible method names, there are more options. It took a little while for Perl 5 to converge on method_names_like_this() (after trying methodNamesLikeThis and LikeThis and so on), but many of those experiments and false starts still linger on CPAN and in end-user code. It'd be nice to avoid all that in Perl 6. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
Mark (), John (): I'd much rather see a single consistent style throughout Yeah, that's was my main point/question. I wanted to know if it was it some intentional convention (e.g., all methods that change the object state use hyphens, and all others use underscores) or if it was just meaningless inconsistency. John, where is the inconsistency of which you write? Curious, I grepped through Temporal.pm in search for hyphens in method names, but found none. // Carl
Re: underscores vs hyphens (was Re: A new era for Temporal)
Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a higher precedence word-separator than the space (or than its intra-identifier stand-in: the underscore). For example: there's an important difference between: initiate_main-sequence_detonator_phase() and: initiate_main_sequence-detonator_phase() The former initiates the detonator phase for the main sequence; the latter initiates the main phase of the sequence detonator. More simply, there's a difference between: $obj1.set_difference($obj2); and: $obj1.set-difference($obj2); The first is setting a difference; the second is computing a difference-of-sets. The rule I intend to use and recommend when employing this new identifier character in multiword names is that you should place an underscore between ordinary unrelated words, and a hyphen only between a word and some modifier that applies specifically to that word. Which, if applied to Temporal, would lead to: my $now = DateTime.from_epoch(time); The Cday method also has the synonym Cday-of-month. (These are also available through the methods Cweek-year and Cweek-number, respectively.) There's a Cday-of-week method, The Cweekday-of-month method returns a number 1..5 The Cday-of-quarter method returns the day of the quarter. The Cday-of-year method returns the day of the year, The method Cwhole-second returns the second truncated to an integer. The Ctime-zone method returns the CDateTime::TimeZone object (i.e. only C.from_epoch() actually uses underscore). Oh, and the optional C:timezone argument to C.new() should probably become C:time-zone for consistency with the C.time-zone() method (or, preferably, we should jut bite the bullet and go with Ctimezone throughout). Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway dam...@conway.org wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). That's certainly an example of how hyphens might gain meaning in Perl 6 names, but I don't think I can endorse it as a convention. People can't even use hyphens correctly in written English. I have very little faith that programmers will do any better in code, leading to the worst of all possible worlds: a convention that is confusing and employed incorrectly much of the time. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
In English, hyphens normally indicate an extra level of reification, where e.g. what is normally a phrase is used in a context that requires a single word: The miller gave us the run of the mill. vs. It was a run-of-the-mill event. As such, examples like day?of?week are somewhat infelicitous, as they could go either way depending on context. In fact, I'd be tempted to go with the punctuation-free weekday, despite spoiling the nice parallelism with day?of?month, year, etc. (Perhaps a generic day_of() that takes a keyword argument would be a useful addition?) But that's going off the track (or off-track). Programming statements do not, in general, read like English, and as such, trying to apply English punctuation rules will at best yield ambiguous results. On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway dam...@conway.org wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a higher precedence word-separator than the space (or than its intra-identifier stand-in: the underscore). For example: there's an important difference between: initiate_main-sequence_detonator_phase() and: initiate_main_sequence-detonator_phase() The former initiates the detonator phase for the main sequence; the latter initiates the main phase of the sequence detonator. More simply, there's a difference between: $obj1.set_difference($obj2); and: $obj1.set-difference($obj2); The first is setting a difference; the second is computing a difference-of-sets. The rule I intend to use and recommend when employing this new identifier character in multiword names is that you should place an underscore between ordinary unrelated words, and a hyphen only between a word and some modifier that applies specifically to that word. Which, if applied to Temporal, would lead to: my $now = DateTime.from_epoch(time); The Cday method also has the synonym Cday-of-month. (These are also available through the methods Cweek-year and Cweek-number, respectively.) There's a Cday-of-week method, The Cweekday-of-month method returns a number 1..5 The Cday-of-quarter method returns the day of the quarter. The Cday-of-year method returns the day of the year, The method Cwhole-second returns the second truncated to an integer. The Ctime-zone method returns the CDateTime::TimeZone object (i.e. only C.from_epoch() actually uses underscore). Oh, and the optional C:timezone argument to C.new() should probably become C:time-zone for consistency with the C.time-zone() method (or, preferably, we should jut bite the bullet and go with Ctimezone throughout). Damian -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
John Siracusa commented: That's certainly an example of how hyphens might gain meaning in Perl 6 names, but I don't think I can endorse it as a convention. People can't even use hyphens correctly in written English. I have very little faith that programmers will do any better in code But then the only alternative is to suffer under Slartibartfast's Conundrum: Slartibartfast: I'd much rather be happy than right, any day. Arthur Dent: And are you? Slartibartfast: Ah, well...that's where it all falls down, of course. ;-) And is it really so hard to teach: use underscore by default and reserve hyphens for between a noun and its adjective? Perhaps it *is*, but then that's a very sad reflection on our profession. I'm certainly not saying we mightn't collectively find a better (more useful) rule, but that one doesn't strike me as particularly hard. Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway dam...@conway.org wrote: And is it really so hard to teach: use underscore by default and reserve hyphens for between a noun and its adjective? Perhaps it *is*, but then that's a very sad reflection on our profession. I'm not sure if the intersection of people who speak English and people who program is better or worse than average when it comes to grammar, but I do know (from editing my share of writing) that the average is very bad and, further, that many programmers do not speak English as a first language, or at all. I'm having trouble imaging any convention that involves mixing word separators being successful. Maybe a completely deterministic one like hyphens after vowels, underscores after consonants, but that's pretty nonsensical. I think it has to be all hyphens or all underscores within a single method name, with the only wiggle room being a possible convention that dictates a different word separator for different kinds of methods. (My personal preference: methods_like_this(), just like in Perl 5. My second choice: methods-like-this(). Either way, no grammar knowledge required beyond knowing where one word ends and another begins—and even that's not a universal skill!) -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 4:53 PM, John Siracusa sirac...@gmail.com wrote: I'm not sure if the intersection of people who speak English and people who program is better or worse than average when it comes to grammar, but I do know (from editing my share of writing) that the average is very bad and, further, that many programmers do not speak English as a first language, or at all. Adjectives and nouns aren't English-only. So Damian's proposal is multi-culti. One could argue that Perl's identifiers, keywords, etc are based on English so that it is more difficult for a non-English speaker to discern why underscore is used in some places and hyphens in other. The solution to that would be rote memorization of method names, including _ and - in the spelling. Not ideal, but most likely what many English speaking programmers would do too. And would cuss over.
Re: underscores vs hyphens (was Re: A new era for Temporal)
Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: I'm having trouble imaging any convention that involves mixing word separators being successful. But the convention Damian is proposing is simply use underscores. Basically camelCase and with_underscores are conventions on how to circunvent the fact that we can't use spaces in our identifiers. What is proposed here is that the p5 convention should be preserved. The hyphen is *not* a space, so it doesn't even get into the discussion of this convention. The basic difference is that when a programmer with sufficient communication skills have a composed word (i.e.: week-day), he will have the ability to use the hyphen instead of either supress it or use an underscore... daniel
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso dan...@ruoso.com wrote: Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: I'm having trouble imaging any convention that involves mixing word separators being successful. But the convention Damian is proposing is simply use underscores. Basically camelCase and with_underscores are conventions on how to circunvent the fact that we can't use spaces in our identifiers. What is proposed here is that the p5 convention should be preserved. The hyphen is *not* a space, so it doesn't even get into the discussion of this convention. The basic difference is that when a programmer with sufficient communication skills have a composed word (i.e.: week-day), he will have the ability to use the hyphen instead of either supress it or use an underscore... These nuances are exactly what will be lost on people who see classes that use both underscores and hyphens in their method names. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
Agreed. Perl borrows vocabulary almost exclusively from English, but it is not English, and its conventions are not those of English. (And the conventions around hyphens that people are citing are quite specifically those of standard written English; other writing systems, even those using the same alphabet and mostly the same punctuation, have different rules). I would personally like to see hyphens used as the standard word separator, with underscores available for exceptions - say, naming a Perl interface method exactly the same as the underlying C function it provides access to. I'd be less happy with underscores everywhere, but either of those solutions is better (IMESHO) than mixing hyphens and underscores, which should be avoided even within an API, never mind a single identifier. On Sat, Apr 10, 2010 at 8:55 PM, John Siracusa sirac...@gmail.com wrote: On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso dan...@ruoso.com wrote: Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: I'm having trouble imaging any convention that involves mixing word separators being successful. But the convention Damian is proposing is simply use underscores. Basically camelCase and with_underscores are conventions on how to circunvent the fact that we can't use spaces in our identifiers. What is proposed here is that the p5 convention should be preserved. The hyphen is *not* a space, so it doesn't even get into the discussion of this convention. The basic difference is that when a programmer with sufficient communication skills have a composed word (i.e.: week-day), he will have the ability to use the hyphen instead of either supress it or use an underscore... These nuances are exactly what will be lost on people who see classes that use both underscores and hyphens in their method names. -John -- Mark J. Reed markjr...@gmail.com
Re: A new era for Temporal
Mark (): This looks much better. Thank you. When can we expect to see the new version implemented in Rakudo? Need any help on that front? A preliminary version is already checked in, and works. It's not full-featured yet, but work is underway. Commits are appreciated, as always. http://github.com/rakudo/rakudo/blob/master/src/core/Temporal.pm // Carl
Re: A new era for Temporal
On Thu, 8 Apr 2010, Carl Mäsak wrote: I do want to explicitly credit Dave Rolsky, whose work on the DateTime family of modules on CPAN has informed much of the current spec, sometimes to the point of verbatim copying. Thanks, but I'd hate to see you copy all my mistakes too! One thing I think is really important is to offer a Date-only object without a time component. The lack of such an object in Perl 5's DateTime family is a real problem. If you're only interested in dates and date math, time and time zones just muddies the water. Also, I really don't think that supporting time zones only in the form of +0100 is useful. This gives the _illusion_ of time zone support, but will inevitable cause all sorts of user facing problems. Buy maybe this is part isn't done? On a smaller point, I think second vs whole_second is the wrong Huffman coding. I'd think most people want the integer value. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: A new era for Temporal
Am 09.04.2010 15:33, schrieb Dave Rolsky:
On Thu, 8 Apr 2010, Carl Mäsak wrote:
I do want to explicitly credit Dave Rolsky, whose work on the DateTime
family of modules on CPAN has informed much of the current spec,
sometimes to the point of verbatim copying.
Thanks, but I'd hate to see you copy all my mistakes too!
One thing I think is really important is to offer a Date-only object
without a time component.
The lack of such an object in Perl 5's DateTime family is a real
problem. If you're only interested in dates and date math, time and time
zones just muddies the water.
I fully agree. I found Date::Simple on CPAN to do exactly what I want if
I want date-only arithmetic. Here's a short summary:
* Dates are constructed with today() or date('2010-04-09')
* Operations: Date - Date = Int, Date + Int = Date, Date - Int =
Date. Also ++ and -- are defined for Date objects. (In Perl 6 that would
Date.succ, Date.pred)
* Date objects can be queried for year, month, day, day of week (maybe
day of year too, not sure)
* Date objects stringify in the same format as accepted in the constructor.
That's it.
I hope to find the tuits to add such a type to the spec, and some
additional constructors (like DateTime.Date or so).
expression of seconds (was Re: A new era for Temporal)
Dave Rolsky wrote: On a smaller point, I think second vs whole_second is the wrong Huffman coding. I'd think most people want the integer value. Well, whatever you call things, the most important thing is to keep the seconds count as a single number which can do fractions, or if you really must break them up, then have the fractional second part as a real in 0..^1. The whole nanosecond-integer-fixed-onesizefitsall-subsecond-precision thing is a terrible hack. Keeping a single number for seconds is best from a conceptual and a usability and a math point of view. If users only want the integer value, then they can just store the second as an integer in the first place. As for the name, well whole_second can be made shorter, or its value could automatically truncate if users assigned it to an Int. Even Larry said that using reals for seconds if we're supporting fractional seconds is preferred in Synopsis 2, and I agree; if people think otherwise, then what is the rationale? -- Darren Duncan
Re: expression of seconds (was Re: A new era for Temporal)
Darren Duncan wrote: Dave Rolsky wrote: On a smaller point, I think second vs whole_second is the wrong Huffman coding. I'd think most people want the integer value. Well, whatever you call things, the most important thing is to keep the seconds count as a single number which can do fractions, or if you really must break them up, then have the fractional second part as a real in 0..^1. The whole nanosecond-integer-fixed-onesizefitsall-subsecond-precision thing is a terrible hack. Keeping a single number for seconds is best from a conceptual and a usability and a math point of view. If users only want the integer value, then they can just store the second as an integer in the first place. As for the name, well whole_second can be made shorter, or its value could automatically truncate if users assigned it to an Int. my Int $x implies a constraint, *not* a coercion. That's: $dt.seconds.Int Though even clearer and same number of characters as whole_seconds is: $dt.seconds.round Jonathan
Re: expression of seconds (was Re: A new era for Temporal)
Jonathan Worthington wrote: Darren Duncan wrote: Dave Rolsky wrote: On a smaller point, I think second vs whole_second is the wrong Huffman coding. I'd think most people want the integer value. Well, whatever you call things, the most important thing is to keep the seconds count as a single number which can do fractions, or if you really must break them up, then have the fractional second part as a real in 0..^1. The whole nanosecond-integer-fixed-onesizefitsall-subsecond-precision thing is a terrible hack. Keeping a single number for seconds is best from a conceptual and a usability and a math point of view. If users only want the integer value, then they can just store the second as an integer in the first place. As for the name, well whole_second can be made shorter, or its value could automatically truncate if users assigned it to an Int. my Int $x implies a constraint, *not* a coercion. That's: $dt.seconds.Int Though even clearer and same number of characters as whole_seconds is: $dt.seconds.round Jonathan Yes, exactly, thank you Jonathan. -- Darren Duncan
Re: expression of seconds (was Re: A new era for Temporal)
On Fri, Apr 9, 2010 at 3:06 PM, Jonathan Worthington jonat...@jnthn.netwrote: Though even clearer and same number of characters as whole_seconds is: $dt.seconds.round This makes more sense to me than the first example you listed because when dealing with time measurement, I rarely think of seconds that are broken down to sub-measurements. Rather, I often think of seconds as an aggregation of milliseconds, so rounding the fraction (a second is internally a fraction of milliseconds) Just Makes Sense. The idea continues downwards to the smallest represented unit of time and upwards to the largest represented unit. -Jason s1n Switzer
Re: A new era for Temporal
On Thu, 8 Apr 2010, Carl Mäsak wrote: We (mberends and masak) just pushed a commit to S32::Temporal which completely replaces what we had before. The changes are rooted in hours of discussion on #perl6, and we feel rather more confident with what we have now than with what we had before. That said, discussion is very welcome. I do want to explicitly credit Dave Rolsky, whose work on the DateTime family of modules on CPAN has informed much of the current spec, sometimes to the point of verbatim copying. Allow me to point out that Dave Rolsky acually wrote or designed a reasonable portion of what was there before the edit by lue (with other parts having been written by myself). I figure Dave is the biggest expert we have on the topic, and hopefully he's learned from his mistakes in implementing DateTime. My understanding was that the spec at that time incorporated things he'd learned. Thus, I'd like to see his work as the basis for this. Thus, I'd like to see an incremental evolution from the pre-lue version, based on discussion between Dave Rolsky and other interested parties. Times and dates are not as straightforward as they look. Feel free to turf out anything I wrote, though :). Allow me to point you all to at least one previous discussion on the matter. http://www.nntp.perl.org/group/perl.perl6.language/2009/02/msg30780.html HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK-
Re: A new era for Temporal
Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? -John
underscores vs hyphens (was Re: A new era for Temporal)
John Siracusa wrote: Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? There are 2 answers to that question: 1. Unlike with Perl 5, Perl 6 supports the use of hyphens in bareword identifiers, except as the first character. In principle, I think this is very welcome, as hyphens are just as reasonable for separating words as underscores, and several other languages support this, and in XML at least it is standard practice. For that matter, Perl 6 also supports single-quotes in bareword identifiers, so you can have routines like isn't() or can't(); I don't like that so much as I prefer not to have characters used for quoted string delimiters in the middle of a bareword string, but I can understand why it was done. And so, if the language supports it and it is reasonable, why not use it? 2. I do think that any particular module should be internally consistent in its naming scheme, so Temporal should use all-underscores or all-hyphens, but not mix and match, unless there is a conceptual distinction between things named with the different styles that are worth highlighting by using different styles; barring that, such an inconsistency in Temporal may be something that should be fixed. -- Darren Duncan P.S. My Muldis D language also has the feature of Perl 6 about supporting both underscore and hyphen separated bareword identifiers, though I don't support the single quotes. While users are free to use what style they want, for all the built-in stuff I have adopted the following convention: For all normal identifiers like the names of system-defined routines or variables or parameters or attributes etc, I use underscore separation. (Type names are typically camel-case like in Perl.) For language keywords or special operator syntaxes in the concrete language grammars, I use hyphen separators when said keywords have multiple words, rather than either underscores or whitespace. I find that this distinction is very effective at making different things look different, and for the keywords or special syntaxes, hyphens actually look better than either underscores or spaces.
A new era for Temporal
We (mberends and masak) just pushed a commit to S32::Temporal which completely replaces what we had before. The changes are rooted in hours of discussion on #perl6, and we feel rather more confident with what we have now than with what we had before. That said, discussion is very welcome. I do want to explicitly credit Dave Rolsky, whose work on the DateTime family of modules on CPAN has informed much of the current spec, sometimes to the point of verbatim copying. The change that just went in is complete in itself, but we still expect to add the following details to it: * DateTime::TimeZone * The methods strftime and strptime * DateTime::Duration * ops: $dt + $dur, $dt - $dur, $dt - $dt Expect these in the next few days or so. // Carl
Re: A new era for Temporal
This looks much better. Thank you. When can we expect to see the new version implemented in Rakudo? Need any help on that front? On Thu, Apr 8, 2010 at 5:52 PM, Carl Mäsak cma...@gmail.com wrote: We (mberends and masak) just pushed a commit to S32::Temporal which completely replaces what we had before. The changes are rooted in hours of discussion on #perl6, and we feel rather more confident with what we have now than with what we had before. That said, discussion is very welcome. I do want to explicitly credit Dave Rolsky, whose work on the DateTime family of modules on CPAN has informed much of the current spec, sometimes to the point of verbatim copying. The change that just went in is complete in itself, but we still expect to add the following details to it: * DateTime::TimeZone * The methods strftime and strptime * DateTime::Duration * ops: $dt + $dur, $dt - $dur, $dt - $dt Expect these in the next few days or so. // Carl -- Mark J. Reed markjr...@gmail.com
