There's a discussion going on #perl6/irc.freenode.org right now wondering
about what .method means. We'd all assumed it meant $self.method (where
$self is always the method invocant) but then had a look at Synopsis 12
which states
Dot notation can omit the invocant if it's in $_:
.doit(1
I should add that Darren and I, who both have similar tendencies towards
larger scale coding where consistency is far preferred to compactness,
both ended up concluding that our style policies will be to _always_ use
explicit invocants (except of course for one liners).
In the case of the Algor
That is correct. It probably should have read "...our style policies
will be to _always_ use explicit invocants, if .foo ends up meaning
$_.foo in the final release (as it does now)".
(of course, I suspect Darren will keep using them anyways, but then he
likes to be even more explicit than I am
On Thu, Mar 17, 2005 at 06:04:56PM +1100, Adam Kennedy wrote:
> I should add that Darren and I, who both have similar tendencies towards
> larger scale coding where consistency is far preferred to compactness,
> both ended up concluding that our style policies will be to _always_ use
> explicit
Larry Wall wrote:
$x = whether $a or $b;
$x = not $a or $b;
would actually be parsed as
$x = whether($a) or $b;
$x = not($a) or $b;
whereas as a native English speaker would probably expect
$x = whether($a or $b);
Reading this makes me wanting:
$x = either $a or $b;
$y = neith
On Wed, Mar 16, 2005 at 11:49:12PM -0600, Rod Adams wrote:
: I haven't gotten a solid answer on when and how Perl will autogenerate
: methods from subs.
In general I don't think of it as autogeneration at all, but as
failover to a different dispatcher. I can't think of a case where an
ordinary
I'm looking to understand symbol tables and the symtable hash better.
What's the motivation for ::() syntax? Is it mainly for binding aliases?
How would $::("MY::bar") behave when my $bar has not been declared?
(Similarly, what happens with an undeclared $::("Foo::bar") ?)
If I do the analogous t
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote:
: Personally, .foo meaning $self.foo seems more consistent to my mind, and
: I'd happily standardise on implicit invocants.
I'm thinking about it. There are definitely things to be said for both
sides, and maybe we can come up with a
Larry Wall writes:
> Perl 5 always makes a copy of return values, but that just turns
> out to not matter for references, since a copy of a reference is as
> good as the original reference. Perl 5 also propagates scalar/list
> context into subs. For $:foo it doesn't matter--it always behaves
> as
On Thu, Mar 17, 2005 at 10:33:42AM +0200, Gaal Yahas wrote:
: I'm looking to understand symbol tables and the symtable hash better.
:
: What's the motivation for ::() syntax? Is it mainly for binding aliases?
It's for explicit symbolic reference. The ${...} syntax is now
entirely reserved for ha
Larry Wall writes:
> In that case we'd have to say that "given" and "for" always require
> "-> $x" inside methods, and that $x is never automatically aliased to
> $_. But there are other ramifications with switch statements and
> exception handlers I have to think through,
In particular, the fac
On Thu, Mar 17, 2005 at 02:06:46AM -0700, Luke Palmer wrote:
: I'll just point out, the rest of this message, with all the autocopy
: complexity (according to /some/ people), uses this assumption. It all
: happily goes away if $self.:bar returns a list if @:bar is declared.
: And I can't, off hand
On Thu, Mar 17, 2005 at 02:21:09AM -0700, Luke Palmer wrote:
> In particular, the fact that `map` rebinds $_. Consider:
>
> method data () {
> map { .process($_) } @.array;
> }
>
> Is that calling `$_.process($_)` for each `$_` in [EMAIL PROTECTED], or is it
> calling `$self.proc
On Thu, Mar 17, 2005 at 07:00:08PM +1100, Adam Kennedy wrote:
> The only minor thing I
> can see would be that you will end up with a slight asymmetry question
> of "if we use $:attribute for a private attribute, do we call :method
> for a private method?"
That occurs no matter if .method means
Rod Adams skribis 2005-03-16 23:16 (-0600):
> Doesn't C go until the longest input is exhausted, returning undef
> at the end of the shorter ones?
No, as that'd break the most common idiom it introduced: use of an array
with 1..Inf, as in the example you're replying to, but also
for @foos ¥
David Storrs <[EMAIL PROTECTED]> wrote:
> Aside from links, that's pretty much the entire perlpodtut boiled down
> into 7 bullets; a little experimentation to get the hang of it and it
> all holds together nicely, easy to remember.
Yes, yes, yes.
Pod is one of the things Perl 5 did almost exactly
Thank you, Luke and Larry, for your replies. They did help.
For now, I will use the syntax $obj.:bar[] and $obj.:baz{} in the
get_bar|baz() accessor methods to get copies returned; if the rules
change again, I'll update later.
I noticed that the example seemed incomplete, saying only what would
Hola...
This message is not about removing wantarray, but finding a better
solution for a typical but annoying usage-idiom.
sub value_added { # not really a wrapper
my $result = original(@args);
...
return $result;
}
Is a typically broken subroutine in perl 5, unless orig
BTW, i should mention that given want { } in s06 is nice for
replacing the simple kind of wantarray usage cases, but not what
this message brought up.
In short, i did read it, so don't send me links ;-)
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me
On Thu, 2005-03-17 at 02:17 -0800, Brent 'Dax' Royal-Gordon wrote:
> David Storrs <[EMAIL PROTECTED]> wrote:
> > Aside from links, that's pretty much the entire perlpodtut boiled down
> > into 7 bullets; a little experimentation to get the hang of it and it
> > all holds together nicely, easy to re
On Wed, 2005-03-16 at 15:09 -0800, David Storrs wrote:
> C[$x[0] > $y] # hmmm...parser ok with that?
> C[$x[0] > $] # hmmm...error, but what was intended: $y] or $]]?
In the former case, it's fine. See the grammar I sent last night.
In the latter case, you would get balanced-[] matching, an
Autrijus Tang wrote:
> > Luke Palmer wrote:
> >
> > And it would be a shame to disallow the use of $_ in map.
>
> Err, wait, I don't think we are discussing whether $_ is to
> be outlawed in map {}.
Perhaps we should consider making $_ readonly in map and grep?
--
Garrett Goebel
IS Development
Aaron Sherman skribis 2005-03-17 8:30 (-0500):
> This is aesthetic preference. I could cite the reasons that I have an
> aesthetic preference for the other syntax, but the reality is that angle
> brackets aren't angle brackets; they are less-than (E) and greater-
> than signs (E). We ignore this f
Garrett Goebel skribis 2005-03-17 8:37 (-0600):
> Perhaps we should consider making $_ readonly in map and grep?
That's one way to avoid clever tricks. Please let's not.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajig
I've been thinking about this in my sleep, and at the moment I think
I'd rather keep .foo meaning $_.foo, but break the automatic binding
of the invocant to $_. Instead of that, I'd like to see a really,
really short alias for $self. Suppose we pick "o" for that, short
for "object". Then we get
On Thu, 17 Mar 2005, Larry Wall wrote:
really short alias for $self. Suppose we pick "o" for that, short
for "object". Then we get self calls of the form:
o.frobme(...)
How 'bout ..frobme(...)? Or would it be a hell to tell from C<..>?
(Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote:
: Then we get self calls of the form:
:
: o.frobme(...)
Sleep Brain would also like to point out that this lets you use o
standalone when you want to pass the current object as an ordinary
argument to some other class. Likewise for
On Thu, Mar 17, 2005 at 05:52:15PM +0100, Michele Dondi wrote:
: On Thu, 17 Mar 2005, Larry Wall wrote:
:
: >really short alias for $self. Suppose we pick "o" for that, short
: >for "object". Then we get self calls of the form:
: >
: > o.frobme(...)
:
: How 'bout ..frobme(...)? Or would it be
On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote:
: Rod Adams skribis 2005-03-16 23:16 (-0600):
: > Doesn't C go until the longest input is exhausted, returning undef
: > at the end of the shorter ones?
That's what has been specified.
: No, as that'd break the most common idiom it introduce
On 17/03/05 00:49 -0500, Aaron Sherman wrote:
> On Wed, 2005-03-16 at 13:42 -0800, Brian Ingerson wrote:
>
> Well, look over AJS Kwid, and see what you think. The bullet syntax you
> give could work fine as a replacement for what I demonstrate, but I
> think everything else is pretty much 1:1. Now
On Thu, Mar 17, 2005 at 08:41:26AM -0800, Larry Wall wrote:
> I've been thinking about this in my sleep, and at the moment I think
> I'd rather keep .foo meaning $_.foo, but break the automatic binding
> of the invocant to $_. Instead of that, I'd like to see a really,
> really short alias for $se
Larry Wall wrote:
That's actually weirdly symmetrical with the notion that only subs can
impose compile-time context on their arguments, while methods always
have to assume list context because you have to generate the argument
list before you can know which method you're going to dispatch to.
Sorr
Larry Wall wrote:
On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote:
: No, as that'd break the most common idiom it introduced: use of an array
: with 1..Inf, as in the example you're replying to, but also
:
: for @foos ¥ 1... -> $foo, $i { ... }
Maybe we need a short-circuit zip:
for
On Thu, 17 Mar 2005, Larry Wall wrote:
: > o.frobme(...)
:
: How 'bout ..frobme(...)? Or would it be a hell to tell from C<..>?
: (Mnemonic reminder: '.'=myself, '..'=my mom - poor analogy, actually!)
:
: How 'bout a single underscore? _.frobme()?!?
Thought about those in the night, but they don'
Larry Wall skribis 2005-03-17 9:05 (-0800):
> That's what has been specified.
> Maybe we need a short-circuit zip:
> for @foos ¥¥ 1... -> $foo, $i { ... }
Because ¥ is shorter than ¥¥, and because the 1... thing is probably
going to be used much, I think it should be the one that returns the
John Macdonald wrote:
A shotgun brainstorming of possible operator names:
well, I didn't follow this thread very closely (and I don't know if it
is "officially" closed :-) but I suddenly thought about "yes". what about:
$x = not $a or $b; # vs
$x = yes $a or $b;
$yesno = yes any(@foo) == an
On 17/03/05 04:40 +0800, Autrijus Tang wrote:
> On Wed, Mar 16, 2005 at 12:09:40PM -0800, Larry Wall wrote:
> > whereas as a native English speaker would probably expect
> >
> > $x = whether($a or $b);
> >
> > So I'm thinking we'll just go back to "true", both for that reason,
> > and because
Mark J. Reed writes:
> Luke Palmer wrote:
>
> >Marcus Adair writes:
> >> Additionally I question whether this is truly a case improving to the
> >> point of least surprise? After all, I don't know a programmer who's
> >> going to be surprised by what true means. There are still *some* things
> >>
On Thu, Mar 17, 2005 at 14:09:26 -0700, Luke Palmer wrote:
> Is wrong. If answer() decides that it should start returning a more
> interesting value of true, then the test fails.
I think the only name for this function, from which you can actually
understand what it does, is
bool(?:ean
On Thu, 2005-03-17 at 09:54, Juerd wrote:
> > > Pod needs incremental improvements--tables
> > Oops, forgot that one. I'll add it tonight, when I get home from work.
>
> See PodTables in the Pugs wiki.
Or see the archive of this list, where we hammered it out previously.
YMMV. I'll have the sec
Aaron Sherman skribis 2005-03-17 16:30 (-0500):
> > See PodTables in the Pugs wiki.
> Or see the archive of this list, where we hammered it out previously.
Since when is anything in Perl 6, except its name, set in stone?
PodTables is a more detailed and more consistent approach to a
suggestion I
I think this should mean $_, and if the user really really really
wants to do .foo on the invocant, then why not just say:
method bar ($_:) {
.foo;
}
This keeps $_ unambiguosly the 'it', while 'this' is more specific.
Think:
it puts the lotion on the skin
method blah {
Brian Ingerson skribis 2005-03-17 11:57 (-0800):
> 'Tis a pity nobody suggested `tis()`.
That sounds more like a smart match on the topic:
if tis 'foo' { ... }
if $_ ~~ 'foo' { ... }
't => $_,
is => ~~
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juer
On Thu, 2005-03-17 at 16:39, Juerd wrote:
> Aaron Sherman skribis 2005-03-17 16:30 (-0500):
> > > See PodTables in the Pugs wiki.
> > Or see the archive of this list, where we hammered it out previously.
>
> Since when is anything in Perl 6, except its name, set in stone?
>
> PodTables is a more
On Thu, 2005-03-17 at 12:28, Brian Ingerson wrote:
> The interesting thing to me is that all 3 syntaxes map over the same
> data model and thus are easily interchangable. The other interesting
> thing is that all three could be supported without affecting the Perl5
> or Perl6 syntax proper.
If an
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > Specifically, I like the use of angle brackets in Pod. Angle brackets
> > are simple, distinctive shapes; they remain wide in variable-width
>
> This is aesthetic preference. I could cite the reasons that I have an
> aesthetic preference for the other
On Thu, 2005-03-17 at 17:07, Brent 'Dax' Royal-Gordon wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > and the hacks in
> > pod syntax (e.g. C<< < >>) to get around this are glaring anti-
> > huffmanisms.
>
> Whatever bracketing character we decide to use, there will always be
> occasions wh
Aaron Sherman wrote:
Sam "mugwump" Vilain refers to each of these syntaxes as /Pod dialects/.
He is working on more formally defining the common model or "AST" that
these dialects map to.
Why? Seriously, why on earth do you want to encourage the proliferation
of variant markup languages?! There are
On Wed, 2005-03-16 at 03:18, Rod Adams wrote:
> I just posted a fresh copy of S29 to:
>
> http://www.rodadams.net/Perl/S29.pod
> http://www.rodadams.net/Perl/S29.html
>From there:
=head2 Obsolete
=item chop
Chop removes the last character from a string. Is that no longer usef
It occurs to me that I may have requested something before that would
cause more problems than it solves if implemented. So I have a
different idea that would hopefully be efficient, powerful, and easy
to learn. In short, make it work much like Perl 5.
The idea is Perl methods and subs will a
On Thu, 17 Mar 2005 16:16:00 -0700, gcomnz <[EMAIL PROTECTED]> wrote:
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
>By the way, I think I've seen a few people suggest some sort of
>syntax-switching mechanism for "Pod6". The day people have to think
>about what dialect of Pod they're usin
As an addendum, my idea would also apply to non-attribute variables.
If you say 'my %abc' in a method or sub, and later say 'return %abc',
then a reference to %abc will be returned by default.
So its not like I'm treating attributes differently.
-- Darren Duncan
At 3:27 PM -0800 3/17/05, Darren D
On Thu, Mar 17, 2005 at 05:04:53PM -0500, Aaron Sherman wrote:
> On Thu, 2005-03-17 at 12:28, Brian Ingerson wrote:
>
> > The interesting thing to me is that all 3 syntaxes map over the same
> > data model and thus are easily interchangable.
>
> It is, however, contrary to the spirit of POD for
Aaron Sherman wrote:
On Wed, 2005-03-16 at 03:18, Rod Adams wrote:
I just posted a fresh copy of S29 to:
http://www.rodadams.net/Perl/S29.pod
http://www.rodadams.net/Perl/S29.html
From there:
=head2 Obsolete
=item chop
Chop removes the last character from a string. Is that no
[No, I'm not back; I'm just passing by. But I feel that I need to comment on
this whole issue]
Even before Brian announced Kwid, I was privately suggesting to Larry that
Markdown (http://daringfireball.net/projects/markdown/) was an excellent
evolution of mark-up notations and might be well sui
Oh, and I forgot to mention:
In the contents of any block, any line with '=' in column zero and a
whitespace character in column 1, has those two characters removed when the
contents are extracted. So you can write:
=begin data POSSIBLE_POD_DIRECTIVES
=
= =doh -- Oh, dear! Oh frikking dear!
= =r
On Thu, 2005-03-17 at 18:06 -0600, Rod Adams wrote:
First off, thanks for the reply. Very nice work you're doing!
> I'll listen to proposals about how to support better randoms. For now I
> think C is a standard PRNG.
Yes, absolutely. If I gave a contrary impression, I did not mean to.
I think
On Wed, 2005-03-16 at 02:18 -0600, Rod Adams wrote:
> I just posted a fresh copy of S29 to:
>
> http://www.rodadams.net/Perl/S29.pod
> http://www.rodadams.net/Perl/S29.html
Couple more points from the docs (mostly to the list, but some to you,
Rod):
multi sub grep (Any|Junction $test : [EMAIL
On Thu, 2005-03-17 at 20:47 -0500, Aaron Sherman wrote:
> Methods on numeric values (should be defined as pseudo-methods on
> unboxed numbers):
>
> chr
> hex
> oct
Sigh... well, now I know what Ctrl-Return does in Evolution :-/
Ok, so what I was getting at was that the above thr
Aaron Sherman wrote:
On Thu, 2005-03-17 at 18:06 -0600, Rod Adams wrote:
This is a SEPARATE need from the need for a repeatable, standard PRNG,
and should always operate off of the best source of entropy available to
the program. Right now, that's /dev/urandom (for non-blocking hybridized
entrop
Aaron Sherman wrote:
On Wed, 2005-03-16 at 02:18 -0600, Rod Adams wrote:
I just posted a fresh copy of S29 to:
http://www.rodadams.net/Perl/S29.pod
http://www.rodadams.net/Perl/S29.html
Couple more points from the docs (mostly to the list, but some to you,
Rod):
multi sub grep (Any|Junction
Aaron Sherman wrote:
On Thu, 2005-03-17 at 20:47 -0500, Aaron Sherman wrote:
Methods on numeric values (should be defined as pseudo-methods on
unboxed numbers):
chr
hex
oct
Sigh... well, now I know what Ctrl-Return does in Evolution :-/
Ok, so what I was getting at was that th
Hello All,
I have been working on some misc. junction tests for Pugs and I ran into an
item which I am not sure of. It has to do with a junction of variables which
is then assigned to variable itself, and how "bound" the variables inside the
junction are. This is best illustrated with code, so
On Thu, Mar 17, 2005 at 10:31:07PM -0600, Rod Adams wrote:
: Aaron Sherman wrote:
: >>Methods on numeric values (should be defined as pseudo-methods on
: >>unboxed numbers):
: >>
: >> chr
: >> hex
: >>oct
: >>
: >>
: >
: >Sigh... well, now I know what Ctrl-Return does in Evolution :-
On Thu, Mar 17, 2005 at 06:11:09PM -0500, Aaron Sherman wrote:
: =head2 Obsolete
:
: =item chop
:
: Chop removes the last character from a string. Is that no longer useful,
: or has chomp simply replaced its most common usage?
I expect chop still has its uses. Also, since $/ is
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> oct and hex are arguably misnamed, since most functions are named by
LW> what they produce, not by what they take as input. I don't know what
LW> the replacement should be, though. Maybe it's not worth fixing.
from_oct, from_hex whi
Stevan Little writes:
> my $a = 'a';
> my $b = '';
> my $c = '';
>
> my $any_of_them = $b | $c | $a;
> # this test passes
> ok('a' eq $any_of_them, '($b | $c | $a) matches at least one "a"');
>
> $b = 'b';
> $c = 'c';
>
> # this test passes ...
> ok('a' eq $any_of_them, '($b | $c | $a) matches a
Damian Conway wrote:
[No, I'm not back; I'm just passing by. But I feel that I need to
comment on this whole issue]
Thanks! This message has lots of useful information that I would have
otherwise probably missed.
It seems that the basic premise of the POD document object model gels
well with t
Larry Wall <[EMAIL PROTECTED]> wrote:
> : C I'll tackle at the same time as C. It's likely
> : staying in some form. I use it from time to time when I'm patching
> : together several automation scripts. (Remember that Perl gets used for
> : the quick and dirty as well as the big and elegant.)
>
>
Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
> LW> oct and hex are arguably misnamed, since most functions are named by
> LW> what they produce, not by what they take as input. I don't know what
> LW> the replacement should be, though. Maybe
70 matches
Mail list logo
