[perhaps]
: bare blocks (even those passed as args) just
: pick up from the surrounding lexical context.
This is definitely a significant simplification.
Is it a problem?
Yes, that's the problem. A bare block would
have to notice at run time that it was called
with unexpected arguments and
On Thu, Nov 21, 2002 at 11:27:07AM -0600, Me wrote:
: And documenting this by the '-' distinction
: described above (ie - means private $_ set
: by mumble, no - means $_ is just the outer
: lexical) would look natural as well being
: logical and strikingly simple.
It would, however, force people
On Thu, 2002-11-21 at 20:11, Brent Dax wrote:
Are you suggesting this?
if($error) {
use visible 'croak';
require Carp;
import Carp: 'croak';
croak($error);
}
No - that would be pointless as well as error-prone.
My idea
Are you suggesting this?
if($error) {
use visible 'croak';
require Carp;
import Carp: 'croak';
croak($error);
}
No - that would be pointless as well as error-prone.
My idea of visible is that it would make a lexically scoped thing
accessible to an inner dynamic scope at
Me wrote:
Well, I could argue that c) already exists
in the form of passing parameters in parens.
This reminds me of the Law of Demeter. It specifies what your methods
should and shouldn't be able to do if you want to build a bright, shiny
system that never has bugs, maintains itself, turns
On Tue, Nov 19, 2002 at 03:09:40PM -0600, Allison Randal 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 $_
On Wed, 2002-11-20 at 15:01, Brent Dax wrote:
We need that capability if we're going to have lexically-scoped exports:
Whilst it would be useful for pragmatic modules to access anything and
everything in the current compilation scope, I submit that access to
dynamic scope should (in general) be
--- Larry Wall [EMAIL PROTECTED] wrote:
...
This might work now, presuming
sub foo (;$_ = $=)
(or whatever) is really a binding, and not an assignment. (That's
another reason why //= is *wrong*--it implies assignment.)
Umm, that's what it was supposed to do.
IOW: sub($param //=
Date: Wed, 20 Nov 2002 12:11:52 -0800 (PST)
From: Austin Hastings [EMAIL PROTECTED]
--- Larry Wall [EMAIL PROTECTED] wrote:
...
This might work now, presuming
sub foo (;$_ = $=)
(or whatever) is really a binding, and not an assignment. (That's
another reason why //=
$_ = 1; mumble { $_ = 2 }; print;
will print 1 or 2?
Least surprise, visually, is obviously 2.
This would be true if bare blocks (even
those passed as args) just pick up from
the surrounding lexical context. And if
that were true, mumble presumably could
not do anything about this
On Wed, Nov 20, 2002 at 04:20:07PM -0600, Me wrote:
: $_ = 1; mumble { $_ = 2 }; print;
:
: will print 1 or 2?
:
: Least surprise, visually, is obviously 2.
:
: This would be true if bare blocks (even
: those passed as args) just pick up from
: the surrounding lexical context. And if
:
Martin D Kealey:
# On Wed, 2002-11-20 at 15:01, Brent Dax wrote:
# We need that capability if we're going to have lexically-scoped
# exports:
#
# Whilst it would be useful for pragmatic modules to access
# anything and everything in the current compilation scope, I
# submit that access to
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
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:
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
On Mon, Nov 18, 2002 at 08:05:47AM +1100, Damian Conway wrote:
: I still think my original:
:
: sub bar(; $foo = $topic) is given($topic) {...}
:
: is the appropriate compromise.
Won't fly. Referring to something lexical before it's declared is
a no-no. I think we need some other way of
Larry Wall wrote:
On Mon, Nov 18, 2002 at 08:05:47AM +1100, Damian Conway wrote:
: I still think my original:
:
: sub bar(; $foo = $topic) is given($topic) {...}
:
: is the appropriate compromise.
Won't fly. Referring to something lexical before it's declared is
a no-no.
I would maintain
Damian Conway:
# Larry Wall wrote:
# On Mon, Nov 18, 2002 at 08:05:47AM +1100, Damian Conway wrote:
# : I still think my original:
# :
# : sub bar(; $foo = $topic) is given($topic) {...}
# :
# : is the appropriate compromise.
#
# Won't fly. Referring to something lexical before it's
Larry:
sub bar(; $foo = topicmumble) {...}
Damian:
topic [would be] Cundef.
I assumed topicmumble implied an 'is given'.
I don't see why it couldn't.
Damian:
Hm. Given that the topic is in some sense
a property of the lexical scope of the subroutine
body, this might be a
On Tue, Nov 19, 2002 at 07:45:25AM +1100, Damian Conway wrote:
: What mumble might be is an interesting, er, topic.
:
: I would argue it ought to be just $_, which is, after all,
: the One True Topic. And conveniently lexically predeclared in all scopes.
:
: I would also argue that it ought not
Larry wrote:
The long and the short of it was that
my sub foo ($_ := $arg = $_)
is how you might set $arg to be both the topic and the given.
Wow. I'm surprised by how much I don't like that syntax! ;-)
I mean, two entirely different meanings for $_ in the space of one parameter
my sub foo ($_ = $_)
to just propagate the outer $_ inward.
That only works when $_ can somehow be
shoe-horned into the parameter list.
Whereas:
my sub foo is given($_)
works for *any* parameter list.
Other than the placeholder situation, I
don't understand when one
ralph wrote:
Other than the placeholder situation, I
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.
For example, the
Adam D. Lopresto wrote:
It seems like that would be useful and common enough to write as
sub bar(;$foo is given) {
...
}
Where $foo would then take on the caller's topic unless it was explicitly
passed an argument.
While I can certainly see the utility of that, I believe it is too
My favorite was from ages ago:
sub bar(;$foo //= $_) {...}
I think that today that would be written more like this:
sub bar(;$foo) is given($def_foo) {
$foo = $def_foo unless exists $foo;
...
}
Though we might get away with:
Luke Palmer wrote:
My favorite was from ages ago:
sub bar(;$foo //= $_) {...}
I think that today that would be written more like this:
sub bar(;$foo) is given($def_foo) {
$foo = $def_foo unless exists $foo;
...
}
Though we might get away with:
sub bar(;$foo = $def_foo) is
Andrew Wilson wrote:
It's the difference between this:
print;
and this:
print $_;
It is as far as I'm concerned exactly what topic is all about.
Exactly.
It let's you write subroutines that behave like builtins with respect
to $_. I think it's generally intended to be used like so:
Acadi asked:
Just ( my ) terminology clean-up : in this example sub{ } is implicit
topicalizer
No. It isn't a topicalizer at all.
( it does not set $_ explicitly )
Or implicitly.
and you are setting $_ for perl .
Yes.
that's why you can use when .
Yes.
is this valid ?
(morning()
Damian Conway writes:
Micholas Clarke asked:
If a subroutine explicitly needs access to its invocant's topic, what is so
wrong with having an explicit read-write parameter in the argument list that
the caller of the subroutine is expected to put $_ in?
Absolutely nothing. And
Micholas Clarke asked:
If a subroutine explicitly needs access to its invocant's topic, what is so
wrong with having an explicit read-write parameter in the argument list that
the caller of the subroutine is expected to put $_ in?
Absolutely nothing. And perfectly legal. You can even call that
On Mon, Nov 11, 2002 at 11:48:06PM -0600, Me wrote:
: Are placeholders only usable with anonymous
: subs, or named subs too?
Placeholders are not intended for use with named subs, since named
subs have a way of naming their parameters in a more readable fashion.
However, it may well fall out that
Apologies for raising the dead (horse)
On Thu, Nov 07, 2002 at 03:27:51PM -0600, Me wrote:
Damian:
[it will be passed to about 5% of subs,
regardless of whether the context is your
10 line scripts or my large modules]
If the syntax for passing it to a sub
remains as verbose as it
Date: Wed, 13 Nov 2002 20:34:49 +
From: Nicholas Clark [EMAIL PROTECTED]
If a subroutine explicitly needs access to its invocant's topic, what is so
wrong with having an explicit read-write parameter in the argument list that
the caller of the subroutine is expected to put $_ in?
access caller's topic is an unrestricted
licence to commit action at a distance.
Right.
Perhaps:
o There's a property that controls what subs
can do with a lexical variable. I'll call
it Yours.
o By default, in the main package, topics are
set to Yours(rw); other lexicals are set
On Wed, Nov 13, 2002 at 08:34:49PM +, Nicholas Clark wrote:
If a subroutine explicitly needs access to its invocant's topic, what is so
wrong with having an explicit read-write parameter in the argument list that
the caller of the subroutine is expected to put $_ in?
It's the difference
ralph wrote:
If the syntax for passing it to a sub
remains as verbose as it currently is,
you are probably right that it won't
be used to achieve brevity!
You're confusing brevity of declaration with brevity of use.
Declarations should always be relatively verbose.
Why do you think your
You're confusing brevity of declaration
with brevity of use.
One needs sufficient brevity of both call
and declaration syntax if the mechanism's
brevity is to be of use in short scripts.
Making (limited) circumvention of [$_'s
lexicality] depend on a verbose and
explicit syntax will help
ralph wrote:
So what is driving you
guys to deliberately avoid a brief def
syntax?
Can't speak for Larry. But what's driving me is the desire
to balance conciseness with comprehensibility, and to keep the
overall cognitive load manageable.
If you're proposing that there be some special
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self
The invocant.
and $line?
A lexical variable that happens to be
bound to the caller's topic.
The invokit perhaps?
placeholders create subroutines, not methods.
Oh.
Are
ralph wrote:
My estimate (based on the -- not inconsiderable --
code base of my own modules) is closer to 5%.
Your estimate of what others will do when
knocking out 10 line scripts in a hurry,
or what's in your current p5 modules?
Both.
Can currying include the given topic?
sub bar
Damian:
[it will be passed to about 5% of subs,
regardless of whether the context is your
10 line scripts or my large modules]
If the syntax for passing it to a sub
remains as verbose as it currently is,
you are probably right that it won't
be used to achieve brevity! I think it's
a pity
ralph hypothesized:
My imagination suggests to me that in a
typical short perl 6 script, between 20%
and 50% of all sub defs would use the
upscope topic... ;
That's some imagination you've got there! ;-)
My estimate (based on the -- not inconsiderable -- code base of
my own modules) is closer
On Tue, Nov 05, 2002 at 05:13:45AM -0600, Me wrote:
relatively few subroutines need access
to the upscope topic.
Well, this is a central issue. What are
the real percentages going to be here?
Just how often will one type the likes
of
- is given($foo is topic) { ... }
rather
On Sun, Nov 03, 2002 at 11:17:32PM -0600, Me wrote:
I started with a simple thought:
is given($foo)
seems to jar with
given $foo { ... }
One pulls in the topic from outside and
calls it $foo, the other does the reverse --
it pulls in $foo from the outside and makes
it the
(naming) the invocant of a method involves
something very like (naming) the topic
Generally, there's no conceptual link...
other than
The similarity is that both are implicit
parameters
which was my point.
Almost the entirety of what I see as relevant
in the context of deciding
ralph wrote:
It's clear you could have come up with
something like one of these:
method f ($a, $b) is invoked_by($self)
method f ($a, $b) is invoked_by($self is topic)
method f ($a, $b) is invoked_by($_)
but you didn't. Any idea why not?
Because most methods need some kind of
I read Allison's topicalization piece:
http://www.perl.com/pub/a/2002/10/30/topic.html
I started with a simple thought:
is given($foo)
seems to jar with
given $foo { ... }
One pulls in the topic from outside and
calls it $foo, the other does the reverse --
it pulls in $foo from
68 matches
Mail list logo
