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 n
On Mon, Apr 12, 2010 at 2:23 PM, Larry Wall 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
>
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
On Mon, Apr 12, 2010 at 1:22 PM, Shawn H Corey 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
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
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 a
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
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 sp
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 bothere
${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 inclu
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/_/-
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 a
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 th
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
p
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 wh
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 y
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 wh
On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway 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
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
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 o
On Sat, Apr 10, 2010 at 5:14 AM, Mark J. Reed 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
On Sun, Apr 11, 2010 at 4:47 AM, Damian Conway wrote:
> And is it really so hard to teach: "use underscore by default and reserve
> hyphens for between a noun and its adjective"? Perhaps it *is*, but
> then that's a very sad reflection on our profession.
>
If anything, it's a sad reflection on h
> 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
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 sa
On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso wrote:
> Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu:
>> I'm having trouble imaging any convention that involves mixing word
>> separators being successful.
>
> But the convention Damian is proposing is simply "use underscores".
>
> Basic
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
c
On Sat, Apr 10, 2010 at 4:53 PM, John Siracusa wrote:
> I'm not sure if the intersection of people who speak English and
> people who program is better or worse than average when it comes to
> grammar, but I do know (from editing my share of writing) that the
> average is very bad and, further, th
On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway wrote:
> And is it really so hard to teach: "use underscore by default and reserve
> hyphens for between a noun and its adjective"? Perhaps it *is*, but
> then that's a very sad reflection on our profession.
I'm not sure if the intersection of people
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
Bu
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
On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway wrote:
> Personally, I'd prefer to see the English conventions carried over to
> the use of general use of hyphen and underscore in identifiers in
> the core (and everywhere else).
That's certainly an example of how hyphens might gain meaning in Perl
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-
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
On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed wrote:
> I'd much rather see a single consistent style throughout
Yeah, that's was my main point/question. I wanted to know if it was
it some intentional convention (e.g., "all methods that change the
object state use hyphens, and all others use unde
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
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 t
36 matches
Mail list logo