Re: underscores vs hyphens (was Re: A new era for Temporal)
Agreed. Perl borrows vocabulary almost exclusively from English, but it is not English, and its conventions are not those of English. (And the conventions around hyphens that people are citing are quite specifically those of standard written English; other writing systems, even those using the same alphabet and mostly the same punctuation, have different rules). I would personally like to see hyphens used as the standard word separator, with underscores available for exceptions - say, naming a Perl interface method exactly the same as the underlying C function it provides access to. I'd be less happy with underscores everywhere, but either of those solutions is better (IMESHO) than mixing hyphens and underscores, which should be avoided even within an API, never mind a single identifier. On Sat, Apr 10, 2010 at 8:55 PM, John Siracusa wrote: > On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso wrote: > > Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: > >> I'm having trouble imaging any convention that involves mixing word > >> separators being successful. > > > > But the convention Damian is proposing is simply "use underscores". > > > > Basically camelCase and with_underscores are conventions on "how to > > circunvent the fact that we can't use spaces in our identifiers". What > > is proposed here is that the p5 convention should be preserved. > > > > The hyphen is *not* a space, so it doesn't even get into the discussion > > of this convention. The basic difference is that when a programmer with > > sufficient communication skills have a composed word (i.e.: week-day), > > he will have the ability to use the hyphen instead of either supress it > > or use an underscore... > > These nuances are exactly what will be lost on people who see classes > that use both underscores and hyphens in their method names. > > -John > -- Mark J. Reed
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso wrote: > Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: >> I'm having trouble imaging any convention that involves mixing word >> separators being successful. > > But the convention Damian is proposing is simply "use underscores". > > Basically camelCase and with_underscores are conventions on "how to > circunvent the fact that we can't use spaces in our identifiers". What > is proposed here is that the p5 convention should be preserved. > > The hyphen is *not* a space, so it doesn't even get into the discussion > of this convention. The basic difference is that when a programmer with > sufficient communication skills have a composed word (i.e.: week-day), > he will have the ability to use the hyphen instead of either supress it > or use an underscore... These nuances are exactly what will be lost on people who see classes that use both underscores and hyphens in their method names. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: > I'm having trouble imaging any convention that involves mixing word > separators being successful. But the convention Damian is proposing is simply "use underscores". Basically camelCase and with_underscores are conventions on "how to circunvent the fact that we can't use spaces in our identifiers". What is proposed here is that the p5 convention should be preserved. The hyphen is *not* a space, so it doesn't even get into the discussion of this convention. The basic difference is that when a programmer with sufficient communication skills have a composed word (i.e.: week-day), he will have the ability to use the hyphen instead of either supress it or use an underscore... daniel
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 4:53 PM, John Siracusa wrote: > I'm not sure if the intersection of people who speak English and > people who program is better or worse than average when it comes to > grammar, but I do know (from editing my share of writing) that the > average is very bad and, further, that many programmers do not speak > English as a first language, or at all. Adjectives and nouns aren't English-only. So Damian's proposal is multi-culti. One could argue that Perl's identifiers, keywords, etc are based on English so that it is more difficult for a non-English speaker to discern why underscore is used in some places and hyphens in other. The solution to that would be rote memorization of method names, including "_" and "-" in the spelling. Not ideal, but most likely what many English speaking programmers would do too. And would cuss over.
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway wrote: > And is it really so hard to teach: "use underscore by default and reserve > hyphens for between a noun and its adjective"? Perhaps it *is*, but > then that's a very sad reflection on our profession. I'm not sure if the intersection of people who speak English and people who program is better or worse than average when it comes to grammar, but I do know (from editing my share of writing) that the average is very bad and, further, that many programmers do not speak English as a first language, or at all. I'm having trouble imaging any convention that involves mixing word separators being successful. Maybe a completely deterministic one like "hyphens after vowels, underscores after consonants," but that's pretty nonsensical. I think it has to be all hyphens or all underscores within a single method name, with the only wiggle room being a possible convention that dictates a different word separator for different kinds of methods. (My personal preference: methods_like_this(), just like in Perl 5. My second choice: methods-like-this(). Either way, no grammar knowledge required beyond knowing where one word ends and another begins—and even that's not a universal skill!) -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
John Siracusa commented: > That's certainly an example of how hyphens might gain meaning in Perl > 6 names, but I don't think I can endorse it as a convention. People > can't even use hyphens correctly in written English. I have very > little faith that programmers will do any better in code But then the only alternative is to suffer under Slartibartfast's Conundrum: Slartibartfast: I'd much rather be happy than right, any day. Arthur Dent: And are you? Slartibartfast: Ah, well...that's where it all falls down, of course. ;-) And is it really so hard to teach: "use underscore by default and reserve hyphens for between a noun and its adjective"? Perhaps it *is*, but then that's a very sad reflection on our profession. I'm certainly not saying we mightn't collectively find a better (more useful) rule, but that one doesn't strike me as particularly hard. Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
In English, hyphens normally indicate an extra level of reification, where e.g. what is normally a phrase is used in a context that requires a single word: "The miller gave us the run of the mill." vs. "It was a run-of-the-mill event." As such, examples like "day?of?week" are somewhat infelicitous, as they could go either way depending on context. In fact, I'd be tempted to go with the punctuation-free "weekday", despite spoiling the nice parallelism with "day?of?month", "year", etc. (Perhaps a generic day_of() that takes a keyword argument would be a useful addition?) But that's going off the track (or off-track). Programming statements do not, in general, read like English, and as such, trying to apply English punctuation rules will at best yield ambiguous results. On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway wrote: > Personally, I'd prefer to see the English conventions carried over to > the use of general use of hyphen and underscore in identifiers in > the core (and everywhere else). > > By that, I mean that, in English, the hyphen is notionally a > "higher precedence" word-separator than the space > (or than its intra-identifier stand-in: the underscore). > > For example: there's an important difference between: > >initiate_main-sequence_detonator_phase() > > and: > >initiate_main_sequence-detonator_phase() > > The former initiates the detonator phase for the main sequence; > the latter initiates the main phase of the sequence detonator. > > More simply, there's a difference between: > > $obj1.set_difference($obj2); > > and: > > $obj1.set-difference($obj2); > > The first is setting a difference; the second is computing a > difference-of-sets. > > The rule I intend to use and recommend when employing this new > identifier character in multiword names is that you should place an > underscore between "ordinary unrelated" words, and a hyphen only > between a word and some modifier that applies specifically to that word. > > Which, if applied to Temporal, would lead to: > >my $now = DateTime.from_epoch(time); > >The C method also has the synonym C. > >(These are also available through the methods C and >C, respectively.) > >There's a C method, > >The C method returns a number 1..5 > >The C method returns the day of the quarter. > >The C method returns the day of the year, > >The method C returns the second truncated to an integer. > >The C method returns the C object > > (i.e. only C<.from_epoch()> actually uses underscore). > > Oh, and the optional C<:timezone> argument to C<.new()> should probably > become C<:time-zone> for consistency with the C<.time-zone()> method > (or, preferably, we should jut bite the bullet and go with C > throughout). > > Damian > -- Mark J. Reed
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway wrote: > Personally, I'd prefer to see the English conventions carried over to > the use of general use of hyphen and underscore in identifiers in > the core (and everywhere else). That's certainly an example of how hyphens might gain meaning in Perl 6 names, but I don't think I can endorse it as a convention. People can't even use hyphens correctly in written English. I have very little faith that programmers will do any better in code, leading to the worst of all possible worlds: a convention that is confusing and employed incorrectly much of the time. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a "higher precedence" word-separator than the space (or than its intra-identifier stand-in: the underscore). For example: there's an important difference between: initiate_main-sequence_detonator_phase() and: initiate_main_sequence-detonator_phase() The former initiates the detonator phase for the main sequence; the latter initiates the main phase of the sequence detonator. More simply, there's a difference between: $obj1.set_difference($obj2); and: $obj1.set-difference($obj2); The first is setting a difference; the second is computing a difference-of-sets. The rule I intend to use and recommend when employing this new identifier character in multiword names is that you should place an underscore between "ordinary unrelated" words, and a hyphen only between a word and some modifier that applies specifically to that word. Which, if applied to Temporal, would lead to: my $now = DateTime.from_epoch(time); The C method also has the synonym C. (These are also available through the methods C and C, respectively.) There's a C method, The C method returns a number 1..5 The C method returns the day of the quarter. The C method returns the day of the year, The method C returns the second truncated to an integer. The C method returns the C object (i.e. only C<.from_epoch()> actually uses underscore). Oh, and the optional C<:timezone> argument to C<.new()> should probably become C<:time-zone> for consistency with the C<.time-zone()> method (or, preferably, we should jut bite the bullet and go with C throughout). Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
Mark (>>), John (>): >> I'd much rather see a single consistent style throughout > > Yeah, that's was my main point/question. I wanted to know if it was > it some intentional convention (e.g., "all methods that change the > object state use hyphens, and all others use underscores") or if it > was just meaningless inconsistency. John, where is the inconsistency of which you write? Curious, I grepped through Temporal.pm in search for hyphens in method names, but found none. // Carl
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed wrote: > I'd much rather see a single consistent style throughout Yeah, that's was my main point/question. I wanted to know if it was it some intentional convention (e.g., "all methods that change the object state use hyphens, and all others use underscores") or if it was just meaningless inconsistency. Perl 6 does need some sort of convention in this area. Since it has a wider range of possible method names, there are more options. It took a little while for Perl 5 to converge on method_names_like_this() (after trying methodNamesLikeThis and LikeThis and so on), but many of those experiments and false starts still linger on CPAN and in end-user code. It'd be nice to avoid all that in Perl 6. -John
r30359 - docs/Perl6/Spec
Author: lwall
Date: 2010-04-10 20:12:11 +0200 (Sat, 10 Apr 2010)
New Revision: 30359
Modified:
docs/Perl6/Spec/S02-bits.pod
Log:
[S02] explicate (non)-relationship of interpolation and whitespace/unspace
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2010-04-10 16:29:54 UTC (rev 30358)
+++ docs/Perl6/Spec/S02-bits.pod2010-04-10 18:12:11 UTC (rev 30359)
@@ -13,8 +13,8 @@
Created: 10 Aug 2004
-Last Modified: 7 Apr 2010
-Version: 212
+Last Modified: 10 Apr 2010
+Version: 213
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -3148,6 +3148,10 @@
notations work in normal Perl code. They work only in interpolations
and regexes and the like.
+Note that the inside of the brackets is not an expression, and you
+may not interpolate there, since that would be a double interpolation.
+Use curlies to interpolate the values of expressions.
+
The old C<\123> form is now illegal, as is the C<\0123> form.
Only C<\0> remains, and then only if the next character is not in
the range C<'0'..'7'>. Octal characters must use C<\o> notation.
@@ -3602,7 +3606,18 @@
"Val = { $a.ord.fmt('%x') }\n"
+However, no interpolated postfix may start with a backslash, so any
+backslash or unspace is not recognized, but instead will be assumed
+to be part of the string outside of the interpolation, and subject
+to the normal backslashing rules of that quote context:
+my $a = 42;
+"Val = $a\[junk\]"; # Val = 42[junk]
+"Val = $a\[junk]"; # Val = 42[junk]
+"Val = $a\ [junk]"; # Val = 42 [junk]
+"Val = $a\.[junk]"; # Val = 42.[junk]
+
+
=item *
In order to interpolate an entire array, it's necessary now to subscript
@@ -3664,13 +3679,19 @@
=item *
Multiple dereferencers may be stacked as long as each one ends in
-some kind of bracket:
+some kind of bracket or is a bare method:
-print "The attribute is @baz[3](1,2,3){$xyz}.attr().\n"
+print "The attribute is @baz[3](1, 2, 3).gethash.{$xyz}.attr().\n"
Note that the final period above is not taken as part of the expression since
-it doesn't introduce a bracketed dereferencer.
+it doesn't introduce a bracketed dereferencer. The parens are not required
+on the C<.gethash>, but they are required on the C<.attr()>, since that
+terminates the entire interpolation.
+In no case may any of the top-level components be separated by
+whitespace or unspace. (These are allowed, though, inside any
+bracketing constructs, such as in the C<(1, 2, 3)> above.)
+
=item *
A bare closure also interpolates in double-quotish context. It may
@@ -3678,11 +3699,14 @@
inside the closure. The expression inside is evaluated in string item
context. You can force list context on the expression using
the C operator if necessary. A closure in a string establishes
-its own lexical scope.
+its own lexical scope. (Expressions that sneak in without curlies,
+such as C<$(...)>, do not establish their own lexical scope, but use
+the outer scope, and may even declare variables in the outer scope, since
+all the code inside (that isn't in an eval) is seen at compile time.)
The following means the same as the previous example.
-print "The attribute is { @baz[3](1,2,3){$xyz}.attr }.\n"
+print "The attribute is { @baz[3](1,2,3).gethash.{$xyz}.attr }.\n"
The final parens are unnecessary since we're providing "real" code in
the curlies. If you need to have double quotes that don't interpolate
r30357 - docs/Perl6/Spec/S32-setting-library
Author: colomon Date: 2010-04-10 18:10:42 +0200 (Sat, 10 Apr 2010) New Revision: 30357 Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod Log: [Numeric] Move sqrt to Numeric. Remove incorrect return value type of roots. Move cis and unpolar to Real. Add to-radians and from-radians to Numeric. Modified: docs/Perl6/Spec/S32-setting-library/Numeric.pod === --- docs/Perl6/Spec/S32-setting-library/Numeric.pod 2010-04-10 15:46:49 UTC (rev 30356) +++ docs/Perl6/Spec/S32-setting-library/Numeric.pod 2010-04-10 16:10:42 UTC (rev 30357) @@ -19,8 +19,8 @@ Created: 19 Mar 2009 extracted from S29-functions.pod -Last Modified: 15 Feb 2010 -Version: 5 +Last Modified: 9 Apr 2010 +Version: 6 The document is a draft. @@ -123,27 +123,21 @@ desired multiplier. For picking a random integer you probably want to use something like C<(1..6).pick> instead. +=item sqrt + + our Numeric multi method sqrt ( Numeric $x: ) is export + +Returns the principle square root of the parameter. + =item roots - method roots (Numeric $x: Int $n --> List of Num) is export + method roots (Numeric $x: Int $n ) is export Returns a list of all C<$n>th (complex) roots of C<$x>. Returns C if C<< $n <= 0 >>, itself if C<$n == 0>, and is free to return a single C if C<$x> is C or C, or in case of complex numbers if one of the components is. -=item cis - -our Complex multi method cis (Real $angle:) is export - -Returns 1.unpolar($angle) - -=item unpolar - -our Complex multi method unpolar (Real $mag: Real $angle) is export - -Returns a complex number specified in polar coordinates. Angle is in radians. - =item i our Complex multi postfix: ( Numeric $x ) @@ -155,6 +149,18 @@ $land\i ($land)i +=item to-radians + + our Numeric multi method to-radians ( Numeric $x: TrigBase $base ) is export + +Convert from C<$base> to radians. + +=item from-radians + + our Numeric multi method from-radians ( Numeric $x: TrigBase $base ) is export + +Convert from radians to C<$base>. + =back @@ -225,13 +231,19 @@ you I call C yourself if you wish to specify a deterministic seed (or if you wish to be differently nondeterministic). -=item sqrt +=item cis - our Real multi method sqrt ( Real $x: ) is export +our Complex multi method cis (Real $angle:) is export -Returns the square root of the parameter. +Returns 1.unpolar($angle) +=item unpolar +our Complex multi method unpolar (Real $mag: Real $angle) is export + +Returns a complex number specified in polar coordinates. Angle is in radians. + + =back =head2 Num
Re: A new era for Temporal
Is Int a proper type? I hope I can use basic operation within Date and hours
in perl6 like:
Date -1/24 + 1/24/60 + Date
On Fri, Apr 9, 2010 at 10:00 PM, Moritz Lenz wrote:
> Am 09.04.2010 15:33, schrieb Dave Rolsky:
>
> On Thu, 8 Apr 2010, Carl Mäsak wrote:
>>
>> I do want to explicitly credit Dave Rolsky, whose work on the DateTime
>>> family of modules on CPAN has informed much of the current spec,
>>> sometimes to the point of verbatim copying.
>>>
>>
>> Thanks, but I'd hate to see you copy all my mistakes too!
>>
>> One thing I think is really important is to offer a Date-only object
>> without a time component.
>>
>> The lack of such an object in Perl 5's DateTime family is a real
>> problem. If you're only interested in dates and date math, time and time
>> zones just muddies the water.
>>
>
> I fully agree. I found Date::Simple on CPAN to do exactly what I want if I
> want date-only arithmetic. Here's a short summary:
>
> * Dates are constructed with today() or date('2010-04-09')
> * Operations: Date - Date => Int, Date + Int => Date, Date - Int => Date.
> Also ++ and -- are defined for Date objects. (In Perl 6 that would
> Date.succ, Date.pred)
> * Date objects can be queried for year, month, day, day of week (maybe day
> of year too, not sure)
> * Date objects stringify in the same format as accepted in the constructor.
>
> That's it.
>
> I hope to find the tuits to add such a type to the spec, and some
> additional constructors (like DateTime.Date or so).
>
Re: underscores vs hyphens (was Re: A new era for Temporal)
I'd much rather see a single consistent style throughout the setting than backwards compatibility with p5 naming conventions. If Temporal is the first setting module to use multiword identifiers, I vote for hyphens. They're easier on the fingers and the eyes; underscores have always felt like an ugly compromise to make the compiler's job easier. On Saturday, April 10, 2010, Carl Mäsak wrote: > John (>): >> Forgive me if this is a question the reveals how poorly I've been >> following Perl 6 development, but what's the deal with some methods >> using hyphen-separated words (e.g., day-of-week) while others use >> "normal" Perl method names (e.g., set_second)? > > I'd just like to point out that the current Temporal spec only does > methods with underscores, including C. > > This goes against my personal preferences; I greatly prefer dashes in > almost all of the code I write. But I acknowledge that most of the > programmers out there seem to expect underscores -- and also, the aim > was to produce a small delta from CPAN's DateTime and not change > around things ad lib. > > // Carl > -- Mark J. Reed
Re: underscores vs hyphens (was Re: A new era for Temporal)
John (>): > Forgive me if this is a question the reveals how poorly I've been > following Perl 6 development, but what's the deal with some methods > using hyphen-separated words (e.g., day-of-week) while others use > "normal" Perl method names (e.g., set_second)? I'd just like to point out that the current Temporal spec only does methods with underscores, including C. This goes against my personal preferences; I greatly prefer dashes in almost all of the code I write. But I acknowledge that most of the programmers out there seem to expect underscores -- and also, the aim was to produce a small delta from CPAN's DateTime and not change around things ad lib. // Carl
