Re: r25402 - in docs/Perl6/Spec: . S32-setting-library

[Darren Duncan]

Darren Duncan wrote:
Presumably the other enhancements we discussed like using the 'Instant' 
name will follow soon.


Well, I spoke too quickly; its already done with r25405; good start there. -- 
Darren Duncan

Re: r25405 - docs/Perl6/Spec/S32-setting-library

[Darren Duncan]

pugs-comm...@feather.perl6.nl wrote:

Author: wayland
Date: 2009-02-19 08:47:26 +0100 (Thu, 19 Feb 2009)
New Revision: 25405

Modified:
   docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
Improved Temporal (previously DateTime) stuff a bit


Okay, so I have a few specific suggestions ...

And by the way, this is easier to read at 
http://perlcabal.org/svn/pugs/view/docs/Perl6/Spec/S32-setting-library/Temporal.pod 
 where you can just see the current version ...



+role   Temporal::Date {
+   has Int $.year;
+   has Int $.month;
+   has Int $.day; # Day of month
+   has Int $.dayofweek;


You could make month/day into positive integers or "subtype of Int where 1..12" 
etc, though it isn't strictly necessary.  Leave year as Int of course, since at 
least in the proleptic Gregorian etc you can have negatives or zero.



+   has Int $.era; # BC, AD, etc, depending on locale
+   has Str $.defaultformat; # A CLDR-formatted string, for use with 
toString();


Now $.era you definitely should change, either to Str like defaultformat or come 
up with some enumerated type, as Int seems wrong there, though Str is probably 
best to make later extensions easier, especially if you're sticking with plain 
Int for the others.



+   multi method infix:{'<=>'}(Temporal::Date $self, Temporal::Duration 
$other);


I don't think it makes sense to compare any kind of Instant/Date/Time to a 
Duration for relative order; they are not the same thing like a position isn't 
the same as a length.



+role   Temporal::Time {
has $.hour;
has $.minute;
has $.second;


You didn't give these attributes types like you did for Date.

I suggest Int (or UInt) for hour/minute if you want to be consistent, and 
Rat/Num for second.



+   multi method infix:{'<=>'}(Temporal::Time $self, Temporal::Duration 
$other);


Likewise with the Date example this doesn't make sense, comparing a position to 
a length.



+role   Temporal::Subsecond {
+   has $.nanosecond;
+}


Two things:

1. You should just make that a Rat/Num $second or $frac_second or something.  I 
know DateTime.pm has the precedent but counting in nanoseconds is too arbitrary, 
especially since newer/future machines would have a higher resolution than that. 
 Using Rat/Num will let this be open-ended.


2. Why not just make normal $.second in Time be a Rat/Num instead?  Users can 
always subtype it with "where is_desired_precision()" or something if they want 
that.  Separating out whole and fractional seconds has a design smell to me 
since they measure the same unit (unlike min/hour/day/mon/year, each of which 
deserve to be separate).



+class	Temporal::Instant 



+   multi method Temporal::Instant infix:<+>(Temporal::Instant $self, 
Duration $other);
 
+	multi method infix:<->(Temporal::Instant $self, Duration $other);

+   multi method infix:<->(Temporal::Instant $self, Duration $other);


You repeated '-' and also the declaration is different than that for '+'; I 
assume you wanted to make your '-' like your '+'.



+   multi method infix:{'<=>'}(Temporal::Instant $self, Duration $other);


Again with the doesn't make sense as per Duration <=> Date|Time.

+class	Temporal::Duration 
+	does Temporal::Date 
+	does Temporal::Time 
+	does Temporal::Subsecond

+{
+}


Okay, I see why you did what you did with those 3 above "doesn't make sense" 
examples; but in that case, I think what you really want is to move the "<=>" 
out of Date|Time and into Duration.  And stuff.


In fact, while they look similar, I wouldn't reuse the Date|Time roles between 
Instant and Duration.  While they consist of the same units, the allowed values 
differ; for Duration any Int is allowed while for Instant generally only 
non-negative constrained values like 1..23 etc are allowed.


But who knows, maybe you can still make the idea of sharing roles in that way 
work, and I do see it making sense in some ways.



+=head2 Temporal::Recurring
+
 This class specifies when a repetitive action (eg. a cron job) happens.  
 
-class	DateTime::Recurring {

+class  Temporal::Recurring {
 ...
 }


I should point out that in some respects any Time is effectively a Recurring 
because it doesn't specify a day and so could mean "on every day"; similarly eg 
if you have a Date but leave the Year undefined (repeat every year) and so on. 
Unless your Instant|Date|Time requires all attributes to be defined, or all unit 
defined attributes than any defined attribute to be defined.


Or more likely in practice, leaving those parts out just means "don't know" and 
not recurring.


But a dedicated Recurring is definitely useful since it can specify other kinds 
of recurrings, like "every 90 minutes from X Instant" for example, and it 
unambiguously means recurring rather than don't know.


-- Darren Duncan

Re: Spec reorganisation

[Timothy S. Nelson]

On Thu, 19 Feb 2009, Carl Mäsak wrote:


Timothy (>), Moritz (>>):

Speaking of Tree, let me quote from IRC:

09:23 < masak> it's a bit unfortunate that the identifier 'Tree' is now
 squatted by an internal class in Perl 6, which is not
general
 enough to reprenest an arbitrary tree data structure.

I fully agree with that. If it's not the most general tree, don't name
it Tree.


   Hmm.  I'm wanting the API for this tree structure to be able to
represent arbitrary general trees.  I'm limited by the fact that the main
trees I'm familiar with are filesystems and XML, and a little with LDAP.
 Can you give examples of types of tree that aren't representable with what
I'm doing?


I'll give it a shot. As previously seen in S16:

role  Tree does Tree::Node {
  has Tree::Node $root; # The root directory
  has Tree::Node $cwn; # The current working directory (node)
  has Bool $can_multiple_parent; # Nodes can have multiple parents
  has Bool $can_link; # Unix links, Windows shortcuts, etc
}

A tree is a graph without cycles.


	Ok, maybe I should call this Graph then, but that would *really* 
confuse people.


The concept of a "root" is very common in computer representations, but in 
no way necessary for a general tree. In fact, in phylogenetics, it's 
business as usual to handle unrooted trees. This makes the $root attribute 
meaningless in at least some cases.


	Interesting.  I'm happy to assume that $root is allowed to be 
Undefined, I think.  But let me ask a question; were you to represent an 
unrooted tree in a computer, how would you do it so that, if you had to look 
around the tree, you could do it?  You'd need some node that was an 
entry-point into the tree.  That's the purpose I'm trying to get at here.


	Also, I have a suspicion that the problem we have here is that the 
term "node" is being used slightly differently by the computer science 
community and the phylogenetic community.  When I look at the unrooted tree 
on:


http://en.wikipedia.org/wiki/Phylogenetic_tree

	...it looks to me like they don't call anything a node unless it has a 
dot at it.  But if I were building a data structure to represent that tree 
(eg. so that I could auto-generate the image on the Wikipedia page), I'd make 
a root node for it, but somehow label it an "invisible" node, and when the 
image was generated, while there would be a node for it inside the computer, 
there'd be no dot on the graph.  So in Computer Science terms, there'd be a 
root node, but in Phylogenetic terms, there wouldn't.  And I think I'd do 
things that way whether I was using Perl6 or not.


	(incidentally, my knowledge of phylogenetics is entirely drawn from 
that Wikipedia page).


Of course, I could be wrong, so I encourage you to keep prodding :).


The $cwn is meaningless in most tree implementations I can think of.


	Agreed, as in XML.  But assuming that that can be Undefined is also 
not a problem.



As to $can_multiple_parent, a structure which allows nodes with
multiple parents is not a tree, it's a directed graph.


	Right, in mathematical/computer science terms, but how often to you 
hear people refer to a file tree/filesystem tree vs. file graph :).


	Hmm.  I've also seen it called Plex.  Would it make everyone happier 
if I called the whole thing "Plex" instead?  Admittedly I've never heard 
anyone refer to a filesystem plex, but at least that has no semantic 
conflicts, and is short enough that it could catch on :).


