Re: Unifying invocant and topic naming syntax
> > 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 no way of > preserving my chosen interface. Or > porting that code cleanly. Well, it would mean the interface gets the additional facet that the caller can /optionally/ explicitly pass $_. I'd call that a benefit, not a problem. What's the issue with porting cleanly? > Besides all that, ($_ = $_) where $_ > means something different from $_ > is Just Plain Wrong. ;-) Well, I don't see it in quite that strong a tone. One could argue that the context of the rhs of assignments in the arg list is /naturally/ the caller's. But I agree it might cause a good ppl to double-take, because of the way it looks. More importantly, it doesn't seem LOUD enough for what it's doing. Unless it doesn't need to be loud because one sorts out the issue of protecting against potential problems by requiring some explicit marking at the caller's end, as I suggested in my recent "Access to caller's topic" post. -- ralph
Re: Unifying invocant and topic naming syntax
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 iterator.
It has a nice mnemonic, looking as it does like a '_' stacked on top
of another.
while <$something> {
if ($=.first) {
# first iteration
}
elsif ($=.last) {
# last iteration
}
}
You could then use $==, $===, etc., to access outer iterators:
while <$foo> {
while <$bar> {
if ($==.first) {
# first foo
}
if ($=.first) {
# first bar
}
}
}
A
Re: Unifying invocant and topic naming syntax
> 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 hard to correctly jump to a previous topic without being fairly explicit. If you start talking about trapeze artists and I change the subject to monkees, then if I say I like the way they swing, you should assume I am talking about monkees unless I have explicitly changed the topic back to trapeeze artists. I don't think there should be a shortcut to do this, an explict way, yes, but not a shortcut as it seems to break the English analogy. Tanton
Re: Continuations
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 qw/"a" "b" "c"/; -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: Continuations
--- 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 bird is the platypus? =Austin __ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com
Re: String concatentation operator
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 that weren't successfully created. Whups, misunderstanding there. I realize that we need to throw an exception (or a junction of exception and not exception) if evaluating one of the junction members. The question is whether we should evaluate them all regardless and then figure it out at the end, and what to do with currently running junction evaluations if we've spawned off multiple threads to evaluate them in parallel. I expect I'm getting a bit too Quantum here, though. I'm thinking that we shouldn't parallelize junction evaluation by default. Dealing with threads has too many issues that must be dealt with to spring it on unsuspecting programs. As for short-circuiting: why not? Junctions are inherently unordered, so there's no guarantee which state of the junction is processed first (whether they're being processed in parallel or series). That's fine. One of the semantics I want nailed down. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unifying invocant and topic naming syntax
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 exist. More to the point, I think it's too much to have to juggle in your (or at least my) head at once. Sure the computer can do it, but that's not much use if I can't figure out what's being referred to. It seems to me, that in English, it is hard to correctly jump to a previous topic without being fairly explicit. I expect this is due to inherent limitations in people. We can't keep too much stuff in flight at any one time in our heads, and stacking referents like this is not something we're well suited for. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unifying invocant and topic naming syntax
> >> $_ # 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:
sub bar ($a, $b)
[$_, $foo]
{ ... }
In the above, implicit args go inside the
square brackets and the topic and $foo of
the sub being def'd are the same as (aliased
to) the topic and $foo of the calling sub.
As I said before, if you call a sub you
really ought to know that sub's signature,
and the above would make it clear that $_
and $foo are shared between caller and callee.
Of course, you might then come back and
change your calling code, accidentally
clobbering a shared lexical. So, back at
the caller end of things, I suggest the
following (simplified from an earlier post):
o There's a property that controls whether
called subs can share a given lexical of
a callee. I'll call this property Yours.
o By default, topics are set to Yours(rw);
other lexicals are set to not Yours.
--
ralph
Re: Continuations elified
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 if that method returns true. Whether it still has the
> automatic binding to $_ and the implicit definedness check is yet
> to be decided.
>
>
> > while <$iter> {...} # Iterate until $iter.each returns false?
>
> Yes.
>
you mean "Iterate until $iter.next returns false?"
what is the difference between the Iterator and lazy array ?
am I right that it is just "interface" : lazy array is an iterator
object "inside" Array interface :
Larry Wall wrote:
> Then there's this approach to auto-iteration:
>
> my @dance := Iterator.new(@squares);
> for @dance {
but then each is very simple method :
class Iterator {
method each( $self:) {
my @a := $self ;
return @a ;
}
}
but then probably we dont need two methods -- next and each .
just like in perl5 each can determine the calling context
class Iterator {
method each( $self:) {
when want Scalar {
...
}
when want Array {
my @a := $self ;
return @a ;
}
}
}
and then <...> could be *really* the sugar for .each ( or .next if it
will be called so ) . in these examples
> In a scalar context:
>
> <$fh> # Calls $fh.readline (or maybe that's $fh.next???>
> <$iter> # Calls $iter.next
> fibs() # Returns iterator object
> # Returns iterator object and calls that
> #object's C method (see note below)
>
>
> In a list context:
>
> <$fh> # Calls $fh.each
> <$iter> # Calls $iter.each
> fibs() # Returns iterator object
> # Returns iterator object and calls object's C
>
<...> *always* force call to .each ( which is context aware ) .
but again all that is based on the assumtion that lazy array is just
Iterator object in the "cloth" of array ( variable container ) . so
this is a question .
arcadi
Re: Coroutines, continuations, and iterators -- oh, my! (Was: Re: Continuations elified)
> 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 necessary? Isn't the "each $dance" just a
bassackwards method invocation (as C is to C<$fh.close()>)?
> Then there's this approach to auto-iteration:
>
> my @dance := Iterator.new(@squares);
> for @dance {
I think this is called "avoiding the question". Now you've converted an
Iterator into an iterator masked behind an array, and asked the C
keyword to create apparently a "private" iterator to traverse it. That
seems like twice as much work for the same output.
Also, I have a problem with the notion of the Iterator class being
tasked with creation of iterators -- how do you deal with objects (even
TIEd arrays) that require magic iterators? Better to ask the class to
give you one. (Of course, C could internally ask
@squares to provide an iterator, but again that adds a layer for little
apparent gain.
> Damian Conway wrote:
> The presence of a C automatically makes a subroutine a
> coroutine:
>
> sub fibs {
> my ($a, $b) = (0, 1);
> loop {
> yield $b;
> ($a, $b) = ($b, $a+$b);
> }
> }
>
> Calling such a coroutine returns an Iterator object with (at least)
> the following methods:
>
> next() # resumes coroutine body until next C
>
> next(PARAM_LIST) # resumes coroutine body until next C,
> # rebinding params to the args passed to C.
> # PARAM_LIST is the same as the parameter list
> # of the coroutine that created the Iterator
What's the value of C? Is this just a shortcut for
re-initializing the iterator? How is this going to work when the
iterator has opened files or TCP connections based on the parameter
list?
my $iter = DNS.iterator(".com.");
while <$iter> {
$iter.next(".com.au.")
if not hackable($_);
}
Furthermore, what's the syntax for including arguments to next in a
diamond operator?
while <$iter>($a, $b) {
...
$a += 2;
}
> each() # returns a lazy array, each element of which
> # is computed on demand by the appropriate
> # number of resumptions of the coroutine body
What's the difference between a lazy array and an iterator? Is there
caching? What about the interrelationships between straight iteration
and iteration interrupted by a reset of the parameter list? Or does
calling $iter.next(PARAM_LIST) create a new iterator or wipe the cache?
How do multiple invocations of each() interact with each other? (E.g.,
consider parsing a file with block comment delimiters: one loop to read
lines, and an inner loop to gobble comments (or append to a delimited
string -- same idea). These two have to update the same file pointer,
or all is lost.)
Some of questions about iterators and stuff:
1- Are iterators now considered a fundamental type?
1a- If so, are they iterators or Iterators? (See 2b1, below)
1b- What value would iterators (small-i) have? Is it a meaningful idea?
2- What is the relationship between iterators and arrays/lists?
2a- Is there an C or C<.toList()> method?
2a1- The notion that Iterator.each() returns a lazy array seems a
little wierd. Isn't a lazy array just an iterator? Why else have the
proposed syntax for Iterator.next(PARAM_LIST)? (Admittedly the
PARAM_LIST doesn't have to be a single integer, like an array.) Or is
that what a small-i iterator is?
2b- Is there a C method? Or some other standard way of
iterating lists?
2b1- Are these "primitive" interfaces to iteration, in fact
overridable? That is, can I override some "operator"-like method and
change the behavior of
while <$fh> { print; }
2b2- Is that what C does in scalar context -- returns an
iterator?
my $iter = each qw(apple banana cherry);
my $junk = all qw(apple banana cherry);
my $itr2 = each $junk; # Whoops! Wrong thread...
3- What's the difference among an iterator, a coroutine, and a
continuation?
3a- Does imposing Damian's iterator-based semantics for coroutines
(and, in fact, imposing his definition of "any sub-with-yield ==
coroutine") cause loss of desirable capability? (Asked in ignorance --
the only coroutines I've ever dealt with were written in assembly
language, so I don't really know anything about what they can be used
to do.)
3b- Is there a corresponding linkage between continuations and some
object, a la coroutine->iterator?
3c- Is there a tie between use of continuations and use of thread or
IPC functionality? Is it a prohibitive tie, one way or the other? That
is, I've been thinking that "A coroutine is just a continuation." But
if "A continuation implies <...>", for example a semaphore or a thread,
or some such, then that may be too expensive.
Re: Unifying invocant and topic naming syntax
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 them to be used
independently:
# a) set topic
sub foo ($param is topic) { ... }
# or it's set implicitly to the first parameter
# b) default
sub foo ($param = 5) { ... }
# c) break lexical scope
$CALLER::varname
The propsals all basically boil down to bits of syntactic sugar that
combine these three features in various ways.
The fundamental question for each of the proposals is "What's the
overall gain for the language in providing syntatic sugar for this
particular combination of features?"
Allison
Re: Unifying invocant and topic naming syntax
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 allowing dynamic scoping of $_ across subroutine calls (for backward compatibility with p5), so we delayed any final call on whether subs topicalize their first argument. We've pretty much resolved the first: such an abuse of lexical scope should be explicitly marked. For consistency, I think the first argument of subs should be the topic by default. Allison
Re: Unifying invocant and topic naming syntax
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 CALLER::_ is good, though.
Also, since we're jamming things into the signature, how do we declare
call-by-value/call-by-reference info?
=Austin
--- Allison Randal <[EMAIL PROTECTED]> wrote:
> 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 them to be
> used
> independently:
>
> # a) set topic
> sub foo ($param is topic) { ... }
> # or it's set implicitly to the first parameter
>
> # b) default
> sub foo ($param = 5) { ... }
>
> # c) break lexical scope
> $CALLER::varname
>
> The propsals all basically boil down to bits of syntactic sugar that
> combine these three features in various ways.
>
> The fundamental question for each of the proposals is "What's the
> overall gain for the language in providing syntatic sugar for this
> particular combination of features?"
>
> Allison
Re: Unifying invocant and topic naming syntax
--- 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.
>
> I dug through the archives. We were considering allowing dynamic
> scoping
> of $_ across subroutine calls (for backward compatibility with p5),
> so
> we delayed any final call on whether subs topicalize their first
> argument. We've pretty much resolved the first: such an abuse of
> lexical
> scope should be explicitly marked.
>
> For consistency, I think the first argument of subs should be the
> topic by
> default.
For methods, will that be the invocant or the first other parameter?
$string.toLanguage("french")
Topic is $string, or "french" ?
=Austin
Re: Unifying invocant and topic naming syntax
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
Re: Unifying invocant and topic naming syntax
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 single character, but why? People will understand > //=. There's not really anything wrong with it. But one of the tricks to an elegant language is that it provides syntatic sugar for commonly used features, instead of requiring you to type out long arcane sequences. The problem is deciding which features deserve the sugar. > The idea of $= as CALLER::_ is good, though. Though C is a nasty sequence. Allison
Re: Unifying invocant and topic naming syntax
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) ^^^ Don't I recall Larry saying that C< //= > for setting a parameter's default value was a Bad Idea, because it means that you can't explicitly pass C to foo()? I thought it'd been changed to C< = > for that reason. Or is this piece of code doing something different? > > 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 > > //=. > > There's not really anything wrong with it. But one of the tricks to an > elegant language is that it provides syntatic sugar for commonly used > features, instead of requiring you to type out long arcane sequences. > The problem is deciding which features deserve the sugar. (See my remark about three paragraphs down.) > > The idea of $= as CALLER::_ is good, though. I'd like to raise my hand in the "please, God, no!" camp, for C< $= >. One of the things about Perl 5 that I dislike the most is all the $( $> $- $= $[ $$ special variables. Yes, we're losing almost all of them - I think the only one that is really left is $! (*), which I can live with - but if we're going to introduce more of these, then perhaps we're not learning from our past mistakes as well as we think we are. Yes, we've already been through the whole C thing and how no one uses it. We don't need to talk about it again. I'm just expressing an opinion. Move along, and tell me how these continuation thingies work again. Besides: inheriting a caller's topic isn't going to be that common a thing that it needs such a short name, is it? > Though C is a nasty sequence. (*) $_ I don't consider special, because my C training leads me to think of _ as an alphabetic character. Probably not true in a Perl lexer, but it's how my brain functions. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] "I am the eye in the sky, looking at you, I can read your mind. I am the maker of rules, dealing with fools, I can cheat you blind. And I don't need to see any more to know that I can read your mind." - _Eye in the Sky_, APP
Re: Unifying invocant and topic naming syntax
--- 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 much shorter. Yes, we > could > > convert //= into a single character, but why? People will > understand > > //=. > > There's not really anything wrong with it. But one of the tricks to > an > elegant language is that it provides syntatic sugar for commonly used > features, instead of requiring you to type out long arcane sequences. > The problem is deciding which features deserve the sugar. > > > 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
Re: Unifying invocant and topic naming syntax
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 between clarity and brevity. Allison -- "Mene, mene, tekel"
Re: Unifying invocant and topic naming syntax
--- 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 $=
> > > sub foo($param is topic //= $CALLER::_ // 5)
> ^^^
> Don't I recall Larry saying that C< //= > for setting a parameter's
> default value was a Bad Idea, because it means that you can't
> explicitly
> pass C to foo()? I thought it'd been changed to C< = > for
> that
> reason.
>
> Or is this piece of code doing something different?
Maybe. This code says "if $param is undef, pull the value from
$CALLER::_. If THAT is undef, it's 5."
So obviously this example doesn't WANT there to be an undef.
But if you wanted an undef and passed it, it wouldn't take it.
So obviously we need ///=, the "only if it REALLY wasn't there"
operator. :-)
Or we could give special meaning to =.
Drat.
Good catch, though.
>
> (See my remark about three paragraphs down.)
>
> I'd like to raise my hand in the "please, God, no!" camp, for C< $=
> >.
> One of the things about Perl 5 that I dislike the most is all the $(
> $>
> $- $= $[ $$ special variables. Yes, we're losing almost all of them
> - I
> think the only one that is really left is $! (*), which I can live
> with
> - but if we're going to introduce more of these, then perhaps we're
> not
> learning from our past mistakes as well as we think we are.
Or maybe we're making a valid, justified decision that facilitating
this kind of thing is desirable.
Remember, signatures are getting an AWFUL lot of information crammed
into them. In fact, I wonder if your question wouldn't be better asked
about all the information we're putting into them: Do we actually know
enough about what we're doing to justify all this?
So far there are (modulo my having confused the line noise):
sub versive(
$invocant is topic:
$arg is rw,
@array is ro,
*@flattened_rest;
@optional_named_ones)
is cached
{
print "Don't let my rhyme \n"
~ " raise your hackles -- \n"
~ "Learn perl6 instead, \n"
~ " Cast off your shackles!\n\n";
print " - OR - \n\n";
print "When your data base \n"
~ " is in a fix -- \n"
~ "Don't sweat the details, \n"
~ " Learn Perl 6! \n";
~ "Burma Shave!\n";
}
And now we're trying to find out how to add one more item --
inherit-from-caller.
It's really a neat idea, since it represents putting an entire idiom
into a single glyph -- essentially, surrounding every sub with
if ($#_ == 0) { $_ := $CALLER::_; }
Except that it's more than that, since you can do it for ANY part:
sub join($re, @*list = $=) # Shouldn't that be @=?
=Austin
Re: Unifying invocant and topic naming syntax
> 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 ppp: c) introducing 'locals' or 'yours' Where this terminology and perspective comes from: My view is that c) is about sharing vocabulary between a caller and a callee to retain much of the referential simplicity and brevity of globals (and hence I think it's a pretty large issue), and c) is also about the fact that this can be done while omitting /all/ the dangers of globals (short of dangers that also apply to ordinary lexicals). Elements of this shared vocabulary might be called 'locals' or 'yours'. -- ralph
Re: Unifying invocant and topic naming syntax
> 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 of cheese just prior to suggesting that. Damian has estimated that 5% of perl 6 code will do so. I've heard he can wolf a lot of pizza. -- ralph
Re: Unifying invocant and topic naming syntax
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 caller, and the "your" keyword doesn't work as well from the caller's point of view: your $_; somesub(); # this sub can see $_ It almost calls for "our"; too bad that's taken. Although the current "our" has the "exclusive we" meaning (me and others but not you), and this would be more of an "inclusive we" (me and you and maybe others); too bad English only has the one set of pronouns for both. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Unifying invocant and topic naming syntax
> > 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 lexical context from any place in a callee's body. It exacerbates the (mostly over-stated, imo) action-at-a-distance concerns about this. I know you can do what you wrote anyway with the $CALLER::foo syntax, but I don't like that either. Allison et al have already intimated that they too find a generic 'yours' (or $CALLER::foo) capability that can be fired off anywhere in a sub's body to be dangerously obscure, to say the least. So while they expect to provide the raw $CALLER::foo capability, they have suggested some sugar that's a lot prettier AND a lot less dangerous for common cases (probably just for dealing with $_, though I am currently thinking it could work rather nicely to have it work for any lexical). Hence my focus on putting any callee side 'yours' sugar in the sub preamble. > However, I also like the idea of having to > mark shareable lexicals explicitly in the > caller, and the "your" keyword doesn't work > as well from the caller's point of view: > > your $_; > somesub(); # this sub can see $_ > > It almost calls for "our"; too bad that's > taken. I was thinking of yours as in "yours too", and as in a property: my $foo is yours; $_ would be yours(rw) by default, all other lexicals are not yours by default. The ability to have yours(ro) and yours(rw) is part of why I was thinking in terms of a property rather than a, er, whatever C is. -- ralph
Re: Unifying invocant and topic naming syntax
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 occur only within certain program portions that are lexically contained within the establishing construct. > So instead I'll argue that the word "break" > is perhaps prejudicially perjorative. > > I'd say, to steer away from being ppp: > > c) introducing 'locals' or 'yours' > > Where this terminology and perspective comes > from: > > My view is that c) is about sharing vocabulary > between a caller and a callee to retain much > of the referential simplicity and brevity of > globals (and hence I think it's a pretty large > issue), and c) is also about the fact that this > can be done while omitting /all/ the dangers of > globals (short of dangers that also apply to > ordinary lexicals). > > Elements of this shared vocabulary might be > called 'locals' or 'yours'. It's a valid proposal. It's just not lexical scope. I'm categorizing, not judging. This fits as a (c) feature. Allison
RE: Unifying invocant and topic naming syntax
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 reach in to the caller's lexical
# context from any place in a callee's body.
# It exacerbates the (mostly over-stated, imo)
# action-at-a-distance concerns about this.
#
# I know you can do what you wrote anyway with
# the $CALLER::foo syntax, but I don't like that
# either.
We need that capability if we're going to have lexically-scoped exports:
{
use FooBar 'baz';
baz(); #OK
}
baz(); #Unknown subroutine
Now, we can either include it in the Perl language or write it specially
for Exporter. If we write it specially for Exporter, someone will
generalize the code and put it in a module (witness PadWalker.pm), so we
might as well have it in the base language and save someone some
hassles.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Unifying invocant and topic naming syntax
> # 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
caller's lexical context, but where one gets
to declare that that is going to happen.
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.
--
ralph
RE: Unifying invocant and topic naming syntax
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 declare its import() function?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: Unifying invocant and topic naming syntax
> # 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 declare its import() function?
Keeping things simple, something like:
method import [*] { ... }
is required if one is to use $CALLERS::
in the body.
Skip the rest unless you enjoy flights
of pure fancy.
=
Being really radical, perhaps [*] means
that all the lexicals in the caller are
mapped to an identical set of lexicals
in the called. Dangerous stuff, huh?
Entering the realms of the truly insane,
one could have something like:
method import (@symbols)
[ { @symbols } ]
{ ... }
to indicate run time eval of the locals
list, but the above ignores all sorts
of practical problems and is plainly
huge overkill for the situation.
(All of this would of course still be
subject to the Yours property that by
default restricts localization to the
topic, and to non-existent lexicals,
ones the called sub intends to /add/
to the caller's lexical context.)
--
ralph
