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 $_:
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
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 =
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
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 a
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 fact that
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
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 Czip 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
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
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 remember.
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, and
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 (Elt) and greater-
than signs (Egt). We ignore this
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
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 a hell
On Thu, Mar 17, 2005 at 11:02:47AM +0100, Juerd wrote:
: Rod Adams skribis 2005-03-16 23:16 (-0600):
: Doesn't Czip 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
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 it's
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 $self.
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.
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't
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) ==
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 it does
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
you may have to
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
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 second
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
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 detailed
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 any
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 syntax,
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 where we need to
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 aren't
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 useful,
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
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 using is the
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
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 you or
[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
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!
=
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 Crand is a standard PRNG.
Yes, absolutely. If I gave a contrary impression, I did not mean to.
I
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 three
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
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
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
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 which state
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 at least one
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
Larry Wall [EMAIL PROTECTED] wrote:
: Cdo filename I'll tackle at the same time as Ceval. 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
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 it's not worth
64 matches
Mail list logo