Whether symlinks are allowed is (1) fairly filesystem-specific, and (2) not 
very pertinent to the tree object itself.


	Hmm.  I agree.  I think what we have here is a miscommunication 
(probably my fault :) ) about what I'm trying to achieve.


	What I want to do is make an API which has many features that the IETF 
community would call MAY instead of MUST; ie. "You don't have to do X, but 
if you do, call it Y".  I agree it's filesystem-specific; it should probably 
be a private attribute or something.  I was wanting the info stored somewhere 
so that it could be looked up, but maybe the thing to do is to let people try 
to link, and catch exceptions :).



What's left is, in effect, this:

role Tree does Tree::Node {
}

While an empty role _does_ indeed have potential, and could be made to
work with most tree implementations out there, it's also a bit of a
shame to pretend to provide four attributes with Tree, neither of
which is actually an attribute of a general graph-theoretical tree.
Just sayin'.


Depends on what you're trying to achieve; see above :).


Another thing I found myself saying yesterday was that "designing a
language also involves knowing when not to decide things for the
programmer." I wish there was a way to say this, while also
emphasizing my appreciation for the many good changes to S16. Files
and I/O are obviously areas where the bikeshedding tendency grows
extra strong, so I'm glad someone actually goes in and does things to
t

Re: r25402 - in docs/Perl6/Spec: . S32-setting-library

[Timothy S. Nelson]

On Thu, 19 Feb 2009, Moritz Lenz wrote:


Hi,

as necessary as this step is, it opens up a new task that I haven't
though of before.

First all the new POD files should appear in a sensible manner on
L, and second there should be good and easy
way to smartlink to these new documents (for example with
L).

pugs-comm...@feather.perl6.nl wrote:

   docs/Perl6/Spec/S32-setting-library/Numeric.pod
   docs/Perl6/Spec/S32-setting-library/Scalar.pod
   docs/Perl6/Spec/S32-setting-library/String.pod


I'd prefer those to have a filename that corresponds the type name, ie
Num.pod and Str.pod - any objections?


	One objection.  Numeric contains Bool, Num, Complex, and :Trig.  Which 
should we call it?  :).


	Of course, an option would be to make 3 or 4 separate files, and that 
may be best in the long run.  Or we could do 
S32-setting-library/Numeric/Bool.pod if we liked that better :).


	My not-very-well-thought-out reason for calling it String is in case 
we wanted to put other string-related stuff in there that doesn't go on Str, 
but that's probably stupid, so I've no complaints about String.pod => Str.pod.


	Also, if there's something special we need to do to rename files, it 
might be wise to hold off for a day or so, to see if we want to rename Tree to 
Plex, as is being discussed on another thread.  If there are no objections 
from anyone, I'm happy to rename Tree to Plex.


:)


-
| 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: r25405 - docs/Perl6/Spec/S32-setting-library

[Timothy S. Nelson]

On Thu, 19 Feb 2009, Darren Duncan wrote:


+role   Temporal::Date {
+   has Int $.year;
+   has Int $.month;
+   has Int $.day; # Day of month
+   has Int $.dayofweek;


You could make month/day into positive integers or "subtype of Int where 
1..12" etc, though it isn't strictly necessary.  Leave year as Int of course, 
since at least in the proleptic Gregorian etc you can have negatives or zero.


	I want this role to be composable into the heavy-lifting non-core 
non-Gregorian modules as well as into Temporal::Interval, so I'm trying not to 
get too specific.



+   has Int $.era; # BC, AD, etc, depending on locale
+	has Str $.defaultformat; # A CLDR-formatted string, for use with 
toString();


Now $.era you definitely should change, either to Str like defaultformat or 
come up with some enumerated type, as Int seems wrong there, though Str is 
probably best to make later extensions easier, especially if you're sticking 
with plain Int for the others.


	I gave era the flick.  I'll assume that negative year are BC, and let 
CLDR worry about the output.


+	multi method infix:{'<=>'}(Temporal::Date $self, Temporal::Duration 
$other);


I don't think it makes sense to compare any kind of Instant/Date/Time to a 
Duration for relative order; they are not the same thing like a position 
isn't the same as a length.


Ok, fixed.


+role   Temporal::Time {
has $.hour;
has $.minute;
has $.second;


You didn't give these attributes types like you did for Date.

I suggest Int (or UInt) for hour/minute if you want to be consistent, and 
Rat/Num for second.


Fixed, I think.



+	multi method infix:{'<=>'}(Temporal::Time $self, Temporal::Duration 
$other);


Likewise with the Date example this doesn't make sense, comparing a position 
to a length.


Fixed.


+role   Temporal::Subsecond {
+   has $.nanosecond;
+}


Two things:

1. You should just make that a Rat/Num $second or $frac_second or something. 
I know DateTime.pm has the precedent but counting in nanoseconds is too 
arbitrary, especially since newer/future machines would have a higher 
resolution than that.  Using Rat/Num will let this be open-ended.


	We also want to be able to avoid floating point rounding problems too. 
I called the role "Subsecond" instead of "Nanosecond" because I want to make 
it possible for future machines to add a $.femtosecond if needed :).


2. Why not just make normal $.second in Time be a Rat/Num instead?  Users can 
always subtype it with "where is_desired_precision()" or something if they 
want that.  Separating out whole and fractional seconds has a design smell to 
me since they measure the same unit (unlike min/hour/day/mon/year, each of 
which deserve to be separate).


	Hmm.  Well, I'll think about it for a while, and hope that Dave Rolsky 
will chime in on this :).


+class	Temporal::Instant 


+	multi method Temporal::Instant infix:<+>(Temporal::Instant $self, 
Duration $other);

 +  multi method infix:<->(Temporal::Instant $self, Duration $other);
+   multi method infix:<->(Temporal::Instant $self, Duration $other);


You repeated '-' and also the declaration is different than that for '+'; I 
assume you wanted to make your '-' like your '+'.


	I've fixed the multi - declarations (there were indeed supposed to be 
two).  I've been sloppy about return values, but I've fixed that now too.



+   multi method infix:{'<=>'}(Temporal::Instant $self, Duration $other);


Again with the doesn't make sense as per Duration <=> Date|Time.


Fixed.

+class	Temporal::Duration +	does Temporal::Date +	does 
Temporal::Time +	does Temporal::Subsecond

+{
+}


Okay, I see why you did what you did with those 3 above "doesn't make sense" 
examples; but in that case, I think what you really want is to move the "<=>" 
out of Date|Time and into Duration.  And stuff.


In fact, while they look similar, I wouldn't reuse the Date|Time roles 
between Instant and Duration.  While they consist of the same units, the 
allowed values differ; for Duration any Int is allowed while for Instant 
generally only non-negative constrained values like 1..23 etc are allowed.


But who knows, maybe you can still make the idea of sharing roles in that way 
work, and I do see it making sense in some ways.


	I thought for a bit I did too, but now I've changed my mind, socks, 
and shoes :).



+=head2 Temporal::Recurring
+
 This class specifies when a repetitive action (eg. a cron job) happens. 
