Re: Documentaion Details (was: underscores vs hyphens)
Matthew Walton wrote: On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey shawnhco...@gmail.com wrote: So, I'll ask again: Where in the official documentation does it state that Perl 6 names are case sensitive? I think it's more important to ask where it says that they aren't. 1) Perl 5 is case sensitive, and the original Apocalypses ran on the basis of 'if it's not mentioned it's the same as Perl 5' 2) The spec assigns no meaning to identifier characters, it just allows you to use a certain set of them. They mean nothing to the language, therefore it has no concept of case to be insensitive about 3) Most popular programming languages are also case-sensitive Maybe it should be explicitly mentioned somewhere, but I think it's a reasonable default assumption. Programmers know that case-insensitivity is a special form of string comparison which involves lots of extra work, so tend to assume (at least in my experience) that it's not going to happen unless they actually ask for it. You're looking at it from the point of view of experienced programmers. What if the person is a high-school student learning Perl 6 as their first programming language? (And yes, I take the point of view that any computer language that a high-school student can not learn is useless.) It's fine to assume that anyone who reads the Apocalypses is a very experienced programmer but when it comes to the official documentation, such things should be explicitly stated. By now, the documentation should be reaching its final stages. Yes, it's a finicky little detail but programming is all about getting the finicky little details right. -- Just my 0.0002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. Eliminate software piracy: use only FLOSS.
Re: Temporal.pod truncate
On Thu, 8 Apr 2010, Carl Mäsak wrote:
Among the cons: we lose the nice symmetry wherein :today clears all
values smaller than days, :toyear clears all values smaller than
years, etc. :tomonday is still pretty straightforward, but it's a
subtle category error.
Of course. What I really want is for weeks to start on Sunday, like
all the calendars around me seem to indicate that they do. Rather than
pushing my particular time-ideology on everyone else, I would like to
see a post-modern solution for the problem.
Having an internal variable like $[ to define the first day of the week
has turned out bad in the past, so I proposed this solution instead.
Apart from that, I wouldn't mind making the change. Though maybe we
should take a step backward and just remove :toweek altogether on
the grounds that it doesn't belong, and is more confusing than useful.
I agree that :toweek is confusing, but just because not everyone can
agree on the definition of week. But if you are writing a calendar
application, it is very useful. We measure time in weeks just as often
as we measure it in months, and weeks are a much less confusing time
interval than months are. Just because we prefer to _write_ dates
in terms of months doesn't mean weeks are any less valid of a time
interval. Anything besides year and day is rather artificial,
so maybe we should forget about months, weeks, hours, minutes and
seconds too. They should all be part of the calendar class, right?
On Fri, 9 Apr 2010, yary assumed:
indeed truncating to any day of the week can be implemented by user
trivially by adding/subtracting a constant number of days from the
Monday returned.
No, it's not a constant.
$sun = DateTime.new('2010-04-11').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-11').trunc( :tomonday ) # 2010-04-05
$sun - $mon == 6 days
$sun = DateTime.new('2010-04-12').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-12').trunc( :tomonday ) # 2010-04-12
$sun - $mon == -1 day
On Thu, 8 Apr 2010, Mark J. Reed wrote:
I think that :toweek should stay as-is; it truncates to whatever the
.week method returns, and that's Monday-based. It would be too
inconsistent for it to do anything else.
Agreed. That's why I asked for :tosunday
Asking for the latest prior Sunday or any other weekday is a useful
function, but it doesn't really have anything to do with 'truncation'.
Asking for the first of the month is truncating to an even more arbitrary
interval than a seven-day period, but we still call it truncation somehow.
The trouble with asking for the prior sunday, is that on sunday an
implementation of the prior() function will return a date 7 days prior to
today, while an implementation of the truncate() function will return
today.
Re: Temporal.pod truncate
On Tue, Apr 13, 2010 at 12:35 PM, John Williams willi...@tni.com wrote: Asking for the latest prior Sunday or any other weekday is a useful function, but it doesn't really have anything to do with 'truncation'. Asking for the first of the month is truncating to an even more arbitrary interval than a seven-day period, but we still call it truncation somehow.\ The size of the unit (and that size's variability) wasn't my point; it's that the unit is part of the fundamental identity of the date. A date is not a day; it's a particular name for a day. So when you truncate it, what you are removing precision from is the name. If the end result doesn't look like part of the name, it's not truncation. IMESHO, of course. The only reason you can truncate to the week in the proposed DateTime is because it includes support for the ISO week-based calendar, in additiion to the Gregorian. So just as you can truncate the Gregorian date April 13, 2010 to April 2010 or to 2010, you can truncate the ISO 8601 date 2010W15-2 to 2010W15 or to 2010. In each case the result of the truncation is the first day of the named period, which in the case of the ISO week calendar happens to be a Monday, but the truncation actually represents the whole period - just as truncating a real number to an integer yields a value that logically represents the entire half-open range from that integer to the next. You can imagine objects representing dates using other calendar systems. Today's Julian date March 31, 2010 could be truncated to March 2010 or to 2010; the Mayan long count 12.19.17.4.17 could be truncated to unial 12.19.17.4 or tun 12.19.17 or katun 12.19 or baktun 12. But unless I'm using a date object that has a baktun property, I wouldn't expect to be able to truncate to the baktun. The trouble with asking for the prior sunday, is that on sunday an implementation of the prior() function will return a date 7 days prior to today, while an implementation of the truncate() function will return today. True; that's why the Calendrica function is called kday-on-or-before instead of prior-kday - or actually, it may have both of those, with the difference you indicated. It's all about choosing the right name. :) Whatever you call it, it's a valuable function, I'm just arguing that it's not truncation unless you're talking about a calendar where you number Sunday-based weeks from a given epoch. -- Mark J. Reed markjr...@gmail.com
Re: Temporal.pod truncate
===
indeed truncating to any day of the week can be implemented by user
trivially by adding/subtracting a constant number of days from the
Monday returned.
No, it's not a constant.
$sun = DateTime.new('2010-04-11').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-11').trunc( :tomonday ) # 2010-04-05
$sun - $mon == 6 days
$sun = DateTime.new('2010-04-12').trunc( :tosunday ) # 2010-04-11
$mon = DateTime.new('2010-04-12').trunc( :tomonday ) # 2010-04-12
$sun - $mon == -1 day
===
You're not understanding me right- the addition subtraction have to
happen twice. (Ever had to truncate to an arbitrary multiple of 10 for
example?)
$sunday =DateTime.new(date_in_question+1 day).trunc( :tomonday) - 1 day
