don't understand when one could do the
'is given($_)' and not do the ($_ = $_).
Any time that the caller's topic isn't
supposed to be explicitly passed as an
argument, but is still used within the
subroutine.
[example]
And, yes, I could make it an optional
argument, but them I have
Larry Wall wrote:
So I was thinking it'd be better to use something different to
represent the outer topic...
How about this:
$_ # current topic
$__ # outer topic
$___ # outer outer topic
...etc...
I also wondered if $= might be a suitable alias to the current
How about this:
$_ # current topic
$__ # outer topic
$___ # outer outer topic
Unfortunately, or maybe fortunately, that is impossible to read correctly
without having to move the cursor and count how many underscores exist.
It seems to me, that in English, it is
Damian Conway said:
Is it illegal now to use quotes in qw()?
Nope. Only as the very first character of a
Paging Mr Cozens. ;-)
So any of these are still fine:
print a b c ;
print \a b c;
print «\a b c»;
Presumably without the backslash here too.
print
--- Damian Conway [EMAIL PROTECTED] wrote:
Iain 'Spoon' Truskett wrote:
@a ???+??? @b
@a ???+??? @b
Y'know, for those of us who still haven't set up Unicode, they look
remarkably similar =)
Think Of It As Evolution In Action
;-)
This coming from someone whose national
At 6:09 PM +1100 11/19/02, Damian Conway wrote:
Dan Sugalski wrote:
We're definitely going to need to nail the semantics down. Would
one thread throwing an exception require all the threads being
aborted, for example?
I would imagine so. You can't reasonably build a junction out of values
At 6:56 AM -0500 11/19/02, Tanton Gibbs wrote:
How about this:
$_ # current topic
$__ # outer topic
$___ # outer outer topic
Unfortunately, or maybe fortunately, that is impossible to read correctly
without having to move the cursor and count how many underscores
$_ # current topic
$__ # outer topic
$___ # outer outer topic
[not sufficiently visibly distinct]
[too much anyway]
Agreed.
Returning to the topic of binding/copying
from a caller to a callee, what about using
square brackets to mark implicit args thus:
Damian Conway writes:
David Wheeler asked:
How will while behave?
Cwhile evaluates its first argument in scalar context, so:
while $fh {...}# Iterate until $fh.readline returns EOF?
More or less. Technically: call $fh.next and execute the loop
body if that
Larry wrote:
So you can do it any of these ways:
for $dance {
for $dance.each {
for each $dance: {
^ note colon
1- Why is the colon there? Is this some sub-tile syntactical new-ance
that I missed in a prior message, or a new thing?
2- Why is the colon
To summarize, we're discussing 3 features:
a) the ability to set the topic with a block (sub, method, etc)
b) the ability to set a default value for a parameter
c) the ability to break lexical scope
1) for $_ only
2) for any variable
Each of these features already have syntax that allows
Larry wrote:
I'm trying to remember why it was that we didn't always make the first
argument of any sub the topic by default. I think it had to do with
the assumption that a bare block should not work with a copy of $_ from
the outside.
I dug through the archives. We were considering
So what's wrong with:
sub foo($param is topic //= $= // 5)# Shorter form with $=
sub foo($param is topic //= $CALLER::_ // 5)
It doesn't really seem like we can make it much shorter. Yes, we could
convert //= into a single character, but why? People will understand
//=.
The idea of $= as
--- Allison Randal [EMAIL PROTECTED] wrote:
Larry wrote:
I'm trying to remember why it was that we didn't always make the
first
argument of any sub the topic by default. I think it had to do
with
the assumption that a bare block should not work with a copy of $_
from
the outside.
Austin wrote:
For methods, will that be the invocant or the first other parameter?
$string.toLanguage(french)
Topic is $string, or french ?
It is the invocant.
Allison
On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote:
So what's wrong with:
sub foo($param is topic //= $= // 5)# Shorter form with $=
sub foo($param is topic //= $CALLER::_ // 5)
It doesn't really seem like we can make it much shorter. Yes, we could
convert //= into a
Ah . . . one message with two things I wanted to talk about. Good.
Allison wrote:
On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote:
So what's wrong with:
sub foo($param is topic //= $= // 5)# Shorter form with $=
sub foo($param is topic //= $CALLER::_ // 5)
--- Allison Randal [EMAIL PROTECTED] wrote:
On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote:
So what's wrong with:
sub foo($param is topic //= $= // 5)# Shorter form with $=
sub foo($param is topic //= $CALLER::_ // 5)
It doesn't really seem like we can make it
Austin wrote:
The idea of $= as CALLER::_ is good, though.
Though C//= $= // is a nasty sequence.
Final // only required for another default:
//= $= // 5 # Default to $CALLER::_, or 5
Aye, it's just a worst case scenario. C//= $= and C= $= are still
line-noisy. It's a trade-off
--- Deborah Ariel Pickett [EMAIL PROTECTED] wrote:
Ah . . . one message with two things I wanted to talk about. Good.
Allison wrote:
On Tue, Nov 19, 2002 at 01:24:30PM -0800, Austin Hastings wrote:
So what's wrong with:
sub foo($param is topic //= $= // 5)# Shorter form with
c) the ability to break lexical scope
Well, I could argue that c) already exists
in the form of passing parameters in parens.
Of course, that doesn't feel like breaking
anything.
So instead I'll argue that the word break
is perhaps prejudicially perjorative.
I'd say, to steer away from being
inheriting a caller's topic isn't going to be
that common a thing that it needs such a short
name, is it?
15% of the perl 5 builtins do so.
I have suggested that, in some extreme
scenarios such as short scripts, perhaps
as many as 50% of subs might do so. But
then again I probably ate a lot
On 2002-11-19 at 16:44:49, Me wrote:
Elements of this shared vocabulary might be
called 'locals' or 'yours'.
I like the 'yours' idea from the point of view of the callee:
my $inherited = your $_;
However, I also like the idea of having to mark shareable lexicals
explicitly in the
Elements of this shared vocabulary might be
called 'locals' or 'yours'.
I like the 'yours' idea from the point of
view of the callee:
my $inherited = your $_;
I like that syntax, but I'm uncomfortable
with an underlying principle, which is that
one can reach in to the caller's
Me wrote:
c) the ability to break lexical scope
Well, I could argue that c) already exists
in the form of passing parameters in parens.
Of course, that doesn't feel like breaking
anything.
Formal parameters are lexically scoped.
Lexical scope: references to the established entity can
Me:
# Elements of this shared vocabulary might be
# called 'locals' or 'yours'.
#
# I like the 'yours' idea from the point of
# view of the callee:
#
# my $inherited = your $_;
#
# I like that syntax, but I'm uncomfortable
# with an underlying principle, which is that
# one can
# I'm uncomfortable [that]
# one can reach in to the caller's lexical
# context from any place in a callee's body.
We need that capability if we're going to
have lexically-scoped exports:
I think I was a bit careless in how I worded
that.
My problem is not that one reaches in to the
Me:
# I am thinking one should have to predeclare
# in a sub's preamble that such a trick will
# be going on.
#
# Thus something like:
#
# sub foo [bar] { ... }
#
# is (part of what is) required to be allowed
# to create a bar sub in the context of the
# caller of foo.
So how does Exporter
# I am thinking one should have to predeclare
# in a sub's preamble that such a trick will
# be going on.
#
# Thus something like:
#
# sub foo [bar] { ... }
#
# is (part of what is) required to be allowed
# to create a bar sub in the context of the
# caller of foo.
So how does
29 matches
Mail list logo