-class	DateTime::Recurring {

+class  Temporal::Recurring {
 ...
 }


I should point out that in some respects any Time is effectively a Recurring 
because it doesn't specify a day and so could mean "on every day"; similarly 
eg if you have a Date but leave the Year undefined (repeat every year) and so 
on. Unless your Instant|Date|Time requires all attributes to be defined, or 
all unit defined attributes than any defined attribute to be defined.


Or more likely in prac

Re: Spec reorganisation

[Daniel Ruoso]

Em Qui, 2009-02-19 às 22:57 +1100, Timothy S. Nelson escreveu:
>   Interesting.  I'm happy to assume that $root is allowed to be 
> Undefined, I think.  But let me ask a question; were you to represent an 
> unrooted tree in a computer, how would you do it so that, if you had to look 
> around the tree, you could do it?  You'd need some node that was an 
> entry-point into the tree.  That's the purpose I'm trying to get at here.

Not at all, that is the same as saying that a list must always be
ordered, and that it should have a beggining. Circular Lists are very
well known.

If you think in a BTree, for instance, you usually don't have a root
node, since a BTree is simply a way to view a list, and you might
receive a node and work only from that context onward. That even applies
for filesystems: what if your process calls (2)chroot? what happens to
the "root" node?

On the other hand, I have to disagree with masak that it would be an
empty role, because there is indeed one operation that you can always do
in a tree node:

role Tree::Node {
   method List lookup(*%options);
}

on a BTree you would have

  $node.lookup(:left);
  $node.lookup(:right);

on a Filesystem you would have

  $node.lookup(:name);
  $node.lookup(:name<..>); 
  $node.lookup(:parent);
  $node.lookup(:root);
  $node.lokoup(:absolute);

on a match object

  $node.lookup(:hiearchy);

on a XML document you would have

  $node.lookup(:xpath);
  $node.lookup(:attribute);
  # of course, DOM would be a complementary API.

Where it could be spec that

  $node.lookup()

should return all the child elements as a lazy list, which means that a
generic tree traversal could be written (and maybe the tree transforming
sub-language).

daniel

Temporal and purity (was: Re: IO, Trees, and Time/Date)

[Timothy S. Nelson]

	Just to clear up ahead of time, the consensus both here and on IRC 
seemed to be that in the core, we put a basic Temporal::Instant object that 
about powerful enough to deal with:

-   localtime/gmtime functionality
-   ctime, mtime, etc, in stat()
-   nanoseconds or whatever needed for (I think) alarm() and things

	There is bucketloads of other functionality that could be implemented, 
and I've included a few of what I consider to be the most important (ie. make 
it work with operators), but we hope to leave most other stuff to CPAN.  Even 
the naming of months, etc, can be left to CPAN.  I've got a few hooks in there 
to deal with things that CPAN will want, but hopefully that's all.


On Thu, 19 Feb 2009, Martin D Kealey wrote:


On Wed, 18 Feb 2009, Timothy S. Nelson wrote:

I'll try and design an API that does what DateTime does, but:



1. Uses more variables, of which I expect the getters and setters to be
overridden.


Please let's NOT have setters on "time" objects.  They're a source of subtle
bugs in such client code AND having mutable objects means you can't use them
in otherwise pure code. (See the separate thread on immutability and
purity.)

Rather, let's have immutable time "values", and methods which return other
"values" where various computations (*1) have been applied. Provide
constructors which take the Y/M/D/h/m/s/dst_now/dst_rule tuple.


	I followed the bits about the computations, and I think I see what 
you're saying about the constructor, but I don't know what you mean by 
'immutable time "values"'.  Could you expand on this a bit?



And please let's not have any implied "default" timezone. That's not to say
it has to be difficult or cumbersome, just explicit, perhaps something like
one of these:

 my &localtime = DateTime::Gregorian.localize( :host_default );
 my &localtime = DateTime::Gregorian.localize( :user_env );
 my &localtime = DateTime::Gregorian.localize( 
:http_client(%http_client_headers) );
 my &localtime = DateTime::Gregorian.localize( :db_server($odbc_handle) );
 my &gmtime= DateTime::Gregorian.localize( :utc );
 my &swatch= DateTime::Gregorian.localize( :tz('Europe/Geneva'), :no_dst );


	Actually, I admit I'd love to get rid of gmtime and localtime 
altogether, while keeping the functionality.  It seems to me that each is 
really a constructor with a different default timezone.  Likewise I'd like to 
get rid of the time() function.


	I snipped the comments about the complexity of calculations.  I figure 
that for most purposes, people don't want the complexity, and as long as CPAN 
can supply something that implements the same role, I'm happy to leave it to 
them.


:)


-
| 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-

r25445 - docs/Perl6/Spec/S32-setting-library

[pugs-commits]

Author: autarch
Date: 2009-02-19 19:14:48 +0100 (Thu, 19 Feb 2009)
New Revision: 25445

Modified:
   docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
This is a very drastic revision (hopefully this won't turn into a revert war ;)

Here's the changes in summary:

removed all references to ...

Locales, including eras, which come from a locale - this is a vast and 
complicated domain

Alternate calendars - also vast and complicated

String parsing of any sort - ditto, see the pattern here? ;)

Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed

Comparing dates or times to durations - this just doesn't make
sense. Is 2009-02-23 greater or less than 5 days?

Any sort of date or time math

Added iso8601 output for every role, and made that the
stringification. ISO8601 is unambiguous world-wide, easy to read, and
easy to output.

Renamed Temporal::Instant to Temporal::DateTime

Got rid of Temporal::Subsecond and just made Temporal::Time allow for
sub-second resolutions. Not sure if this is best done with an
$.attosecond attribute or as a decimal number.

Renamed Temporal::Timezone to Temporal::TimeZone::Observance. The
latter is a simple thing which represents the offset, isdst flag, and
short name for a given local time. This information should be
available on all supported platforms. TimeZones themselves are
complicated and very much platform-dependent. Better to leave this as
a separate CPAN6 distro.

Got rid of all mutating operators on everything. The built-ins should
be immutable for simplicity.

Added numification overloading for Temporal::DateTime, which gives us
comparison for free.


Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-02-19 17:45:07 UTC 
(rev 25444)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-02-19 18:14:48 UTC 
(rev 25445)
@@ -15,9 +15,10 @@
 Moritz Lenz 
 Tim Nelson 
 Daniel Ruoso 
+Dave Rolsky 
  Date:  19 Mar 2009 extracted from S29-functions.pod and S16-IO.pod
  Last Modified: 19 Feb 2009
- Version:   1
+ Version:   2
 
 The document is a draft.
 
@@ -31,8 +32,7 @@
 
 =item gmtime
 
- our Time multi gmtime ( Time $time? )
- our Time multi method gmtime ( Time $time: )
+ our Temporal::DateTime multi gmtime ( Num $epoch? = time() )
 
 Identical to:
 
@@ -40,179 +40,160 @@
 
 =item localtime
 
- our Time multi localtime ( Time $time?, Time::Zone $tz? )
- our Time multi method localtime ( Time $time: Time::Zone $tz? )
+ our Temporal::DateTime multi localtime ( Num $epoch? = time() )
 
-Returns a time object whose default timezone is C<$tz> (or the system's
-default timezone if none is provided).
+These functions take an epoch value and return a C
+object. For C the time zone is taken from the local
+system. For C the time zone is aways UTC.
 
-If used as a function, and no time is provided, the current time is used.
+If no time is provided, the current time is used.
 
-Note that no matter what, C<$time>'s concept of "its timezone" is discarded
-in favor of something new.
-
 =item time
 
- our Time multi time()
+ our Num time()
 
-Returns a C object. There are a number of uses for this
-object, all of which can be found in the documentation for C.
+Returns an epoch value for the current time.
 
-There is, by default, no timezone associated with this Time object, so
-whatever default the system has will take over if timezone-specific
-data is accessed.
-
 =back
 
 =head1 Roles
 
