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 th
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 ma
> > (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 dec
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 acce
> 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 than
-> $foo: { ... }
?
My imagination suggests to me tha
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) { ... }
>
> > My imagination suggests to me that in a
> > typical short perl 6 script
>
> That's some imagination you've got there! ;-)
:>
> 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 s
> Can currying include the given topic? Can
> I do something like:
>
> $foo = &bar.assuming( _ => 0)
>
> or whatever the latest syntax is?
Oops. More clearly:
sub bar is given($foo) {
...
}
$foo = &bar.assuming( foo => 0 )
--
ralph
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 is
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
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 he
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
exe
> > 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 method
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 verb
> 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 $_
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
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
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 nothin
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 given($
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 ?
(mor
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 c
> > 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 wi
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
Larry:
> > sub bar(; $foo = ) {...}
Damian:
> topic [would be] C.
I assumed 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 possibility:
>
> sub bar($foo i
On Tue, Nov 19, 2002 at 07:45:25AM +1100, Damian Conway wrote:
: >What 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 be cal
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
defi
> > 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 understa
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 Class::Contract
> > 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
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
> 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
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
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 al
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
--- 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
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
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
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
--- 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
> 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
> 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 call
> > 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
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
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
#
> # 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:
# 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.
>
>
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 w
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 $_ f
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($pa
> 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
> > a
> $_ = 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 (wit
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 d
> [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 argument
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 peopl
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.
> > 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 inn
> "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 s
71 matches
Mail list logo
