# -X's auto-(un)quoting?

6 views

### Michele Dondi

Apr 21, 2005, 4:18:17 AM4/21/05
to perl6-l...@perl.org
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 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' Michele -- Mary had a little lamb;/Its fleece was green as limes. And every even number greater than two/Is the sum of two primes. - Robert Israel in sci.math, "Re: all math problems reduce to linguistics" ### Larry Wall unread, Apr 21, 2005, 11:54:29 AM4/21/05 to perl6-l...@perl.org 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 ### Juerd unread, Apr 21, 2005, 12:40:54 PM4/21/05 to perl6-l...@perl.org 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 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); I still like -r -w$fn much better than the binding and the ~~ things.

### Larry Wall

Apr 21, 2005, 6:50:12 PM4/21/05
to perl6-l...@perl.org
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 ### Michele Dondi unread, Apr 22, 2005, 3:24:51 AM4/22/05 to Larry Wall, perl6-l...@perl.org 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"

### Larry Wall

Apr 22, 2005, 5:27:46 AM4/22/05
to perl6-l...@perl.org
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

### Juerd

Apr 22, 2005, 5:28:06 AM4/22/05
to perl6-l...@perl.org
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. ### Larry Wall unread, Apr 22, 2005, 11:42:10 AM4/22/05 to perl6-l...@perl.org 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:/, *@opts) returns Handle {...}
multi sub open ($u of Str where /^http:/, *@opts) returns Handle {...} multi sub open ($u of Str where /^ftp:/, *@opts) returns Handle {...}
multi sub open ($u of Str where /^mailto:/, *@opts) 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

### Juerd

Apr 22, 2005, 11:53:48 AM4/22/05
to perl6-l...@perl.org
Larry Wall skribis 2005-04-22 8:42 (-0700):

> multi sub open ($u of Str where /^http:/, *@opts) 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. ### Larry Wall unread, Apr 22, 2005, 12:47:12 PM4/22/05 to perl6-l...@perl.org 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

### Juerd