+The intent behind these classes is to provide an absolutely minimal,
+but still useful, set of core behavior. The assumption is that the
+core will ship with a simple set of classes so that C and
+C have something to return.
+
 =head2 Temporal::Date
 
-You probably want to use the Temporal::Instant object instead.  
+You probably want to use the Temporal::DateTime object instead.
 
 role   Temporal::Date {
-   has Int $.year;
-   has Int $.month;
-   has Int $.day; # Day of month
-   has Int $.dayofweek;
-   has Int $.era; # BC, AD, etc, depending on locale
-   has Str $.defaultformat; # A CLDR-formatted string, for use with 
toString();
+my subset Month of Int where { 1 <= $^a <= 12 };
+my subset Day of Int where { 1 <= $^a <= 31 };
+my subset DayOfWeek of Int where { 1 <= $^a <= 7 };
 
-   method  toString($format => $.defaultformat);
+   has Int   $.year;
+   has Month $.month = 1;
+   has Day   $.day = 1;
 
-   multi method Temporal::Instant infix:<+>(Temporal::Date $self, 
Temporal::Time $other);
-   multi method Temporal::Instant infix:<+>(Temporal::Date $self, 
Temporal::Duration $other);
+# This can be cached internally, but it's a calculated value,
+# not an attribute.
+   method day-of-week () retu

Temporal revisited

[Dave Rolsky]

After some discussion I made a number of drastic revisions to 
S32-setting-library/Temporal.pod


What I want to see in Perl 6 is a set of very minimal roles that can be 
used to provide a simply object from gmtime() and localtime(). These 
objects should not handle locales, proper Olson timezones, string parsing, 
user-defined formatting, or math.


They're basically simply little data blobs with some overloading and a few 
handy methods.


I imagine that a real classes which do math, handle leap seconds, 
formatting, and so on will _also_ do these roles, but this should be done 
out of core.


I don't really know Perl 6 all that well, so I'd welcome review, in 
particular of my Perl 6-isms, and also just of the general concepts.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: r25402 - in docs/Perl6/Spec: . S32-setting-library

[Moritz Lenz]

Hi,

as necessary as this step is, it opens up a new task that I haven't
though of before.

First all the new POD files should appear in a sensible manner on
L, and second there should be good and easy
way to smartlink to these new documents (for example with
L).

pugs-comm...@feather.perl6.nl wrote:
>docs/Perl6/Spec/S32-setting-library/Numeric.pod
>docs/Perl6/Spec/S32-setting-library/Scalar.pod
>docs/Perl6/Spec/S32-setting-library/String.pod

I'd prefer those to have a filename that corresponds the type name, ie
Num.pod and Str.pod - any objections?

Cheers,
Moritz
-- 
Moritz Lenz
http://perlgeek.de/ |  http://perl-6.de/ | http://sudokugarden.de/

Re: r25405 - docs/Perl6/Spec/S32-setting-library

[Darren Duncan]

Timothy S. Nelson wrote:

On Thu, 19 Feb 2009, Darren Duncan wrote:
You could make month/day into positive integers or "subtype of Int 
where 1..12" etc, though it isn't strictly necessary.  Leave year as 
Int of course, since at least in the proleptic Gregorian etc you can 
have negatives or zero.


I want this role to be composable into the heavy-lifting non-core 
non-Gregorian modules as well as into Temporal::Interval, so I'm trying 
not to get too specific.


Sure, fair enough.


+roleTemporal::Subsecond {
+has$.nanosecond;
+}


Two things:

1. You should just make that a Rat/Num $second or $frac_second or 
something. I know DateTime.pm has the precedent but counting in 
nanoseconds is too arbitrary, especially since newer/future machines 
would have a higher resolution than that.  Using Rat/Num will let this 
be open-ended.


We also want to be able to avoid floating point rounding problems 
too. I called the role "Subsecond" instead of "Nanosecond" because I 
want to make it possible for future machines to add a $.femtosecond if 
needed :).


Don't get hung up on floating point.  That's assuming an implementation detail 
which will very often not exist.  Instead you should be assuming that the 
conceptually non-integer numeric type is exact precision like a big-rat, and if 
any implementations are less exact, then this can be matched or undercut by a 
subtype spec that requests a lower resolution such that semantics are still 
exact, and that when rounding inevitably occurs, it happens in a user or 
operator specified manner.  Besides, an implementation may still choose to use 
an integer for implementation, but its granularity can be flexible depending on 
the use case.  Specifying $.nanosecond is short-sighted, and expecting one may 
add $.femptosecond later just is unnecessarily complex.


2. Why not just make normal $.second in Time be a Rat/Num instead?  
Users can always subtype it with "where is_desired_precision()" or 
something if they want that.  Separating out whole and fractional 
seconds has a design smell to me since they measure the same unit 
(unlike min/hour/day/mon/year, each of which deserve to be separate).


Hmm.  Well, I'll think about it for a while, and hope that Dave 
Rolsky will chime in on this :).


If you want good accuracy, you at least need distinct [seconds, minutes, days, 
months] units because in the general case those never exactly convert between 
each other.  You need to keep them separate because they are separate units in 
practice.  In practice you also want [years, hours], which are [1:12 month, 1:60 
minutes] for Gregorian, and maybe less specific with other calendars, because 
that is just so useful.  This goes for Instant and appropriately applies to 
Duration.  You *only* combine units into one number if for all possible uses of 
those units they convert on an exact ratio.  Which is why you don't combine 
seconds with minutes or hours with days etc.  And which is why subsecond and 
whole-second *can* be combined.  Appropriate separation allows better accuracy 
in letting people express what they mean rather than shoehorning it into a less 
accurate space, like DateTime.pm shoehorns into Days+Seconds+Nanoseconds.


Ideally in the general case, your YMDHIS collection will also support having any 
or all of those attributes undefined, to signify "don't know" or "don't care for 
that level of precision".  Subtypes can mandate that any or all of the 
attributes are defined, so for example a typical Date would specify YMD is 
defined and HIS is not, and Time would specify HIS is defined and YMD is not. 
If you define Date|Time as subtypes of Instant then this also generalizes a way 
to define interactions like adding or subtracting such, and also makes it easy 
for people to define other levels of precision, such as all-but-seconds-defined 
etc.  You could also bring back DateTime as a type name, which is Instant where 
all 6 YMDHIS attributes are defined, for example.  You get some semantic 
symmetry or asymmetry that way where it does some good.


-- Darren Duncan

r25451 - docs/Perl6/Spec

[pugs-commits]

Author: hinrik
Date: 2009-02-19 22:37:47 +0100 (Thu, 19 Feb 2009)
New Revision: 25451

Modified:
   docs/Perl6/Spec/S29-functions.pod
Log:
[S29] fix Pod errors

Modified: docs/Perl6/Spec/S29-functions.pod
===
--- docs/Perl6/Spec/S29-functions.pod   2009-02-19 21:16:16 UTC (rev 25450)
+++ docs/Perl6/Spec/S29-functions.pod   2009-02-19 21:37:47 UTC (rev 25451)
@@ -682,6 +682,8 @@
 
 These functions are exported into the default namespace
 
+=over
+
 =item all -- see S32-setting-library/Container.pod
 
 =item any -- see S32-setting-library/Container.pod
@@ -744,6 +746,8 @@
 
 =item zip -- see S32-setting-library/Container.pod
 
+=back
+
 =head2 Non-default Functions
 
 These functions which existed in perl5 still exist, but are not part of the 
default 
@@ -944,6 +948,8 @@
 Not sure whether these are exported by default or not.  Also, many may no 
longer exist; if 
 so, they should be entered in the "Obsolete" section.  
 
