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
