invocant vs. topic (was: Re: -X's auto-(un)quoting?)

2005-04-26 Thread Thomas Sandlaß
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

Re: invocant vs. topic (was: Re: -X's auto-(un)quoting?)

2005-04-26 Thread Mark Reed
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

goto, enter, leave, etc. (Was: Re: -X's auto-(un)quoting?)

2005-04-25 Thread Thomas Sandlaß
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Paul Seamons
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
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:

Re: -X's auto-(un)quoting?

2005-04-25 Thread Paul Seamons
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 := $_; ...

Re: -X's auto-(un)quoting?

2005-04-25 Thread Thomas Sandlaß
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Paul Seamons
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.

Re: -X's auto-(un)quoting?

2005-04-25 Thread Thomas Sandlaß
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Paul Seamons
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
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 ) }

Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Luke Palmer
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Juerd
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 --

Re: -X's auto-(un)quoting?

2005-04-25 Thread Luke Palmer
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Nathan Wiger
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

Re: -X's auto-(un)quoting?

2005-04-25 Thread Rod Adams
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

Re: -X's auto-(un)quoting?

2005-04-24 Thread John Macdonald
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Nigel Hamilton
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Matt
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Mark A. Biggar
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Matt Creenan
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;

Re: -X's auto-(un)quoting?

2005-04-23 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Matt Creenan
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Brano Tichý
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

Re: -X's auto-(un)quoting?

2005-04-23 Thread Rod Adams
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Michele Dondi
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Larry Wall
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 :

Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Matt
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Matt
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Mark Reed
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Larry Wall
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Matt
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.

Re: -X's auto-(un)quoting?

2005-04-22 Thread Mark A. Biggar
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Larry Wall
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Matt
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
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://...;;

Re: -X's auto-(un)quoting?

2005-04-22 Thread Larry Wall
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

Re: -X's auto-(un)quoting?

2005-04-22 Thread Juerd
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

Re: -X's auto-(un)quoting?

2005-04-21 Thread Larry Wall
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

Re: -X's auto-(un)quoting?

2005-04-21 Thread Juerd
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 seems to me that -e «$_» would handle most of these cases, as long as whitespace always comes in quoted so

Re: -X's auto-(un)quoting?

2005-04-21 Thread Larry Wall
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