Apr 22, 2005, 12:49:03 PM4/22/05
to perl6-l...@perl.org
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. ### Matt unread, Apr 22, 2005, 2:44:42 PM4/22/05 to Juerd, perl6-l...@perl.org On Fri, 22 Apr 2005 14:24:25 -0400, Juerd <ju...@convolution.nl> 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:\/\//, *@opts) returns
>> Handle {...}
>
> Well, it's mailto:exa...@example.com, not mailto://exa...@example.com.
>

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)>/, *@opts) returns >> Handle {...} >> Where < <protocol(file)> > expands to < file:// > > > Yes, but it's probably easier to just use a hash: %protocol<file>. > Easier or more efficient? ### Matt unread, Apr 22, 2005, 2:20:53 PM4/22/05 to Larry Wall, perl6-l...@perl.org On Fri, 22 Apr 2005 11:42:10 -0400, Larry Wall <la...@wall.org> 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:/, *@opts) returns Handle
> {...}
> multi sub open ($u of Str where /^http:/, *@opts) returns Handle > {...} > multi sub open ($u of Str where /^ftp:/, *@opts) returns Handle {...}
> multi sub open ($u of Str where /^mailto:/, *@opts) 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:\/\//, *@opts) returns Handle {...}
multi sub open ($u of Str where /^http:\/\//, *@opts) returns Handle {...} multi sub open ($u of Str where /^ftp:\/\//, *@opts) returns Handle {...}

multi sub open ($u of Str where /^mailto:\/\//, *@opts) 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)>/, *@opts) returns
Handle {...}

Where < <protocol(file)> > expands to < file:// >

### Juerd

Apr 22, 2005, 2:24:25 PM4/22/05
to Matt, perl6-l...@perl.org
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:\/\//, *@opts) returns > Handle {...} Well, it's mailto:exa...@example.com, not mailto://exa...@example.com. > 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)>/, *@opts) returns
> Handle {...}
> Where < <protocol(file)> > expands to < file:// >

Yes, but it's probably easier to just use a hash: %protocol<file>.

### Juerd

Apr 22, 2005, 3:09:21 PM4/22/05
to Matt, perl6-l...@perl.org
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:ma...@weakmind.org' {
.say(q0:to<.>
Subject: Useful mailto open
User-Agent: Perl 6

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)>/, *@opts) returns > >>Handle {...} > >>Where < <protocol(file)> > expands to < file:// > > >Yes, but it's probably easier to just use a hash: %protocol<file>. > Easier or more efficient? Yes. ### Mark Reed unread, Apr 22, 2005, 4:57:59 PM4/22/05 to Juerd, Matt, perl6-l...@perl.org > 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 ### Matt unread, Apr 22, 2005, 5:08:52 PM4/22/05 to Juerd, perl6-l...@perl.org On Fri, 22 Apr 2005 15:09:21 -0400, Juerd <ju...@convolution.nl> 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:ma...@weakmind.org' { > .say(q0:to<.> > Subject: Useful mailto open > User-Agent: Perl 6 > In-Reply-To: <op.spnc0sii8hsiyb@codeslut> > 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:pass@address:port' { .say(q0:USER username PASS password ); .close or fail; } Though I'm not sure exactly how the FTP protocol works :) ### Larry Wall unread, Apr 22, 2005, 9:31:03 PM4/22/05 to perl6-l...@perl.org 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:ma...@weakmind.org' { : .say(q0:to<.> : Subject: Useful mailto open : User-Agent: Perl 6 : In-Reply-To: <op.spnc0sii8hsiyb@codeslut> : : 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:ma...@weakmind.org' {
_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:ma...@weakmind.org' { ·say(...); ·close or fail; } But I'm sure some will argue that's too subtle. (Hi, @Larry<Damian>.) Well, hey, as long as we're looking at Latin-1, we could use superscripts to indicate nested topic defaults. given open 'mailto:ma...@weakmind.org' { 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:ma...@weakmind.org' {
!say(...);
!close or fail;
}

Sigh. We could also take  away from user-defined literals and say

given open 'mailto:ma...@weakmind.org' {
say(...);
close or fail;
}

But I rather like  for user-defined literals. I suppose bare ^
is also available:

given open 'mailto:ma...@weakmind.org' {
^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

### Matt

Apr 22, 2005, 9:55:10 PM4/22/05
to Larry Wall, perl6-l...@perl.org
On Fri, 22 Apr 2005 21:31:03 -0400, Larry Wall <la...@wall.org> wrote:

>
> given open 'mailto:ma...@weakmind.org' {
> ^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!)

### Mark A. Biggar

Apr 22, 2005, 10:37:51 PM4/22/05
to Larry Wall, perl6-l...@perl.org
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:ma...@weakmind.org' { > _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:ma...@weakmind.org' {
> ·say(...);
> ·close or fail;
> }
>
> But I'm sure some will argue that's too subtle. (Hi, @Larry<Damian>.)

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:ma...@weakmind.org' {
> 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:ma...@weakmind.org' { > ^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. ### Juerd unread, Apr 23, 2005, 7:23:51 AM4/23/05 to perl6-l...@perl.org 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, @Larry<Damian>.) 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

Apr 23, 2005, 7:25:10 AM4/23/05
to Matt, perl6-l...@perl.org
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.

### Nigel Hamilton

Apr 23, 2005, 7:42:11 AM4/23/05
to Juerd, Matt, perl6-l...@perl.org
>> 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

### Matt

Apr 23, 2005, 10:01:42 AM4/23/05
to Juerd, perl6-l...@perl.org
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd <ju...@convolution.nl> 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 ;)

### Mark A. Biggar

Apr 23, 2005, 1:55:17 PM4/23/05
to Matt, Juerd, perl6-l...@perl.org
Matt wrote:

> On Sat, 23 Apr 2005 07:25:10 -0400, Juerd <ju...@convolution.nl> 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. ### Matt Creenan unread, Apr 23, 2005, 2:19:25 PM4/23/05 to Mark A. Biggar, Juerd, perl6-l...@perl.org On Sat, 23 Apr 2005 13:55:17 -0400, Mark A. Biggar <ma...@biggar.org> 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?

### Juerd

Apr 23, 2005, 2:19:07 PM4/23/05
to Mark A. Biggar, perl6-l...@perl.org
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

or is $__ already taken? brano tichy ti...@dss.sk ### Rod Adams unread, Apr 23, 2005, 6:49:23 PM4/23/05 to perl6-l...@perl.org Larry Wall wrote: > I suppose bare ^ >is also available: > > given open 'mailto:ma...@weakmind.org' { > ^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.

### John Macdonald

Apr 24, 2005, 10:43:28 AM4/24/05
to Juerd, Mark A. Biggar, perl6-l...@perl.org
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.

### Thomas Sandlaß

Apr 25, 2005, 9:13:18 AM4/25/05
to Larry Wall, perl6-l...@perl.org
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:ma...@weakmind.org' { 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ß) ### Paul Seamons unread, Apr 25, 2005, 11:52:42 AM4/25/05 to perl6-l...@perl.org 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

### Juerd

Apr 25, 2005, 12:48:04 PM4/25/05
to Paul Seamons, perl6-l...@perl.org
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