Re: underscores vs hyphens (was Re: A new era for Temporal)
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). More is better. It was better to have upper as well as lower case letters in variables. It is better to have - as well as _ The more specialised use of upper case letters, such as SYSTEM identifiers, seems to have evolved over time. Depending on my fancy, I sometimes use variables like OriginalValue and sometimes Starting-value. If the program is just for me, who cares? If the software is for a company, they will set the rules. Communities at large generate their own standards. Where it matters, people obey them. Where rules are set because it is supposed to be a good thing, programmers take delight in breaking them. Personally, the rule use only - or _ consistently throughout a module reeks of a rule for rule's sake, one for the breaking. Damian's suggestion seems to me very useful because (for those that wish to follow it) it imposes an extra precision of thought, which almost always facilitates better programming. Adopting it will, I think, lead to more elegant code, for those that like that sort of thing. Regards, Richard
Re: underscores vs hyphens (was Re: A new era for Temporal)
Am I the only one who sees a hyphen and thinks binary minus? Just because the parser can disambiguate this use of it doesn't mean the reader's brain can do so as easily. (I assume we're talking about the same character, 0x2D, and not something from further afield in the Unicode tables, right?) Also, what happens when code gets run through mailers or other programs that think a hyphen is an acceptable place to break a line? Does the code still work after copy and paste with that newline inserted? -- Peter Scott http://www.perlmedic.com/ http://www.perldebugged.com/ http://www.informit.com/store/product.aspx?isbn=0137001274 http://www.oreillyschool.com/courses/perl1/
Re: underscores vs hyphens (was Re: A new era for Temporal)
Peter Scott wrote: Am I the only one who sees a hyphen and thinks binary minus? Just because the parser can disambiguate this use of it doesn't mean the reader's brain can do so as easily. It's all a matter of practice. Since variables begin with sigils, and you should put whitespace around infix operators anyway, it's not really hard. Have you tried looking at actual Perl 6 code that uses hyphens? I have, and I didn't find it hard. (I assume we're talking about the same character, 0x2D, and not something from further afield in the Unicode tables, right?) Yes. Also, what happens when code gets run through mailers or other programs that think a hyphen is an acceptable place to break a line? Does the code still work after copy and paste with that newline inserted? The existence of broken tools shouldn't stop progress -- rather the progress should encourage us to fix broken tools (or replace them with better ones). Cheers, Moritz
Re: underscores vs hyphens (was Re: A new era for Temporal)
Darren Duncan wrote: See http://perlcabal.org/syn/S02.html#Names for your answers. Thanks for the link but nowhere in it does it state tha Perl 6 names are case sensitive. The best the do is this, which implies it is but doesn't state it. Other all-caps names are semi-reserved. We may add more of them in the future, so you can protect yourself from future collisions by using mixed case on your top-level packages. (We promise not to break any existing top-level CPAN package, of course. Except maybe ACME, and then only for coyotes.) So, I'll ask again: Where in the official documentation does it state that Perl 6 names are case sensitive? -- 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: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey shawnhco...@gmail.com wrote: Darren Duncan wrote: See http://perlcabal.org/syn/S02.html#Names for your answers. Thanks for the link but nowhere in it does it state tha Perl 6 names are case sensitive. The best the do is this, which implies it is but doesn't state it. Other all-caps names are semi-reserved. We may add more of them in the future, so you can protect yourself from future collisions by using mixed case on your top-level packages. (We promise not to break any existing top-level CPAN package, of course. Except maybe ACME, and then only for coyotes.) 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.
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote: : Damian Conway wrote: : The relevant suggestion regarding hyphens vs underscores is: : : ...to allow both characters, but have them mean the same thing. : : That is, any isolated internal underscore can be replaced with an : isolated internal hyphen (and vice versa), without changing the meaning : of the identifier. : : I am formally opposed to this idea. I see that making underscores : and hyphens to be equivalent is akin to having case-insensitive : identifiers, where Perl,PERL,perl mean the same thing. Rather : what I want is to be everything-sensitive, as AFAIK Perl 6 currently : is; if something looks different, it is different. -- Darren Duncan Well, Perl 6 won't be everything-sensitive, since by default it does string comparisons under some kind of Unicodian Normalization. But I'm inclined to keep - and _ as unique characters, and just let the culture evolve over time; I think the end result will be to require (by convention) official APIs to use hyphens for all normal interfaces; underscores anywhere in a name will come to mean this is private, use at your own risk regardless of where underscores are used, much like current meaning of leading underscores. But I don't think it should be anything tighter than a convention, or we make language interoperability more difficult (particularly with Perl 5). As for the horror of people having to memorize lists again or Risk Using The Wrong Character...I'm afraid I just don't buy it. The standard parser will likely be pointing out spelling errors and conjecturing emendations for near misses. Whole-program analysis can even do this for any method names that look wrongish. The difference between Acme-X and Acme_X is no worse than the difference between Damian and Damien, at least in Levenshtein distance. Larry
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, Apr 12, 2010 at 2:23 PM, Larry Wall la...@wall.org wrote: On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote: : : I see that making underscores : and hyphens to be equivalent is akin to having case-insensitive : identifiers, where Perl,PERL,perl mean the same thing. Rather : what I want is to be everything-sensitive, as AFAIK Perl 6 currently : is; if something looks different, it is different. -- Darren Duncan ... As for the horror of people having to memorize lists again or Risk Using The Wrong Character...I'm afraid I just don't buy it. Larry, I'm curious what you think of this example: A web page of Perl 6 documentation suggests that you should call time-local. Unfortunately, in the font that my browser uses, the height of that single stroke is ambiguous. Of course, we could have no sympathy and just say, get a better font, but this problem will likely creep up over and over, would it not? I agree with you that this doesn't really help the person writing code from scratch, but that's not the same as a developer who is trying to interact with potentially dozens of libraries with various sources of documentation from comments to Web pages. I'd suggest the following in decreasing order of urgency: - Choose a single character (hyphen or underscore) to use in standard library code to separate the component words of an identifier (remember that underscore is only special in C-like code because it's standing in for space). - Never use dash versus underscore notationally (e.g. a-b indicates that the identifier is to be used one way vs a_b indicates otherwise) - Allow only one such character in any given identifier That last item rolls into a whole rant of mine against ambiguity in identifiers. Most often this stems from Unicode that puts the programmer in the position of having to have good enough font support to tell ambiguous names apart (and in cases like Αpple or Рerl or Ρerl, you're just doomed regardless), but dashes and underscores are a good example of the same problem cropping up elsewhere. On the more general point, I really feel that no language should ever allow identifiers to mix Unicode blocks without strong reason. Specifically: - Underscore (or dash or whatever your notational separator is) should be the only exceptional character allowed in all identifiers - Identifiers should never include c̈ombining m̅arks - Upon scanning the first alpha character in an identifier, no further alpha characters should be allowed except as they come from the same code block or related supplemental block (related might be expanded to include first-class blocks in some cases to allow for combinations like Kanji (Chinese in Unicode) + Hirigana, etc.) - Upon scanning the first numeric character in an identifier, no further numeric characters should be allowed except as they come from the same code block (again, there might be some wiggle in some exceptional cases, but the goal is to avoid counting in more than one system at a time). Should all of these be hard errors? Perhaps not, but certainly they should at least yield warnings by default. PS: While I never finished the implementation of Sand, its simplistic guide to Unicode identifiers might be useful in illuminating what I'm describing above: http://www.ajs.com/ajswiki/Sand:_Syntax_and_Structure#Identifiers -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Mon, 2010-04-12 at 11:23 -0700, Larry Wall wrote: The standard parser will likely be pointing out spelling errors and conjecturing emendations for near misses. Whole-program analysis can even do this for any method names that look wrongish. The difference between Acme-X and Acme_X is no worse than the difference between Damian and Damien, at least in Levenshtein distance. Ah yes, I forgot about this feature. Consider my argument for choosing only one separator throughout the standard setting Way Less Adamant -- though I still think it's a good idea. -'f
RE: underscores vs hyphens (was Re: A new era for Temporal)
From: Mark J. Reed [mailto:markjr...@gmail.com]
[...]
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).
Consider s/English/Linux/ for example. :-)
One consideration leading up to allowing - in P6 identifiers (initially in
the context of an optional syntax-tweaking module) involved compatibility with
fairly common usage in {directory and file} names (where spaces are avoided for
cross-platform reasons). I've always thought {Lisp variable names and
Unix/Linux file names} with hyphens (versus underscores) were {more readable
and substantially easier to type (during long typing sessions)}.
http://groups.google.com/group/perl.perl6.language/browse_thread/thread/1625baa7eead0d71/
http://groups.google.com/group/perl.perl6.compiler/browse_thread/thread/e6cc5dc9360ada36/c59f2fb1f49b80f5?lnk=gstq=r28689#c59f2fb1f49b80f5
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.
[...]
++!
Best regards,
Conrad
Conrad Schneiker
www.AthenaLab.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 4:47 AM, Damian Conway dam...@conway.org 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. If anything, it's a sad reflection on humanity. I don't see any special reason that our profession should be an exception to Sturgeon's law. And, IMHO, conventions should be such that every Joe-Coder should to be able to understand and use them, which means they should be as simple as possible. This thread itself proves that the choice of places where hyphen and underscore should be used under this scheme *feels* ambiguous, even if it strictly isn't so. I believe it would be best to have a rule for hyphen-or-underscore that can be mechanically applied. This would enable a perl6critic tool to check its proper usage, and more importantly, make the choice easy for Joe-Coder since he does not like to think much about function names. With such conventions, it is important to cater to mere mortals, since their code would form the bulk, which means a misunderstanding on their part would make their 'convention' the popular one, which is probably not a good thing. We might end up with PHP-ish nightmare of mixed conventions in function naming. I might go so far as to say that we could drop underscores altogether, and embrace the Lispy way of using hyphens everywhere. Easier to type, looks good, and simple to apply. My 2c, Sundar -- ! Knowing others is intelligence; knowing yourself is true wisdom. Mastering others is strength; mastering yourself is true power. ! If you realize that you have enough, you are truly rich.
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:14 AM, Mark J. Reed markjr...@gmail.com wrote: 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. As another data point ... me too. I'd prefer to see hyphens than underscores. -Scott 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 cma...@gmail.com 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 Cday_of_week. 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 markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
Well, if we're not going to try to implement linguistically based
hyphenation/underscoriation rules (and I'd still argue that hyphenating
adjectives to nouns and underscoring everything else isn't exactly
rocket science), then I'd suggest we reconsider a radically different
proposal that was made on this list five years ago:
http://www.mail-archive.com/perl6-language@perl.org/msg22675.html
The relevant suggestion regarding hyphens vs underscores is:
...to allow both characters, but have them mean the same thing.
That is, any isolated internal underscore can be replaced with an
isolated internal hyphen (and vice versa), without changing the meaning
of the identifier.
This would be the death of fine distinctions such as between:
activate_main-sequence_detonator();
and:
activate_main_sequence-detonator();
which would now resolve to the same subroutine...and do so even if
that subroutine had been declared as
sub activate-main-sequence-detonator {...}
But perhaps such distinctions are indeed too fine and subtle, and we
would be better off eliminating the possibility of them entirely.
Hyphen/underscore equivalence would allow those (apparently elite few) who
can correctly use a hyphen to correctly use the hyphen, whilst the
shambling masses can just randomly type underscores or hyphens between
each word, as their atavistic whims dictate.
;-)
Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, 2010-04-10 at 17:20 -0700, yary wrote: 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. And there's the rub for me. One of the goals of Perl 6 is to reduce the amount of rote memorization of special cases that Perl 5 required. Any mixed use of _ and - in the standard setting defies that goal. (FWIW, I don't really care which is used -- I see arguments for both -- but I do firmly believe the standard setting should only use one or the other. Damian's Temporal example in which only one method used a different separator made the rules-versus-exceptions part of my brain scream for mercy.) -'f
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases where even the elite rocket surgeons in their ivory control towers can't agree on which is correct. It's less too subtle for JAPH and more too subtle for consensus even among the cognoscenti.. The edge cases would be back to rote memorization. On Sunday, April 11, 2010, John Siracusa sirac...@gmail.com wrote: On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
I can't help but agree with Damian. I don't see much of a point in making a distinction between - and _. More specifically, if a user were to define a function (say, i-hate-camel-case()), it would not be good to let them be the same. Readability would suffer when examining someone's code and you see i_hate_camel_case() and you can't find that function (in my example there are 8 different possibilities for what the actual function was defined as!) However, in core functionality, such a distinction should be made /if it makes sense/. For example, allowing 3 _ 4 in place of 3 - 4 would not make sense, while obscure commands (the PIR functions in rakudo, for example), would do better to not be so stringent (or at least tell you what you did wrong). This is my best guess based on what I know. I don't know the whole story, and I'm always ready to be convinced otherwise. -- Don't Panic!
Re: underscores vs hyphens (was Re: A new era for Temporal)
Egad, no to the equivalence. We'd be back in case-insensitive-language land, only without the benefit of even that dubious tradition. And at least for me, the beef with mixing hyphens and underscores is not that the great unwashed masses can't handle it, but that there will inevitably be cases where even the elite rocket surgeons in their ivory control towers can't agree on which is correct. It's less too subtle for JAPH and more too subtle for consensus even among the cognoscenti.. The edge cases would be back to rote memorization. On Sunday, April 11, 2010, John Siracusa sirac...@gmail.com wrote: On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John -- Mark J. Reed markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: Well, if we're not going to try to implement linguistically based hyphenation/underscoriation rules (and I'd still argue that hyphenating adjectives to nouns and underscoring everything else isn't exactly rocket science), then I'd suggest we reconsider a radically different proposal that was made on this list five years ago: http://www.mail-archive.com/perl6-language@perl.org/msg22675.html The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. I was about to say that if hyphens and underscores mean the same thing, then why are Perl 6's identifiers case sensitive? But, you know what, I haven't found any documentation stating they are. Could someone please give me the URI in the official documentation where this is stated. Thanks. -- 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: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. That is, any isolated internal underscore can be replaced with an isolated internal hyphen (and vice versa), without changing the meaning of the identifier. I am formally opposed to this idea. I see that making underscores and hyphens to be equivalent is akin to having case-insensitive identifiers, where Perl,PERL,perl mean the same thing. Rather what I want is to be everything-sensitive, as AFAIK Perl 6 currently is; if something looks different, it is different. -- Darren Duncan
Re: underscores vs hyphens (was Re: A new era for Temporal)
Em Dom, 2010-04-11 às 07:54 -0700, Damian Conway escreveu: The relevant suggestion regarding hyphens vs underscores is: ...to allow both characters, but have them mean the same thing. er... this smells like :: and ' in Perl 5... Which, while I find Acme::Don't amusing, cannot be stated as sane design... daniel
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: underscores vs hyphens (was Re: A new era for Temporal)
${A-1} = 3.14159;
$A = $A-1;
$A = $A -1;
$A-=2;
$A = 123E-2;
$A = Pi();
$B = sin ($A-1);
$B = sin (${A}-1);
$B = sin($A -1);
-2**2 = -4 except when it comes out +4 as in MS Excel.
_2**2 = +4 in some other languages that use _ as a unary minus operator.
Will editors be bothered when I try to include - in the list of characters
that are considered words when double clicking? When doing a find and replace
all as words?
Is the unicode equivalent of nbsp; allowed in a variable name?
--
-- Give me liberty or give me Obamacare --
Re: underscores vs hyphens (was Re: A new era for Temporal)
Doug McNutt wrote:
${A-1} = 3.14159;
$A = $A-1;
$A = $A -1;
$A-=2;
$A = 123E-2;
$A = Pi();
$B = sin ($A-1);
$B = sin (${A}-1);
$B = sin($A -1);
-2**2 = -4 except when it comes out +4 as in MS Excel.
_2**2 = +4 in some other languages that use _ as a unary minus operator.
Will editors be bothered when I try to include - in the list of characters
that are considered words when double clicking? When doing a find and replace all as
words?
Is the unicode equivalent of nbsp; allowed in a variable name?
See http://perlcabal.org/syn/S02.html#Names for your answers.
Essentially, I believe that any character at all is allowed in a variable name.
Its just that for most characters, when you use them the variable name has to
be quoted. The common unquoted identifier syntax is much more limited, and is
mainly what was being discussed here.
-- Darren Duncan
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 Cday_of_week. 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
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 cma...@gmail.com 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 Cday_of_week. 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 markjr...@gmail.com
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed markjr...@gmail.com 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
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)
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 Cday method also has the synonym Cday-of-month. (These are also available through the methods Cweek-year and Cweek-number, respectively.) There's a Cday-of-week method, The Cweekday-of-month method returns a number 1..5 The Cday-of-quarter method returns the day of the quarter. The Cday-of-year method returns the day of the year, The method Cwhole-second returns the second truncated to an integer. The Ctime-zone method returns the CDateTime::TimeZone 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 Ctimezone throughout). Damian
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway dam...@conway.org 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)
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 dam...@conway.org 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 Cday method also has the synonym Cday-of-month. (These are also available through the methods Cweek-year and Cweek-number, respectively.) There's a Cday-of-week method, The Cweekday-of-month method returns a number 1..5 The Cday-of-quarter method returns the day of the quarter. The Cday-of-year method returns the day of the year, The method Cwhole-second returns the second truncated to an integer. The Ctime-zone method returns the CDateTime::TimeZone 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 Ctimezone throughout). Damian -- Mark J. Reed markjr...@gmail.com
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)
On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway dam...@conway.org 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)
On Sat, Apr 10, 2010 at 4:53 PM, John Siracusa sirac...@gmail.com 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)
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 8:23 PM, Daniel Ruoso dan...@ruoso.com 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)
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 sirac...@gmail.com wrote: On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso dan...@ruoso.com 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 markjr...@gmail.com
underscores vs hyphens (was Re: A new era for Temporal)
John Siracusa wrote: 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)? There are 2 answers to that question: 1. Unlike with Perl 5, Perl 6 supports the use of hyphens in bareword identifiers, except as the first character. In principle, I think this is very welcome, as hyphens are just as reasonable for separating words as underscores, and several other languages support this, and in XML at least it is standard practice. For that matter, Perl 6 also supports single-quotes in bareword identifiers, so you can have routines like isn't() or can't(); I don't like that so much as I prefer not to have characters used for quoted string delimiters in the middle of a bareword string, but I can understand why it was done. And so, if the language supports it and it is reasonable, why not use it? 2. I do think that any particular module should be internally consistent in its naming scheme, so Temporal should use all-underscores or all-hyphens, but not mix and match, unless there is a conceptual distinction between things named with the different styles that are worth highlighting by using different styles; barring that, such an inconsistency in Temporal may be something that should be fixed. -- Darren Duncan P.S. My Muldis D language also has the feature of Perl 6 about supporting both underscore and hyphen separated bareword identifiers, though I don't support the single quotes. While users are free to use what style they want, for all the built-in stuff I have adopted the following convention: For all normal identifiers like the names of system-defined routines or variables or parameters or attributes etc, I use underscore separation. (Type names are typically camel-case like in Perl.) For language keywords or special operator syntaxes in the concrete language grammars, I use hyphen separators when said keywords have multiple words, rather than either underscores or whitespace. I find that this distinction is very effective at making different things look different, and for the keywords or special syntaxes, hyphens actually look better than either underscores or spaces.