+=over
+
 =item Signal-related
 
 alarm
@@ -1023,6 +1029,8 @@
 wait
 wantarray
 
+=back
+
 =head1 Additions
 
 Please post errors and feedback to perl6-language.  If you are making

Re: r25445 - docs/Perl6/Spec/S32-setting-library

[Darren Duncan]

pugs-comm...@feather.perl6.nl wrote:

Author: autarch
Date: 2009-02-19 19:14:48 +0100 (Thu, 19 Feb 2009)
New Revision: 25445

Modified:
   docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
This is a very drastic revision (hopefully this won't turn into a revert war ;)


I agree with your changes in general.  Let the base Temporal just be basic roles 
and let implementing
classes fill out more details, provide operators and system services and 
formatting and locales and timezones and so on.



Renamed Temporal::Instant to Temporal::DateTime


As per my previous post, I recommend having both, like this:

  role Instant {
has Int $.year;
...
has Rat $.second;
  }

  role DateTime is Instant where defined $.year ... and defined $.second;

  role Date is Instant where defined $.year ... and defined $.day;

  role Time is Instant where defined $.hour ... and defined $.second;

So something like that.  So Date and Time mean all Date|Time details, and 
DateTime means all details of both.  And Instant means any combination of 
defined or not of said member attributes.  And that's actually why I advocated 
Instant as a name for that more-broad-than-DateTime thing.


So please provide all 4 roles, that's what I strongly support.

-- Darren Duncan

P.S.  I will be away from a computer during Fri-Sun and much of today too so if 
I don't chime in then it is not due to disinterest.

Re: r25405 - docs/Perl6/Spec/S32-setting-library

[Dave Rolsky]

On Thu, 19 Feb 2009, Darren Duncan wrote:

And which is why subsecond and whole-second *can* be combined.  Appropriate 
separation allows better accuracy in letting people express what they mean 
rather than shoehorning it into a less accurate space, like DateTime.pm 
shoehorns into Days+Seconds+Nanoseconds.


Not to get too off-topic, but this is just incorrect. The way DateTime.pm 
handles this _internally_ is to store days since an epoch, and seconds 
into the day (and nanoseconds).


Ignoring the precision lost by using nanoseconds, this storage format is 
otherwise perfectly precise. While the number of seconds per minute, hour, 
or day varies, we can _calculate_ the hour & minute from that value. 
Similarly, we can _calculate_ the year, month, & day with perfect 
accuracy.


It's not necessary to store each unit internally in order to get 
everything right, and not doing so makes some things a lot easier (though 
it makes other things harder ;)



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: r25445 - docs/Perl6/Spec/S32-setting-library

[Dave Rolsky]

On Thu, 19 Feb 2009, Darren Duncan wrote:


As per my previous post, I recommend having both, like this:

 role Instant {
   has Int $.year;
   ...
   has Rat $.second;
 }

 role DateTime is Instant where defined $.year ... and defined $.second;

 role Date is Instant where defined $.year ... and defined $.day;

 role Time is Instant where defined $.hour ... and defined $.second;

So something like that.  So Date and Time mean all Date|Time details, and 
DateTime means all details of both.  And Instant means any combination of 
defined or not of said member attributes.  And that's actually why I 
advocated Instant as a name for that more-broad-than-DateTime thing.


Is there a way in which a class which does the Date role could change the 
type $.year so it was "Int|Undef"?


I'd prefer to leave the notion of an incomplete Date(|Time|DateTime) out 
of the core, because it makes everything more complicated.


If, OTOH, I couldn't make OnCPAN6::DateTime::Incomplete do the DateTime 
interface, that'd be a good argument for changing the core interface.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: r25405 - docs/Perl6/Spec/S32-setting-library

[Darren Duncan]

Dave Rolsky wrote:

On Thu, 19 Feb 2009, Darren Duncan wrote:
And which is why subsecond and whole-second *can* be combined.  
Appropriate separation allows better accuracy in letting people 
express what they mean rather than shoehorning it into a less accurate 
space, like DateTime.pm shoehorns into Days+Seconds+Nanoseconds.


Not to get too off-topic, but this is just incorrect. The way 
DateTime.pm handles this _internally_ is to store days since an epoch, 
and seconds into the day (and nanoseconds).


That's what I thought I was saying; you use those 3 units.

Ignoring the precision lost by using nanoseconds, this storage format is 
otherwise perfectly precise. While the number of seconds per minute, 
hour, or day varies, we can _calculate_ the hour & minute from that 
value. Similarly, we can _calculate_ the year, month, & day with perfect 
accuracy.


It's not necessary to store each unit internally in order to get 
everything right, and not doing so makes some things a lot easier 
(though it makes other things harder ;)


I prefer to make value representation simpler at the possible cost of 
calculation, focusing on being able to encode accurately what you know or don't 
know or mean to say or don't mean to say.  Using a representation in terms of an 
epoch is going more the other way.  With my preference, you don't need to do any 
calculations with lookup tables etc in order to know what you have in human 
understandable terms; rather you just need that to derive something else 
relative to where you are.


Well, I can see reasons for both ways, but I prefer the more split apart way, 
and that's also what SQL and some other data-focused languages and some other 
languages do, not to mention what people do, which I think is a good precedent.


And of course, my argument is more what the role, aka the interface looks like, 
where focusing on accuracy is important.  The implementation could go all sorts 
of other ways in order to make storage space or calculations or comparisons more 
efficient.


-- Darren Duncan

Re: r25445 - docs/Perl6/Spec/S32-setting-library

[Darren Duncan]

Dave Rolsky wrote:

On Thu, 19 Feb 2009, Darren Duncan wrote:
So something like that.  So Date and Time mean all Date|Time details, 
and DateTime means all details of both.  And Instant means any 
combination of defined or not of said member attributes.  And that's 
actually why I advocated Instant as a name for that 
more-broad-than-DateTime thing.


Is there a way in which a class which does the Date role could change 
the type $.year so it was "Int|Undef"?


I'd prefer to leave the notion of an incomplete Date(|Time|DateTime) out 
of the core, because it makes everything more complicated.


If, OTOH, I couldn't make OnCPAN6::DateTime::Incomplete do the DateTime 
interface, that'd be a good argument for changing the core interface.


I was under the impression that Perl typed containers are allowed to hold Undef 
by default, eg when you say "has Int $foo" that allows an Undef $foo by default. 
 So in that case I'm already getting what flexibility I want by default if that 
is how the roles are declared.  Correct me if I'm wrong. -- Darren Duncan

Re: Temporal and purity (was: Re: IO, Trees, and Time/Date)

[Martin Kealey]

On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
> On Thu, 19 Feb 2009, Martin D Kealey wrote:
> > Rather, let's have immutable time "values", and methods which return other
> > "values" where various computations (*1) have been applied. Provide
> > constructors which take the Y/M/D/h/m/s/dst_now/dst_rule tuple.
>
> I followed the bits about the computations, and I think I see what
> you're saying about the constructor, but I don't know what you mean by
> 'immutable time "values"'.  Could you expand on this a bit?

We want an "Instant" class whose objects have value semantics rather than
container semantics. Because:

1. It makes them usable in "pure" code

2. "Date isa Instant" works sensibly: anywhere that expects an Instant, you
can give it a Date. (Assuming we all agree that dates start at midnight, but
then we *are* talking specifically Gregorian dates.)

(If you have container objects, that can't work, and neither can the
reverse, tempting though it is. So tempting in fact that it's part of the
Java language definition.  Uggh!)

3. Having separate writable attributes is offering someone a cannon with
which to shoot their own foot off, as far as having buggy code goes.
(Strictly, this doesn't preclude having a container object where you set the
epoch-second, or set the year, month, day, hour, minute and second all at
once, but even if they're not in the design to begin with, sometime someone
naïve is going to add them.

4. Let's face it, they're pretty small objects. They're on a par with a
"Num", and should get similar treatment.

-Martin

Re: Spec reorganisation

[Geoffrey Broadwell]

On Thu, 2009-02-19 at 22:57 +1100, Timothy S. Nelson wrote:
> On Thu, 19 Feb 2009, Carl Mäsak wrote:
> > A tree is a graph without cycles.

That's insufficient.  In fact, there are a number of ways that the
general concept of an acyclic graph must be constrained before you get
something you can call a 'tree'.

> > The concept of a "root" is very common in computer representations, but in 
> > no way necessary for a general tree. In fact, in phylogenetics, it's 
> > business as usual to handle unrooted trees. This makes the $root attribute 
> > meaningless in at least some cases.
> 
>   Interesting.  I'm happy to assume that $root is allowed to be 
> Undefined, I think.  But let me ask a question; were you to represent an 
> unrooted tree in a computer, how would you do it so that, if you had to look 
> around the tree, you could do it?  You'd need some node that was an 
> entry-point into the tree.  That's the purpose I'm trying to get at here.

A tree with nodes but without a root is not a tree -- it's a collection
of trees, more commonly called a grove or forest.


-'f

Re: Spec reorganisation

[Timothy S. Nelson]

On Thu, 19 Feb 2009, Daniel Ruoso wrote:


Em Qui, 2009-02-19 às 22:57 +1100, Timothy S. Nelson escreveu:

Interesting.  I'm happy to assume that $root is allowed to be
Undefined, I think.  But let me ask a question; were you to represent an
unrooted tree in a computer, how would you do it so that, if you had to look
around the tree, you could do it?  You'd need some node that was an
entry-point into the tree.  That's the purpose I'm trying to get at here.


Not at all, that is the same as saying that a list must always be
ordered, and that it should have a beggining. Circular Lists are very
well known.


	I guess I'm trying to say something slightly different.  Let me give 
an example.  If you tried to create a circular list in Perl, with, eg.


class   Node {
has $nextnode;
has $data;
}

	...and you got a few, and linked them in a circle, but then got rid of 
all variables that refer to them, then if I understand correctly, you'd be 
entirely unable to get the data out again.  But given one (or more) variables 
that points to this list, you'd be able to walk around in it and retrieve all 
the data.


	What I want the Tree role to do is to be a place where we can ensure 
that at least one of the nodes is referred to.



If you think in a BTree, for instance, you usually don't have a root
node, since a BTree is simply a way to view a list, and you might
receive a node and work only from that context onward. That even applies
for filesystems: what if your process calls (2)chroot? what happens to
the "root" node?


	It changes :).  So I guess chroot should be replaced with a setter on 
$Tree.root :).



