Re: licensing issues
On Sun, 14 Jan 2001, David Grove wrote: > Ladies and gentlemen, maybe licensing isn't the method of choice of > preventing the abuses that are harming this community, but it seems to be > the appropriate place to affect at least one of the two: What abuses? What the heck are you talking about? Why are people suddenly freaking out about licenses? Perl's dual license seems to have served it well, since AFAIK there has never been a major issue where someone has been in violation of the license (intentional or otherwise). What problem are you aiming to fix? > 2) The existing policies (or lack thereof) or lack of attention or concern > allow a(ny) company to purchase strong control in the development and > direction of the Perl language for proprietary goals (which is why I asked > the question about 5.005_03... linux distros are outright rejecting it > everywhere, as is FreeBSD). Uh-oh, here comes the ActiveState rant. AFAICT, your ActiveState hostility mostly stems from your assertion that they were responsible for the release schedule of 5.6.0. This has two big assumptions: 1. That it was released too early. I happen to agree but that's largely irrelevant. 2. That AS somehow had a vested interest in this early release and knowingly forced a buggy 5.6.0 on the community. Even agreeing with #1, I have yet to see any evidence on #2. And mind you, I am very anti-corporate and skeptical of all that corporations do. Yet I still think you have no case. -dave /*== www.urth.org We await the New Sun ==*/
Re: licensing issues
On Sun, 14 Jan 2001, David Grove wrote: > 1. What if a company, ANY company, whether through collusion or by any > other means, historically has had, currently has, or in the future will > have, the ability to disregard the perl license mechanism as it stands > because of questionable "grammar", or the spirit of the licenses because > of unstated "spirit"? (Forget for a moment that it's now been discussed as > historical fact, and keep it in the abstract.) That does seem to be a good argument for tightening up the AL, which has been discussed and submitted to Larry as an RFC, I believe. > 2. What if a company, ANY company, hires key members of whatever governing > Perl body exists, for the specific purpose of affecting public opinion > about that company and controlling the development of the Perl language; > and that company can affect public opinion concerning itself and its > actions due to control of "public" media; and that company can affect > elite (not elitist) opinions due to misguided devotion to those key > members? This seems to me to be a problem of the community, rather than a license. If members of the community working on the core of Perl allow themselves to be bought and sold, _AND_ nobody else in the community complains, then we've gotten what we deserve. I would suggest that the proper way to handle this is for the community to be self-policing. If someone in a position of influence in the community is obviously acting in the best interests of their employer (without taking into account the community's interests) then they should be asked to leave the community. I just don't see how this particular problem could be solved through licensing. -dave /*== www.urth.org We await the New Sun ==*/
Re: Really auto autoloaded modules
On Thu, 1 Feb 2001, Nathan Wiger wrote:
> There's the big problem of overlapping function names. If I say:
>
>$name = param('name');
>
> I probably mean "use CGI". But maybe there's some other module that has
> param() also? What if I really mean "use CGI::Minimal"?
Here's a gross thought (for implementors at least ;)
If it sees
use CGI qw( param header );
the autoloader could look for a module which implements the 'CGI'
interface and has those two functions. This could be CGI or CGI::Minimal.
Then there needs to be a way to figure out which to load. Hopefully the
smallest/quickest.
And code that does this:
use CGI qw( param header heavy_lifting );
Would get CGI.pm.
If the loading is done based on interface implementation (there's a nice
nebulous idea) this could be very slick (and very hairy to implement).
Just a thought.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Really auto autoloaded modules
On Thu, 1 Feb 2001, Michael G Schwern wrote: > Problem is, its extremely difficult to figure out what module > implements what. Sure, if you see a C you have a I wasn't clear. I was thinking that somehow a module would register with the core what interfaces it support when it is installed. Anything else is madness (ok, my idea is madness too). -dave /*== www.urth.org We await the New Sun ==*/
Re: Really auto autoloaded modules
On Fri, 2 Feb 2001, Jarkko Hietaniemi wrote: > What I think is needed is some sort of opaque tag: the name of the > 'contract' the API claims to fulfill. The name can be the name of > the standard, the name of the company, the name of the individual. > (Java does a very similar thing but they propose embedding the DNS > name as part of the package name: I think they the right idea but > the proposed implementation sucks.) That's what I was thinking. The point is that the module identifies the services it provides. Multiple modules may provide overlapping sets of services. Modules could also be somehow ranked (memory usage and speed come to mind). Then I could put this into my module: needs CGI; needs URI; needs HTML::Output; needs HTTP; There may be five modules implementing the 'CGI' interface, three for URI, and two for HTTP. If it so happens that one module (CGI.pm, for example), implements three of the interfaces I need, then that may be a better choice than loading several separate modules. Or there may be a very fast but less stable (or less portable) XS module for HTTP and a slower but very stable and portable pure Perl version. They would have different module names but would both implement the HTTP interface. One thing this suggests to me is that part of the module install process may include asking the installer what precedence they want to give the module for each of the interfaces it supports. The other question is how we define an interface (as opposed to how we name it). -dave /*== www.urth.org We await the New Sun ==*/
Re: Things have paused... really?
On Tue, 20 Feb 2001, Dan Sugalski wrote: > At 01:32 PM 2/20/2001 -0600, Dave Rolsky wrote: > > > >Hmm, I think of Python as more Babbit than Mahler. Perl is ... John Cage? > > Would that mean that perl 6 corresponds to 4'33"? (If I have the composers > right...) As someone else pointed out, you are correct. However, that's not exactly what I was thinking with that analogy. If Perl 6 is 4'33" that would be most unfortunate. Actually, I was thinking of the difference between "there is one way" (Python & Babbitt's serialism (side note: Babbitt is a _really_ nice guy and not a crazy fascist though I can't stand his music)) and TMTOWTDI (John Cage for sure). -dave /*== www.urth.org We await the New Sun ==*/
Re: Things have paused... really?
On Tue, 20 Feb 2001, Simon Cozens wrote: > valuable and interesting. (aside: Python is Mahler. Discuss.) So while we may Hmm, I think of Python as more Babbit than Mahler. Perl is ... John Cage? -dave /*== www.urth.org We await the New Sun ==*/
Re: Perl 6 modules plan
On Tue, 14 Aug 2001, Nathan Wiger wrote: > This is very similar to what Params::Validate does right now; in fact, > the module could well inherit from it. That'd be tricky since its not OO but you could build on it. Alternately, I'd be happy to add more features to Params::Validate (I don't feel like its done yet) though I am not interested in adding code that would allow people to more easily implement multiple interfaces ala CGI. -dave /*== www.urth.org We await the New Sun ==*/
Re: relational data models and Perl 6
On Thu, 15 Dec 2005, Luke Palmer wrote:
On 12/15/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
I propose, perhaps redundantly, that Perl 6 include a complete set of
native
Okay, I'm with you here. Just please stop saying "native" and "core".
Everyone.
Here, here.
I would like to hear from Ovid and Dave Rolsky on this issue too, as
they seem to have been researching pure relational models.
My take on this is that with all the features that are supposed to be in
Perl6, implementing a declarative mini-language for relations and tuples
would be a simple matter of programming ;)
The following bits seem to me to be key to making this work:
* built-in set operators, which can presumably be overloaded
* powerful OO system
* optional strong typing
* macros and grammar engine
So we can do stuff like this:
my $emp_rel = Relation.new_from_dbms('Employee');
my $dep_rel = Relation.new_from_dbms('Department');
my $emp_dep_rel = $emp_rel natural join $dep_rel; # natural join is a macro of
some sort
my @array = $emp_dep_rel.sorted_tuples($emp_rel.attribute('name'));
This is a kind of bastardized semi-logical semi-OO language, but
presumably we could do this instead
my $relation = relational($dbh, <And then presumably the Perl-side of the implementation will have some
sort of object that does relational things, like:
my $iterator = $relation.iterator( sort => 'employee_name' );
In fact, there's really no reason this couldn't be done in Perl5 today.
The hard part is gluing the Perl bits to a DBMS, or alternatively
implementing all of the relational logic (and therefore an RDBMS) in Perl.
Given that there is no truly relational DBMS available, I'm not sure
exactly what Perl6 can do here, as the hard part is implementing such a
that TRDBMS. Of course, you could implement one client-side on top of a
SQL DBMS. It's just a simple matter of programming ;)
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Time::Local
On Tue, 5 Jul 2005, Gaal Yahas wrote: Regarding Time::Local fields, it's an object now, so the order of things Should that be Time::localtime? In P5 there are Time::localtime & Time::gmtime, which are thin OO facades over the language builtins. Then there's the module Time::Local, which is entirely different. All of those provide useful functionality, and probably Time::Local should be part of the language, _or_ localtime & gmtime should be in a library. * .year is the Gregorian year, no 1900 offeset or anything like that. Yes! * .month and .wday are one-based. Sunday == 1. Haskell has them as enums which avoids off-by one confusion completely; I made them like I did because that's like humans think of them. And yes again! * .picoseconds - we don't promise this granularity is available by the system, but I don't suppose we'll ever need anything finer than that :-) The more granularity the better, really. DateTime right now supports nanoseconds, which was a semi-arbitrary choice that seemed granular enough. Picoseconds is even better. Anyone who needs more probably has some sort of special hardware providing their data anyway, and will need a special interface to it (hand waving). * Once we sort out context and want in pugs, I can return a List when one is expected, instead of an object. Then the order of fields becomes important and I'm inclined to go with year first, like the Haskell module, so that least significant things come last. This is the reverse of p5 Time::Local. When timelocal and timegm are implemented, they will of course use whatever order their inverses use. I'd agree that this makes the most sense. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Tue, 5 Jul 2005, Juerd wrote: No. Humans don't USE numbers for week days! So beginning at 1 makes no sense, except for humans who like creating lists like (undef, ). In fact, I would prefer to not having any 0 :) This should be separated into day() and day_name(). It's hardly obvious that day() should return a string, much less a bit of English! As for 0 vs 1 as the index, I think this is a bit of a red herring. If you're constantly using this as an array index you're operating at too low a level (IMO). If all your programs start with: my @DayNames = qw( Sunday Monday Tuesday ... ); I think you have a bigger problem than simply adjusting for a 1-indexed day number ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Wed, 6 Jul 2005, Juerd wrote: I think the problem one has is much bigger even if a day *number* is ever displayed. Then beginning with 1 because that's where most humans begin counting, is wrong. It's a technical thing, and that should be kept as simple as possible, and as technical as possible, for easier compatibility with existing technical things. Calling Sunday 1 and not having a 0 would certainly upset and offend me. My weeks begin on Mondays, as do most people's weeks here. At the same time, I can accept any day as the first day if that first day is 0, because 0 is technical and internal anyway, not meant for humans. I'm sure lots of people would want an index 1 to be Sunday, if there is no index 0. This all is solved simply by NOT skipping 0, and using an arbitrarily chosen day for the first. Or, well, for compatibility, Sunday :) Computers and Perl count from 0. People count from 1. If something begins at 1, it is expected to be a people's thing. And with week days, this just doesn't work, as not everyone's week starts at the same day. On reflection, I realized it doesn't matter too much to me. In the end, I'm likely to need a higher-level interface than this to do something interesting (like print a day _name_ or calculate the second Sunday of the month) and that interface will just use the information Perl's builtins give it. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: $object.meta.isa(?) redux
On Wed, 10 Aug 2005, Luke Palmer wrote: A new development in perl 6 land that will make some folks very happy. There is now a Set role. Among its operations are (including parentheses): (+) Union (*) Intersection (-) Difference (<=) Subset (<) Proper subset (>=) Superset (>) Proper superset (in) Element (=) Set equality It makes this folk very happy for one. I can see two very cool things coming out of this off the bat: 1. You could create a very nice mini-language that is 99% already defined in Perl6 for generating SQL or other RDBMS queries. 2. Writing a true RDBMS in Perl6 will be that much easier, because now all I'll have to do is overload these for the appropriate object types (relation, tuple, etc) and the code for doing various things will flow very naturally. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
[changing the subject line for the benefit of the summarizer ...] On Wed, 10 Aug 2005, Larry Wall wrote: And now some people will begin to wonder how ugly set values will look. We should also tell them that lists (and possibly any-junctions) promote to sets in set context, so that the usual way to write a set of numbers and strings can simply be <1 dog 42 cat 666.5> Groovy, but what about this? <1 dog 42 cat 42> Maybe a warning with an optional fatality under "use strict 'sets'"? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Mon, 15 Aug 2005, Larry Wall wrote: But the best part is that if we abandon UTC leap seconds for civil time, we don't have to remember leap seconds going forward, only backward from 2000. So you want to take on the (very irritating, I tell you) burden of leap seconds going _backwards_ but not going forwards? But that's in contrast to your saying that the epoch would be December 31, 1999 at 23:59:29.0 UTC. Or did I misread your earlier messages? -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Tue, 16 Aug 2005, zowie wrote: Hmmm... at least backwards leap-seconds are fixed. Handling leap-seconds for all time requires net access or frequent software updates, but a single block of 32 comparisons handles everything up to A.D. 2000. Well, if you want accuracy you need to get that info one way or another, right? Although since most servers use NTP (or whatever MS uses), and that ultimately goes back to UTC from atomic clocks, you can always get an accurate local time (except _during_ leap a second when POSIX goes insane). Anyway, I don't think we should worry about this too much. There are a couple of ways to use epochs. One is to use it for sorting/comparison, like for file last mod times. In that case, the actual datetime the epoch represents is irrelevant. If you need to do anything with the actual datetime, I think it's best to turn it into some higher-level representation, like a date(time) object. The existing Time::Local bits in pugs are a reasonable start at a simple lightweight datetime class, and I'm hoping to be able to provide a more complete set of classes for date & time bits in the future. If we can encourage people to always use one of these, then hopefully most people will never need to care what Perl6's epoch actually _means_. It's just a magic number you pass to some function or library. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Wed, 17 Aug 2005, Autrijus Tang wrote: ...This seems to be quite consistent with the rumoured US proposal to abolish leap seconds by adding leap hours every 500 years or so: Wow, a piece of US government policy I can actually support! Hell must be a cold place right now. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Time::Local
On Wed, 17 Aug 2005, Sam Vilain wrote: Why on earth would you want to encourage such a short sighted programming practise? The earth wobbles like a spinning top. In fact It's hardly short sighted to want leap seconds to be abandoned (not in Perl but world wide). The few people who _really_ care about syncing to midnight can still have them, but the rest of the world would be just fine with a leap hour every couple hundred years. synced, etc. Date modules (which, really, people should be using) then have something sensible to work with and can easily provide the alternate times. Environments that really can't guarantee an absolute epoch can simply return unanchored times and let the modules throw exceptions when you try to convert them to real times or times with impossible levels of accuracy. Great, so now code that works in one environment throws a "cannot find an up-to-date leap seconds table" exception in another? Eek! -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Hoping that Params::Validate is not needed in Perl6
One of the things I'm looking forward to in Perl6 is greatly improved
sub/method signatures.
I'm hoping that this will eliminate the need for anything like
Params::Validate, which IMO is a nasty hack to make up for a serious
weakness in Perl5.
I'm going to go over the various features in P::V and see if there are
equivalents in Perl6, and bring up any questions I have. I think this
will be interesting for folks still new to P6 (like myself) and existing
P::V users (I think there's a fair number, but maybe I flatter myself ;)
Mandatory vs. Optional Parameters
This is a pretty straightforward one in P6, I think. Parameters can be
marked as required with "is required" like this:
sub date ($year, ?$month, ?$day) # positional
sub date (+$year is required, +$month, +$day) #named
This is ok but frankly I'm not too keen on the fact that for positional
subs, the default is required, but for named params it's the other way
around.
Wouldn't it clearer to just use a leading "?+" for optional named params?
Default Values
sub date ($year, ?$month = 1, ?$day = 1)
sub date (+$year is required, +$month = 1, +$day = 1)
Again, nice and straightforward.
Type Validation, "isa", & "can"
Params::Validate allows for several ways to check the _value_ of a
parameter. One way is to specify a primitive type like "SCALAR" or
"ARRAYREF". In P6 we have that with this:
sub date (Scalar +$year is required, ...)
I'm not sure is "Scalar" is a valid type though, but that's ok because we
have better types built in. In this case we should really use "Int" for a
year.
P::V also allows one to specify a class membership ("isa)" or one or more
methods ("can") a given object/class must have. In Perl6 we can just
specify a class:
sub transmit (Receiver $receiver)
If I understand this correctly, Receiver is a role here, and one that many
different classes may use/implement. This basically combines the isa &
can concepts. Instead of specifying required _methods_, we specify the
role, which seems conceptually cleaner anyway.
Regexes and Callbacks
P::V lets you validate a value based on a regex or one or more callbacks.
I think these can be replaced with subtypes, which is one of the most
exciting new P6 features (for me).
So instead of this (Perl5 P::V):
{ size => { callbacks =>
{ 'is a valid month' => sub { $_[0] >= 1 && $_[0] <= 12 }
we can now do this:
my subtype Month where { 1 <= $^s <= 12 }
This is so freaking awesome!
Then we just reference the subtype in our sub declaration:
sub date { $year, Month ?$month = 1, Day ?$day = 1 }
Subtypes can also be defined as regexes:
my subtype PerlIdentifier where / <++[_]> <+++[_]>* /;
(not 100% sure on that rule but you get the idea)
Dependencies, Exclusions, and "Require one-of"
With P::V I can do this:
{ credit_card_number =>
{ optional => 1,
depends => [ 'credit_card_expiration', 'credit_card_holder_name' ] },
credit_card_expiration => { optional => 1 },
credit_card_holder_name => { optional => 1 },
}
I have no idea how I might do this in Perl6, but I would love to see it
supported as part of parameter declarations
Similarly, something I've wanted to add to P::V is exclusions:
{ credit_card_number =>
{ optional => 1,
excludes => [ 'ach_bank_account_number' ] },
}
Another thing that would be really nice would be to require one of a set
of parameters, or one set out of multiple sets, so we could say "we need
credit card info _or_ bank account info".
For example, with the examples above, I probably want to require _either_
a credit card number _or_ a bank account number. Providing both is an
error, but so is not providing either.
Again, no idea how to do this in Perl6, but it seems like something that
could be supported via sub declarations
Since all of these can be checked at compile time (sometimes), it seems
like they'd be useful parts of the language, as opposed to something
user-created. Of course, I understand that there will be more ways to
mess with the compilation in Perl6.
Transformations
Another potential future feature for P::V is the ability to specify some
sort of transformation callback for a parameter. This is handy if you
want to be flexible in what inputs you take, but not explicitly write code
for all cases:
{ color => { regex => qr/^(?:green|blue|red)$/i,
transform => sub { lc $_[0] } }
}
I suspect that this could be implemented by a user-provide trait like "is
transformed":
sub print_error ($color where m:i/^ [green | blue | red] $/ is transformed {
lc })
Presumably this can be done with the existing language. It doesn't add
anything at compile time, so it really doesn't need to be part of the
language.
Anyway, I'd love to hear feedback on this. What did I get right? What
did I get wrong? Did I miss a more elegant way to do something? What
other types of param validation do
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, 17 Aug 2005, Luke Palmer wrote:
Dependencies, Exclusions, and "Require one-of"
With P::V I can do this:
{ credit_card_number =>
{ optional => 1,
depends => [ 'credit_card_expiration', 'credit_card_holder_name' ] },
credit_card_expiration => { optional => 1 },
credit_card_holder_name => { optional => 1 },
}
I have no idea how I might do this in Perl6, but I would love to see it
supported as part of parameter declarations
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration &&
defined $credit_card_holder_name }
{...}
But that's really yucky.
Hideous, indeed. Presumably with macros or some other compile time thing
that can be turned into something more palatable.
Similarly, something I've wanted to add to P::V is exclusions:
{ credit_card_number =>
{ optional => 1,
excludes => [ 'ach_bank_account_number' ] },
}
Another thing that would be really nice would be to require one of a set
of parameters, or one set out of multiple sets, so we could say "we need
credit card info _or_ bank account info".
Yeah, I suppose that would be nice. However, when you're doing these
kinds of complex dependencies, you'd like to provide your own error
messages when they fail. That is, instead of:
'$credit_card_number excludes $ach_bank_account_number'
You could say:
'You can't give a credit card number and a bank account number, silly!'
Actually, I forgot to mention this in my original post, but in general
it'd be nice to be able to provide some sort of callback/object to be
called whenever a parameter check fails, and it'd be nice to be able to
provide more than one, so I can have custom parameter exception logic per
class or sub.
So I wonder whether this kind of logic is better for a P::V module in
Perl 6. Let somebody else think about the hard stuff like that.
It'd be nice to catch this at compile time whenever possible, though.
Presumably this can be done with the existing language. It doesn't add
anything at compile time, so it really doesn't need to be part of the
language.
Even things that do add things at compile time don't need to be part
of the language. That's why "use" is a macro. :-)
Yes, but see above. I know we can do things like add syntax at compile
time, but can we do these sorts of checks? I'm sure the answer is yes,
but how easy will it be? Of course, if it's implemented via a C6AN module
it's only got to be done once, but it's worth thinking about.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Thu, 18 Aug 2005, Yuval Kogman wrote:
You sortof can:
sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration &&
defined $credit_card_holder_name }
{...}
multi sub validate () { # no credit card info
}
multi sub validate (
$credit_card_number,
$credit_card_expiration,
$credit_card_holder_name
) {
}
Yeah, while playing with datetime stuff for pugs it occurred to me that
providing a fallback multi sub could be quite handy.
But I'd really like to get this stuff done at compile time wherever
possible. If I write this:
validate( credit_card_number: $number );
it should blow up at compile time, right?
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Wed, 17 Aug 2005, Dave Rolsky wrote:
Type Validation, "isa", & "can"
Params::Validate allows for several ways to check the _value_ of a parameter.
One way is to specify a primitive type like "SCALAR" or "ARRAYREF". In P6 we
have that with this:
sub date (Scalar +$year is required, ...)
I'm not sure is "Scalar" is a valid type though, but that's ok because we
have better types built in. In this case we should really use "Int" for a
year.
And another question. How will I make Perl6 not do automatic coercion for
me. If I have this sub:
sub date (Int +$year is required, +$month, +$day)
and someone does this:
date('this year', 12, 1);
I'd prefer for this to fail, rather than giving me -12-01! I vaguely
remember a mention of "use strict 'types'" either on this list or hanging
out with some pugs folks at YAPC.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: Hoping that Params::Validate is not needed in Perl6
On Thu, 18 Aug 2005, Autrijus Tang wrote: On Wed, Aug 17, 2005 at 11:45:52PM -0500, Dave Rolsky wrote: And another question. How will I make Perl6 not do automatic coercion for me. If I have this sub: sub date (Int +$year is required, +$month, +$day) BTW, Pugs supports the ++ syntax, which iirc is said to be back in favour during the Oscon design meeting: sub date (Int ++$year, +$month, +$day) Uh, great, what's the syntax mean again? It _looks_ like "+" as a prefix now means "must be passed as a name param" and "++" means must be passed as a named param and is required. Seems good to me. You will probably get: 1. a compile time warning of unsafe coercion, possibly made fatal. and 2. a NaN at runtime if you ignore the warning. Excellent. And presumably #1 will be activated by some lexically scoped pragma like "use strict 'types'"? Hurry up and finish. I want to use this language, darnit! And yes, I know about pugs, obviously, but for production usage I need less of a moving target ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Adding more kwalitee tests
On Mon, 5 Sep 2005, Thomas Klausner wrote: has_perl_dependency: In the META.yml (assuming it exists) there is a dependency on the version of perl required to install the dist. The goal of this is to make life a little easier on installers and CPAN testers and a few other things. Many many modules should pass this test already. The main goal however, is to help enable the NEXT kwalitee test to have better coverage. Hmm. I never added this of any to my dists. It might also be annoying for people if authors add a newer version of Perl as a prereq than they have installed and some installer then goes off to fetch & install a new version of Perl. (And it's a lot of hassle to find the exact lowest version of Perl you need). I'm pretty sure that CPAN and CPANPLUS will explicitly _not_ do this. The "perl" dependency is handled specially. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: coercion and context
On Wed, 14 Sep 2005, Luke Palmer wrote: my Int $int = $num; Explicit coercion, however, isn't done with context: it is done with the .as() method: $num.as(Int). I think that's weird. Not to mention the fact that you might have put an Int there for typechecking purposes instead of coersion purposes, and you actually want it to die if $num is a string. Hmmm, how do we get both at once? My 2 cents ... Coercion and typechecking need to be fairly distinguishable for reading and writing code, as they're very different things. I for one like "my Int $int" as type checking, meaning it'll die if not given an int, and some sort of method/function for coercion, presumably the above-mentioned "as(Int)". The default should be type-checking is always strict, and coercion is never automatic, IMO. Otherwise it's just not that useful, because you always have to remember the various auto-coercion rules. Of course, for people who think that's "intuititive", there could be some sort of "use coercion" pragma, maybe something like: use coercion Num => Int uses .int, String => Int uses .numerify_if_looks_like_number, Date => String uses .date; Of course I'm pulling the syntax/API from my nether regions. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Test run of the new Phalanx 100
On Mon, 17 Jan 2005, Andy Lester wrote: Msql-Mysql-modules This is just the old distro that contained DBD::mysql and DBD::msql. I don't think the latter is maintained, and DBD::mysql is already on the list. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Taint mode testing and project Phalanx
On Mon, 20 Oct 2003, Andrew Savige wrote: > I noticed in Test::Tutorial: > "Taint mode is a funny thing. It's the globalest of all global features. > Once you turn it on it effects all code in your program and all modules > used (and all the modules they use). If a single piece of code isn't > taint clean, the whole thing explodes. With that in mind, it's very > important to ensure your module works under taint mode." Not to mention that it's buggy as hell. For example, in various versions of Perl I've used there have been rather serious bugs in the regex engine when taint mode is on, even when dealing with untainted variables! I for one think taint mode is rather hopeless until taint mode itself gets better testing in the Perl core. > What are general opinions re taint tests for CPAN modules? > (i.e. a test with #!perl -Tw as the first line of the test). See above. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Taint mode testing and project Phalanx
On Mon, 20 Oct 2003, Michael G Schwern wrote:
> On Tue, Oct 21, 2003 at 12:24:03AM -0500, Dave Rolsky wrote:
> > On Mon, 20 Oct 2003, Andrew Savige wrote:
> > > I noticed in Test::Tutorial:
> > > "Taint mode is a funny thing. It's the globalest of all global features.
> > > Once you turn it on it effects all code in your program and all modules
> > > used (and all the modules they use). If a single piece of code isn't
> > > taint clean, the whole thing explodes. With that in mind, it's very
> > > important to ensure your module works under taint mode."
> >
> > Not to mention that it's buggy as hell. For example, in various versions
> > of Perl I've used there have been rather serious bugs in the regex engine
> > when taint mode is on, even when dealing with untainted variables!
>
> I've never hit anything like this. Do you have examples?
Well, one example comes from my Params::Validate module, where I have this
little bit of XS:
while (he = hv_iternext(p)) {
/* This may be related to bug #7387 on bugs.perl.org */
#if (PERL_VERSION == 5)
if (! PL_tainting)
#endif
SvGETMAGIC(HeVAL(he));
Whee, a random taint related bug.
Then there was the time I found that pos() didn't get updated inside
s/\G...//gc matches when taint mode was on, for certain versions of
Perl working with some strings (but not others). I don't think this
bug exists in the current version any more.
I could never reproduce this in a concise example, unfortunately.
Anyway, my taint mode experience has been that random things break in very
weird ways when using it.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: Taint mode testing and project Phalanx
On Tue, 21 Oct 2003, Michael G Schwern wrote: > On Tue, Oct 21, 2003 at 12:34:44PM -0500, Dave Rolsky wrote: > > Anyway, my taint mode experience has been that random things break in very > > weird ways when using it. > > All the more reason to test with it on. :) At this point I've become rather disgusted with it. When taint mode breaks pos(), and as a result your regex-based parser blows up in weird ways, and you spend many, many hours figuring out what exactly is happening, and then can't reduce it to a simple test case, you tend to get a little peeved. Tim's #ifdef idea for testing taint mode seems like a really good idea. Once I know it's well tested in the core, I'll be happy to test my own modules with it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Refactoring a test program: advice sought
On Mon, 17 Nov 2003, darren chamberlain wrote: > * Andrew Savige [2003-11-15 14:51]: > > I took a quick look a mod_perl and Template Toolkit (TT). > > TT has a: > > lib/Template/Test.pm > > which looks wrong to me (should that not be under t/lib instead?). > > Template::Test contains a bunch of (pre-Test::More) testing methods that > are geared towards writing TT tests. Some of my TT plugins use > Template::Test instead of Test::More. And Mason includes a module caled HTML::Mason::Tests in its distro. I've used that module for my MasonX::Request::WithApacheSession module, and I expect it to be installed as part of the Mason core code. This seems useful for things like templating tools and other things which create their own environment, like mod_perl, POE, etc. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: RFC 63 (v3) Exception handling syntax
On 15 Aug 2000, Perl6 RFC Librarian wrote: > =head2 Exceptions > > Exceptions are objects belonging to some C class. Cing > an exception creates the object; therefore, C above is just a > class name. C lets you subclass C to create them; > C appears to be a better name for a core functionality. > > The C function is just syntactic sugar for creating a new > exception class;it merely amounts to C<@EXCEPTION::ISA = 'Exception'>. I think its important to also provide some syntactic sugar for creating a hierarchical structure more than 2 levels deep. For example, I may have an Exception::Foo and then want an Exception::Foo::DB subclass of it. My Exception::Class module on CPAN is pretty much all about being able to do this easily. It also implements a base exception but that's really for convenience and isn't necessary. -dave /*== www.urth.org We await the New Sun ==*/
Re: Draft 1 of RFC 88 version 2.
On Thu, 17 Aug 2000, Tony Olekshy wrote:
> trace
>
> A listref containing a snapshot of the call-stack as at the time
> the exception is first raised. The array contains hashes (one
> per call stack level), each containing one key value pair for
> each snapshot value at that level. Here are some examples:
>
> $e->{trace}->[0]->{file}
> $e->{trace}->[0]->{line}
> $e->{trace}->[0]->{sub}
If the exception is an object I'd like to see this be an object as well.
I have a module on CPAN called Devel::StackTrace that implements an
interface for this.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Draft 3 of RFC 88 version 2.
On Sat, 19 Aug 2000, Tony Olekshy wrote: > die > > If argument isa "Exception", raise it as the new exception and > die in the fashion that Perl 5 does. > > If argument is a string, wrap it in a new Error object, setting > the message ivar to the given string, and raise that instead. Actually, the Perl5 die takes a list as its argument and does join '', @_ to it to make the actual error message. > If argument is anything else, raise a run-time exception. So this probably shouldn't be the case. /*== www.urth.org We await the New Sun ==*/
Re: RFC 88: Possible problem with shared lexical scope.
On Sun, 20 Aug 2000, Tony Olekshy wrote:
> Shared:
>
> try { my $p = P->new; my $q = Q->new; ... }
> finally { $p and $p->Done; }
> finally { $q and $q->Done; }
>
> If P->new throws, then the second finally is going to test
> $q, but it's not "in scope" yet (its my hasn't been seen).
> Or is it? If it isn't, I'll take shared lexical scoping out
> and put a note about this in ISSUES instead of the current:
This is not an issue (at least if my works in Perl 6 as it does in Perl
5). The scoping is determined at compile time so $q will be in scope
after this chunk is parsed. At run time it may or may not get something
assigned to it but your code already checks that.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: RFC 88: Possible problem with shared lexical scope.
On Sun, 20 Aug 2000, Tony Olekshy wrote:
> That would be nice. But does this mean that in the following
> case:
>
> try { fragile(); }
> catch { my $caught = 1; }
> finally { $caught and ... }
>
> storage for $caught is allocated and initialized to undef at the
> beginning of the *try* block, even though you're not allowed to
> see it there? Finally has to see it, as undef, even if the catch
> block isn't entered.
If all those pieces were in the same scope I think it would still work
like this (in Perl5-ish code):
{
try { fragile(); # It must be Italian }
my $caught;
catch { $caught = 1; }
finally { $caught and ... }
}
It's the same as in perl5 with a block:
{
print $foo;
my $foo = 1;
}
This is a compile time error because $foo isn't in scope til its declared.
Of course, what I know about the Perl internals fits on the head of a pin
so someone more knowledgeable should feel free to jump in.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: RFC 88: Possible problem with shared lexical scope.
On 22 Aug 2000, Chaim Frenkel wrote:
> Could you tell me why you would want two finallys?
>
> Why not put them into one?
> TO> my ($p, $q);
> TO> try { $p = P->new; $q = Q->new; ... }
> TO> finally { $p and $p->Done; }
> TO> finally { $q and $q->Done; }
Presumably because all finally blocks are executed before exceptions
thrown in finally blocks are propagated upwards. That's my guess at
least.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On Thu, 24 Aug 2000, Hildo Biersma wrote: > Don't impose your religion on others. If people want 'this' instead of > 'self', that should be just fine. > > It should be pretty easy to define the appropriate $ME-reader like this: > > use ObjectStyle 'self'; > > or > > use ObjectStyle 'Java'; > > for the appropriate, per-module scoped, definitions for: > > - self vs this > - super vs SUPER vs base vs parent > - DESTROY vs finalize vs destructor > - default of 'private', 'protected' or 'public' > > and any others we can come up with... I'm all for TMTOWTDOI but I really object to this idea. I have enough to deal with when reading other's modules without having to look for DESTROY *or* destroy *or* finalize *or* I_am_dying *or* whatever. Perl needs to walk a line between being flexible and remaining a language where I can download something from CPAN and have some chance of understanding it. Maybe the following would be ok: use self; # otherwise object is in @_ That I could live with. 4 different sets of object names and special sub names would kill me. -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC: Automatic accessors for hash-based objects
On Sat, 26 Aug 2000, James Mastros wrote:
> This example shows how much easier it would have been to write the
> example on line 170 of perltoot.pod:
>
> package Person;
> use strict;
>
> ##
> ## the object constructor (simplistic version) ##
> ##
> sub new {
> my $self = {};
> $self->{name} :accessible('rw') = undef;
> $self->{age} :accessible('rw') = undef;
> $self->{peers}:accessible('rw') = [];
> bless($self); # but see below
> return $self;
> }
This is an interesting idea. I would think that ideally it would be
combined with pre-declared limited keyspace hashes (which we currently
have in a semi-crippled way with pseudohashes). I'd much prefer that
these declarations happen outside the contructor, more like this maybe.
Also I really dislike 'rw' and such. Let's be a little clearer:
And this way we could drop the whole :accessible thing. How about this:
use fields qw(
name :read :write
age :read :write
peers :read :write
birth_date :read
);
Of course, what I think I really want is the ability to do a sort of
auto-tie so that instead of Perl generating accessors, it ties my
attributes directly to my own accessor function. That could be
incorporated into this syntax perhaps? Mayb as:
use fields qw(
name :read => \&name :write => \&name
age :read => \&get_age :write => \&set_age
);
Just some thoughts.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: RFC 188 (v1) Objects : Private keys and methods
On 1 Sep 2000, Perl6 RFC Librarian wrote:
> Private entries of hashes could be I accessed in packages
> that inherit from the entry's package, by qualifying (i.e. prefixing) the
> key with the entry's package name. For example:
>
> package Base;
>
> sub new {
> my ($class, @data) = @_;
> bless private { data => [@data] }, $class;
> }
>
>
> package SortableBase;
> use base 'Base';
>
> sub sorted {
> my ($self) = @_;
> print sort @{ $self->{Base::data} };
> }
Gack! This is in fact the reason I'm avoiding Tie::SecureHash, which is
otherwise well suited to my needs.
If I'm several lays deep in a hierarchy it seems awfully onerous for me to
have to know which ancestor my hash keys came from.
I would find a 'protected' keyword that did the same thing but allowed
unqualified access to child classes _much_ more useful.
I think both would be best.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: code repository
On Thu, 7 Sep 2000, Michael G Schwern wrote: > Refactoring is simply the automated alteration of code without > effecting its purpose. A simple example would be reversing the order > of arguments in a subroutine. A refactoring tool would be able to do > this for you automatically and in all code which uses that subroutine. > Handy. It does this by defining a set of simple operations which a > refactoring tool must be able to perform. From those simple > operations, it can do much more complicated things. Actually, I don't think that refactoring as a concept has anything to do with tools. Refactoring is simply the concept that sometimes you need to fix code that ain't broken. In other words, sometimes you have to do some sort of redesign in order to make future development easier, not because there's a bug to be fixed. Refactoring tools simply help you do some of these things more easily. -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC 222 (v1) Interpolation of method calls
First of all, I think this is a great idea
On 14 Sep 2000, Perl6 RFC Librarian wrote:
> Are there any contexts besides double quotes ("", qq{}, <<"EOF") where this
> need be applied? What about inside regexes? And if so, left and/or right
> hand side?
Regexes are enough like double quoted strings that I think _not_
interpolating here would be confusing. The same goes for backticks
(`)/qx, which is double-quote interpolated as well.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: RFC 260 (v1) More modules
On 19 Sep 2000, Perl6 RFC Librarian wrote: > =head2 Which modules? Just to throw out some possibilities for discussion: Date::Manip or some other date manipulation module. Date::Manip is cool but awfully huge, I know. Can't think of others right at this moment. -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC 245 (v1) Add new C keyword to DWIM for clearing values
On 17 Sep 2000, Perl6 RFC Librarian wrote:
>my $name = undef;
>my($a, $b, $c, $d, $e, $f) = undef;
Well, these two get the result they want. Try this code:
my($a, $b, $c, $d, $e, $f) = undef;
my %h = ( a => $a, b => $b, c => $c, d => $d, e => $e, f => $f );
while (my ($k, $v) = each %h)
{
print defined $v ? "$k is defined" : "$k is undefined";
print "\n";
}
it prints:
a is undefined
b is undefined
c is undefined
d is undefined
e is undefined
f is undefined
Why would anyone expect that assigning undef to anything would produce an
empty string. That makes no sense at all.
>my $name = empty;
what's wrong with $name = '';
>my($a, $b, $c, $d, $e, $f) = empty;
>my(@name, $age, %attrs) = empty;
What is the point of doing
my @name = ();
That's the same as:
my @name;
In fact, only for scalars does your proposed empty builtin do anything
different from my or local in terms of the value of the variable.
> And its purpose is intuitive: It causes a value to become C,
> without being undefined. Note that it can also shorten code in some
> situations.
Well, I don't want to encourage people to needlessly 'initialize'
variables in Perl.
The only case where it makes a difference is where you do:
my $x;
$x .= 'a';
$x .= 'b';
and you'll get an unitialized value warning. In that case, doing:
my $x = '';
is shorter and clearer. There's no point in trying to 'initialize' arrays
or hashes, because you'll never get those warnings with it.
> Nonetheless, feel free to point out why this is a bad idea and I'll
> gladly retract it.
See the above ;)
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: IO, Trees, and Time/Date
On Wed, 18 Feb 2009, Timothy S. Nelson wrote: Agreed, and that's kinda what I'm doing. But I still think there's room for improvement. 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. What does that mean? 2. Documents in terms of operator overloading I'm assuming that Perl 6 will make overloading saner. In Perl 5, it's a nasty hack. 3. Depends a lot more on CLDR formats Yes! 4. Doesn't have multiple functions that perform exactly the same thing Also yes. I copied this from Time::Piece, for reasons that probably made sense at the time. 5. As a consequence of all of the above, has a lot fewer functions (while still providing all the same functionality). Also good. I've actually started on some DateTime stuff for Perl 6, sort of. One thing I'd like to do is have Date, Time, and DateTime classes. There's a lot of people who _only_ need dates, and having to deal with time (and therefore time zones and other madness) is a useless conceptual burden. I was also hoping to separate out leap second handling so that it was a layer on top of a simple TAI-based underpinning. But really, I'd hate to see any of this be core. Date and time modules will need to be released regularly to keep up with things like locale updates, time zone changes, leap second announcements, etc. It wasn't clear to me whether you were proposing putting this yet-to-be-named thing core, of course. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Temporal revisited
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: r25405 - docs/Perl6/Spec/S32-setting-library
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
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: Temporal changes (was: Re: r25445 - docs/Perl6/Spec/S32-setting-library)
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
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.
I really don't think this is a good idea. CLDR is complicated _and_ likely
to change in the future, as it's defined by a spec which we do not
control.
It's also entirely oriented around locales, so to do it even vaguely
properly we'd have to at least include a locale, and which one would that
be? en-US?
Again, locales are complicated and subject to change.
If there _must_ be a formatter (which I don't think is necessary), I'd
suggest it be based on the Unix strftime. Except that still has some
locale-specific bits. However, generally you can get the system itself to
implement this for you.
+# 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.
I like those methods because they're fluent and easy to read. I think
forcing people to use a formatter for common, trivial cases is gross.
OTOH, I think the name returning methods could be dropped from core
entirely.
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:
No, by mutating I mean anything which changes the object. As I said, I
think it's best that the built-ins be immutable.
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.
Because DateTime makes sense and is a clear description of what the thing
is. Instant is incredibly ambiguous, and not a common term for such
things.
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.
But this is a bunch of roles. If I upload something called just "DateTime"
to CPAN6, it better do this role, right? That's part of the reason I'm
trying to keep things really simple.
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?
I'm sure there could be one constructor as a language built-in, time being
a reasonable candidate. But I can also see the value of having two, one
for UTC and one for local time.
-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
On Thu, 19 Feb 2009, Larry Wall wrote:
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.
Well, if you look at the spec I _did_ create subsets for most of those
values like this:
my subset Hour of Int where { 0 <= $^a <= 23 };
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...
That's certainly fine with me, but I think we'd still want some simple
objects on top of them, rather than handing people a single epoch numbre
to deal with.
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
Re: Temporal revisited
On Fri, 20 Feb 2009, David Green wrote: 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. Define really basic math. I don't think there is such a thing. DateTime math is complex. Attempts to make it less complex end up making it much harder on the end user. For example, you could say "all math is done in terms of seconds", but then there's literally no way to "add 1 month". 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. Duh, I dunno. I'll leave that to @Larry to decide. Honestly, I'm much more interested in the roles than the built-in interface. 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.) As I said in the spec, you _can_ get an observance for a given epoch value quite easily. This tells you the offset from UTC, whether DST is in effect, and a short name identifier (like CST). What you can't get easily in a cross-platform manner is a hook into the associated set of rules that defines all the timezone transitions in effect. 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. If there is a UTC epoch stored/calculable in each object, you can compare them safely. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Temporal revisited
On Fri, 20 Feb 2009, Richard Hainsworth wrote:
a) I am strongly in favour of "Instant" over "DateTime" for several reasons,
one being that it marks a new approach.
I don't care _that_ much. I'm happy to leave it to @Larry.
b) Although for business we use a calendar derived from the one decreed by
Julius Caesar, via Pope Gregory, additional days, and leap seconds, there are
many calendars in use, and there is no overwhelming logical reason why a
different calendar might not be used in the future. For the interested, the
Jews, Muslims, Baha'is and Chinese all use different calendars.
Yes, and this will be a great thing for CPAN6 ;)
c) Fixing the core6 time processing functionality to a specific calendar is
restrictive, whereas focussing on an underlying handling of time using an
accepted synchronisation standard allows for easier extensions.
d) This would mean that the functionality of dates should be handled by
modules.
Thus Temporal::Gregorian would include functionality that leads to years
from 1AD, 7 days of the week, 12 months with unequal day lengths, days
starting at midnight, and a mapping from the core perl6 values to current
calender values, eg. 20 Feb 2009.
Having a default set of roles that is Gregorian makes sense. It's the
world-wide standard, and has been for about 100 years or so. There's no
good reason to think that this will change in the lifetime of Perl 6.
e) Perhaps we could define the minimum time functionality in core perl6 by
some set of principles:
- attributes that will allow time keeping within a program;
- attributes that provide access to a global synchronisation standard;
- attributes that make it easy to map the global synchronisation onto a given
calendar structure;
- duration measuring (basic stopwatch functionality).
f) Date arithmetic is calendar-related because
$days_2_Xmas = Date('25 Dec 2009') - today();
requires information about the structure of months dependent on the year, but
it is also related to synchronisation to provide the today() term.
g) Depending on the software needs, date arithmetic can be simple, only
dealing with the next few years. Other times, it needs to be more complex, to
handle dates across centuries. Hence, there would be
Temporal::Gregorian::1907AD, Temporal::Gregorian::1AD etc.
I don't really follow this part.
h) Time functionality seems to me to need both immutable parts, viz., links
to the global synchronisation, and mutable - timezone and daylight saving. (I
would include these as part of the time-keeping part of the system). The time
of day depends on the position of the computer, but not on the calender date.
But if software is being written to be used on a portable or travelling
computer, there needs to be the means to change these offsets, perhaps as the
software is running.
A timezone _observance_ is not mutable. An observance is associated with a
specific datetime. If the datetime changes, the observance should change,
but this is a complicated thing to handle. If the datetime is immutable,
then this is a non-issue.
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
Re: Temporal revisited
On Fri, 20 Feb 2009, Leon Timmermans wrote: On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky wrote: 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. Why should an Instant be a role, and not a concrete class? What would one instant do that another can't? Representing a specific moment in time sounds like a very concrete thing to me. Presumably the core would also ship with a class that does the Temporal::DateTime role. However, it'd also be nice for things on CPAN6 to be able to satisfy an API that codes against these roles. I think that letting things in the core be replaceable is a good design. -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
On Fri, 20 Feb 2009, Daniel Ruoso wrote: Em Qui, 2009-02-19 às 15:58 -0800, Larry Wall escreveu: 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... I beg to disagree. If we're going to use an epoch, it should be the Operating System's epoch. Anything else will lead to confusion and disorder ;P And which OS epoch would that be? See http://en.wikipedia.org/wiki/Epoch_(reference_date)#Computing I don't care what epoch we standardize on, as long as it's consistent across platforms. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Temporal revisited
On Fri, 20 Feb 2009, Dave Whipp wrote: I'm getting a bit lost following precisely what's being proposed. What I'm sort of feeling is that there are two fundamental immutable types needed: Instants and Durations: multi sub infix:<-> (Instant, Instant --> Duration) multi sub infix:<+> (Instant, Duration --> Instant) multi sub infix:<-> (Instant, Duration --> Instant) Of those three, I think only the first is really required for core, so you can do stopwatch type calculations. If the Duration is just seconds, the latter two are fairly useless and broken. If it's not just seconds, the math is much more complicated, and that's not the sort of thing that belongs in core. , plus a bunch of formatting/coercion classes/functions (some of which understand time zones, etc): Please, no. Leave this for CPAN6. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Temporal revisited
On Fri, 20 Feb 2009, Larry Wall wrote: Duration and Instant are both simple (but typed) Num semantics on seconds. There are no integers unless you specifically ask for an interpretation in minutes, hours, fortnights, what have you. The basic flow of time is continuous and stable in Perl 6, or as continuous and stable as we can make it. Hence our ideal timeline will be strict atomic time in TAI, and machines that don't have access to the current atomic time will have to approximate it as best they can. They're already broken anyway, in my opinion. Only atomic time in atomic seconds will be futureproof over the long haul. All other interpretations are negotiable via libraries, but time must be considered a position on a real timeline, and seconds are a reasonable unit for measuring that timeline. The method in $duration.seconds should not have to do any calculations to return the Num number of seconds, because whether we're talking about gigaseconds or femtoseconds, we're still talking about seconds. Time has no relationship to integers apart from cultural artifacts. Let's keep our integers in the libraries, not in the fundamental definition of what "now" and "then" mean. As long as there's no attempt to provide math beyond "add this many seconds to this many seconds", it's probably safe. That will make it clear that there's no way to calculate "one month from today" using the core API. What I'm really trying to avoid is something like the Perl 5 Time::Seconds & Time::Piece combo, where the former defines a constant of ONE_MONTH so you can do: my $time = Time::Piece->new( ... ) $time += ONE_MONTH; But since ONE_MONTH is defined in terms of seconds, this is completely broken. Of course, if you're dealing with TAI only, you're safe for constants up to ONE_WEEK. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Temporal revisited
On Fri, 20 Feb 2009, mark.a.big...@comcast.net wrote: "one month from today" is ill-defined regardless what time system you are using. There are dates from which "one month from today" can be reasonably argued to be any of 5 different days. This is why bank contracts are always to be written to say 30, 60 or 90 days not 1, 2 or 3 months from now. It is ill-defined, but a good API can make something reasonable out of it. I refer you to DateTime and DateTime::Duration, which provide a reasonable API for this. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Perl 6 fundraising and related topics.
On Thu, 21 Feb 2008, Geoffrey Broadwell wrote: Someone earlier in this thread mentioned that this can't be done directly because of rules surrounding TPF's non-profit status. Someone else pointed out the problems with TPF officers benefitting directly from the donations, even though some of the current and former TPF officers would be great candidates for support. Which made me think ... wasn't this why Mozilla created a corporation? I doubt that's why. If TPF owned The Perl Corporation (TPC), there'd still be serious conflict of interest issues were TPC to be employing TPF board members or other officers. If anything, this would look even _worse_ than giving them grant money from TPF! The main reason a nonprofit would create a for-profit subsidiary is in order to engage in business activities outside of that nonprofits tax-exempt purpose. That purpose is generally defined by the nonprofit's mission. TPF's missions is: The Perl Foundation is dedicated to the advancement of the Perl programming language through open discussion, collaboration, design, and code. I would guess that MoFo founded MoCo primarily because it wanted to pursue income sources that weren't compatible with MoFo's nonprofit status. I'm guessing that this was primarily the Google deal, and it was determined that the income from Google would be business income, and that it would be so much that if it came directly to MoFo it would compromise MoFo's status as a 501c3 nonprofit. I'd guess that the reasoning behind this is that in the Google deal, Google gets a benefit from the money it pays. It's not a donation. That means it's business income. TPF is not in a similar position at this time. There is no massive source of income available that would not be a donation, to the best of my knowledge. If there were such a source, forming a subsidiary for-profit corporation would be worthwhile. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Perl 6 fundraising and related topics.
On Thu, 21 Feb 2008, Joshua Gatcomb wrote: I am mostly ignoring the rest of what others have said in this thread because I think it is detracting from your intention of getting money to people to work more. Here is one thing that has frustrated me about TPF. They are a non-profit organization. Yeah, kind of suprising that would be the frustrating thing. The issue is that they can't take money from Bob to give to Sue to work on Bob's widget. This is an extreme oversimplification but in general, they have to abide by the rules that allow them to keep their non-profit status. Where am I going with this? This doesn't make any sense to me. There's nothing about being a nonprofit that prevents TPF from accepting donations targeted to a specific program. There's a bit of accounting overhead to make it happen, but it's perfectly legal and in keeping with TPF's 501c3 status and its mission. Regardless if we use TPF or not, I think what will get more people to contribute is having some say as to where there money goes. To that end, I suggest having a list of projects currently being funded. A donator can choose which fund their money goes to or can choose a general fund if they don't care. I don't suggest these projects be generic and nebulous either (though they could be for the same reason a general fund is). In other words, there might be a Rakudo fund - generic. There might also be a fund to fix RT # 31415 which is a Rakudo bug. I don't object to the idea of targeted donations, nor of having the community be more involved in that targeting. Sounds groovy. However, I'm not too interested in handing my personal cash over to TPF. I've thought about this for a while, and I'm convinced that for a variety of reasons, TPF should be working on getting most of its funding from corporations. One of the main reasons is simply that there's more bang for the fundraising effort. I can't afford to give TPF $5k, but there's many, many companies using Perl that could easily give $5k or maybe $50k. over where it went. Actually, it has been years since I have contributed to TPF. Now, I just write a check to the individual(s) I want to help. I don't get the tax write off but I know where my money is going. I would never do this, because it's not tax-deductible. Also, if you pay them enough (>= $2k, I believe) you'll have to file a 1099 form because they're now a subcontractor for you ;) Personally, I really think it's important that any money funding Perl work go through TPF. It keeps things tax-deductible _and_ it imposes a higher degree of accountability on the process. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Perl 6 fundraising and related topics.
On Fri, 22 Feb 2008, [EMAIL PROTECTED] wrote: That's what made me come to the conclusion that it's really "The Parrot Foundation". As brian mentioned, the NLNet grant is what's driving the Parrot work. AFAIK, there haven't been any Parrot-related grants for a long time besides that one and the MoFo/TPF grant to Patrick. To see other grants given go here - http://www.perlfoundation.org/grants Most of them are Perl 5 related. There are also the micogrants (http://www.perlfoundation.org/microgrants) which are all Perl 6 focused, but only one is Parrot-specific. So where is the problem? Why doesn't the money flow one way or another? Does TPF want to sponsor more Perl 5 related development? Or was that offer, $5k for 1 month full time hacking, not known before? TPF definitely does want to sponsor more on Perl 5. I think this is mostly TPF's communications problem. People don't know about the grants, or don't know what is likely to be accepted, don't know when to apply, etc. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Perl 6 fundraising and related topics.
On Tue, 26 Feb 2008, Ovid wrote: How else should we be advertising this? These mailing lists might be a good place. Basically, places where the work in question is done also seem like good places to advertise. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: Temporal
On Sat, 2 May 2009, Timothy S. Nelson wrote: Hi. Can someone (Dave Rolsky?) please tell me why rewriting S32/Temporal in terms of Enum roles would be bad? See the example of Enum day roles here: http://www.rakudo.org/node/39 Because day and month names are hardly universal, and forcing people to use English seems rather bizarre. What's gained from this? -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
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
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: 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: r30398 - docs/Perl6/Spec/S32-setting-library
On Fri, 16 Apr 2010, pugs-comm...@feather.perl6.nl wrote: +=head2 Semi-internal methods + +[This section is severely conjectural] + +For efficient implementation of arithmetics on C objects, two more +methods are exposed: + +$d.daycount +Date.new-from-daycount(Int $daycount) I'd _really_ like to see this be based on Rata Die, which is January 1, 0001. See http://en.wikipedia.org/wiki/Rata_Die This epoch value is used as the basis for many calendrical calculations in the Calendarical Calculations book, and has in turn been used as the method for calendar conversion in the Perl 5 DateTime sweet. Exposing this value explicitly (rata-die-day-count) would be a wise decision, IMO. Also, "day-count", not "daycount" ;) -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
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) */
