Luke Palmer wrote:
My brother asked me to take out the trash. I asked him to do it.
I believe that the subject there is my brother in the first sentence
and I in the second. The topic is either to take out the trash or
just the trash throughout (English speakers wouldn't have any trouble
I¹m only an amateur linguist, but from a linguistic point of view, there are
several related terms in this space.
The term ³subject² has many meanings in English, including ³topic². But
from a grammatical and linguistic standpoint, there are only two meanings of
³subject², and ³topic² is a
Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). I wish there were more keys on my keyboard...
What is the status of my proposal to reserve the indirect object syntax
for calls on $_ and the .method form for the invocant in
I think the original (or the latest original) reason for breaking .meth from
meaning $_.meth is that $_ is transitory and there was no way back to the
nameless invocant. In the absense of having a way back, I and others
strongly advocated breaking the link. I think we hated to do it.
Now if
Paul Seamons skribis 2005-04-25 9:52 (-0600):
a way back
What is this way back you repeatedly mention?
If it is having a name for the invocant, then there has always been one:
method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}
Or, well, two:
What is this way back you repeatedly mention?
If it is having a name for the invocant, then there has always been one:
method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}
Or, well, two:
method foo {
my $self := $_;
...
Juerd wrote:
However, the discussion is about changing these simple, clear, and
useful rules to a more complex situation of choosing a default based on
what the default will be used for, making the default for methods the
invocant rather than $_. I hate those plans and would love to see the
Paul Seamons wrote:
Yes, I know there can be a way back. In this thread, none of the
examples give one using existing Perl 6 syntax. They are all proposing new
ways. This is one more.
Sorry if this sounded brash. I have a habit of not figuring out that there is
more of the message to read.
Paul Seamons wrote:
method foo {
for 1 .. 10 {
$^.method(.sqrt);
}
}
I would make that:
method foo
{
for 1 .. 10
{
.method sqrt: # $?SELF.method( $_.sqrt() )
}
}
Then usage is:
my $x = blubb;
$x.foo; # $x.method( sqrt(1) ) .. $x.method( sqrt(10) )
Iff blubb has got a
Paul Seamons skribis 2005-04-25 11:12 (-0600):
By this reasoning - why have a shortcut to any of the invocants at all? This
thread has headed in the direction of finding a way to figure out how to call
methods on the invocant without using the signatures name. On a method call
without a
Thomas Sandlaß skribis 2005-04-25 19:30 (+0200):
.method sqrt: # $?SELF.method( $_.sqrt() )
I don't like your solution simply because I don't like indirect object
calls. I avoid to and want to continue to avoid them, and do want a
short way for $_. Besides that, I think whatever default
Thomas Sandlaß skribis 2005-04-25 19:13 (+0200):
I think your basic error in perception is that $_ is a runtime variable
while the invocant(s) are more a design time assumption of what the
method is working on.
$_ is the *topic*. Its role in design and thinking is gigantic.
The funny thing is
Paul Seamons wrote:
So then, to get back to the invocant... I can't say that I liked many of the
proposals. The one that seemed to have merit though was $^. I'd propose the
following.
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the
Paul Seamons skribis 2005-04-25 13:02 (-0600):
method foo ($self:) {
return grep { $self.is_ok( .value ) } $self.info_pairs;
# .value called on the topic $_
}
I think that to be fair, you have to leave out the redundant $self
there.
return grep { $self.is_ok( .value ) }
Paul Seamons wrote:
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get confused at the need for all these
Juerd writes:
(While typing this, I realised that there may be, in English, a
difference between subject and topic. If that's true, please educate
me.)
Well, from a non-linguist's point of view, they are two very different
things.
My brother asked me to take out the trash. I asked him to
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Juerd
--
Nathan Wiger writes:
Paul Seamons wrote:
meth foo {
$_.meth; # defaults to the invocant
.meth; # operates on $_ which defaults to the invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I'm starting to get
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
definitions).
Then I
Nathan Wiger wrote:
Juerd wrote:
Nathan Wiger skribis 2005-04-25 13:35 (-0700):
My point is simply that we pick one or the other, instead of
both/aliases/etc.
But TIMTOWTDI. One way may be great for writing maintainable code, while
the other is useful in oneliners (including single line method
On Saturday 23 April 2005 14:19, Juerd wrote:
Mark A. Biggar skribis 2005-04-23 10:55 (-0700):
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea.
In that case, why even have
Larry Wall skribis 2005-04-22 18:31 (-0700):
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). I wish there were more keys on my keyboard...
Which I think would be a very bad idea, so while I can (as long as no
other decision has been made), I'm
Matt skribis 2005-04-22 21:55 (-0400):
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending replies).
Why were you just kidding? I think
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt skribis 2005-04-22 21:55 (-0400):
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
I read your message after I suggested the same thing
Matt wrote:
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt skribis 2005-04-22 21:55 (-0400):
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)
I read your message after I suggested
On Sat, 23 Apr 2005 13:55:17 -0400, Mark A. Biggar [EMAIL PROTECTED] wrote:
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea. They have a similar problems to constructs like
next 5;
Mark A. Biggar skribis 2005-04-23 10:55 (-0700):
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea.
In that case, why even have OUTER::?
I agree, though, and have always found
Matt Creenan skribis 2005-04-23 14:19 (-0400):
Hm.. didn't really think of that. Though, how often would that really
happen?
Often -- this is exactly the same problem as Python has with its
significant indenting. Move code around and you have to manually adjust
it to the new levels. The
On Sat, 23 Apr 2005 14:21:06 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt Creenan skribis 2005-04-23 14:19 (-0400):
Hm.. didn't really think of that. Though, how often would that really
happen?
Often -- this is exactly the same problem as Python has with its
significant indenting. Move code around
Personally I'd never use 3 levels or above. ..say or .say is it.
Beyond that, I would start naming the topics. Also, I would only use
..say on quick and dirty code probably.
But why are we so keen on finding a way to save a few characters isntead
of just naming the topic which leads to
Larry Wall wrote:
I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
That almost makes sense, given that $^a is like $_. It also points vaguely
upward toward some antecedent. I could maybe get used to that, if I
tried real
On Thu, 21 Apr 2005, Larry Wall wrote:
: perl -lne 'print if -e :q'
It seems to me that -e «$_» would handle most of these cases, as long as
whitespace always comes in quoted so that you always end up with one word.
I would say this is hardly the case for the kind of file lists I was
referring
On Fri, Apr 22, 2005 at 09:24:51AM +0200, Michele Dondi wrote:
: Speaking of which, I like to think of (some) adverbs in terms of cmd line
: switches, and maybe it's just me, but I think it would be extremely useful
: to have a full set of tricky ones providing reasonable defaults
:
Larry Wall skribis 2005-04-21 15:50 (-0700):
There's one minor problem with -r -w $file, which is that it evaluates
right-to-left, which is going to surprise some people who think they
want to say
-e -r $file
when they really mean
-r -e $file
It doesn't have to, of course. The test
On Fri, 22 Apr 2005 14:24:25 -0400, Juerd [EMAIL PROTECTED] wrote:
Because a URI scheme ends in :. It http: followed by anything other than
// should fail because it is invalid, not fall back to file handling.
IFF you're handling URIs.
multi sub open ($u of Str where /^mailto:\/\//, [EMAIL
On Fri, 22 Apr 2005 21:31:03 -0400, Larry Wall [EMAIL PROTECTED] wrote:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
That almost makes sense, given that $^a is like $_. It also points
vaguely
upward toward some antecedent. I could maybe get used
Anyway, is there any other URI scheme besides for mailto: that doesn't use
://?
It¹s optional for news:; news:comp.lang.perl is a valid URI for accessing that
Usenet newsgroup via whatever your default news server is.
There aren¹t any slashes in the aim: scheme (not part of the IANA
On Fri, Apr 22, 2005 at 09:09:21PM +0200, Juerd wrote:
: Matt skribis 2005-04-22 14:44 (-0400):
: We're talking about the *built-in* functions here, right?
:
: I don't know.
:
: Anyway, is there any other URI scheme besides for mailto: that doesn't use
: ://?
:
: I don't know, but if you
On Fri, 22 Apr 2005 15:09:21 -0400, Juerd [EMAIL PROTECTED] wrote:
Matt skribis 2005-04-22 14:44 (-0400):
mailto isn't something you can open really, for read at least.
No, but writing to it ought to simplify things :)
given open 'mailto:[EMAIL PROTECTED]' {
.say(q0:to.
Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). I wish there were more keys on my keyboard...
I know it's a bit counter-cultural, but at the moment I'm wondering
if we can make this work instead:
given open 'mailto:[EMAIL
On Fri, Apr 22, 2005 at 11:28:06AM +0200, Juerd wrote:
: Which brings me to the following: can open please use the same kind of
: $file, so that open $filehandle just checks $filehandle's mode and
: returns $filehandle again? That way, every library function that accepts
: a filename automatically
On Fri, 22 Apr 2005 11:42:10 -0400, Larry Wall [EMAIL PROTECTED] wrote:
You speak of open as if it must be a single function. We're now
living in the age of MMD, so what you're asking for is a no-brainer.
If we decided to we could even do MMD with constraints:
multi sub open ($u of Str where
Matt skribis 2005-04-22 14:20 (-0400):
Well why can't you define the functions like so:
Because a URI scheme ends in :. It http: followed by anything other than
// should fail because it is invalid, not fall back to file handling.
IFF you're handling URIs.
multi sub open ($u of Str where
Matt skribis 2005-04-22 14:44 (-0400):
We're talking about the *built-in* functions here, right?
I don't know.
Anyway, is there any other URI scheme besides for mailto: that doesn't use
://?
I don't know, but if you want to find this out,
http://www.iana.org/assignments/uri-schemes is
Larry Wall skribis 2005-04-22 8:42 (-0700):
multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns
Handle {...}
Though that would potentially be problematic if you wanted to open
a file whose name started with http:
open ./http://...;;
open file://$CWD/http://...;;
On Fri, Apr 22, 2005 at 05:53:48PM +0200, Juerd wrote:
: I kinda like the IO::All module, except for how it overloads and .
: my $page == io(http://www.wall.org/~larry;);
:
: IO used in this way denies that there's non-stream-based IO too.
How so? Where's the xor?
: Waiting for a
Larry Wall skribis 2005-04-22 9:47 (-0700):
: my $page == io(http://www.wall.org/~larry;);
: IO used in this way denies that there's non-stream-based IO too.
How so? Where's the xor?
Good point.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
Are the -X functions still going to be there? I definitely hope so!
However, to come to the actual question, it has happened to me to have to
do, in perl5 that is:
perl -lne 's/^//;s/$//;print if -e'
or (less often)
perl -lne '$o=$_;s/^//;s/$//;print $o if -e'
Ok: no much harm done (to my
On Thu, Apr 21, 2005 at 10:18:17AM +0200, Michele Dondi wrote:
: Are the -X functions still going to be there? I definitely hope so!
Certainly. They're useful, and one of the things people love about Perl.
In fact, we're enhancing them to be stackable, so you can say
if -r -w -x $filename
On Thu, Apr 21, 2005 at 06:40:54PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-21 8:54 (-0700):
: if $filename ~~ -r -w -x {...}
:
: Just curious - would the following dwym?
:
: if (prefix:-r prefix:-w prefix:-x)($filename) { ... }
It might do what you mean. Personally, I
51 matches
Mail list logo