On the other hand, I have to disagree with masak that it would be an
empty role, because there is indeed one operation that you can always do
in a tree node:

role Tree::Node {
  method List lookup(*%options);
}


[snipped lookup examples]

	Hmm.  It seems we're trying to achieve the same things, but you want 
everything done as parameters to a lookup method, whereas I want everything 
done as attributes and methods on the node.


:)


-
| 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: r25445 - docs/Perl6/Spec/S32-setting-library

[Larry Wall]

On Thu, Feb 19, 2009 at 05:05:32PM -0600, Dave Rolsky wrote:
> On Thu, 19 Feb 2009, Darren Duncan wrote:
>
>> As per my previous post, I recommend having both, like this:
>>
>>  role Instant {
>>has Int $.year;
>>...
>>has Rat $.second;
>>  }
>>
>>  role DateTime is Instant where defined $.year ... and defined $.second;
>>
>>  role Date is Instant where defined $.year ... and defined $.day;
>>
>>  role Time is Instant where defined $.hour ... and defined $.second;
>>
>> So something like that.  So Date and Time mean all Date|Time details, 
>> and DateTime means all details of both.  And Instant means any 
>> combination of defined or not of said member attributes.  And that's 
>> actually why I advocated Instant as a name for that 
>> more-broad-than-DateTime thing.
>
> Is there a way in which a class which does the Date role could change the 
> type $.year so it was "Int|Undef"?

Doesn't have to.  Int already comes with an undefined value known as
Int, aka the protoobject.  Only subset types (and their cousins, native
types) can restrict values to being defined, and they do so on the
primarily on basis of constraints, and only secondarily on whether the
underlying storage can represent an undefined value.   So an Int can be
undefined, but an int can't.  A Num can be undefined, but a num can only
approximate that with NaN.

So the built-in types may certainly represent incomplete information.

That being said, I'm thinking that all actual times represented by
floats in Perl are TAI time, not the Unix pseudo time with hidden
leap seconds.  I sure wish they'd done away with civic leap seconds
in 2000 and said we'll put in a leap minute or two on century breaks...

Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000.  Standard TAI would work too.
In any case, I think if Perl is to be taken seriously for scientific
computing its native seconds shouldn't be varying in length.  And I
also think with the advent of ubiquitous GPS we're getting to the
point where nearly all computers will know the correct atomic time.
Time is on our side, as it were...

Larry

Re: r25405 - docs/Perl6/Spec/S32-setting-library

[Darren Duncan]

Darren Duncan wrote:

Dave Rolsky wrote:
It's not necessary to store each unit internally in order to get 
everything right, and not doing so makes some things a lot easier 
(though it makes other things harder ;)


I prefer to make value representation simpler at the possible cost of 
calculation, focusing on being able to encode accurately what you know 
or don't know or mean to say or don't mean to say.  Using a 
representation in terms of an epoch is going more the other way.  With 
my preference, you don't need to do any calculations with lookup tables 
etc in order to know what you have in human understandable terms; rather 
you just need that to derive something else relative to where you are.


Well, I can see reasons for both ways, but I prefer the more split apart 
way, and that's also what SQL and some other data-focused languages and 
some other languages do, not to mention what people do, which I think is 
a good precedent.


Replying to myself here ...

One further advantage of going my way of a calendar based rather than the epoch 
based representation is that it handles reasonable future dates correctly.


For example, if a user wanted to specify the date "2025 March 3rd at 15:30:00h", 
then storing it as [2025,3,3,15,30,0] will still mean exactly that date and time 
later, what the user intended.


Whereas, if we go with the epoch approach, then we have to encode that involving 
a count of seconds from an epoch, but we don't know how many leap seconds we 
need to have, since those are decided semi-arbitrarily; it may be that when 2024 
rolls around and our epoch-using code is keeping that same count-of-seconds, 
then suddenly the value has changed to, say, 15:29:55h or something.


It comes down to what is more important, preserving positions in time DWIM as 
the user intended, or preserving a particular delta of time from now.


I say leave the complexity to when you explicitly do date-add or date-diff etc 
and keep the representation simple.


Users expect that there might be subtle variations or roundoffs when you 
calculate something new (eg, rounding off 2/3 expressed in decimal or binary 
notation), but users expect that a conceptual value they explicitly set doesn't 
change.


Of course, I'm thinking from a database language point of view, being concerned 
with value consistency over time, but general purpose languages should typically 
have a lot of the same priorities and sensibilities.


-- Darren Duncan

More trees and roles

[Timothy S. Nelson]

On IRC, ruoso wrote:

wayland, one important thing I didn't mention in the mail is that I 
understand that if some attribute is going to be undefined for some cases in 
a Role, then it doesn't belong in that role, but in a more specialized 
one... 


the good thing about roles is that they don't require an hierarchy

(which is what makes the Java API so terrible)


	One problem (as I mentioned elsewhere just now) is that I'm trying to 
specify an API with optional parts.  Maybe I should stop using roles for this 
:).


	I'd argue, also that Undefined isn't really undefined, it's really a 
