with it. Is it valid to not use a when/default chain in CATCH
or to change topic, using: $_ = $my_new_topic. ?
An example of that would be helpful.
My second point involves re-throwing errors with useful stack traces.
Here's an example similar to what we do in CGI::App:
try { boom(); }
if ($!) {
die died
topic that flows
into blocks from further outside if not explicitly bound with - like:
$topic := Some.new;
$_ := $topic;
for @objects { .action } # call on $/ from @objects with $_ := $topic
# in all loops
@objects».action; # same for single action syntax
Luke Palmer wrote:
My brother asked me to take out the trash. I asked him to do it.
I believe that the subject there is my brother in the first sentence
and I in the second. The topic is either to take out the trash or
just the trash throughout (English speakers wouldn't have any trouble
I¹m only an amateur linguist, but from a linguistic point of view, there are
several related terms in this space.
The term ³subject² has many meanings in English, including ³topic². But
from a grammatical and linguistic standpoint, there are only two meanings of
³subject², and ³topic
And should stay off-list, thanks.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
Iain Truskett [EMAIL PROTECTED] writes:
* Jonadab the Unsightly One ([EMAIL PROTECTED]) [01 Jul 2003 23:41]:
Iain Truskett [EMAIL PROTECTED] writes:
Not the only one. And with Parrot being able to execute
Z-code, it might be sane to port Inform to Parrot!
Did you mean port Inform
On Wed, Jul 02, 2003 at 08:55:37AM +1000, Iain Truskett wrote:
* Jonadab the Unsightly One ([EMAIL PROTECTED]) [01 Jul 2003 23:41]:
Iain Truskett [EMAIL PROTECTED] writes:
Not the only one. And with Parrot being able to execute
Z-code, it might be sane to port Inform to Parrot!
Did
Iain Truskett [EMAIL PROTECTED] writes:
Not the only one. And with Parrot being able to execute Z-code, it
might be sane to port Inform to Parrot!
Did you mean port Inform to run on Parrot, or port Inform to compile
to parrot? If the former, that should be no problem. If the latter,
I'm not
* Jonadab the Unsightly One ([EMAIL PROTECTED]) [01 Jul 2003 23:41]:
Iain Truskett [EMAIL PROTECTED] writes:
Not the only one. And with Parrot being able to execute
Z-code, it might be sane to port Inform to Parrot!
Did you mean port Inform to run on Parrot, or port Inform
to compile to
[EMAIL PROTECTED] (Jonathan Scott Duff) writes:
My only dream is that by this time next year we have a fully-
functional-people-can-use-it-in-production Perl6. It doesn't even
have to be 100% complete; I think just 85% would be enough if it were
the right 85%.
I've been using an 85%-complete
Simon Cozens writes:
I've been using an 85%-complete Perl 6 in production for the past five
years. It's called Perl 5. ;)
Unfortunately, although Perl 5 may be 85% of Perl 6, it is the 85% that has
been sliced up so many times that it's now looking like a sloppy Joe. The
trick with perl 6 is
On Sun, 29 Jun 2003 05:17:44 -0400, Gyan Kapur wrote
reconstituted cheeseburger
/me wonders if pitching Perl6 as a reconstituted cheeseburger is going to
sell it to the world. :-)
-Miko
Miko O'Sullivan
Programmer Analyst
Rescue Mission of Roanoke
Miko O Sullivan [EMAIL PROTECTED] writes:
- I'm looking forward to more Pure Perl modules. I frankly admit
that I don't like coding in C. Every time I download a module that
has compiled C code I feel like I'm stuck in some place where I want
to play baseball and everybody else wants to
Ah, summertime (at least here in the northern hemisphere). The language list
has slowed down to a trickle, hopefully because everybody is relaxing in a
cool place, idly sipping non-alcoholic spritzers next to some special person,
reading low-brow literature (or, as in my case, Apoc 6).
This
On Fri, Jun 27, 2003 at 10:50:40PM -0400, Miko O Sullivan wrote:
It would be interesting to hear your Perl6 daydreams.
My only dream is that by this time next year we have a fully-
functional-people-can-use-it-in-production Perl6. It doesn't even
have to be 100% complete; I think just 85% would
Jonathan Scott Duff wrote in perl.perl6.language :
My only dream is that by this time next year we have a fully-
functional-people-can-use-it-in-production Perl6. It doesn't even
have to be 100% complete; I think just 85% would be enough if it were
the right 85%.
20% would be enough if
Rafael Garcia-Suarez [EMAIL PROTECTED] writes:
Jonathan Scott Duff wrote in perl.perl6.language :
My only dream is that by this time next year we have a fully-
functional-people-can-use-it-in-production Perl6. It doesn't even
have to be 100% complete; I think just 85% would be enough if it
'-' means the topic gets set and is
private to the block (ignoring aliasing effects):
$_ = 1; for @foo - $_ { $_ = 2 }; print; # 1
It seems to me that a logical conclusion would be
that a blank arg list after a '-' would mean the
topic remains private (and is set to undef).
Perhaps having bare
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
) be more closely controlled... and of
course the former can be used to implement the latter:
use visible '$topic';
no visible '$_';
-Martin
--- 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 //=
in to the block and executing it?
sub mumble (block) {
block()
}
Oddly, if we make the first argument the
topic by default, the second block actually
gets block as its topic. That's...strange.
This would go away with the above scenario.
--
ralph
(block) {
: block()
: }
:
: Oddly, if we make the first argument the
: topic by default, the second block actually
: gets block as its topic. That's...strange.
:
: This would go away with the above scenario.
True, but I think Cmumble has to be able to wrap its own idea of $_
around
to dynamic scope should (in general) be
# more closely controlled... and of course the former can be
# used to implement the latter:
#
# use visible '$topic';
#
# no visible '$_';
if($error) {
require Carp;
import Carp: 'croak';
croak
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
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
--- 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
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
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
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
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
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
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
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
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 Class
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
with:
sub bar(;$foo = $def_foo) is given($def_foo) {
...
}
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.
--
Adam Lopresto
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
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
Me writes:
Sorta. To quote an excellent summary:
Topic is $_.
is $_ always lexical variable.
Yes.
Or I can have $MyPackage::_ ?
You can copy or alias any value.
so if I understand correctly ,
Every topicalizer defines a topicalizer scope
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
On Wed, Nov 13, 2002 at 03:11:32PM +0200, [EMAIL PROTECTED] wrote:
: so if I understand correctly ,
:
: Every topicalizer defines a topicalizer scope in which there is
: implicit declaration
:
: my $_ ;
:
: and then lexical $_ ( implicitely ) is bound to ( or assigned to )
: whatever it
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 makes it clear.
If I understand all this correctly, as is, this access caller's topic
is an unrestricted
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
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
Larry Wall writes:
Correct, $_ is always lexical. But...
: or * will it be implicitely my $_ -- class/package lexical
There's no such thing as a class/package lexical. I think you
mean file-scoped lexical here.
ooo, now I understand : *scope* is orthogonal concept to
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
On Thu, Nov 14, 2002 at 04:28:17AM +0200, [EMAIL PROTECTED] wrote:
:
: : will it be an error to declare it as our $_ ;
:
: No, in this case, $_ is still considered a lexical, but it just happens
: to be aliased to a variable in the current package.
:
:
: which variable ? it seems
confirm that one can't do:
sub f ($a = mumble) { ... }
or
sub f (;$_ = mumble) { ... }
where mumble is the upscope it and $_
is the sub's topic.
I seriously doubt it but, as always, that's up to Larry.
If it were allowed, the syntaxes might be something like:
sub f ($a = $CALLER
$^_ }; # shorthand for
$foo = sub { print $_ } is given($_);
If you're proposing that there be some special
exemption for $^_ so that it (a) doesn't
placehold a parameter and (b) aliases the
caller's topic instead
Well it clearly does placehold something.
In
method f ($self
exemption for $^_ so that it (a) doesn't
placehold a parameter and (b) aliases the
caller's topic instead
Well it clearly does placehold something.
Sure. It's placeholds a parameter named $^_, which
may or may not be equivalent to a parameter named $_
(Larry will need to rule on that bit
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
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
I just want to be sure I understand correctly :
In your article at perl.com you describes various ways and situations
when perl creates a topic and this is described as perl making the
following binding on my behalf:
$_ := $some_var ; *1*
and probably marking $_ with some additional
In the hope this saves Allison time, and/or
clarifies things for me, I'll attempt some
answers.
In your article at perl.com you describes
various ways and situations when perl
creates a topic and this is described as
perl making the following binding on my behalf:
$_ := $some_var ; *1
Me writes:
In the hope this saves Allison time, and/or
clarifies things for me, I'll attempt some
answers.
Thanks .
In your article at perl.com you describes
various ways and situations when perl
creates a topic and this is described as
perl making the following binding
is the upscope it and $_
is the sub's topic.
Can currying include the given topic?
Maybe.
Naturally, I see this as another symptom
of the way upscope it is being treated
as a second class citizen, and that this
is leading things in the wrong direction.
And what about a topic placeholder
On Thu, Nov 07, 2002 at 01:36:07PM -0600, Me wrote:
: is *1* _all_ that topic is about ?
:
: Sorta. To quote an excellent summary:
:
: Topic is $_.
A real topicalizer also sets a topicalizer scope that can be broken out of.
: also
:
: a := ( $a, $b)
:
: Er, I don't think
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
(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
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
93 matches
Mail list logo
