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: 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: 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
