-X's auto-(un)quoting?
Michele Dondi
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
: 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
> 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.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Larry Wall
: 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
> : 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
: Speaking of which, I like to think of (some) adverbs in terms of cmd line
: 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
> 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
: 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
> multi sub open ($u of Str where /^http:/, *@opts) returns Handle {...}
> 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
: > 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
> : > 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
>
> 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
>
> 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
> 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
> 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;
}
> 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
> <://>?
>
> 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
> 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
: 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
>
> 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
> 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
> 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
> 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
>> 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
> 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
> 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
>
> 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
> 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
> 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.
Matt Creenan
> 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.
Brano Tichý
> 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
ti...@dss.sk
Rod Adams
> 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.
-- Rod Adams
John Macdonald
> 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ß
> 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
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
> 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.)
Thomas Sandlaß
> 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ß)
Paul Seamons
> 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
Thomas Sandlaß
> 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ß)
Paul Seamons
>
> 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 *@_ 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
Juerd
> 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 problem name 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
> 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
> .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...
Nathan Wiger
>
> 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
Juerd
> 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.
Paul Seamons
> > $_.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):
method foo {
$SELF.prop = $SELF.meth($SELF.get_foo, $SELF.get_bar);
$SELF.say("Hello " ~ $SELF.prop);
}
That looks considerably more messy than:
method foo {
$.prop = .meth(.get_foo, .get_bar);
.say("Hello " ~ $.prop);
}
Perl syntax is wonderful for being able to say as much as possible without
losing meaning - assuming you can read perl. The short identifiers are able
to express a lot in a little space.
> Having .method assume $SELF is an added nicety, but if it introduces
> added parsing problems then it's hardly worth it.
The .method problem isn't about parsing - it is about knowing which variable
it applies to.
Current syntax would do:
method foo ($self:) {
return grep { $self.is_ok( .value ) } $self.info_pairs;
# .value called on the topic $_
}
Proposed syntax previous to this thread
method foo {
return grep { .is_ok( $_.value ) } .info_pairs;
# .is_ok called on invocant not the topic
}
Proposed syntax in this thread (among various others)
method foo {
return grep { $^.is_ok( .value ) } $^.info_pairs;
# .value called on the topic
}
The goal is to be able to be concise yet intuitive - so that you could do:
my @good_objects = grep { .is_ok } @candidate_objects;
> 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?)
That is the goal - to find some nice variable that looks vaguely usable and
that people won't rebel against using.
Paul
Nathan Wiger
>>> 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
Luke Palmer
> (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
Juerd
> 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).
Luke Palmer
> 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
Nathan Wiger
> 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
Rod Adams
> 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
Aaron Sherman
> 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.
The reasons I don't "use English" in P5:
* Variable access is slower
* Names like OUTPUT_AUTOFLUSH are painful
* I remember $', $/, $\ more easily (that's probably just from
having written code with them for 13+ years)
Now, assuming P6 makes:
$FUNKYNAME := $*;
efficient, then my only real concern is how much of a pain these are to
type. I'd really love to have names that are short (3-7 characters) and
yet clear enough to justify using English.
Let's look at P5 English, and see how that might look. Note that these
are all regular variables (e.g. no "$*" noise), which is because an
explicit call to "use English" would import these names to your
namespace.
P5 P6
$ARG ok
$MATCH ok
$PREMATCH $BEFORE
$POSTMATCH $AFTER
$LAST_PAREN_MATCH $LAST
@LAST_MATCH_END @POSEND
$INPUT_LINE_NUMBER n/a
$INPUT_RECORD_SEPARATOR n/a
$OUTPUT_AUTOFLUSH n/a
$OUTPUT_FIELD_SEPARATOR $FIELDSEP
$OUTPUT_RECORD_SEPARATOR $RECSEP
$LIST_SEPARATOR $LISTSEP
$SUBSCRIPT_SEPARATOR $SUBSEP (already an alias in P5)
$FORMAT_PAGE_NUMBER n/a
$FORMAT_LINES_PER_PAGE n/a
$FORMAT_LINES_LEFT n/a
@LAST_MATCH_START @POSSTART
$FORMAT_NAME n/a
$FORMAT_TOP_NAME n/a
$FORMAT_LINE_BREAK_CHARACTERS n/a
$FORMAT_FORMFEED n/a
$ACCUMULATOR n/a
$CHILD_ERROR n/a
$ERRNO $ERR (it's not just a number, POSIX aside)
$EXTENDED_OS_ERROR $OSERR
$EVAL_ERROR n/a
$PID good (note: might be n/a if accessed through OO)
$UID good
$EUID good
$GID good
$EGID good
$PROGRAM_NAME $PROG
$COMPILING n/a?
$DEBUGGING n/a?
$SYSTEM_FD_MAX ? (will P6 have access to this?)
$INPLACE_EDIT ?
$OSNAME good (but might be in a separate module)
$PERLDB ?
$LAST_REGEXP_CODE_RESULT $RULEEVAL
$EXCEPTIONS_BEING_CAUGHT ?
$BASETIME good
$PERL_VERSION $PERL
$WARNING ?
$EXECUTABLE_NAME $PERLEXE
ARGV ?
$ARGV good, but probably ARGS
ARGVOUT ?
@F ?
@INC ?
@_ alias: @PARAMS
%INC ?
%ENV good
%SIG good (but possibly different)
As a side note, I'd like to suggest that "English" is just rubbing
people's noses in the fact that they're not allowed to program in their
native tongue. "Names" might be less in-your-face.
Thomas Sandlaß
> 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ß)
Mark Reed
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.
Luke Palmer
> On Mon, 2005-04-25 at 22:24 -0500, Rod Adams wrote:
>
> > 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.
>
> The reasons I don't "use English" in P5:
>
> * Variable access is slower
% perl -MBenchmark=timethese -MEnglish -e 'timethese(1e6, {
"/" => sub { $/ = "\n" },
"RS" => sub { $INPUT_RECORD_SEPARATOR = "\n" }
})''
Benchmark: timing 1000000 iterations of /, RS...
/: 2 wallclock secs ( 1.41 usr + 0.00 sys = 1.41 CPU) @ 709219.86/s (n=1000000)
RS: 1 wallclock secs ( 1.20 usr + 0.05 sys = 1.25 CPU) @ 800000.00/s (n=1000000)
Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually
they're the same: on each run a different one won, but just barely like
this).
When will you people stop caring about speed that doesn't matter. Even
if $/ were faster, it would only be by a neglegable amount. Your
readability is a lot more important than a few clock cycles here and
there.
Ever since I stopped caring about speed, I've started to write code
almost twice as fast. And the code itself isn't slower. It's just the
fact that after I used to write every line, I would think "is this fast
enough; could I make it faster?". I would even trip myself up,
abandoning projects because I couldn't find a fast enough way to do it,
or because my current implementation was too slow. But not by evidence,
just by judgement upon looking at the code.
Speed is important. And I'm a game programmer, so speed is pretty
important to me. I've found (and this is widely known, but perhaps
every programmer needs to discover it for himself) that it is hard to
tell where you will be spending most of your cycles. Once you know,
then you can go back and optimize it.
And I promise, that will never be somewhere where the difference between
$/ and $INPUT_RECORD_SEPARATOR matters.
Luke
Aaron Sherman
> Aaron Sherman writes:
> > The reasons I don't "use English" in P5:
> >
> > * Variable access is slower
> Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually
> they're the same: on each run a different one won, but just barely like
> this).
Remember that I'm a Perl 3 programmer who has just gotten used to this
"5" thing... ;-)
I sometimes lose track of the ugly hacks that have been rationalized
into workable practice over the versions. "use English" used to require
an extra level of indirection in the implementation, but clearly no
longer does. I don't have a perl older than 5.6.1 to test against, but
this was probably back in the 5.002 or 5.003 timeframe. I'm guessing.
> When will you people stop caring about speed that doesn't matter.
This matters. I'm not going to switch around all over the place, I'm
either going to use the English names everywhere or the punctuation
names everywhere, not a mix of both -- THAT would be terribly unreadable
-- and back when that access hurt (I did measure it), I could not have
afforded to use the English variables in tight loops. For example:
while(<>) {
if ($. == 1) {
print "Header: $_";
}
$total += $_;
if (eof) {
$. = 0;
}
}
This was the very sort of thing that convinced me not to "use English"
back in the day, when I measured performance of one reporting program
with and without English variables. I found that with them it took about
10 minutes longer than without. Without won.
> Ever since I stopped caring about speed, I've started to write code
> almost twice as fast. And the code itself isn't slower.
Ok, so let's separate the premature optimization from removing massive
bottlenecks from code. When I can get a reporting program that takes
30-60 minutes to run to drop 10 minutes in execution time, I'm going to
do that. This is NOT premature optimization.
What you describe is what Knuth has also described. You should never
worry about trivial details of optimization while writing the minutia of
a program because a) you don't know if that bit of code will even exist
in the final version b) the optimization might be better accomplished at
a higher level c) you might be PREVENTING optimization opportunities at
a higher level!
> And I promise, that will never be somewhere where the difference between
> $/ and $INPUT_RECORD_SEPARATOR matters.
It used to be. Clearly the ugly hack that was "use English" has been
fixed. Old lessons are not easily unlearned.
Either way this is not really about Perl 6, is it?
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Luke Palmer
> > Ever since I stopped caring about speed, I've started to write code
> > almost twice as fast. And the code itself isn't slower.
>
> Ok, so let's separate the premature optimization from removing massive
> bottlenecks from code. When I can get a reporting program that takes
> 30-60 minutes to run to drop 10 minutes in execution time, I'm going to
> do that. This is NOT premature optimization.
Oh. Wow. That's, er, significant. I came into Perl right at the
beginning of 5.6.0, so I can't say anything about this history. I
couldn't imagine that a variable indirection could add that much to a
segment of code. But if you say so... I retract my comment. Well, no I
don't. I retract the fact that my comment was directed at you. There's
still a lot of premature optimization going on[1].
Luke
[1] I'm surely guilty of one of them. I feel like the autothreading
semantics of junctions will be way to expensive without the compiler
knowing whether there a junction in a particular variable. But I have
nothing to back that fear up, it was just a gut reaction. And I fought
pretty hard....
Graham Barr
> On Tue, 2005-04-26 at 10:48, Luke Palmer wrote:
>> Aaron Sherman writes:
>
>>> The reasons I don't "use English" in P5:
>>>
>>> * Variable access is slower
>
>> Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually
>> they're the same: on each run a different one won, but just barely
>> like
>> this).
>
> Remember that I'm a Perl 3 programmer who has just gotten used to this
> "5" thing... ;-)
>
> I sometimes lose track of the ugly hacks that have been rationalized
> into workable practice over the versions. "use English" used to require
> an extra level of indirection in the implementation, but clearly no
> longer does. I don't have a perl older than 5.6.1 to test against, but
> this was probably back in the 5.002 or 5.003 timeframe. I'm guessing.
It is also the fact that English.pm mentions $' and $` and that any
mention
of those variables flips a global switch inside perl which causes
*every*
regex with capturing parens to be slower.
See http://search.cpan.org/~nwclark/perl-5.8.6/pod/perlvar.pod#BUGS
Graham.
Aaron Sherman
> There's still a lot of premature optimization going on [...]
> I'm surely guilty of one of them. I feel like the autothreading
> semantics of junctions will be way to expensive without the compiler
> knowing whether there a junction in a particular variable.
Well, more to the point, autothreading of junctions will hit the wall of
Parrot duping the interpreter. That's probably not something you want to
suffer just to resolve a junction, is it?
I suppose it depends on how snarled the junction is....
Luke Palmer
> On Wed, 2005-04-27 at 14:38, Luke Palmer wrote:
>
> > There's still a lot of premature optimization going on [...]
> > I'm surely guilty of one of them. I feel like the autothreading
> > semantics of junctions will be way to expensive without the compiler
> > knowing whether there a junction in a particular variable.
>
> Well, more to the point, autothreading of junctions will hit the wall of
> Parrot duping the interpreter. That's probably not something you want to
> suffer just to resolve a junction, is it?
What? Why will it do that?
Luke
Aaron Sherman
> Aaron Sherman writes:
> > Well, more to the point, autothreading of junctions will hit the wall of
> > Parrot duping the interpreter. That's probably not something you want to
> > suffer just to resolve a junction, is it?
>
> What? Why will it do that?
Why? Well, you can read what Dan wrote, 'cause I'm sure not going to
pretend I'm enough of a threads programmer to have an educated opinion:
http://groups-beta.google.com/group/perl.perl6.internals/msg/18b86bff49cac5a0?dmode=source
We'd decided that each thread has its own interpreter. Parrot
doesn't get any lighter-weight than an interpreter, since trying
to have multiple threads of control share an interpreter seems
to be a good way to die a horrible death.
-Dan Sugalski / 14 Apr 2005
I'm not saying it's a good or bad thing, but people on THIS list seem to
keep pretending that threading will be light-weight, and unless I'm
misunderstanding what "each thread has its own interpreter" means (and
Dan confirmed it in pretty clear terms when I asked), that's simply not
the case.
Dan's terse followup is at:
http://groups-beta.google.com/group/perl.perl6.internals/msg/e1885fc6da8aa068?dmode=source&hl=en
Dave Whipp
"threading"? If the compiler knows its compiling for a single-processor
system, then it could optimise the "threading" into a simple loop --
heck, it could even inline it if it knows the size of the junction at
compile time. I read the term "threading" to simply mean that we don't
guarentee the order of execution between the different invocations of
the called function (and possibly that we don't share updates to
unshared data -- though I'm not so sure about that).
Jonathan Scott Duff
> On Thu, 2005-04-28 at 10:00, Luke Palmer wrote:
> > Aaron Sherman writes:
>
> > > Well, more to the point, autothreading of junctions will hit the wall of
> > > Parrot duping the interpreter. That's probably not something you want to
> > > suffer just to resolve a junction, is it?
> >
> > What? Why will it do that?
>
> Why? Well, you can read what Dan wrote, 'cause I'm sure not going to
> pretend I'm enough of a threads programmer to have an educated opinion:
>
> http://groups-beta.google.com/group/perl.perl6.internals/msg/18b86bff49cac5a0?dmode=source
> We'd decided that each thread has its own interpreter. Parrot
> doesn't get any lighter-weight than an interpreter, since trying
> to have multiple threads of control share an interpreter seems
> to be a good way to die a horrible death.
> -Dan Sugalski / 14 Apr 2005
I believe these are two distinct uses of the term "threading".
Autothreading of junctions is orthogonal to parrot interpreter
threads. Junction autothreading does *NOT* require interpreter
threads. Junction autothreading just means that routines will be
executed for each element of the junction (not necessarily in
parallel).
Someone correct me if I'm wrong.
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Gcomnz
> As a side note, I'd like to suggest that "English" is just rubbing
> people's noses in the fact that they're not allowed to program in their
> native tongue. "Names" might be less in-your-face.
Why are we even having to say use English or Names or whatever? Why
not just make it a part of the core alongside the original short
special var names? In my opinion the short version of special vars is
one of the worst features of Perl, despite the fact that I like
concise code. But then again, I'm not a golfer.
Marcus Adair
Rod Adams
>On Thu, 2005-04-28 at 10:00, Luke Palmer wrote:
>
>
>>Aaron Sherman writes:
>>
>>
>
>
>
>>>Well, more to the point, autothreading of junctions will hit the wall of
>>>Parrot duping the interpreter. That's probably not something you want to
>>>suffer just to resolve a junction, is it?
>>>
>>>
>>What? Why will it do that?
>>
>>
>
>Why? Well, you can read what Dan wrote, 'cause I'm sure not going to
>pretend I'm enough of a threads programmer to have an educated opinion:
>
>
I would be dismayed if autothreading used threads to accomplish it's
goals. Simple iteration in a single interpreter should be more than
sufficient.
-- Rod Adams
Aaron Sherman
Of course, you're right, and Larry and others have made this point
repeatedly. I can be a tad thick from time to time ;-)
Uri Guttman
RA> I would be dismayed if autothreading used threads to accomplish it's
RA> goals. Simple iteration in a single interpreter should be more than
RA> sufficient.
how autothreading is implemented is distinct from the language
feature. a simple version is the iteration mentioned above. but on a
multiprocessor with (poosibly prespawned) threads on a large junction,
it could be much faster to use parrot threads. but that is just an
optimization which uses parallel processing and is not needed for
working junction semantics. larry has hinted that autothreading could be
parallel underneath if that is supported. maybe choosing the desired
implementation would be a pragma.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Aaron Sherman
> I would be dismayed if autothreading used threads to accomplish it's
> goals. Simple iteration in a single interpreter should be more than
> sufficient.
Sorry, I misunderstood. Thanks for the clarification.
Sam Vilain
> I would be dismayed if autothreading used threads to accomplish it's
> goals. Simple iteration in a single interpreter should be more than
> sufficient.
For sure. No point in doing 10_000 cycles to set up a scratch area
for a single boolean test that might take 10 cycles.
A software transaction (atomic { } block) behaves in many ways like
setting up a new interpreter thread and exiting at the end. I expect
these will be more lightweight than a real thread... in some cases
able to be reduced to no-ops.
So, implementing autothreading using STM as the 'localizing' engine
is another possibility within a single process/thread.
Sam.