Re: Proposal for a new Temporal time-measurement paradigm
On Wed, 21 Apr 2010, Mark J. Reed wrote: I recommend not to open this up for 6.0.0 core. Calendar conversion is easy to do in a module, and the Date class has an absolute day count, which is really all you need everything for an intermediate representation. It wouldn't be hard to port Calendrica, for instance. What he said. Perl is all about good Huffman coding. The _vast_ majority people who need to do stuff with dates and datetimes will be dealing with the modern Gregorian calendar. Therefore, having a correct and simple to use implementation of some minimal Gregorian calendar objects in core makes a lot of sense. For folks who need to get fancier, the day count on the Date class will allow simple conversion between calendars, which they can find on CPAN6, along with modules that do more with the Gregorian calendar. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: 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 CDate 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: 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 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: 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: 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, Leon Timmermans wrote: On Thu, Feb 19, 2009 at 7:26 PM, Dave Rolsky auta...@urth.org 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, 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) */
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: 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) */
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: 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: 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, EOF);
( ( Employee RENAME name AS employee_name ) NATURAL JOIN ( Department
RENAME name AS department_name ) )
WHERE X.department_name = 'Management'
EOF
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: 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: 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 / +alpha+[_] +alpha+digit+[_]* /;
(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 other folks use/want to see?
-dave
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: 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: $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 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: 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: 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 Csub foo {...} 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 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: 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 188 (v1) Objects : Private keys and methods
On 1 Sep 2000, Perl6 RFC Librarian wrote:
Private entries of hashes could be Iindirectly 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: 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: 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 ==*/
