Hi, folks. As has probably been obvious to most of you, I've been
really busy with my O'Reilly day job and haven't had time to attend to
Perl 6 and Parrot business. With no prompting, Allison Randal stepped
forward and has been taking on more and more of the day-to-day running
of the show. I
Michael G Schwern writes:
> my @images = map { $_ _ '.jpg' } qw(pic1 pic2 pic3);
>
> Hmmm, that's visually unappealing.
my @images = map { "$_.jpg" } qw(pic1 pic2 pic3);
Now that's sexay.
Nat
>From newsforge:
nile writes, "Today, dLoo released the complete architecture of an
extensible peer-to-peer programming language. Unlike traditional languages,
this language is defined on the Internet. Its syntax and semantics can be
extended by posting additional pieces of the language. As de
Dan Sugalski writes:
> Doing it properly in a module is significantly more of a pain than doing it
> in the core. Faking it with a module means a fair amount of (reasonably
> slow) perl code, doing it in the core requires a few extra lines of C code
> in the method dispatch opcode function.
Wo
Anyone seen this? It has a little of the flavour of what we're
going to do.
http://xlang.sourceforge.net/
Nat
Daniel S. Wilkerson writes:
> Therefore, if it isn't a back-end and it isn't a front-end, what is it?!
> Perl6 seems to be a "nothing sandwich". Not that this is bad, Zen is this
> way.
Simon's done a good job of explaining this, but I'll try too.
You're right, we're designing many things. Lar
Ariel Scolnicov writes:
> Am I the only one here who's confused?
>
> How does the printing happen in the correct order? I mean, if I said
>
> my $x = "Post order: &show($root, $post)\n";
> print $x;
>
> then (I hope) we're agreed printing would happen in the *wrong* order
> (first the
Edward Peschko writes:
> Exactly. This has not been finalized in an Apocalypse - hence the question
> whether or not it has been 'blessed'.
>
> So - has this decision been made?
I've heard Larry saying things that make me think strict and -w
will not be on by default. I'll leave it to him to c
Simon Cozens writes:
> On Tue, May 15, 2001 at 03:47:36PM -0700, Mark Koopman wrote:
> > i think that's the idea...they have similar meanings, so they should do
> > similar things. hey it's the English language, i'll leave it up to someone
> > else to come up with the 7 other ways to prove owners
Edward Peschko writes:
> Ok, question here. Are these exegesises 'blessed'? What is open to
> debate on this?
As Simon says, ask whatever questions you want.
> print "Post order: "; show($root,$post); print "\n";
> would be better off written as:
> print "Post order: &show($root, $post)\n";
Dave Storrs writes:
> at first I was alarmed and a bit appalled at a lot of the
> changes...e.g., the 'HASH $tree is rw' parameter declaration.
> "Jesus," I thought "if I wanted a typed languaged, I'd use C++."
> The more I read, however, the more I became convinced that these
> were actually eleg
Michael G Schwern writes:
> "$foo has true" doesn't flow as well as "$foo is true". Dunno quite
> what the other expected uses are.
$foo has truth; # :-)
This leads naturally to:
$foo has the_buddha_nature;
$foo has ten_days_to_live;
$foo has meddled_in_my_affairs_one_too_many_times!
Edward Peschko writes:
> I think its really time to have a vote on this, I think that all
> that has been said about this issue has been said...
It's definitely not time for a vote. Larry'll take what's been said
by both sides and make a decision, just one of a zillion different
decisions that h
Larry Wall writes:
> wanted, you still get the length. If you're worried about the delayed
> operation, you can force numeric context with $x = +@tmp;, just as you
> can force string context with a unary ~.
How often are you likely to do this? Speaking as a reader of code,
I've always hated una
I don't think that extreme positions ("minimalist!" "bloater!")
helps here. I think the important question to ask about any given
feature is: what will it let me do? Features with no good answer to
this question obviously have no place in core. Attempting to align
with one or another philosoph
Andy Dougherty wrote:
> Yes, precisely. I often have one-liners embedded in larger shell scripts.
> Most of those survived the perl4->perl5 transition intact. I'd hope the
> same can be said for the perl5->perl6 transition.
This is exactly the situation that Larry mentioned on Wednesday as
an e
Glenn Linderman wrote:
> New RFC ideas?
Please, dear God, no. :-)
Nat
Title: http://dev.perl.org/rfc/73.html
> [25]RFC 73: All Perl core functions should return objects
>
[...]
>
> I'm thinking that the solution is better abstract type support
> for data values that happen to be represented internally by C
> structs. We get bogged down when we try to tran
Peter Scott wrote:
> Some of us got to reading Damian's design for Perl 5+i which was announced
> at the same time and are suffering from blown minds after learning how fast
> he wrote the thing.
Consider how blown his mind is after WRITING it :-)
> Oh, and who put him up to that, eh?
I'm sure
Not a comment at all on it? Was I accidentally unsubscribed to
perl6-language?
*tap* *tap* is this thing on?
Nat
Larry's approaching perl6 through the Programming Perl book (the Camel).
He's going chapter by chapter through the Camel, writing documents about
the perl6 equivalent concepts. These missives are known as "Apocalypses",
for reasons best known to Larry. :-)
He's churning through the RFCs, looking
Espen Harlinn writes:
> I'm trying to locate information about the Perl 6 Language, i.e. what
> changes are proposed to the Perl language and so on.
> Can anyone point me in the right direction ???
In case anyone else is wondering:
http://dev.perl.org/
Nat
Dan Sugalski writes:
> I'm fine with silly things, it's dangerous things I don't much care for.
> Which isn't to say I'm against loading remote program code, I just think
> this isn't the way to do it.
use autoload { Bar => 'uddi://blah/some/Bar' };
(here I take a big swill from the web servic
Jarkko Hietaniemi writes:
> > True, but you can't do any of all that without knowing the platform
> > accurately (nontrivial and requires core mod or XS). Once that's
> > done, the rest is just a matter of extending File::Spec
> > (trivial and pure Perl).
>
> Trivial? *cough* *snigger*
If it w
John van V writes:
> If perl.org is unacceptable for some reason I can easily create a
> mailing list on puny.vm.org
Thanks for the offer, but I don't think we'll need it. I think we're
hampered right now by the fact that we don't know much about what
perl6 is going to look like. Until we get m
--- start of forwarded message ---
# CFP in English, followed by French (see below) #
Third North American YAPC: First Call for Participation
Yet Another Society
calls for your participation in
YA
John Porter writes:
> Perl6 ought to support pluggable sort algorithms, just as Perl
> now supports pluggable comparison functions.
By "pluggable" you mean that sort() should be overridable?
Nat
I just got off the phone with Larry. He's been laid up for three
weeks with a trip to Japan followed by a virus from Japan. He's on
his feet again, and continuing to work through the RFCs.
He's changing the way he's doing it. Now he's going to try to find
clusters of RFCs on a particular topic
John Siracusa writes:
> Not to seem ungrateful, but is there any hope of getting the slides up as
> well? You'd think it'd be a no-brainer, but there have been many Wall
> speeches that have gone by with no slides on the web (well, none that I
> could find, anyway.) I want to know what the audie
Here's a summary of the points that came up in Larry's Atlanta Linux
Showcase talk. I've run this summary past Larry, and he has approved
it as being a fair representation of what he said. Remember that
these are just his current thoughts, not concrete decisions.
This is available on the web th
Here's the rest of my transcription of Larry's talk. He hasn't had
time to proofread it, so I'm posting it now in the interest of getting
it out. Ask, please add it to your page at dev.perl.org. When you
do, please send mail to pudge and mjd so they can announce the
completed transcription on p
Uri Guttman writes:
> overall i agree. but i use objects much more now and don't think about
> the runtime cost at all (estimated to be %30)
All the world is not an Uri.
I know a company that had to rewrite most of their OO code because it
was the bottleneck in their application. The rewrite wa
David L. Nicol writes:
> > interim()?
>
> In discussing how to rename "local"
> we appear to be trading in the spatial metaphor for the temporal.
> How about
> fornow
I'd rather not revisit this, or any other, RFC until Larry's had a
chance to *really* comment and put forward his suggesti
It's time for the XML vs POD discussion to end. The RFCs are in
limbo now, and this conversation is serving no visible purpose.
Thanks,
Nat
Nathan Wiger writes:
> > True, C<> and E<> are pretty warty, but they clearly identify
> > something more presentational in nature.
>
> Yes, this is true. I think it's pretty apparent that the <> syntax is
> broken - there's too much stuff (like -> and <>) that uses duplicate
> characters. This c
It's valid to want to change the cultural makeup of perl6, but the
-language list is not the place for it. Try perl6-meta, and please
make concrete proposals. I see this "p5p sucks, we need something
better" as pointless unless there are definite ideas of what would
be better.
Nat
At this point, I think the whole thread on functions throwing
exceptions should either be:
(a) turned into an RFC
or
(b) abandoned.
This discussion is going around and around like a piece of toilet
paper in a weakly-flushing toilet.
Nat
Michael G Schwern writes:
> You can do it! While it seems "food" and "supermarket" are critical
> to the understanding of a shopping-cart, they're really just
> incedental. I'm saying the same thing about un/pack!
>
> If I grok'd the bastards, I'd write the explaination myself.
Please take thi
Sven said:
> >As I mailed to Nathan Torkington several days ago (without getting
> >a reply), many people use chop() a lot and his perl526 substitute
> >"s/.\z//s;" will not work because it returns the number of
> >chars changed, not the char itself like c
Tom Christiansen writes:
> and so and so forth.*That's* how people most expect functions to
> work, and when a few of them don't, this confuses them. That's
> what we get people wanting to do
>
> $line_sans_terminator = chomp ;
>
> or
>
> $last_list_element = pop some_func();
Th
Chaim Frenkel writes:
> I would like to have an undef returned.
Ah, I see. You want subroutines to return undef if they're given it
for any of their arguments. That'd break the lazy programmer practice
of passing undef expecting it to become "" or 0. They don't have
warnings on, of course.
Na
My first preference is for overriding constant strings.
My second preference is to provide a user-defined quoting operator mechanism,
possibly as part of a user-defined operator mechanism.
My third preference is for a new operator.
I personally do not want to see q() screwed with.
Nat
Perl6 RFC Librarian writes:
> This RFC proposes two-stage autoloading: one stage may be registered
> to act when the symbol is encountered at compile time, the other
> when the subroutine is called. Autoloading on the second stage does not
> I the subroutine, only I it.
You have a beautiful min
Michael G Schwern writes:
> I have misgivings. I like single-quote context *because* you don't
> have to worry about anything magical (except ' and \).
Genericise it.
Alter the overloaded string constant behaviour of perl5 so that
when you say:
use MagicInterpolativeStrings;
$foo = '$bar <
Chaim Frenkel writes:
> Somehow I find
> if (40 == ($foo = substr($bar, index($bar, 'xyz' {
> }
I don't understand your hypothetical code. substr() returns the
substring of $bar from the position retutned by index, onward.
When would this be 40, if index is going to return the po
Chaim Frenkel writes:
> Removing -1 as a valid result, could be a breakage (if someone is
> doing something weird with a negative result)
I don't care, so long as the perl526 translator can wrap perl6's
index/rindex. And I gave sample code for it to do that.
> Would it be reasonable to ask that
Perl6 RFC Librarian writes:
> An inconsistency between "C" and "<>" bugs me: "C" means
> "C" so it seems like "<>" should mean "C<$_ = > <>".
> I can't yet think of code that this extension would break.
I assume you mean that <> in void context should assign to $_?
Any code that has set $_, the
Peter Scott writes:
> >> ($a, $b, $c) = ;
> >> or
> >> @a[4,1,5] = ;
> >> only read three lines?
> >
> >I think this is a superb idea, and look forward to someone's RFC'ing it.
Should be part of the want() context. Permit operations to discover
(as does split) how many el
Eric Roode writes:
> Useful functions all, no doubt. But I would lobby heavily for a new
> set of names -- ones that can be remembered! Quick -- which trims
> leading spaces, champ, chump, or chimp?
My favourite: chafe().
Nat
Tom Hughes writes:
> I must admit it had never occurred to me that somebody might
> deliberately use keys or values to achieve that, but I guess
> somebody might be relying on it without realising it.
while (($k,$v) = each %foo) {
last if ...;
}
keys %foo;# reset the iterator
w
Tom Christiansen writes:
> But %hash->BUCKET_USE() should return what's currently there.
Do you really use this information? Really? I have no objection
to supplying a way to discover it, but this might even be in an
external module rather than built into the language given how rarely
it's used
Tom Christiansen writes:
> So code that says
>
> chop($k,$v)
>
> will need to say
>
> for ($k,$v) { s/.\z//s }
>
> or else something like:
>
> for ($k, $v) { substr($_, length() - 1) = '' }
I don't think chop() is an operation that's done often enough for
either of the things ab
Ed Mills writes:
> Duck & cover Nate- I sugested that weeks ago and the flames are just dying
> down in my mailbox..
Whoops, sorry. I didn't realize that had already been submitted.
I just read through the mail archive and didn't see much in the way of
flames there. J.S. Duff wants to keep th
(I'm going to RFC these if nobody presents any killer complaints about
them, it's just that writing RFCs is more work than I want to go through
for tiny little changes like these, especially if they turn out to be
dumb).
%hash in scalar context should return what scalar(keys(%hash))
currently doe
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
Nat
It's probably worth reading through the Python Enhancement Proposals
(PEPs) to see if there's anything that makes sense to steal:
http://python.sourceforge.net/peps/
Nat
David L. Nicol writes:
> If we use exceptions of some kind to handle
> syntax, encountering an exception of type "unknown-keyword:Cmp" could
> result in the subroutine definition getting run to clarify this piece
> of code.
I'm nervous about this. I'm trying to picture what happens, and
having t
Bart Lateur writes:
> I don't get it. What makes it so hard? If you see a "/" when you're
> expecting an operator, or end of statement, then it's division. If you
> were expecting an expression, it's a regex. Ain't it?
We're talking tokenizing vs parsing. If I'm just getting back a
sequence of c
Tom Christiansen writes:
> There are unsolvable problems here, though.
Unsolvable without knowledge of the Perl language, yes. As
always, easy tasks will be easy and there'll be a continuum of
difficulty as the task gets harder.
I just want easy filters to be possible!
Nat
Tom Christiansen writes:
> If the goal is to make Perl parsable by emacs, might as well just
> say that.
That's not my goal.
Damian's Text::Balanced does a pretty good job of tokenizing Perl
as it is. / by itself requires a lot of lookahead, and it's still
a guess.
Being able to have any progr
Stephen P. Potter writes:
> Great idea. I'd love to see us come up with some "meta" RFCs which say
> what the main goals of perl6 are. Then we could align the current RFCs
> with those meta RFCs to make sure we're meeting those goals.
Highly unlikely to happen, as we have lots of people with di
Bart Lateur writes:
> Oh. I would have put my hopes on a better (= more generic) O::Deparse
> mechanism to make Perl analyse the source code for you. Rewriting a Perl
> in a module seems a bit silly to me.
I don't know enough swear words to say how much I fucking hate the
stupid braindead dumbfuc
Dan Sugalski writes:
> Personally I think I'm in favor of Nat's suggestion of allowing the
> definition of new infix operators and let this be taken care of in a
> module, but that's just passing the buck. (Not that it's a bad strategy,
> mind... :)
Solve the generic problem, not a specific on
We need a way to mix eq, the things to be compared, and the operation
to be done on them before they are compared:
lc{ $foo eq $bar }
$foo eq (lc) $bar
$foo eq{lc} $bar
None of those are like any existing syntax in Perl. The current way:
lc($foo) eq lc($bar)
seems fine in compari
On the subject of 'strict', I'm looking forward (once the typing
proposals string out) to having
use strict 'types';
To turn Perl into full B&D mode. This will also enable maximum
optimizations.
I'm picturing type-checking at this level:
my hash %a;
my StructuredHash %b;
%b = %a;
Randal L. Schwartz writes:
> Joe> thing in Perl, we'd need to be able to match a substring, and
> Joe> then call an arbitrary function in the middle of a pattern match,
> Joe> and to back out the call if the match failed.
>
> Already done in 5.6. :) "perldoc perlre".
Anyone who has actually tri
Larry Wall writes:
> Now all we have to do is make the program a variable, and the two
> requirements become one.
Compile the main() program code into a subroutine called 0, and you're
off!
&0 anyone? :-)
(that's digit 0, by analogy to $0)
Nat
And at this point we seem to have run out of steam for changing perl6
in this direction. Please take dialogue on the perl5 documentation to
the perl5-porters list.
Thanks,
Nat
John Porter writes:
> So? Perl's not like that. Perl is diagonal. And this is just
> another corner being cut.
Cut away enough corners, and you have a black hole. Or something :-)
My point is that before you reach to invent new syntax, see if there's
a way to do what you want with the existi
John Porter writes:
> I suppose that's true. But why would
> %( foo => 1, bar => 2 )
> be "working harder" than
> %{{ foo => 1, bar => 2 }}
> ??? It's few keystrokes and would be a less tricky concept
> to remember.
It's a new syntax, not orthogonal to anything we already have. The
Casey R. Tweten writes:
> Wow. Now that, that, is lame. You're saying that keys() expects
> it's first argument to begin with a %? Why should it care what it's
> argumen begins with?
The keys function changes its arguments' data structure. keys resets
the each iterator (see the documentation
Damian Conway writes:
> If domeone is putting this RFC together, please remember to propose
> that C and C should handle opcodes as well as source:
>
> host-a:foo.pl: dump SOCKET;
>
> host-b:bar.pl: { local $/; eval };
>
> Or:
>
> sub suspend { open $fh, ">$_[0]" or die; d
Steve Fink writes:
> My code for doing what I thought Exporter did is:
>
> sub import {
> my $p = caller(1);
> *{"${p}::E"} = \%{"${p}::E"};
> }
>
> but that doesn't run afoul of use strict 'refs'. Can you point me to the
> passage in Exporter.pm that uses this?
It does run afoul of use
Larry Wall writes:
> I'd entertain a proposal that ... be made a valid term that happens
> to do nothing, so that you can run your examples through perl -c for
> syntax checks. Or better, make it an official "stub" for rapid
> prototyping, with some way of getting a warning whenever you execute
>
Ed Mills writes:
> Is eq needed? Can't == be used for either context?
>$a == 'cat'
> is readily distinguishable from
>$a == 2;
> so the compiler should be able to determine context.
if ($a == $b)
Is that string comparison or numeric comparison?
Nat
Nathan Wiger writes:
> Anyone RFC'ing this yet?
I could RFC it in vague terms, but I'm waiting to see how things
like interfaces turn out.
> Which reminds, anyone gonna RFC the rumored death of typeglobs? :-)
I figured that as Larry had used it as an example of things that were
up for grabs in
Stephen P. Potter writes:
> * The match operator, C, is always required (bare C becomes a fatal
> error).
I could live with that. Damian's done some work trying to tokenize
Perl and knows what the weird edge cases are. Damian, can you post
your short list?
> * Replace C, C, and C with equiva
Steve Fink writes:
> And both those examples apply to the underpinnings. Ok, maybe I have an
> unusually broad definition of the word "underpinnings". Think "anything
> that can't be done with a pure perl module".
I'm not wild about that metric, either. Exporter is pure Perl, but
I'd love to see
David L. Nicol writes:
> RFC: Perl6 is Final. There will Be No Perl7
>
> We declare that our framework willbe so flexiblke
> that anything can be done with it and there will be no penalty
> for something being in-core opposed to out-of-core and so on.
Bad idea. You can't make anything
Damian Conway writes:
> $add = ^a + ^b;
> # a thousand lines later...
> $incr = $add->(1);
> # a thousand lines later...
> $x = $incr->($x);
I picture $add->(1) cloning add's optree, filling in the 1 where
appropriate, then returning a reference to the new (cloned) o
Damian Conway writes:
> me, at least) trivial implementation issues, well documented in the
> compiler literature. I choose to ignore them because I *have* to ignore
> them or my brain is going to melt.
The brief explanations you gave ("here's how it would be translated",
and "walk each statement
Steve Fink writes:
> True. Would anyone mourn @$scalar_containing_variable_name if it died?
> I've never used it, and I'm rather glad I haven't. Perl5's -w doesn't
> notice $x="var"; print @$x either -- it'll complain if you mention @var
> once.
These are symbolic references. You can forbid them
Damian Conway writes:
>> * Using the pattern returned from some function as part of a regex
>
> /pattern returned from ${\some_function} as part of a regex/
(??{ some_function() }) more generally
>> * Using an array of "words" as an alternate list as part of a regex
> /match any of (${\
Don't forget that the rationale behind the infix dereferencing is
this:
@variable_name
@{variable_name}
@$scalar_containing_variable_name @$scalar_containing_value_ref
@{ code evaluating to variable name } @{ code giving value ref }
Nat
Perl6 RFC Librarian writes:
> =head2 Re-currying deferred expressions
>
> The subroutines generated by a placeholder are not exactly like the
> equivalent subroutines shown above. If they are called with fewer than the
> required number of arguments, they return another higher order function,
> w
Steve Fink writes:
> We are NOT here to construct a radically better language. We are here to
> design the underpinnings of one.
Perhaps. And by "perhaps", I mean "no".
We're here to say what we'd like to see in the next version of Perl.
These can be big things (currying) or small (hashes retur
John Porter writes:
> > push is _not_ a method. @var is not an object.
>
> You are deluded.
This is a highly unproductive avenue of discourse.
Let the people who want to drop punctuation propose dropping
punctuation. Arguing about it won't change their mind, but it will
(a) piss everyone of
Chaim Frenkel writes:
> The other magic variables would simply end up as some funny 8-bit
> characters floating around. With one's handy (several thousand page)
> translation table one can then interpret the meaning.
That's insane. We're trying to get rid of special variables named
after obscure
Karl Glazebrook writes:
> Well said!
>
> My take: I like perl, I don't mind it the way it is. But I'd be happier if
> it was a lot more like python! (indentation aside)
This begs the question of why you're not using python. If it's just
indentation, that's silly. Surely there are patches to th
Chaim Frenkel writes:
> CN> Can we please cut down on the traffic to perl-announce, maybe make it
> CN> moderated? Thanks,
>
> Perhaps, the esteemed Librarian could make the -announce a Bcc?
One of the moderators was a little too approval-happy. I believe
this has been fixed as of a few hours
Dan Sugalski writes:
> Unfortunately, I think you're somewhat under-informed as to the inherent
> capabilities of people's brains.
Ok, at this point I think all parties have to step away and let the
RFCs fall where they will.
It's obvious that there are two types of people: those who don't mind
Perl6 RFC Librarian writes:
> It is proposed that in a list context, operators are applied
> component-wise to their arguments. Furthermore, it is proposed that
> this behaviour be extended to functions that do not provide a specific
> list context.
I don't mind making Perl's builtins do this. M
Nathan Wiger writes:
> Nonetheless, I think a better thing would be to figure out if it's
> possible to "fix" this issue. I would *really* like lvalue subs ==
> rvalue subs.
I think conflating:
foo(@vals)
and
foo() = @vals
is misleading and going to cause more confusion that it solves.
>
Nathan Wiger writes:
> sub somesub {
> my(@stuff) = @_;
> # do nothing
> }
>
> Then I think both of these should act exactly the same:
>
> somesub(@values);
> somesub = @values;
EUGH. No way!
Assignment should be used to reflect (get this) assignment. Using
it
Jarkko Hietaniemi writes:
> > Better would be to redefine what m//g means in a scalar context.
> >
> > $_ = "foofoofoofoofoofoofoo";
> > $count = m/foo/g;
> >
> > 1 is just as true as 7.
>
> I like this. No extra //modifiers to learn.
scalar context of /g is already defined to be som
Peter Scott writes:
> >You're right. If RFC 45 is implemented they would however be inconsistent.
>
> No, || is half-consistent at the moment: the left hand side is forced into
> scalar context but the result context propagates down the right hand
> side. I challenge anyone to come up with a r
Chaim Frenkel writes:
> [use wacky Unicode characters for new operators]
> I can see that this would give problems for current editors and displays,
> but by the time perl6 comes out, perhaps the situation would be better.
No. Never ever gamble on the future being better than the present.
Don't
Piers Cawley writes:
> > > The $a and $b of the sort comparator were A Bad Idea to begin with.
> >
> > Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1] can't
> > be used, or even a more standard $1 and $2. Either one makes it more
> > obvious what's being operated on.
>
> $1 &
John Porter writes:
> foo $= ( bar, quux ); # provide scalar context to both sides
> foo @= ( bar, quux ); # provide list context to both sides
>
> This is very harmonious with the provision of two sets of operators
> for numeric and string comparisons.
I assume you've dropped this
Nathan Wiger writes:
> Well, this argument makes more sense. However, I still have to disagree.
> In fact, I think the opposite: ALL subs *should* be lvaluable by
> default. Here's why.
I think I failed to explain Damian's use of the word 'dangerous'.
my $var;
sub routine {
$var;
}
T
1 - 100 of 154 matches
Mail list logo
