> # 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.
>
>
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'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
c
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
#
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 ent
> > 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 ca
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 call
> 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
> 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 be
--- 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)# Sho
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 betw
--- 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
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)
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
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
--- 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
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 C
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 al
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:
>
> 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 i
Damian Conway writes:
> David Wheeler asked:
>
> > How will while behave?
>
> C 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 i
> >> $_ # 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
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
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
tha
--- 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 som
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
> 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 i
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 ite
> > 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
29 matches
Mail list logo
