invocant vs. topic (was: Re: -X's auto-(un)quoting?)
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
allowing it to be both).
Let me translate that to my understanding of Perl6:
method Brother::ask( $object ) # $?SELF .does Brother
{
$_ = please, take out the trash.; # definition of it
$object.ask; # invocant asks object to do it
}
method ask # $?SELF .does Any
{
caller.ask; # invocant asks caller to do it (or is the syntax
caller.self.ask?)
}
my Brother $brother; # declaration needed to dispatch to Brother::ask
$brother.ask( $luke ); # brother asks luke to take out the trash
At runtime the call chain either runs into an undefined object error
in the second invocation of Brother::ask or an endless loop of
invocations of the second method is spawned with alternating callers.
Or, I'm off-topic ;)
PS: We all know that trash doesn't take itself out.
So, $_.ask is pointless :)
--
TSa (Thomas Sandla)
Re: invocant vs. topic (was: Re: -X's auto-(un)quoting?)
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 distinct term. One meaning of ³subject² is specific to the grammar of a given language, such as English, in which we have ³subjects² and ³objects². The more general linguistic term is usually capitalized (³Subject²) and even more usually abbreviated as ³S²; it refers only to what we call the subject of an intransitive verb. What we call the subject of a transitive verb is more generally called the ³Agent², or ³A², and what we call the direct object of a transitive verb is more generally called a ³Patient², or ³P². Different languages group S, A, and P differently in how they are treated by the grammar; English, like most European languages, lumps S and A together and separates P; such languages are called ³nominative-accusative² (or just ³accusative²) languages. Then you have ³topic² and ³focus², which are closely related. Basically, the focus is the main thing that you¹re talking about in a given sentence, and is usually introduced by that sentence. The topic is a known quantity under discussion. So you frequently have the focus of one sentence which may or may not be its subject - being the topic for subsequent discussion. Example: A) I went to the game yesterday. B) While there, I saw Smoltz strike out 15 batters. The grammatical subject of sentence A is ³I², and it is actually a Subject in SAP terms. But the focus is the game. The definite article implies that the listener knows which game is being discussed, but it¹s still being introduced as a new element here. If there is a topic, we don¹t know what it is. The grammatical subject of B is still ³I², but this time it¹s an Agent; the Patient is an action (Smoltz striking out 15 batters), and that action is also the focus. But the topic is the game.
goto, enter, leave, etc. (Was: Re: -X's auto-(un)quoting?)
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 (single)methods?
Thus .method *always* expands to $?SELF which of course isn't available
outside of method definitions.
This postfix colon call syntax has to go with a new syntax for landing sites
into code positions like we have goto for jumping out. I proposed to call
the goto partner 'land' but it could also be the enter function which
defines the entry points into a block, calling the ENTER blocks if
coming from the outside or so. Typical entry points that come to mind
are before/after parameter (type) check. BTW, does goto call all LEAVE
blocks that are left and all ENTER blocks that are entered? If not all,
which ones are picked?
Then the example becomes
given open 'mailto:[EMAIL PROTECTED]' {
say: (...); # space needed to avoid say:(...) syntax?
close: or fail; # or even 'close or fail'
}
This postfix colon syntax is basically needed only if a different entry
point into the dispatch of e.g. close shall be taken. A plain close starts
from MMD, while close: starts from namespace scoped single dispatch on $_
and fails over to MMD. Either syntax '$_.close' and 'close $_:' is already
valid and both need more chars when interpolated: $_.close() or {$_.close}
and {close $_:}.
But some whitespace rules are needed to disambiguate
method: option; #1
from
method :option; #2a
and
method:option; #2b
Case #1 calls method on $_ with the return value of option,
while cases #2 call method with adverbial modifier option set
to true.
A nice extension that also saves the trailing ; is to say that
a single indirect method call in a line autoterminates or some such.
I mean to warp the postfix colon indirect object syntax into doing
double duty as statement separator. Well, actually the
semicolon is half a colon in that respect :)
Then we get:
given baz()# $_ := baz() or with temp?
{
bar:# $_.bar()
blubb: # $_.blubb()
whatever: # $_.whatever()
}
and
method foo()# foo( $?SELF: )
{
.bar;# $?SELF.bar()
.blubb; # $?SELF.blubb()
.whatever; # $?SELF.whatever()
}
and combined:
method foo()# foo( $?SELF: )
{
# given foo() works syntactically but could recurse infinitly
given baz() # temp $_ := baz()
{
.bar; # $?SELF.bar()
blubb: # $_.blubb()
.whatever: # MMD whatever( $?SELF, $_: )
}
}
BTW, are the two method examples valid without a surrounding class scope?
I think it's not strictly needed because foo would be added to class Any.
Hmm, this would also produce:
$obj.method $foo, $bar: $x, $y, $z;
to mean
method( $obj, $foo, $bar: $x, $y, $z );
and of course
$obj.method: $x, $y, $z;
means
method( $obj, $_: $x, $y, $z );
--
TSa (Thomas Sandlaß)
Re: -X's auto-(un)quoting?
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 we can introduce another way back so that we can always get to the
invocant if we want to, then I'd say lets leave .meth always working on $_ .
It does have beauty and simplicity.
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 invocant
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
for 1 .. 10 {
$_.say; topic of for
.say; # use $_
$^.say; # stringifies invocant 1
$^1.say; # stringifies invocant 1
$^2.say # stringifies invocant 2
}
}
The rules then are simple. .meth always operates on $_. $_ is always the
current topic. $_ defaults to the invocant of the method. $^1 refers to the
first invocant. $^ is an alias for $^1. $^n refers to the nth invocant.
Nice and simple. No conflict with existing naming conventions.
Paul
Re: -X's auto-(un)quoting?
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:
method foo {
my $self := $_;
...
}
Three, even:
method foo {
my $self = \$_;
for (1..10) {
$$self.method(.sqrt)
}
}
And probably even more. TAMT0WTDI! :)
Now if we can introduce another way back so that we can always get to the
invocant if we want to, then I'd say lets leave .meth always working on $_ .
It does have beauty and simplicity.
Agreed!
$^.meth; # is the invocant
$^1.meth; # is the first invocant
$^2.meth; # is the second invocant
I don't understand the concept of multiple invocants. How does that
work?
$^ as an alias for the invocant works for me, because sorts before
anything else, and the invocant's just the 0th argument.
The rules then are simple. .meth always operates on $_. $_ is always the
current topic. $_ defaults to the invocant of the method.
Yes! The problem isn't that this hasn't already been thought of -- it is
the current spec even.
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
current spec, that is as you decribe above, implemented in the final
version.
(Or well, I believed this was the spec until I tried finding it. I can
find the stuff about .method defaulting to $_ in S12, but $_ being an
alias for the invocant is harder to find.)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 := $_;
...
}
Three, even:
method foo {
my $self = \$_;
for (1..10) {
$$self.method(.sqrt)
}
}
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 signature and without invoking Perl5isms there would not be a way
back to the invocant once you enter nested block.
The point of all of this discussion is to not have to set $self to anything.
The argument for .meth as opposed to $self.meth of $_.meth was that .meth was
clear enough to mean the current topic and was a nice huffmanization.
method foo ($self:) {
for (1..10) {
$self.method(.sqrt)
}
}
That works great - so long as I specify the signature. I'm lazy, I don't want
to type the signature all the time. Consider:
method foo {
for 1 .. 10 {
$^.method(.sqrt);
}
}
Still pretty readable. I kind of like $^1 too which seems to behave like
$^variable quite nicely. I guess that $^1 should actually be $^0 so that we
are properly zero indexed. At this point - it sort of looks like Perl5's
$_[0] except now $^0 is just an alias and and it gets all of the attributes
given by the signature (should a signature be given) - plus we don't have to
deal with the [EMAIL PROTECTED] array.
Or, well, two:
method foo {
my $self := $_;
...
}
If I didn't like typing the signature - why would I want to type all of that
code to bind the variable? I'm lazy. The signature wouldv'e been shorter.
That looks Perl5ish.
Three, even:
Same argument as the last with a different aliasing.
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.
Paul
Re: -X's auto-(un)quoting?
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 current spec, that is as you decribe above, implemented in the final version. 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. Perl6 has invented the notion of topic as a global lexically scoped variable that is orthogonal to the invocant and non-invocant parameters of (multi) methods. We have two distinct names for these two concepts: $_ and $?SELF. Additional multi method invocants need names anyway. E.g. in methods of GUI classes the invocant would be the selected widget and the topic the event. (Or well, I believed this was the spec until I tried finding it. I can find the stuff about .method defaulting to $_ in S12, but $_ being an alias for the invocant is harder to find.) My reading is that the two concepts have developed concurrently and only recently some pitfalls were identified when they are combined. -- TSa (Thomas Sandlaß)
Re: -X's auto-(un)quoting?
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.
Juerd wrote:
$^ as an alias for the invocant works for me, because sorts before
anything else, and the invocant's just the 0th argument.
Didn't see that in your response - I responded to the first topic section but
failed to see there was another.
Juerd wrote:
I don't understand the concept of multiple invocants. How does that
work?
If my ability to parse the Synopses was very good, I'd tell you where I saw
mention of it - or maybe it was in the mailing list. Either way that is the
point of the colon in the:
method foo ($self: $arg1, $arg2) {}
So that in theory there would be
method foo ($self, $otherself: $arg1, $arg2) {}
In the end, I'd just like the rules for what .meth does and what $_ is to be
concise and clear - whatever the sytax is that is adopted.
Paul
Re: -X's auto-(un)quoting?
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 method .method that takes a Num as param ;)
--
TSa (Thomas Sandlaß)
Re: -X's auto-(un)quoting?
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 signature and without invoking Perl5isms there would not be a way back to the invocant once you enter nested block. The point of all of this discussion is to not have to set $self to anything. The argument for .meth as opposed to $self.meth of $_.meth was that .meth was clear enough to mean the current topic and was a nice huffmanization. Agreed, but you put it as if there was no way of getting there, instead of there being a way that isn't satisfactory. I agree that having a short way to use the invocant is good, and like your $^ proposal. I still don't understand what the second invocant could be, though. Another character that has no prefix meaning yet is . are a bit overused already, but perhaps this can fit in. It has the benefit of being shift+dot on a US keyboard :P That works great - so long as I specify the signature. I'm lazy, I don't want to type the signature all the time. Consider: When will people realise that this problem is exactly the same thing as what you get when two other topicalizers are nested, and TREAT it like exactly the same problem, so that a solution can be invented that solve both problems in one stroke. This said, I really do think the ^ thing is nice. But if you really think not having a short syntax to reach something in a higher level block is a problem, then be consistent and declare nested given/for blocks a problem too. The current invocant problem is really not that much different from the outer topic problem, or, in larger scope, the outer block problem, which is solved with labels. outer topic problem name it, or use OUTER:: outer block problem name it (label it) invocant problemname it! or use $?SELF The same problem comes up whenever things can nest. So I'm more or less expecting discussion about outer rule problem outer class|grammar problem (?) parent process %ENV problem (learn to live with it) parent object problem (familiar...) Whether or not naming it is the answer in every occassion is a good question. Probably when dealing with parent stuff, it is not, because we want those things to be anonymous more often than the other things. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 is chosen should be consistently applied to both syntaxes. Of course, the same consistency prescripbes that $_ be that default... Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 that in this way, the invocant is just that: being important for design and thinking, and that makes it... a topic. Following this, considering the topic and the invocant the same thing works. Until you temporarily change the topic, which means that if you want the previous topic, you have to be more specific when referring to it. This is consistent with natural languages as well. Having two topics, one for the short stuff ($_, sentence) and one for the long stuff ($self, paragraph) makes sense too. I recall having read that Japanese had something like that. But making the default thing you're referring to anything but the most recent (in programming: innermost) topic, is madness. (While typing this, I realised that there may be, in English, a difference between subject and topic. If that's true, please educate me.) E.g. in methods of GUI classes the invocant would be the selected widget and the topic the event. In my thinking, the event would not be named, because it is not something you operate on. Events just happen - it should be the name of the method, and the code inside should very rarely need that information (except when needed to call a supermethod, for example). The event being the topic makes sense only if all events are handled by the same method, in which you use a dispatch table. But OO itself is a pretty neat dispatching machine already. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 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 special
variables. I vote that we steal from prior art in numerous other
languages and just auto-set $SELF or $THIS or whatever and call it done.
Having .method assume $SELF is an added nicety, but if it introduces
added parsing problems then it's hardly worth it.
OR, choose $^ and don't set $SELF (or $?SELF or whatever), but having
dup short and long names is a waste, since people will always chose the
short one (who uses English in Perl 5, really?)
-Nate
Re: -X's auto-(un)quoting?
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 ) } .info_pairs;
Proposed syntax in this thread (among various others)
method foo {
return grep { $^.is_ok( .value ) } $^.info_pairs;
# .value called on the topic
}
I think that also wanted:
method foo {
return grep { ^is_ok( .value ) } ^info_pairs;
# .value called on the topic
}
That is the goal - to find some nice variable that looks vaguely usable and
that people won't rebel against using.
Variable or alternative for the dot.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 special
variables. I vote that we steal from prior art in numerous other
languages and just auto-set $SELF or $THIS or whatever and call it done.
The problem is that there is no globally safe name to use that uses letters
only. Also there is a certain line noise problem (which may not really be a
problem - but looks like one once we have a more concise alternative):
I understand the purported problem, but what I'm saying is that it
really isn't one. Variables magically coming into existence doesn't seem
to be a problem for any language but Perl 6. Many other languages set
this automagically.
method foo {
$SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
$SELF.say(Hello ~ $SELF.prop);
}
I'm not sure the point of this block; it's hardly horrific. Any external
script would have to say:
$invocation = new Class;
$invocation.meth($invocation.get_foo, $invocation.get_bar);
If the point is that $^ saves typing over $?SELF then I agree; my point
is simply that we pick one or the other, instead of both/aliases/etc.
-Nate
Re: -X's auto-(un)quoting?
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 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 allowing it to be both). Interesting, this is the same kind of reasoning (and backwards naming) that I used when I proposed ` as the subjective dot. Speaking of such a dot, there are things I like about ^ and things I don't. It is fairly visually intrusive on the one hand. On the other, it's on the top of the line rather than the bottom, which makes a nice contrast from the regular dot. As alternatives, Damian has suggested meth(), and I've suggested meth(). They both look wrong. I'm not even sure we're on the right track, changing the dot (changing the dot also includes Thomas's proposal: his dot is just postfix). I do think that considering the distinction between subject and topic is important to getting it right, however. Luke
Re: -X's auto-(un)quoting?
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 -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 confused at the need for all these special
variables. I vote that we steal from prior art in numerous other
languages and just auto-set $SELF or $THIS or whatever and call it done.
The problem is that there is no globally safe name to use that uses
letters only. Also there is a certain line noise problem (which may not
really be a problem - but looks like one once we have a more concise
alternative):
I understand the purported problem, but what I'm saying is that it
really isn't one. Variables magically coming into existence doesn't seem
to be a problem for any language but Perl 6. Many other languages set
this automagically.
method foo {
$SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
$SELF.say(Hello ~ $SELF.prop);
}
I'm not sure the point of this block; it's hardly horrific.
I think it is. It's obviously a matter of taste. But all those $SELFs,
in my opinion, really take away from the meaning of the code. I loathe
reading such Perl 5 OO code, for precisely the same reason. We already
have a shorthand (which is an only-hand in some cases) for accessing
attributes:
method foo {
$.prop = $self.meth($.foo, $.bar);
$self.say(Hello $.prop);
}
And it seems natural to go for methods too, especially since attributes
are allowed just to be fancy methods.
I have always wondered what would happen if we blurred the distinction
altogether. It's tricky, because you need direct access to implement
accessors. But since variables for which accessors are not
automatically generated are already marked as $:, perhaps it is an
option:
class Point {
has $.x is rw;
has $.y is rw;
has Pdl $:coords;
method set_coords(Pdl $new) {
($.x, $.y) = ($new $:coords.inverse Pdl.new($.x, $.y)).list;
$:coords = $new;
}
method swap_coords() {
$.set_coords(Pdl([0, 1; 1, 0])); # calls a method with $. syntax
}
}
Luke
Re: -X's auto-(un)quoting?
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 suggest use English for Perl 6 too. I think you'll find that,
like Perl 5, people always use the short forms.
Has ANYONE on this list ever done something like this?
use English;
if ($OSNAME =~ /MSWin32/) {
$OUTPUT_AUTOFLUSH++;
local $WARNING = 0;
print Windoze\n or die Can't print: $OS_ERROR;
}
I'd bet everyone would write that as:
if ($^O =~ /MSWin32/) {
$|++;
local $^W = 0;
print Windoze\n or die Can't print: $!;
}
Crap, I had to open the Camel just to find the long names. :-)
-Nate
P.S. I know this is the first time I've spoken up on Perl 6
in 5-ish years, so nice to see you all once again
Re: -X's auto-(un)quoting?
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
definitions).
Then I suggest use English for Perl 6 too. I think you'll find that,
like Perl 5, people always use the short forms.
Has ANYONE on this list ever done something like this?
use English;
if ($OSNAME =~ /MSWin32/) {
$OUTPUT_AUTOFLUSH++;
local $WARNING = 0;
print Windoze\n or die Can't print: $OS_ERROR;
}
Not exactly a fair comparison, since it's common to not use English
due to the $ issue.
I suspect that if that was not the case, it would be used more.
-- Rod Adams
Re: -X's auto-(un)quoting?
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 OUTER::? Referring to something by relative position is great when refactoring will not change the relationship. If you refactor the enclosing context, whatever context is wrapped around me is changed by refactoring in the right way; while that specific thing that is 2 levels out (at the time I wrote this code) is changed in the wrong way, because the specific context you want to refer to may now be 1 or 3 or 50 levels out.
Re: -X's auto-(un)quoting?
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 using the current syntax :) I even consider breaking compatibility with bare Perl 6, for my grammar, if that's necessary to get .foo to use the same implicit LHS as .[5]. Subs and loops are related, and aliasing the invocant as $_ the same way a loop aliases the loop variable as $_ makes sense to me. when you use a loop within a sub, do the same thing as when you use a loop within another loop: explicitly use the full name, or use OUTER::. We do, after all, have better ways of declaring private methods and functions now. so maybe we don't need to reserve _ for that anymore. I was planning on using prefixed underscore for macros that slurp up till the end of a line, so syntax highlighting could be adjusted for those things that would otherwise break. With non-underscore, I'd have to use a litter, or make my macro a prefix operator, which is more work. And it would save two characters over $_.foo(). But recovering C programmers will scream, and probably prefer _.foo(), even if it only saves one character. _ on my keyboards is two keys, shift and -, while . is only one. In fact, I find $_.foo even easier to type than _.foo, and better looking. Especially because the $ sigil is part of the name now, _ without sigil should not be used. Maybe it's time to raid Latin-1 for the next closest thing to a dot, middle dot: ·say(...); ·close or fail; Please, no. But I'm sure some will argue that's too subtle. (Hi, @LarryDamian.) String index for an array? say¹(...); close¹ or fail; Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo(). For that matter, I think repeating prefixed dots works just as well: .foo# $_.foo ..foo # $OUTER::_.foo # OUTER::$_.foo ...foo # $OUTER::OUTER::_.foo # OUTER::OUTER::$_.foo This shouldn't clash with yada, I think. (In the case it does (why would it?), adding parens is an obvious way to break ambiguity: (...).) Yes, especially the c: scheme. :-) I have no pity for Win32 users :) For all I care, they can use file:///c|/... or the awful MSIE variant file://c:\foo\bar. But I guess it's safe to treat single-letter schemes as Win32/DOS volumes, as there are no single-letter URI schemes. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 replies). Why were you just kidding? I think it's a great idea. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 it's a great idea. I like it too. In normal writing ... acts as a kind of 'think back' operator. Even though the writer uses it to signal an afterthought - it also makes the reader 'think back' to what preceded the afterthought. Syntax like .say ..say ...say enables the writer to add an afterthought and the reader to 'think back' to precisely the right scope. It allows you to have N scopes too .say, that would be cool. I hope this doesn't cause trouble for yada yada because I really like that operator too. Nige
Re: -X's auto-(un)quoting?
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 (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. Juerd Well I like it too. I just didn't think anyone would actually go for it. I guess I underestimated how crazy you guys are ;)
Re: -X's auto-(un)quoting?
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 the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. Well I like it too. I just didn't think anyone would actually go for it. I guess I underestimated how crazy you guys are ;) 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; meaning jump to the next iteration of the loop 5 level out. Any time you refactor you code and change levels, they break in a subtle and very hard to debug way, causing mysterious errors. Just like the current Perl construct of labeled loops so that you can talk about the target loop explicitly, the proper solution for up-level access to $OUTER::OUTER::...::OUTER::_ is to create a named binding like $uplevel_topic := $_; at that upper level and then use that to refer to it at lower levels. Beside is ...foo(); seven of eight levels up? Any other way than explicit naming is madness; leading to unreadable and unmaintainable code. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: -X's auto-(un)quoting?
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; meaning jump to the next iteration of the loop 5 level out.
Any time you refactor you code and change levels, they break in a
subtle and very hard to debug way, causing mysterious errors. Just like
the current Perl construct of labeled loops so that you can talk about
the target loop explicitly, the proper solution for up-level access to
$OUTER::OUTER::...::OUTER::_ is to create a named binding like
$uplevel_topic := $_; at that upper level and then use that to refer
to it at lower levels. Beside is ...foo(); seven of eight levels
up? Any other way than explicit naming is madness; leading to
unreadable and unmaintainable code.
Hm.. didn't really think of that. Though, how often would that really
happen? You can just explicility refer to the topic if you refactor. So
long as there is another way, I'm not sure that problem constitutes not
putting in such a shortcut.
I do see this as a being a bit confusing though:
given open 'file a' {
given open 'file b' {
given open 'file c' {
.say(...);
..say(...);
...say(...);
}
}
}
Doesn't that just encourage writing confusing code? Also, does anyone
else initial read it as doing say on file a first, then b, then c; instead
of c, b, a?
Re: -X's auto-(un)quoting?
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 this, that using the full name
(binding one if it doesn't have one already) is the better solution.
given returns_object() - $foo {
when SomeClass { ... }
}
I think we all agree that smart match (implied by when) should work on
$_. The following is consistent with the above:
method ($foo: @bar) {
when SomeClass { ... }
}
Only the first line changes, and everything still works as expected.
The same would work very well for method calls:
method ($foo: @bar) {
.method;
}
I would expect that if we change the first line back (less academically,
copied and pasted the code elsewhere), it would still work on the same
thing.
given returns_object - $foo {
.method;
}
The block passed to given aliases the first argument to $_. Methods
should do the same. And I really beleave that using a : to separate
instead of , does not make the invocant any less the first argument.
They have a similar problems to constructs like next 5; meaning jump
to the next iteration of the loop 5 level out.
Yes, that's ugly.
Any time you refactor you code and change levels, they break in a
subtle and very hard to debug way, causing mysterious errors.
Same thing for having one thing default to $_ and another to $self, in a
way. If everything defaults to $_, which may or may not be the same
thing as $self, things become more predictable, and you can when
refactoring just copy the body of a loop to a new method without
breaking it.
Just like the current Perl construct of labeled loops so that you
can talk about the target loop explicitly, the proper solution for
up-level access to $OUTER::OUTER::...::OUTER::_ is to create a named
binding like $uplevel_topic := $_; at that upper level and then use
that to refer to it at lower levels.
Indeed. Fortunately, many built in constructs involving blocks that get
arguments already set up that binding for you.
Beside is ...foo(); seven of eight levels up?
A rather irrelevant question, IMHO. It is as irrelevant as the similar
Is 5521243 approximately .5 million or 5.5 million?, because just as
you can write 5_521_243 to make the number more clear, you could write
... ... .foo();
to show it's 7 dots.
Any other way than explicit naming is madness; leading to unreadable
and unmaintainable code.
Not if implict naming (completely implicit, that is, so without any
indication of level even) is consistent in what it means. Currently,
things default to $_ in almost every place where a value is needed but
left out. I'd hate to see that change to some other variable for only a
portion of the operations now defaulting to $_.
Automatic binding of the invocant as $_ and the possibility to provide
your own name for the thing (either by specifying it in the signature or
by explicitly using the := operator) makes that .method defaulting to
working on $_ is not a problem.
A method's block shouldn't be too different from a given's block, or any
other closure for that matter. They should both topicalize using the
same semantics, IMO.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 problem with ..foo is less apparent because you're likely to copy all the levels at once, and it's relative rather than absolute. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 and you have to manually adjust it to the new levels. The problem with ..foo is less apparent because you're likely to copy all the levels at once, and it's relative rather than absolute. Juerd 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 more readble code? If it's not self-descriptive, I think it does more harm than good.
Re: -X's auto-(un)quoting?
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 more readble code? If it's not self-descriptive, I think it does more harm than good. then how about alias $OUTER::_ with $__ as a special exception? it looks familiar (maybe too much), but as it would be used in quick and dirty code, there wouldn't be that much $_ to confuse it with. or is $__ already taken? brano tichy [EMAIL PROTECTED]
Re: -X's auto-(un)quoting?
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 hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
I like this.
Only I'd have C .foo means C $_.foo and C ^foo mean C
$self.foo , assuming $self is the first invocant.
Why swap them? because $_ is known for performing magical disappearing
acts all over the place, and the ^ ties in with the $^x of parameters.
As for shortcuts to $OUTER::_, perhaps $-, if it's not put to some
better usage, but anything beyond that is getting too obscure for common
usage.
-- Rod Adams
Re: -X's auto-(un)quoting?
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 to. Not that this is terribly relevant from a world wide perspective, I guess... That seems more general than a special option to -X ops. 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 (user-overridable, of course), short enough to be easy to type; e.g: unlink :warn; # roughly equivalent to Perl5's # unlink or warn Could not remove `$_':$!\n; Michele -- Whoa! That is too weird! I asked around among the math faculty here and it turns out that _every one's_ wife is married to a mathematician! - Dave Rusin in sci.math, Re: Genetics and Math-Ability
Re: -X's auto-(un)quoting?
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 : (user-overridable, of course), short enough to be easy to type; e.g: : : unlink :warn; # roughly equivalent to Perl5's : # unlink or warn Could not remove `$_':$!\n; The problem with that approach is also evident in Unix culture. How many different ways are there to ask for help, or to get verbose output, or to specify the output filename? How many different ways are there to specify input and output delimiters? -e means something very different to Perl than to rpm. Does this version of chown use -r or -R for recursion? Admittedly, some of these problems would have been reduced if Unix had gone with long option names to begin with. But a lot of these problems come from too many people in too many places inventing too many similar things without the benefit of a culture that encourages a common standard without forcing one. In Perl culture we must guard against the extremes of central control vs anarchy, and choose a middle path. And some of these things can be headed off by designing the interface differently. We wouldn't need a recursion option on chmod/chown/cp etc. if Unix had a notation for all the files under this one. Similarly, if Perl has consistent warning and exception mechanisms that are easy to use and properly scoped, people are less tempted to make up one of their own. All that being said, we did design named parameters into Perl 6 so that an interface could have options. But people are quick to add options without thinking about the global consequences of name choice. I feel like there's a cultural solution there somewhere, but I don't know what it is, because that's the sort of thing cultures are better at inventing than I am. :-) Larry
Re: -X's auto-(un)quoting?
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 can be postponed and delegated
to the lexical first -X operator. A matter of letting -X behave
differently in -X context than in any other context, I guess.
Now the interesting thing about the ~~ approach is that it naturally
lends itself to
given $file {
when :x {...}
when :r:w {...}
when :r(0) {...}
when :u | :g{...}
default:
}
I suppose it's a little bit rude to grab all the pairs for testing
against all the strings, so maybe we have to say
given $file.test {...}
$file.test ~~ :r:w
or maybe
given $file.stat {...}
$file.stat ~~ :r:w
Perfect!
BTW, I'm assuming the $file is either $filename or $filehandle there.
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 also accepts an open filehandle, which has a
thousand and one benefits.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 PROTECTED])
returns
Handle {...}
Well, it's mailto:[EMAIL PROTECTED], not mailto://[EMAIL PROTECTED]
True, I did not think of that. But it can at least be defined for most
URI schemes to check for ://, in the case of HTTP, FTP, etc.
We're talking about the *built-in* functions here, right?
Anyway, is there any other URI scheme besides for mailto: that doesn't use
://? mailto isn't something you can open really, for read at least.
If it's for built-in, then only the most common protocols would be defined
I imagine. The ones I can think of that you can read from/stream in use
://, so I don't see why the methods for those protocols can't be defined
with ://. Maybe I'm missing something here though.. which does happen a
lot ;)
Also, I don't know much about rules with regex yet, but could you do
something like...
multi sub open ($u of Str where /protocol(file)/, [EMAIL PROTECTED])
returns
Handle {...}
Where protocol(file) expands to file://
Yes, but it's probably easier to just use a hash: %protocolfile.
Easier or more efficient?
Re: -X's auto-(un)quoting?
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 to that, if I
tried real hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
I think ^ makes the most sense. I like how it points up. Like it's
saying HEY! THE TOPIC IS UP THERE!
Though, it IS still a bit odd. It seems more like a modifier on the
function, than a reference to the topic.
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!)
Re: -X's auto-(un)quoting?
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 standard, but widely supported for accessing AOL-compatible IM clients from web browsers). There are no slashes in tel: (telephone numbers), though I don¹t know what you could do with those from Perl. :) And I¹m sure there are others. The syntax after the colon is pretty much arbitrarily determined by the scheme prefix, so a global constraint on it is a bad idea. -Mark
Re: -X's auto-(un)quoting?
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 want to find this out,
: http://www.iana.org/assignments/uri-schemes is probably a good starting
: point.
:
: 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.
: Subject: Useful mailto open
: User-Agent: Perl 6
: In-Reply-To: [EMAIL PROTECTED]
:
: Hello, world!
: .
: );
: .close or fail;
: }
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 PROTECTED]' {
_say(...);
_close or fail;
}
We do, after all, have better ways of declaring private methods and
functions now. so maybe we don't need to reserve _ for that anymore.
And it would save two characters over $_.foo(). But recovering C
programmers will scream, and probably prefer _.foo(), even if it only
saves one character. Maybe it's time to raid Latin-1 for the next
closest thing to a dot, middle dot:
given open 'mailto:[EMAIL PROTECTED]' {
·say(...);
·close or fail;
}
But I'm sure some will argue that's too subtle. (Hi, @LarryDamian.)
Well, hey, as long as we're looking at Latin-1, we could use superscripts
to indicate nested topic defaults.
given open 'mailto:[EMAIL PROTECTED]' {
say¹(...);
close¹ or fail;
}
Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
Or we go back to .foo always meaning $_.foo and use ¹.foo to call the
first invocant, ².foo to call the second, ³.foo to call the third.
Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds
if we didn't autobox literal numbers. Though that would put a crimp
in the Rubyish
3.times:{ say It's true! }
Okay, that's kinda nuts. How 'bout we change ! to ¬ and then we can
say:
given open 'mailto:[EMAIL PROTECTED]' {
!say(...);
!close or fail;
}
Sigh. We could also take ` away from user-defined literals and say
given open 'mailto:[EMAIL PROTECTED]' {
`say(...);
`close or fail;
}
But I rather like ` for user-defined literals. 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 hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
: If it's for built-in, then only the most common protocols would be defined
: I imagine.
:
: No, if it's built in, we should stick to the spec and interpret every
: ^\w+: (roughly - see RFCs for syntax specifics) as a scheme.
Yes, especially the c: scheme. :-)
Larry
Re: -X's auto-(un)quoting?
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.
Subject: Useful mailto open
User-Agent: Perl 6
In-Reply-To: [EMAIL PROTECTED]
Hello, world!
.
);
.close or fail;
}
Good point, I didn't think of that :) That would be awesome if you could
do that in perl6 without needing any extra libraries.
What about ftp?
given open 'ftp://user:[EMAIL PROTECTED]:port' {
.say(q0:USER username
PASS password
);
.close or fail;
}
Though I'm not sure exactly how the FTP protocol works :)
Re: -X's auto-(un)quoting?
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 PROTECTED]' {
_say(...);
_close or fail;
}
We do, after all, have better ways of declaring private methods and
functions now. so maybe we don't need to reserve _ for that anymore.
And it would save two characters over $_.foo(). But recovering C
I kind of like that, but see below.
programmers will scream, and probably prefer _.foo(), even if it only
saves one character. Maybe it's time to raid Latin-1 for the next
closest thing to a dot, middle dot:
given open 'mailto:[EMAIL PROTECTED]' {
·say(...);
·close or fail;
}
But I'm sure some will argue that's too subtle. (Hi, @LarryDamian.)
I agree, too subtle.
Well, hey, as long as we're looking at Latin-1, we could use superscripts
to indicate nested topic defaults.
given open 'mailto:[EMAIL PROTECTED]' {
say¹(...);
close¹ or fail;
}
Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
Or we go back to .foo always meaning $_.foo and use ¹.foo to call the
first invocant, ².foo to call the second, ³.foo to call the third.
Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds
if we didn't autobox literal numbers.
Given I like _.foo(), we can get around the autobox problem by using
_2.foo(), _3.foo, etc. Even though those are legal(?) variable names
I've never seen them used in code anywhere.
But I rather like ` for user-defined literals. I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
This kind of works also. And it would allow ^2.foo(), ^3.foo(), etc. or
even ^^.foo(), ^^^.foo(), etc (nah!).
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 hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
Too late, maybe.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: -X's auto-(un)quoting?
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 also accepts an open filehandle, which has a
: thousand and one benefits.
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 /^file:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^ftp:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^mailto:/, [EMAIL PROTECTED]) returns
Handle {...}
...
Though that would potentially be problematic if you wanted to open
a file whose name started with http:, so we'd probably want to
give that suite of multis a different name. Call it io() maybe, if
we can unify the Handle and IO abstractions. As I've said before,
I kinda like the IO::All module, except for how it overloads and .
But Perl 6 has == and == that can do that instead, which just happen
to be called pipes, strange coincidence. :-)
Presumably you can write a slurp like this:
my $page == io(http://www.wall.org/~larry;);
Larry
Re: -X's auto-(un)quoting?
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 /^file:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^http:/, [EMAIL PROTECTED]) returns Handle
{...}
multi sub open ($u of Str where /^ftp:/, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^mailto:/, [EMAIL PROTECTED]) returns Handle
{...}
...
Though that would potentially be problematic if you wanted to open
a file whose name started with http:, so we'd probably want to
give that suite of multis a different name. Call it io() maybe, if
we can unify the Handle and IO abstractions. As I've said before,
I kinda like the IO::All module, except for how it overloads and .
But Perl 6 has == and == that can do that instead, which just happen
to be called pipes, strange coincidence. :-)
Well why can't you define the functions like so:
multi sub open ($u of Str where /^file:\/\//, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^http:\/\//, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^ftp:\/\//, [EMAIL PROTECTED]) returns Handle {...}
multi sub open ($u of Str where /^mailto:\/\//, [EMAIL PROTECTED]) returns Handle
{...}
Also, I don't know much about rules with regex yet, but could you do
something like...
multi sub open ($u of Str where /protocol(file)/, [EMAIL PROTECTED]) returns
Handle {...}
Where protocol(file) expands to file://
Re: -X's auto-(un)quoting?
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 /^mailto:\/\//, [EMAIL PROTECTED])
returns
Handle {...}
Well, it's mailto:[EMAIL PROTECTED], not mailto://[EMAIL PROTECTED]
Also, I don't know much about rules with regex yet, but could you do
something like...
multi sub open ($u of Str where /protocol(file)/, [EMAIL PROTECTED])
returns
Handle {...}
Where protocol(file) expands to file://
Yes, but it's probably easier to just use a hash: %protocolfile.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 probably a good starting
point.
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.
Subject: Useful mailto open
User-Agent: Perl 6
In-Reply-To: [EMAIL PROTECTED]
Hello, world!
.
);
.close or fail;
}
If it's for built-in, then only the most common protocols would be defined
I imagine.
No, if it's built in, we should stick to the spec and interpret every
^\w+: (roughly - see RFCs for syntax specifics) as a scheme.
Also, I don't know much about rules with regex yet, but could you do
something like...
multi sub open ($u of Str where /protocol(file)/, [EMAIL PROTECTED])
returns
Handle {...}
Where protocol(file) expands to file://
Yes, but it's probably easier to just use a hash: %protocolfile.
Easier or more efficient?
Yes.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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://...;;
:)
In fact, I'm a big proponent of using URIs instead of filenames where
possible. It can even provide a more portable way of saying
\\sambaserver\share, in smb://sambaserver/share, which can be translated
to whatever the system supports, possibly failing because it's just not
supported.
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.
Waiting for a certain wire to get shorted is input too, as is writing
directly to graphic memory a form of output.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 certain wire to get shorted is input too, as is writing : directly to graphic memory a form of output. I don't see how an IO is prevented from being used like any other handle. The handle type is there so MMD can pick out particular behaviors for == and syswrite(). And different subtypes of handles can pick out different behaviors. Even the OS can keep track of the types of file descriptors that are just integers as far as the user is concerned. Larry
Re: -X's auto-(un)quoting?
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 http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
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 {...}
to and the conditions. Or maybe there's a better solution to that
now that we have junctions, on the order of
if $filename ~~ -r -w -x {...}
Then we also get our or for free. We'd just say that ~~ binds
the default of -X just as it does m// or s///.
The only fly in the ointment is that this is awfully ambiguous because
-X is a unary operator looking for an argument, and you're not giving
it one. But it might think the next thing is a sub ref starting with ''.
Ouch. Not sure where to go with that, other than require space or parens
when ambiguous.
: 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 fingertips). But then, talking about
: huffmanization, could a standard adverb be provided for -X's to the effect
: of specifying that the passed filename is quoted, say in double (or if
: sensible in single) quotes: for I find that to be a common filelist
: format. Ideally, what I'd like to do is
:
: 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.
That seems more general than a special option to -X ops.
Larry
Re: -X's auto-(un)quoting?
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 would never mean that if I
could help it. :-)
: 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.
: That seems more general than a special option to -X ops.
:
: Wouldn't it be a good option to combine the filetest operators into one
: operator? It'd even be historically correct to call that test:
:
: test(:r :w, $fn);
Hmm. I think this works syntactically:
$file ~~ all(:r:w)
: I still like -r -w $fn much better than the binding and the ~~ things.
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
But that doesn't really matter much unless you're so much into speed
that you think about falsifying the test without doing a stat().
Now the interesting thing about the ~~ approach is that it naturally
lends itself to
given $file {
when :x {...}
when :r:w {...}
when :r(0) {...}
when :u | :g{...}
default:
}
I suppose it's a little bit rude to grab all the pairs for testing
against all the strings, so maybe we have to say
given $file.test {...}
$file.test ~~ :r:w
or maybe
given $file.stat {...}
$file.stat ~~ :r:w
which leaves room for lstat if we need it, though I can't say I'm fond
of the Unix naming scheme here. If we borrow from IO::All maybe it's just:
given io($file) {...}
io($file) ~~ :r:w
BTW, I'm assuming the $file is either $filename or $filehandle there.
Larry