value.  For example, say you malloc some memory in C, there could be anything 
in it; it really *is* undefined.  Whereas the Perl 6 "Undefined" value is 
guaranteed to always return "Undefined".


	I guess it's because I was expecting people using a composition of 
Tree to go:


if(! defined($footree.root)) { warn "Unrooted tree"; }

...instead of

if(! $footree.has('$root')) { warn "Unrooted tree"; }
# Does this even work???

Or maybe even:

try {
$footree.root;
CATCH {
when /Error: has no attribute named 'root'/ {
warn "Unrooted tree";
}
}
}

...you can see why I prefer the first one :).

Anyway, 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-

Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

[Timothy S. Nelson]

On Thu, 19 Feb 2009, pugs-comm...@feather.perl6.nl wrote:


Author: autarch
Date: 2009-02-19 19:14:48 +0100 (Thu, 19 Feb 2009)
New Revision: 25445

Modified:
  docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
This is a very drastic revision (hopefully this won't turn into a revert war ;)


	I hope not.  My plan is to argue about them on the mailing list, and 
hope that we'll come to some reasonable consensus :).


	I'd also like to say a mea culpa -- I had a commit ready to go before 
I asked Dave/autarch to make the appropriate changes, but I forgot to commit 
it :).  So some of the stupid things are things I should've done myself.


	I've noticed that a number of my objections were scattered various 
places throughout my reply, so I'm taking the liberty of grouping a few things 
together by argument :).


Formatters
==


removed all references to ...

[snip]

Format specifiers - this could come from locales (CLDR specifies this)
or strftime, but again, it's more complicated than is needed

[snip]

Added iso8601 output for every role, and made that the
stringification. ISO8601 is unambiguous world-wide, easy to read, and
easy to output.


	I'm quite keen to have something here as a formatter.  I was hoping 
for CLDR, but I'd be happy with even a subset of CLDR that does what we want. 
Or even, failing that, with the ISO8601 part being implemented as a formatter.



+# These always return the long English names
+method month-name () returns Str; # "January"
+method day-name () returns Str;   # "Tuesday"


	This is one reason I was wanting a formatter -- then we wouldn't need 
all these functions.  People could just go $time.format('') and get what 
they want.  Like I said though, the core might be better off with a subset of 
CLDR that does month name, day name, and the ISO8601 stringification.



+# returns the date formatted in ISO8601 style - 2008-01-25
+   method iso8601 () returns Str
+{ [ self.year, self.month, self.date ].join('-') };


	I was hoping we could leave this also to a formatter that would be 
called upon by infix:{'~'}.



DateTime math
=


removed all references to ...

[snip]

Any sort of date or time math

[snip]

Got rid of all mutating operators on everything. The built-ins should
be immutable for simplicity.


	Date/time math was something else I'm also very keen to have.  The 
other built-ins play happily with operators -- why wouldn't the temporal ones? 
By "mutating operators", do you mean "multi operators"?  If so, I urge you to:

-   Read my comments lower down in this e-mail about the infix:<~>
operator, which will give you some appropriate background
-   See http://perlcabal.org/syn/S03.html#Smart_matching which appears to
me to make the ~~ operator do all kinds of things (although I could be
wrong here).  Actually, the point I'm making is much more easily seen
by finding "=head1 Smart matching" in
http://svn.pugscode.org/pugs/docs/Perl6/Spec/S03-operators.pod

Other things



Here's the changes in summary:

removed all references to ...

Locales, including eras, which come from a locale - this is a vast and 
complicated domain

Alternate calendars - also vast and complicated

String parsing of any sort - ditto, see the pattern here? ;)

Comparing dates or times to durations - this just doesn't make
sense. Is 2009-02-23 greater or less than 5 days?


I agree, this was stupid :).


Renamed Temporal::Instant to Temporal::DateTime


	Hmm.  We had some mailing list discussion about this, and agreed on 
Instant.  I'd like to see your reasons in favour of DateTime.


	One of my (unmentioned) reasons for not calling it DateTime is that I 
was expecting the CPAN module to be called DateTime, and didn't want to stamp 
on any names.  But that's not as high a priority.



Got rid of Temporal::Subsecond and just made Temporal::Time allow for
sub-second resolutions. Not sure if this is best done with an
$.attosecond attribute or as a decimal number.


See other discussions on the mailing list.


Renamed Temporal::Timezone to Temporal::TimeZone::Observance. The
latter is a simple thing which represents the offset, isdst flag, and
short name for a given local time. This information should be
available on all supported platforms. TimeZones themselves are
complicated and very much platform-dependent. Better to leave this as
a separate CPAN6 distro.


	Bewdy mate!  :)  [to translate that into non-Australian, it's 
"Beauty, mate", or "I'm pleased, friend"].



Added numification overloading for Temporal::DateTime, which gives us
comparison for free.


Cool :).

	In case I didn't say this elsewhere, I'd be happy to see localtime and 
gmtime disappear in favour of other temporal constructors.  And surely time() 
could be merged in as well?



+method infix:{'~'} return Str { self.iso8601 };


	Also, while I may be wrong, my read

r25452 - docs/Perl6/Spec/S32-setting-library

[pugs-commits]

Author: wayland
Date: 2009-02-20 02:42:25 +0100 (Fri, 20 Feb 2009)
New Revision: 25452

Modified:
   docs/Perl6/Spec/S32-setting-library/Temporal.pod
Log:
Minor syntax fix


Modified: docs/Perl6/Spec/S32-setting-library/Temporal.pod
===
--- docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-02-19 21:37:47 UTC 
(rev 25451)
+++ docs/Perl6/Spec/S32-setting-library/Temporal.pod2009-02-20 01:42:25 UTC 
(rev 25452)
@@ -88,7 +88,7 @@
method iso8601 () returns Str
 { [ self.year, self.month, self.date ].join('-') };
 
-method infix:{'~'} return Str { self.iso8601 };
+method Str { self.iso8601 };
 
