On Tue, Aug 05, 2008 at 05:43:57PM +0800, Audrey Tang wrote:
> John M. Dlugosz 提到:
>> Does that mean that traits can come before the signature? Or should it
>> be corrected to
>> method close () is export { ... }
>
> It's a simple typo. Thanks, fixed in r14572.
The strange thing is that we
John M. Dlugosz 提到:
Does that mean that traits can come before the signature? Or should it
be corrected to
method close () is export { ... }
It's a simple typo. Thanks, fixed in r14572.
Cheers,
Audrey
On Thu, Apr 10, 2008 at 11:36:09PM -0500, Patrick R. Michaud wrote:
: Yes, but where does resolve down to a typename?
: My reading of STD.pm is that becomes a
: (since it's not a 'where' clause in this case), and is currently
: one of , , or .
Value is supposed to include fulltypename, but I
On Thu, Apr 10, 2008 at 09:18:38PM -0700, Larry Wall wrote:
> On Fri, Apr 11, 2008 at 03:26:02AM -, John M. Dlugosz wrote:
> : S06 shows how to define named-only parameters, "marked with a prefix :".
> But no example shows anything more than a bare parameter name. No type is
> ever given!
>
On Fri, Apr 11, 2008 at 03:26:02AM -, John M. Dlugosz wrote:
: S06 shows how to define named-only parameters, "marked with a prefix :". But
no example shows anything more than a bare parameter name. No type is ever
given!
:
: Looking through my copy of STD.pm, I'm baffled, as it seems not
On 11/23/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Luke wrote:
>
> > On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> >
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >> :syntax
> >
> >
> > Aren't we providing an interface to define your own r
Luke wrote:
On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
:syntax
:syntax
:syntax
:syntax
:syntax
:syntax
Aren't we providing an interface to define your own regex modifiers?
Sure. But it'd lead to much less namespace pollution and much greater
readabilit
On 11/22/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> :syntax
> :syntax
> :syntax
> :syntax
> :syntax
> :syntax
Aren't we providing an interface to define your own regex modifiers?
All of these can easily be mapped into Perl 6 patterns, so...
Modules welcome! ;-)
On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote:
> I have been meaning to do some kind of p5 prototype of this, I can
> push it up the TODO list if it would help you.
As you can probably infer from the amount of time that it has taken for me
to realise that I've failed to reply to
On 11/3/05, Michele Dondi <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Nov 2005, Ruud H.G. van Tol wrote:
>
> >> http://www.nntp.perl.org/group/perl.perl6.language/17556
> >
> > I understand that Perl6 allows blocks with changed/enhanced syntax, so
> > it is or will become possible (to add it) as if it w
On Wed, 2 Nov 2005, Ruud H.G. van Tol wrote:
http://www.nntp.perl.org/group/perl.perl6.language/17556
I understand that Perl6 allows blocks with changed/enhanced syntax, so
it is or will become possible (to add it) as if it was in the core
language.
Do I understand that right? Something as sim
On Thu, 2005-10-20 at 17:12 -0700, Nate Wiger wrote:
> If Perl 6 is going to be successful, this means it must change the
> fewest key things with the most benefits.
I think there's an assumption here that not only do I not hold but I do
not even understand.
Suppose that I am a game developer wi
Feh - I really need to get on gmail's case for providing a keystroke
for "Reply to All".
Rob
-- Forwarded message --
From: Nate Wiger <[EMAIL PROTECTED]>
Date: Oct 21, 2005 2:38 PM
Subject: Re: $1 change issues [was Re: syntax for accessing multiple
versions
On 2005-10-21 1:54 PM, "Nate Wiger" <[EMAIL PROTECTED]> wrote:
> BTW, C and PHP both use -> "still".
C++ is probably more relevant than C, but since it inherited the syntax,
same diff. But in their case the underlying form is still a dot; A->B is
just syntactic sugar for (*A).B. The distinction
Luke Palmer wrote:
Every regex engine in every language uses $1 or \1. This includes Java,
JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow
other languages seem ok with this, because it's a widely-used convention.
Perl 6's patterns are _not_ regexes anymore. But I doubt t
On Thu, Oct 20, 2005 at 09:14:15PM -0400, John Adams wrote:
> From: Luke Palmer <[EMAIL PROTECTED]>
>
> > But $1 in Perl 5 wasn't the same as $1 in a shell script.
>
> I'm all for breaking things that need breaking, which is why I
> keep my mouth shut most of the time--either I see the reason or
-Original Message-
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
>I can state the compelling reason for this one -- it's way too
confusing when $1, $2, $3, etc. correspond to $/[0], $/[1], $/[2], etc.
>In many discussions of capturing semantics earlier in the year,
nearly everyone usin
On Thu, 20 Oct 2005, Luke Palmer wrote:
Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
Perl 6 from some non-Perl 5 language is going to be more comfortable
with dot.
(Also, I did like the arrow notation, but) how cool would be
@cool=grep ->cool, @misc; # if compared to
On 10/21/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> On 10/21/05, Benjamin Smith <[EMAIL PROTECTED]> wrote:
> > On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote:
> > > Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
> > > Perl 6 from some non-Perl 5 language is goi
On 10/21/05, Benjamin Smith <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote:
> > Huh? So you want to go back to Perl 5's arrow? *Anybody* coming to
> > Perl 6 from some non-Perl 5 language is going to be more comfortable
> > with dot.
>
> Unless it was Sm
On Thu, Oct 20, 2005 at 06:39:34PM -0600, Luke Palmer wrote:
> On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
> > Luke Palmer wrote:
> > > The fact that we use . instead of -> (like every other language on
> > > the planet)?
> >
> > You're using my argument for me - thanks. See above.
>
> Huh?
On Thu, Oct 20, 2005 at 05:12:32PM -0700, Nate Wiger wrote:
> Every regex engine in every language uses $1 or \1. This includes Java,
> JavaScript, C, PHP, Python, awk, sed, the GNU regex libs, etc. Somehow
> other languages seem ok with this, because it's a widely-used convention.
This quibbling
From: Luke Palmer <[EMAIL PROTECTED]>
> But $1 in Perl 5 wasn't the same as $1 in a shell script.
Sure--but that's not what I said.
I'm all for breaking things that need breaking, which is why I keep my mouth
shut most of the time--either I see the reason or I suspect (that is, take on
faith,
On 10/20/05, John Adams <[EMAIL PROTECTED]> wrote:
> Then the target audience is specifically not people coming from a
> shell scripting background, who are quite used to the idea that $0 is
> different from $1 in a way in which $1 is not different from $2.
> Correct?
But $1 in Perl 5 wasn't the s
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> >
> > Okay, I may still be missing your point, so let me try to summarize
> > just to be sure we're on the same page: You say that the thing that
> > is going to hinder migration to Perl 6 is the fact that it's different
> >
Luke Palmer wrote:
Okay, I may still be missing your point, so let me try to summarize
just to be sure we're on the same page: You say that the thing that
is going to hinder migration to Perl 6 is the fact that it's different
from Perl 5.
Intentionally trite oversimplification. My problem is
-Original Message-
From: Luke Palmer <[EMAIL PROTECTED]>
> Our target audience is only somewhat from a Perl 5 background. People
from Java, from Python, from C, and even just starting to program will
be learning Perl 6, and they would rather have all the language be
zero-based, rather tha
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
> I think you missed my point(s), but if you feel compelled to write me
> off as a "complainer" just because I have a counter-opinion that is at
> least somewhat built from a good amount of experience, then I do think
> you're wearing a set of blin
Luke Palmer wrote:
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
$1 is a prime example. $0 means the program name (all scopes). $1 is the
first match. It's been that way for a very, very, very long time, and
it works just great. There is no *compelling* reason to change this,
other than t
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
> $1 is a prime example. $0 means the program name (all scopes). $1 is the
> first match. It's been that way for a very, very, very long time, and
> it works just great. There is no *compelling* reason to change this,
> other than to satisfy a few
Nicholas Clark wrote:
$1 is a prime example. $0 means the program name (all scopes). $1 is the
first match. It's been that way for a very, very, very long time, and
it works just great. There is no *compelling* reason to change this,
other than to satisfy a few people that think it "should be
> Unfortunately many people WILL have to deal with such changes, and
> the question should be: Does a given change offer a clear improvement?
> As you said, if we're helping %1 of people %1 of the time, are the
> other 99% really going to change all their scripts? No chance.
You again misread what
On Thu, Oct 20, 2005 at 11:31:03AM -0700, Nate Wiger wrote:
> $1 is a prime example. $0 means the program name (all scopes). $1 is the
> first match. It's been that way for a very, very, very long time, and
> it works just great. There is no *compelling* reason to change this,
> other than to sat
Rob Kinyon wrote:
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
And, it shares alot with other languages people know and use.
That's more because languages are incestuous (like Perl) instead of
languages independently arriving at the same conclusions. Yes, the
"while" loop is going to lo
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
> And, it shares alot with other languages people know and use.
That's more because languages are incestuous (like Perl) instead of
languages independently arriving at the same conclusions. Yes, the
"while" loop is going to look the same everywher
On 10/20/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
> Larry Wall wrote:
> > I think there can be some kind of community metainformation that sets
> > defaults appropriately. And if not, the site/project can certainly
> > establish defaults. On the other hand, a lot of projects do simply
> > want t
Larry Wall wrote:
I think there can be some kind of community metainformation that sets
defaults appropriately. And if not, the site/project can certainly
establish defaults. On the other hand, a lot of projects do simply
want to specify the version and author explicitly eveyr time,
and they'd
On Wed, Oct 19, 2005 at 03:58:17PM -0700, Nate Wiger wrote:
: Larry Wall wrote:
: >This is one of those accomodations to the real world, like everyone
: >agreeing on a standard URI format. We're really trying to keep
: >these module names close to what you'd see as the name of, say,
: >the corresp
On Wed, Oct 19, 2005 at 09:12:47PM -0400, Rob Kinyon wrote:
: On 10/19/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
: > My concern is that we're solving problems that don't really exist in
: > real-world Perl usage. Are there really two competing authors of DBI?
: > Or, for any product, do two people
On 10/19/05, Nate Wiger <[EMAIL PROTECTED]> wrote:
> My concern is that we're solving problems that don't really exist in
> real-world Perl usage. Are there really two competing authors of DBI?
> Or, for any product, do two people really try to market "SuperWidget"?
> No, one person just changes to
Larry Wall wrote:
This is one of those accomodations to the real world, like everyone
agreeing on a standard URI format. We're really trying to keep
these module names close to what you'd see as the name of, say,
the corresponding .rpm file. These modules have to have names that
work outside of
On Wed, Oct 19, 2005 at 03:10:13PM -0700, Nate Wiger wrote:
: Larry Wall wrote:
: >Well, we thought about opening it up like that, but we really kinda
: >need to establish what is an official part of the "long name" for
: >uniqueness purposes, and try to avoid too much visual clutter in
: >standard
Larry Wall wrote:
Well, we thought about opening it up like that, but we really kinda
need to establish what is an official part of the "long name" for
uniqueness purposes, and try to avoid too much visual clutter in
standard usage.
Going with that... I would think that the "official" part is r
On Wed, Oct 19, 2005 at 01:30:07PM -0700, Nate Wiger wrote:
: Stevan Little wrote:
: >Nicholas,
: >
: >This is addressed in S11, here is a link:
: >
: > http://search.cpan.org/~ingy/Perl6-Bible/lib/Perl6/Bible/S11.pod
: >
: >To summarize, the syntax to load the modules is:
: >
: > use Dog-1.2.1;
Stevan Little wrote:
Nicholas,
This is addressed in S11, here is a link:
http://search.cpan.org/~ingy/Perl6-Bible/lib/Perl6/Bible/S11.pod
To summarize, the syntax to load the modules is:
use Dog-1.2.1;
While the syntax to create a specific version of a module is:
my Dog-1.3.4-cpan:JRA
On Wed, Oct 19, 2005 at 09:33:39AM -0400, Stevan Little wrote:
: On Oct 19, 2005, at 4:10 AM, Larry Wall wrote:
: >On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote:
: >: Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol
: >: table. Then once the compilation process is c
On Wed, Oct 19, 2005 at 09:33:39AM -0400, Stevan Little wrote:
> However, this brings up an issue I was thinking about. Take this code
> for instance:
>
> use Cat-0.0.1;
> use PetStore;
>
> my Cat $kitty .= new();
>
> --- in PetStore.pm ---
>
> use Dog;
> use Cat-0.0.5;
>
> Which C
On Wed, Oct 19, 2005 at 12:59:34PM +0200, Ruud H.G. van Tol wrote:
: Larry Wall:
:
: > I think using two different versions from the same
: > module is going to be relatively rare.
:
: For dealing with two generations at the same time, like with
: conversions: in stead of designing and applying a
Larry,
On Oct 19, 2005, at 4:10 AM, Larry Wall wrote:
On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote:
: Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol
: table. Then once the compilation process is complete, I traverse the
: symbol table hierarchy collecting all
Larry Wall:
> I think using two different versions from the same
> module is going to be relatively rare.
For dealing with two generations at the same time, like with
conversions: in stead of designing and applying a patch (SQL's ALTER
COLUMN, etc.), create a new dataset and let the old informati
On Tue, Oct 18, 2005 at 07:38:19PM -0400, Stevan Little wrote:
: Then this is added as "Dog-0.0.2-cpan:LWALL" into the main symbol
: table. Then once the compilation process is complete, I traverse the
: symbol table hierarchy collecting all the names. Any duplicate short
: names (Dog) are no
On Oct 18, 2005, at 11:15 PM, Rob Kinyon wrote:
NB: Dog-*-cpan:LWALL and Dog-*-cpan:JRANDOM, as well as *-*-cpan:LWALL
are also needed for entry into the mix because if there's only one
module loaded that is signed by cpan:LWALL, that should be sufficient
disambiguation for the parser. (How main
> Another school of thought would be that "Dog" alone would be
> considered ambiguious and so we would just alias far enough to be
> clear, like this:
>
>Dog => Ambiguity Error!
>Dog-1.2.1 => Dog-1.2.1-cpan:JRANDOM
>Dog-0.0.2 => Dog-0.0.2-cpan:LWALL
>
> Of course, this means that
Nicholas,
This is addressed in S11, here is a link:
http://search.cpan.org/~ingy/Perl6-Bible/lib/Perl6/Bible/S11.pod
To summarize, the syntax to load the modules is:
use Dog-1.2.1;
While the syntax to create a specific version of a module is:
my Dog-1.3.4-cpan:JRANDOM $spot .= new("woo
On 10/18/05, Juerd <[EMAIL PROTECTED]> wrote:
> Nicholas Clark skribis 2005-10-18 22:41 (+0100):
> > my $foo = DBI(1.38)->new();
> > my $bar = DBI(1.40)->new();
>
> I like this syntax, and have a somewhat relevant question: can a module
> be aliased entirely, including all its subclasses/-roles
Nicholas Clark skribis 2005-10-18 22:41 (+0100):
> my $foo = DBI(1.38)->new();
> my $bar = DBI(1.40)->new();
I like this syntax, and have a somewhat relevant question: can a module
be aliased entirely, including all its subclasses/-roles/-.*?
Something like
use DBI as RealDBI;
use
Rob Kinyon wrote:
On 5/28/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
(This thread is referencing http://www.perlmonks.org/?node_id=461105)
I'd like to start writing the Module::Build/ExtUtils::MakeMaker for
Pugs. One of the first things that was mentioned was that the syntax
for use needs to
On 5/28/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> (This thread is referencing http://www.perlmonks.org/?node_id=461105)
>
> I'd like to start writing the Module::Build/ExtUtils::MakeMaker for
> Pugs. One of the first things that was mentioned was that the syntax
> for use needs to support specif
Adam Kennedy wrote:
You get all those possibilities whenever you install any new version
of a module you get from someone else, regardless of a p5->p6 hop. In
p6, when you say "use Digest;", you are specifically asking for what
p6 considers the "latest" version. In p5, it was "first match on
You get all those possibilities whenever you install any new version of
a module you get from someone else, regardless of a p5->p6 hop. In p6,
when you say "use Digest;", you are specifically asking for what p6
considers the "latest" version. In p5, it was "first match on libpath".
Except that
Adam Kennedy wrote:
On the migration front, when someone ports Digest.pm to Perl6, I get
a "free" upgrade, assuming the module author was kind enough to up
the version number.
You are making a pretty huge assumption here that whoever has a
namespace in p5 CPAN has first dibs at the P6 names
On the migration front, when someone ports Digest.pm to Perl6, I get a
"free" upgrade, assuming the module author was kind enough to up the
version number.
You are making a pretty huge assumption here that whoever has a
namespace in p5 CPAN has first dibs at the P6 namespace of the same
name,
Autrijus Tang wrote:
So, this now works in Pugs with (with a "env PUGS_EMBED=perl5" build):
use Digest--perl5;
my $cxt = Digest.SHA1;
$cxt.add('Pugs!');
# This prints: 66db83c4c3953949a30563141f08a848c4202f7f
say $cxt.hexdigest;
This includes the "Digest.pm" from Perl 5. DBI.
Autrijus Tang wrote:
So, this now works in Pugs with (with a "env PUGS_EMBED=perl5" build):
use Digest--perl5;
my $cxt = Digest.SHA1;
$cxt.add('Pugs!');
# This prints: 66db83c4c3953949a30563141f08a848c4202f7f
say $cxt.hexdigest;
This includes the "Digest.pm" from Perl 5.
Autrijus Tang <[EMAIL PROTECTED]> writes:
> So, this now works in Pugs with (with a "env PUGS_EMBED=perl5" build):
>
> use Digest--perl5;
>
> my $cxt = Digest.SHA1;
> $cxt.add('Pugs!');
>
> # This prints: 66db83c4c3953949a30563141f08a848c4202f7f
> say $cxt.hexdigest;
>
> This i
At 12:06 PM +0800 5/25/05, Autrijus Tang wrote:
So, this now works in Pugs with (with a "env PUGS_EMBED=perl5" build):
use Digest--perl5;
my $cxt = Digest.SHA1;
$cxt.add('Pugs!');
# This prints: 66db83c4c3953949a30563141f08a848c4202f7f
say $cxt.hexdigest;
This includes the "Di
[EMAIL PROTECTED] wrote:
I don't think that a role has a long and a short name. This is
because they aren't subject to MMD. I think of them more as
beeing expanded like C++ templates even though the actual mechanism
will be much more sophisticated. Actually I think of them as F-bounds
as well ;)
Uh
Miroslav Silovic wrote:
Uhm, but C++ templates are subject to (compile-time) MMD, once you
specialise them. In other words,
role Something[Int $num] {...}
role Something[String $num] {...}
Hmm, C++ has no free floating templates. They always template a
class/struct or a function. The Perl6 equiva
Ingo Blechschmidt wrote:
I meant: The colon should still act as the delimiter between the params
which account to the long name of the role and those which don't, but
otherwise the syntax should be the same as the standard subroutine
signature syntax, allowing optional params, etc.
I don't think th
Hi,
"TSa (Thomas SandlaÃ)" wrote:
> you wrote:
>> I wondered if it would be useful/good/nice if the syntax for
>> specifying role parameters would be the same as the standard
>> subroutine signature syntax (minus the colon, which
>> separates the parameters which do account to the long name
>> of
HaloO Ingo,
you wrote:
I wondered if it would be useful/good/nice if the syntax for
specifying role parameters would be the same as the standard
subroutine signature syntax (minus the colon, which
separates the parameters which do account to the long name
of the role from the ones which don't).
Larry Wall writes:
> If you write:
>
> multi method add( $self: Foo $foo, Bar $bar );
>
> then there are multiple add methods in the current class. Note the
> invocant is not optional in this case. Also, there's an implied
> second colon after $bar, indicating the end of the arguments to be
- Original Message -
From: "Jonathan Lang" <[EMAIL PROTECTED]>
> So the following three declarations cover very similar (but not quite
> identical) things:
>
> multi sub call ($a: $b) {...}
> submethod invoke ($a: $b) {...}
> method check ($a: $b) {...}
>
> All three of these use mu
I think most everyone is missing the new simplicity of the current
conception of "multi". It's now completely orthogonal to scoping
issues. It merely says, "I'm putting multiple names into a spot
that would ordinarily demand a unique name."
In other words, what a name means in a given scope is a
Jonathan Lang wrote:
multi sub call ($a, $b: $c) {...}
multi submethod invoke ($a, $b: $c) {...}
multi method check ($a, $b: $c) {...}
Why do we suddenly need to append the "multi" keyword to "submethod" and
"method"?
So the compiler knows we really did mean for that (sub)method to be multip
Luke Palmer wrote:
> Jonathan Lang writes:
> > Luke Palmer wrote:
> > > Well, "multi" is no longer a declarator in its own right, but rather
> > > a modifier. Synopsis & Exegesis 6 show this.
> >
> > I don't know about Exegesis 6,
>
> Then you should probably read it. It is the most recent o
Jonathan Lang writes:
> My apologies for the break in the chain of responses; I lost your reply
> before I could reply to it, and had to retrieve it from the list archives.
>
>
> Luke Palmer wrote:
> > Well, "multi" is no longer a declarator in its own right, but rather a
> > modifier. Synopsis
My apologies for the break in the chain of responses; I lost your reply
before I could reply to it, and had to retrieve it from the list archives.
Luke Palmer wrote:
> Well, "multi" is no longer a declarator in its own right, but rather a
> modifier. Synopsis & Exegesis 6 show this.
I don't
Jonathan Lang writes:
> To make "method" work as an alternative for "multi" in every case, the
> only changes that you'd need to make would be to allow more than one
> invocant to be explicitly specified in the "method" syntax, and to allow
> the positional portion of the parameter list to optional
79 matches
Mail list logo
