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/_/-
On Fri, 9 Apr 2010, Darren Duncan wrote:
conceptual and a usability and a math point of view. If users only want the
integer value, then they can just store the second as an integer in the first
place. As for the name, well "whole_second" can be made shorter, or its
Users will not always co
On Sun, 11 Apr 2010, Moritz Lenz wrote:
I've planned to add such a module to the Perl 6 spec, but some comments
on #perl6 suggested it should be kept out of core to prevent bloat.
Still if the overall opinion is that Perl 6 should have such a module
out of the box, I'll be happy to spec it.
I
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
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #74286]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=74286 >
rakudo: class A { method foo {} }; say A.can("foo").WHAT
rakudo ae2e81: OUTPUT«Method
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
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #74236]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=74236 >
rakudo: class A {}; my $x = &A::nosuch
rakudo 43f865: OUTPUT«Null PMC access in can()
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
Dave Rolsky wrote:
> On Thu, 8 Apr 2010, Carl Mäsak wrote:
>
>> I do want to explicitly credit Dave Rolsky, whose work on the DateTime
>> family of modules on CPAN has informed much of the current spec,
>> sometimes to the point of verbatim copying.
>
> Thanks, but I'd hate to see you copy all my
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
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #74274]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=74274 >
rakudo: class A { has $!a }; my $a = A.new(a => 42); my $method
= method { return $!a }
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
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #74282]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=74282 >
The rx{ } quoting construct seems to be not yet implemented in master:
12:53 <@moritz_>
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #74276]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=74276 >
11:57 < sundar> It seems quit is recognized as something special, given it
# New Ticket Created by Peter Lobsinger
# Please include the string: [perl #74272]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=74272 >
Hi,
Attached is a patch correcting the problem described below.
Parrot has a symbol
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
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #74234]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=74234 >
rakudo: subset A of Mu; my A $x
rakudo 43f865: OUTPUT«Nominal type check failed for pa
> Log:
> [Numeric] Move sqrt to Numeric. Remove incorrect return value type of roots.
> Move cis and unpolar to Real. Add to-radians and from-radians to Numeric.
The return value for roots should have been corrected (to List of
Numeric), not removed.
--
Jonathan "Dataweaver" Lang
> 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
27 matches
Mail list logo