multi method infix:{'<=>'} (Temporal::Date $self, Temporal::Date 
$other) {
 $self.year <=> $other.year

Re: Exegesis 7/format() question

[Brandon S. Allbery KF8NH]

On 2009 Feb 17, at 1:54, Timothy S. Nelson wrote:
	Hi all.  According to S29, the Perl 5 format() function is  
obsolete, and it says "See Exegesis 7".  According to Exegesis 7,  
there will be a Form.pm which implements similar functionality, but  
has to be "use"d.  My questions are:

1.  Is the Form.pm module discussed anywhere in the specs?
2.	This seems to imply that the Form.pm module will be included as  
part
	of the standard Perl distribution, but not "use"d by default.  Is  
this

the case?  I presume this is also true of the IO roles.  Is there
somewhere a list of all the modules that will be part of the standard
Perl6 distro?



I may be out of date, but last I'd heard Form.pm had been neither  
documented nor specced (much less written) and was expected not to  
make the initial Perl6 release.


(It would be difficult to spec given that IO is only just being  
specced now and nothing is firm yet.)


--
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

Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

[Timothy S. Nelson]

On Thu, 19 Feb 2009, Larry Wall wrote:


Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000.  Standard TAI would work too.


	I've wondered sometimes about the idea of having a dual/moving epoch. 
By this, I mean that you have eg. two Ints, one which represents the years 
since 1AD or whatever, and the other of which represents the number of seconds 
from the beginning of that year.  I'm sure many of you can see the advantages 
and disadvantages of that scheme better than I can, but I thought I'd throw it 
out there so you can all see whether or not you like it.



-
| 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: Exegesis 7/format() question

[Timothy S. Nelson]

On Thu, 19 Feb 2009, Brandon S. Allbery KF8NH wrote:


On 2009 Feb 17, at 1:54, Timothy S. Nelson wrote:
	Hi all.  According to S29, the Perl 5 format() function is obsolete, 
and it says "See Exegesis 7".  According to Exegesis 7, there will be a 
Form.pm which implements similar functionality, but has to be "use"d.  My 
questions are:

1.  Is the Form.pm module discussed anywhere in the specs?
2.  This seems to imply that the Form.pm module will be included as part
	of the standard Perl distribution, but not "use"d by default.  Is 
this

the case?  I presume this is also true of the IO roles.  Is there
somewhere a list of all the modules that will be part of the standard
Perl6 distro?


I may be out of date, but last I'd heard Form.pm had been neither documented 
nor specced (much less written) and was expected not to make the initial 
Perl6 release.


(It would be difficult to spec given that IO is only just being specced now 
and nothing is firm yet.)


	It turns out someone on IRC is starting to work on this, and it's 
already been done by Damian as as the Perl 5 module Perl6::Form(s?), and the 
documentation on that will be considered a draft spec.


Anyway, 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: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

[Chris Dolan]

On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote:


On Thu, 19 Feb 2009, Larry Wall wrote:


Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000.  Standard TAI would work too.


	I've wondered sometimes about the idea of having a dual/moving  
epoch. By this, I mean that you have eg. two Ints, one which  
represents the years since 1AD or whatever, and the other of which  
represents the number of seconds from the beginning of that year.   
I'm sure many of you can see the advantages and disadvantages of  
that scheme better than I can, but I thought I'd throw it out there  
so you can all see whether or not you like it.




I don't see the advantage of either of those.  TAI 2000 is just UTC  
1970 plus a constant offset.  1AD is just UTC 1970 minus a bigger  
constant offset.  Sure, those are slightly easier epochs for a human  
(ignoring the Julian/Gregorian shift), but not any easier for a  
computer.  UTC 1970 has the big advantage that it is already the  
underlying value returned by most operating systems and many date/ 
time libraries, so there's no extra additive operation to perform if  
that's what you want.


A much more important issue is the use of integer seconds.   
Milliseconds is a much more useful precision for humans and micro- or  
nanoseconds is a better precision for machines.  I think Time::HiRes  
with a better API as a builtin would be a big win.


Aside: I just learned the other day that Java's Thread.sleep(long  
millis, int nanos) method just rounds the nanos to the nearest millis  
and invokes Thread.sleep(long millis).  I guess that's a forward  
looking API for when the OS really can timeslice that small, but it's  
a little silly today.
http://krugle.org/kse/entfiles/jdk/sun.com/jdk-1.5/j2se/src/share/ 
classes/java/lang/Thread.java#246


Maybe Perl 6 should be really forward looking and include a time  
dilation factor so it can be the first language designed from the  
ground up for interstellar travelers who want to use a non-inertial  
reference.  Or GPS?  :-)


Chris

Re: Perl's internal time (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

[Timothy S. Nelson]

On Thu, 19 Feb 2009, Chris Dolan wrote:


On Feb 19, 2009, at 10:17 PM, Timothy S. Nelson wrote:


On Thu, 19 Feb 2009, Larry Wall wrote:


Well, leaving that rant aside, I'm still tempted to say that times
in Perl 6 are TAI seconds since 2000.  Standard TAI would work too.


	I've wondered sometimes about the idea of having a dual/moving epoch. 
By this, I mean that you have eg. two Ints, one which represents the years 
since 1AD or whatever, and the other of which represents the number of 
seconds from the beginning of that year.  I'm sure many of you can see the 
advantages and disadvantages of that scheme better than I can, but I 
thought I'd throw it out there so you can all see whether or not you like 
it.




I don't see the advantage of either of those.  TAI 2000 is just UTC 1970 plus 
a constant offset.  1AD is just UTC 1970 minus a bigger constant offset. 
Sure, those are slightly easier epochs for a human (ignoring the 
Julian/Gregorian shift), but not any easier for a computer.  UTC 1970 has the 
big advantage that it is already the underlying value returned by most 
operating systems and many date/time libraries, so there's no extra additive 
operation to perform if that's what you want.


	Having now read the Wikipedia page on time_t, I withdraw my suggestion 
:).



A much more important issue is the use of integer seconds.  Milliseconds is a


	The new interface looks like it will cope with something small fairly 
well.  Dave Rolsky is doing a good job, even though I think there may be room 
for improvement :).


Maybe Perl 6 should be really forward looking and include a time dilation 
factor so it can be the first language designed from the ground up for 
interstellar travelers who want to use a non-inertial reference.  Or GPS?


	I'm not a rocket surgeon, but we'd need a $.velocity to calculate 
that, wouldn't we?


:)


-
| 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: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)

[Wayland]

On Fri, 20 Feb 2009, Timothy S. Nelson wrote:


+role   Temporal::DateTime {
+has Temporal::Date $!date handles ;


	Can't do this, I think; this would require an instance of 
Temporal::Date, which is a role and can't be instantiated.  That's why I was 
using "does" instead.  I don't know what the alternative is, but I'll leave 
that to you :).


Ok, I'm wrong here; sorry :).


-
| 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: Temporal and purity (was: Re: IO, Trees, and Time/Date)

[David Green]

On 2009-Feb-19, at 4:39 pm, Martin Kealey wrote:
2. "Date isa Instant" works sensibly: anywhere that expects an  
Instant, you
can give it a Date. (Assuming we all agree that dates start at  
midnight, but

then we *are* talking specifically Gregorian dates.)


I don't like dates just starting at midnight because I've run into too  
many awkward cases where $time < $date doesn't do what you mean  
because it assumes 0:00:00 when you meant 23:59:59.  I'd rather have  
dates becomes time-ranges.


Or perhaps don't make them coercible and require an explicit  
conversion via $date.morning or $date.evening or something.   (Maybe  
require $time ∩ $date or $time ⊂ $date?)



-David

Re: Temporal revisited

[David Green]

On 2009-Feb-19, at 11:26 am, Dave Rolsky wrote:
What I want to see in Perl 6 is a set of very minimal roles that can  
be used to provide a simply object from gmtime() and localtime().  
These objects should not handle locales, proper Olson timezones,  
string parsing, user-defined formatting, or math.


Yes; I myself haven't had to worry about leap-seconds before, and may  
very well never have to.  Really basic math is common enough that it  
seems reasonable to include, though.  And we get that by being able to  
numify times, though I'm not sure about officially making time()  
return a Num -- isn't that exposing an implementation detail?  If I  
need an epoch value, I'd expect to have to say $time.epoch or  
$time.epoch(1970) or something.

our Time::localtime(:$time,:tz)


Why can't we just have time() that takes a :tz adverb and dispense  
with gmtime() and localtime()?  I also think that timezones should be  
required, so that it's impossible to have a time and not know what TZ  
it's supposed to be.


If there's no "simple enough" way to do minimal timezones, then allow  
only GMT (and require using a suitable module to recognise any other  
TZ).  If you really don't care because you know for sure the TZ will  
never matter, say "use timezone ".  (You may as well not care  
that all the times are GMT in that case.  But if it turns out someday  
that you do care, you can't say you didn't know.)


Or maybe allow any string as a timezone by default.  If all your times  
use the same TZ, that's fine; but as soon as you try to work with two  
times with different zones, you'll get an error, unless you're using a  
module that knows how to convert between those zones.


(While we're at it, why is "time zone" still officially two words?   
Usually I like to side with the dictionary, but I can't figure out how  
"timezone" has escaped becoming de facto standard English.)


((I also prefer "Instant" to "DateTime" unless we end up using both,  
as in Darren Duncan's suggestion.))



-David