RE: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
-Original Message-
From: Smylers [mailto:smyl...@stripey.com]
Sent: Wednesday, August 24, 2011 2:20 AM
To: perl6-language@perl.org
Subject: Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32]
backtraces
overhaul)
Moritz Lenz writes:
Am 23.08.2011 10:46, schrieb Damian Conway:
... why hidden_from_backtrace instead of hidden-from-backtrace?
... low-level things are spelled with underscores, while we reserve
the minus character for user-space code.
So the idea is that if Perl 6 has an identifier zapeth_clunk itself that
leaves zapeth-clunk free to be used by developers to mean something
else?
Is that something we want to enable?
Code with identifiers that differ only in word separators sounds like it
would be most confusing to maintain. Are there specific circumstances in
which it would be useful?
[snip]
This feature came about (along with Larry's generalization to include 's)
in response to a question I posed back around 2008 (IIRC) about the
feasibility of a P6 module to allow hyphens in identifiers.
(BTW, I frequently mix hyphens with underscores to make space-free file
names with hyphenated dates, hyphenated words, and so on. But I wouldn't
want hyphens and underscores treated as equivalent, just as I wouldn't want
upper and lowercase letters treated as equivalent. Then again, use strict;
is my friend, so I don't anticipate non-trivial problems with such sorts
non-equivalences. YMMV.)
Here is a reply of mine to an old thread on this topic; others have
independently expressed somewhat similar sentiments.
===
[Sun 4/11/2010 12:45 AM]
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/1625
baa7eead0d71/
http://groups.google.com/group/perl.perl6.compiler/browse_thread/thread/e6cc
5dc9360ada36/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: [perl6/specs] a7cfe0: [S32] backtraces overhaul
S19 uses hyphens for all of perl6's long-form command-line flags. Command-line flags and methods are separate sets. Hyphens would be the norm for flags. In S28, we find $*EXECUTABLE_NAME and %*META-ARGS listed within 10 lines of each other. S32-setting-library_IO.pod and S32-setting-library_Numeric.pod each have public multi-word method names with hyphens. In both cases, hyphens are linking qualifying adjectives to nouns, while hyphens separate distinct words. One could argue that is not inconsistent. On 8/23/11, Patrick R. Michaud pmich...@pobox.com wrote: On Tue, Aug 23, 2011 at 05:36:27PM +0200, Damian Conway wrote: And I'd like there to be a more consistent approach than that (though I don't really care what it actually is). +1 to consistency. Pm
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
Moritz Lenz writes: Am 23.08.2011 10:46, schrieb Damian Conway: ... why hidden_from_backtrace instead of hidden-from-backtrace? ... low-level things are spelled with underscores, while we reserve the minus character for user-space code. So the idea is that if Perl 6 has an identifier zapeth_clunk itself that leaves zapeth-clunk free to be used by developers to mean something else? Is that something we want to enable? Code with identifiers that differ only in word separators sounds like it would be most confusing to maintain. Are there specific circumstances in which it would be useful? Patrick R. Michaud writes: On Tue, Aug 23, 2011 at 05:36:27PM +0200, Damian Conway wrote: I'd like there to be a more consistent approach than that +1 to consistency. Could we have underscores and hyphens mean the same thing? That is, Perl 6 always interprets illo-figut and illo_figut as being the same identifier (both for its own identifiers and those minted in programs), with programmers able to use either separator on a whim? That would seem to be the most human-friendly approach. Smylers -- http://twitter.com/Smylers2
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
On Wed, Aug 24, 2011 at 11:19, Smylers smyl...@stripey.com wrote: Could we have underscores and hyphens mean the same thing? That is, Perl 6 always interprets illo-figut and illo_figut as being the same identifier (both for its own identifiers and those minted in programs), with programmers able to use either separator on a whim? That would seem to be the most human-friendly approach. I'm not so sure about the human-friendliness, but it certainly would be more obfuscation-friendly and less editor- and search-friendly. -- Jan
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
Damian (), Moritz (), Smylers (): ... why hidden_from_backtrace instead of hidden-from-backtrace? ... low-level things are spelled with underscores, while we reserve the minus character for user-space code. So the idea is that if Perl 6 has an identifier zapeth_clunk itself that leaves zapeth-clunk free to be used by developers to mean something else? Not much of a problem in Perl 6 in the first place; built-ins from the setting are considered to be lexical declarations from a block outside of the mainline program code, and any declarations made by the developer will just shadow these. No, my understanding is that the naming convention is there to separate stuff API stuff from internals stuff: dashes this is part of the Perl 6 API -- feel free to call it underscores this is an internal function -- unless you're doing something internal yourself, you shouldn't call it To me, it has a nice visual mnemonic, since underscores themselves are more low-level. Of course, it remains to be seen whether this convention is (a) useful, (b) correctly guessing the boundaries between API and low-level, or even (c) consistently applied within the spec. Damian (), Patrick (), Smylers (): I'd like there to be a more consistent approach than that +1 to consistency. Could we have underscores and hyphens mean the same thing? That is, Perl 6 always interprets illo-figut and illo_figut as being the same identifier (both for its own identifiers and those minted in programs), with programmers able to use either separator on a whim? That would seem to be the most human-friendly approach. Maybe, but in my humble opinion that wouldn't promote consistency in user code. Also, the name mangling needed to do this would waterbed up *somewhere* and likely cause new, interesting kinds of pain. // Carl
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
Am 24.08.2011 11:33, schrieb Carl Mäsak: Damian (), Moritz (), Smylers (): ... why hidden_from_backtrace instead of hidden-from-backtrace? ... low-level things are spelled with underscores, while we reserve the minus character for user-space code. So the idea is that if Perl 6 has an identifier zapeth_clunk itself that leaves zapeth-clunk free to be used by developers to mean something else? Not much of a problem in Perl 6 in the first place; built-ins from the setting are considered to be lexical declarations from a block outside of the mainline program code, and any declarations made by the developer will just shadow these. No, my understanding is that the naming convention is there to separate stuff API stuff from internals stuff: dashes this is part of the Perl 6 API -- feel free to call it underscores this is an internal function -- unless you're doing something internal yourself, you shouldn't call it To me, it has a nice visual mnemonic, since underscores themselves are more low-level. That's how I understood it too, but wasn't able to phrase it so nicely. Of course, it remains to be seen whether this convention is (a) useful, (b) correctly guessing the boundaries between API and low-level, or even (c) consistently applied within the spec. (c) is false, I'm quite sure. I'm all for cleaning it up, once we agree on a naming scheme Damian (), Patrick (), Smylers (): I'd like there to be a more consistent approach than that +1 to consistency. Could we have underscores and hyphens mean the same thing? That is, Perl 6 always interprets illo-figut and illo_figut as being the same identifier (both for its own identifiers and those minted in programs), with programmers able to use either separator on a whim? That would seem to be the most human-friendly approach. It's not machine friendly. It means you can't easily dispatch methods by looking them up in hash, you first have to name-mangle. And consider how often you call methods in Perl 6 (like, all the time), that wouldn't be nice at all. Maybe, but in my humble opinion that wouldn't promote consistency in user code. Also, the name mangling needed to do this would waterbed up *somewhere* and likely cause new, interesting kinds of pain. Like interoperation with other languages. What if you call methods from a language that doesn't have this name mangling rule (like, all of them)? Suddenly you must be careful where you didn't have to be careful before. So a best practice would evolve that you always be careful in the first place, and the whole idea is being frowned upon. Let's take a shortcut, frown upon the idea right now, and don't spec it :-) Cheers, Moritz
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
That kind of consistency is not much better than inconsistency in terms of usability, IMO. I'd much prefer a purely lexical convention that doesn't rely on how you assign parts of speech or define a single word that has a hyphen in it. Given that we allow hyphens in identifiers, I'd personally like to see them used everywhere, for all identifiers defined at the p6 level. Lower-level names that are just called from p6 are of course another matter. I could also see substituting underscores for hypens in all-caps names for ease of typing (at least, that'd be easier on US keyboards). On Tuesday, August 23, 2011, Parrot Raiser 1parr...@gmail.com wrote: S19 uses hyphens for all of perl6's long-form command-line flags. Command-line flags and methods are separate sets. Hyphens would be the norm for flags. In S28, we find $*EXECUTABLE_NAME and %*META-ARGS listed within 10 lines of each other. S32-setting-library_IO.pod and S32-setting-library_Numeric.pod each have public multi-word method names with hyphens. In both cases, hyphens are linking qualifying adjectives to nouns, while hyphens separate distinct words. One could argue that is not inconsistent. On 8/23/11, Patrick R. Michaud pmich...@pobox.com wrote: On Tue, Aug 23, 2011 at 05:36:27PM +0200, Damian Conway wrote: And I'd like there to be a more consistent approach than that (though I don't really care what it actually is). +1 to consistency. Pm -- Mark J. Reed markjr...@gmail.com
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
Smylers wrote: Could we have underscores and hyphens mean the same thing? That is, Perl 6 always interprets illo-figut and illo_figut as being the same identifier (both for its own identifiers and those minted in programs), with programmers able to use either separator on a whim? I oppose this. Underscores and hyphens should remain distinct. That would seem to be the most human-friendly approach. I disagree. More human friendly is if it looks different in any way then it is different. (I am not also saying that same-looking things are equal, given Unicode's redundancy.) If you're going to treat hyphens and underscores in identifiers as being equal then you should make them case-insensitive too, because its the same kind of lack of distinction. I think that a better change, if we're going to change something, is to make hyphens illegal in bareword identifiers, just allowing them in quoted ones. Then we also gain consistency that if something looks symbolic then its an operator, not a question of whether we have a minus operator or not. If one points to XML as an example of working hyphens in bareword identifiers, I should point out that those are typically in a -quoted context, and we also don't see symbolic bareword operators in the same place. Apples and oranges. -- Darren Duncan
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
Darren Duncan dar...@darrenduncan.net wrote on Wed, 24 Aug 2011 11:18:20 PDT:
Smylers wrote:
Could we have underscores and hyphens mean the same thing? That is, Perl
6 always interprets illo-figut and illo_figut as being the same
identifier (both for its own identifiers and those minted in programs),
with programmers able to use either separator on a whim?
I oppose this. Underscores and hyphens should remain distinct.
That would seem to be the most human-friendly approach.
I disagree. More human friendly is if it looks different in any way then it
is
different. (I am not also saying that same-looking things are equal, given
Unicode's redundancy.)
Your mentioning of Unicode is poignant. In Unicode properties, you are not
supposed to have to worry about these things.For example, from UTS#18:
Note: Because it is recommended that the property syntax be lenient
as to spaces, casing, hyphens and underbars, any of the
following should be equivalent: \p{Lu}, \p{lu}, \p{uppercase
letter}, \p{uppercase letter}, \p{Uppercase_Letter}, and
\p{uppercaseletter}
Simillarly, since this applies to property names as well as to property
values, these are all the same:
\p{GC =Lu}
\p{gc =Lu}
\p{General Category=Lu}
\p{General_Category=Lu}
\p{general_category=Lu}
\p{general-category=Lu}
\p{GENERAL-CATEGORY=Lu}
\p{generalcategory =Lu}
\p{GENERALCATEGORY =Lu}
I'll let you permute the RHS on your own. :)
However, I use the opposite of that sort of loose matching of identifiers
in my own code. For example, when I make a named character alias, I always
use lowercase so that it looks different from an official one.
use charnames :full, :alias = {
e_acute = LATIN SMALL LETTER E WITH ACUTE,
ae = LATIN SMALL LETTER AE,
smcap_ae= LATIN LETTER SMALL CAPITAL AE, # this is a lowercase
letter
AE = LATIN CAPTIAL LETTER AE,
oe = LATIN SMALL LIGATURE OE,
smcap_oe= LATIN LETTER SMALL CAPITAL OE, # this is a lowercase
letter
OE = LATIN CAPITAL LIGATURE OE,
};
I don't make E_ACUTE and eacute also work there. However, there is a
new :loose that does do that, but I suspect I shan't use it, since I use
both ae and AE differently in existing code.
--tom
Re: Underscores v Hyphens (Was: [perl6/specs] a7cfe0: [S32] backtraces overhaul)
Tom Christiansen wrote:
Darren Duncan dar...@darrenduncan.net wrote on Wed, 24 Aug 2011 11:18:20 PDT:
I oppose this. Underscores and hyphens should remain distinct.
That would seem to be the most human-friendly approach.
I disagree. More human friendly is if it looks different in any way then it is
different. (I am not also saying that same-looking things are equal, given
Unicode's redundancy.)
Your mentioning of Unicode is poignant. In Unicode properties, you are not
supposed to have to worry about these things.For example, from UTS#18:
Note: Because it is recommended that the property syntax be lenient
as to spaces, casing, hyphens and underbars, any of the
following should be equivalent: \p{Lu}, \p{lu}, \p{uppercase
letter}, \p{uppercase letter}, \p{Uppercase_Letter}, and
\p{uppercaseletter}
snip
Sure, but Unicode character names are a distinct issue from Perl identifiers.
Apples and oranges.
For dashes and underscores etc, the fact that they both exist distinctly in
Unicode and that people consider have circumstances to use one over the other,
means they are considered distinct, and we need to preserve that treating as
distinct.
-- Darren Duncan
[perl6/specs] a7cfe0: [S32] backtraces overhaul
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: a7cfe02002f665c120cf4b735919779820194757 https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 Author: Moritz Lenz mor...@faui2k3.org Date: 2011-08-23 (Tue, 23 Aug 2011) Changed paths: M S32-setting-library/Exception.pod Log Message: --- [S32] backtraces overhaul spec hidden_from_backtrace trait, be more verbose on backtrace stringification, and introduce separate BackTraceLine class
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
It's a trivial point, but why hidden_from_backtrace instead of hidden-from-backtrace? Especially given that the associated method is is-hidden, not is_hidden? Are we consistently using underscores for multi_word traits and hyphens for multi-word methods? Wouldn't it be nice to have a consistent and teachable rule? And why is this entire message written in questions? Have I simply been watching too many Whose Line Is It Anyway? episodes? Damian?
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
Am 23.08.2011 10:46, schrieb Damian Conway: It's a trivial point, but why hidden_from_backtrace instead of hidden-from-backtrace? Especially given that the associated method is is-hidden, not is_hidden? The current stance seems to be that low-level things are spelled with underscores, while we reserve the minus character for user-space code. Try grepping the specs for identifiers of built-ins that have a minus in it -- I didn't find any in a quick search. And why is this entire message written in questions? Is it? I'm afraid I don't understand what you mean. See https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 maybe it's a charset problem on your machine, or something. Cheers, Moritz
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
Am 23.08.2011 10:56, schrieb Moritz Lenz: And why is this entire message written in questions? Is it? I'm afraid I don't understand what you mean. Never mind?
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
Help us always-explains-the-joke-man!!... :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Moritz Lenz [mailto:mor...@faui2k3.org] Sent: Tuesday, August 23, 2011 04:56 AM To: perl6-language@perl.org perl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul Am 23.08.2011 10:46, schrieb Damian Conway: It's a trivial point, but why hidden_from_backtrace instead of hidden-from-backtrace? Especially given that the associated method is is-hidden, not is_hidden? The current stance seems to be that low-level things are spelled with underscores, while we reserve the minus character for user-space code. Try grepping the specs for identifiers of built-ins that have a minus in it -- I didn't find any in a quick search. And why is this entire message written in questions? Is it? I'm afraid I don't understand what you mean. See https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 maybe it's a charset problem on your machine, or something. Cheers, Moritz
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
If you're asking for an explanation of the humour, then it's easy. There is no word play or a significant reference to a program only available to a special audience. Seems to me that when Damian got to the end of his email he noticed that each sentence ended in a '?' That's not usual. Most emails contain assertions and questions. The humour is really when he appended a ? to his own name. Was he really questioning what he was called? Richard On 08/23/2011 02:19 PM, philippe.beauch...@bell.ca wrote: Help us always-explains-the-joke-man!!... :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Moritz Lenz [mailto:mor...@faui2k3.org] Sent: Tuesday, August 23, 2011 04:56 AM To: perl6-language@perl.orgperl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul Am 23.08.2011 10:46, schrieb Damian Conway: It's a trivial point, but why hidden_from_backtrace instead of hidden-from-backtrace? Especially given that the associated method is is-hidden, not is_hidden? The current stance seems to be that low-level things are spelled with underscores, while we reserve the minus character for user-space code. Try grepping the specs for identifiers of built-ins that have a minus in it -- I didn't find any in a quick search. And why is this entire message written in questions? Is it? I'm afraid I don't understand what you mean. See https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 maybe it's a charset problem on your machine, or something. Cheers, Moritz
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
Whoosh No... LOL I was making reference to another Whose Line game, (as Damian was with the all questions thing)... And the hyphen thing. :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Richard Hainsworth [mailto:rich...@rusrating.ru] Sent: Tuesday, August 23, 2011 06:28 AM To: perl6-language@perl.org perl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul If you're asking for an explanation of the humour, then it's easy. There is no word play or a significant reference to a program only available to a special audience. Seems to me that when Damian got to the end of his email he noticed that each sentence ended in a '?' That's not usual. Most emails contain assertions and questions. The humour is really when he appended a ? to his own name. Was he really questioning what he was called? Richard On 08/23/2011 02:19 PM, philippe.beauch...@bell.ca wrote: Help us always-explains-the-joke-man!!... :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Moritz Lenz [mailto:mor...@faui2k3.org] Sent: Tuesday, August 23, 2011 04:56 AM To: perl6-language@perl.orgperl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul Am 23.08.2011 10:46, schrieb Damian Conway: It's a trivial point, but why hidden_from_backtrace instead of hidden-from-backtrace? Especially given that the associated method is is-hidden, not is_hidden? The current stance seems to be that low-level things are spelled with underscores, while we reserve the minus character for user-space code. Try grepping the specs for identifiers of built-ins that have a minus in it -- I didn't find any in a quick search. And why is this entire message written in questions? Is it? I'm afraid I don't understand what you mean. See https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 maybe it's a charset problem on your machine, or something. Cheers, Moritz
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
I always think of the questions game in Rosencrantz and Guildenstern (Lenzmoritz and Damienstern?) instead of Whose Line?. 15-love, Conway! On Tuesday, August 23, 2011, philippe.beauch...@bell.ca philippe.beauch...@bell.ca wrote: Whoosh No... LOL I was making reference to another Whose Line game, (as Damian was with the all questions thing)... And the hyphen thing. :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Richard Hainsworth [mailto:rich...@rusrating.ru] Sent: Tuesday, August 23, 2011 06:28 AM To: perl6-language@perl.org perl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul If you're asking for an explanation of the humour, then it's easy. There is no word play or a significant reference to a program only available to a special audience. Seems to me that when Damian got to the end of his email he noticed that each sentence ended in a '?' That's not usual. Most emails contain assertions and questions. The humour is really when he appended a ? to his own name. Was he really questioning what he was called? Richard On 08/23/2011 02:19 PM, philippe.beauch...@bell.ca wrote: Help us always-explains-the-joke-man!!... :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Moritz Lenz [mailto:mor...@faui2k3.org] Sent: Tuesday, August 23, 2011 04:56 AM To: perl6-language@perl.orgperl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul Am 23.08.2011 10:46, schrieb Damian Conway: It's a trivial point, but why hidden_from_backtrace instead of hidden-from-backtrace? Especially given that the associated method is is-hidden, not is_hidden? The current stance seems to be that low-level things are spelled with underscores, while we reserve the minus character for user-space code. Try grepping the specs for identifiers of built-ins that have a minus in it -- I didn't find any in a quick search. And why is this entire message written in questions? Is it? I'm afraid I don't understand what you mean. See https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 maybe it's a charset problem on your machine, or something. Cheers, Moritz -- Mark J. Reed markjr...@gmail.com
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
The current stance seems to be that low-level things are spelled with underscores, while we reserve the minus character for user-space code. Try grepping the specs for identifiers of built-ins that have a minus in it -- I didn't find any in a quick search. I had a little more time to look and found... S12 describes Attribute objects as having a method named 'has-accessor', but also having a method named 'get_value'. S19 uses hyphens for all of perl6's long-form command-line flags. In S28, we find $*EXECUTABLE_NAME and %*META-ARGS listed within 10 lines of each other. S32-setting-library_IO.pod and S32-setting-library_Numeric.pod each have public multi-word method names with hyphens. And both also list other identifiers that use underscores. I'm not sure I'm seeing the pattern, though. Apart perhaps from older parts of the spec use underscores, newer parts use hyphens. And I'd like there to be a more consistent approach than that (though I don't really care what it actually is). Damian
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
On Tue, Aug 23, 2011 at 05:36:27PM +0200, Damian Conway wrote: And I'd like there to be a more consistent approach than that (though I don't really care what it actually is). +1 to consistency. Pm
