/--- On Thu, Aug 24, 2000 at 12:30:25PM -0400, John Porter wrote:
| Still not good. "trans" is too overloaded word. "transaction"?
| "transactional"? (a bit too long...) "atomic"?
|
| "acid"?
\---
"transactional" and "transaction" are quite long, I don't like that.
"acid" could be
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
True Polymorphic Objects
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 25 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 159
Status: Developing
=head1
Nathan Wiger wrote:
OK here is a basic question: how do we specify element access in
PDL type arrays?
$a[$i][$j][$k] or $a[$i,$j,$k]
Both of these already have firm meaning in Perl. The second one is used
to bite off selected elements of an array. So if you want a different
eh?
"NW" == Nathan Wiger [EMAIL PROTECTED] writes:
NW If arrays are maintained "properly" (not flattened) in Perl, then they
NW will remain separate, whether as parameters, across = assignments, etc,
NW etc. The same goes true for mixing arrays and scalars and hashes:
NW @stuff =
On Thu, 24 Aug 2000 17:57:55 -0700, Peter Scott wrote:
I've read 151 a few times, and I don't understand how it can impact
the implementation of RFC 88 as a module. Please explain.
If $@ and $! are merged, then in code like
try {
system_call_that_fails();
On Fri, 25 Aug 2000 07:47:14 -0400, Stephen P. Potter wrote:
| Do we have an RFC yet that proposes Perl to be easier parsable?
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
At 14.17 +0200 2000-08-25, Bart Lateur wrote:
I propose that one of the main goals should be that perl6 ought to be
bugfree.
Feasable? Nah...
How about "easier to introduce new features into without introducing
new bugs" :-)
Cajo
---
Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236
Adverb
[Apologies for the late reply. Still catching up]
On Thu, 17 Aug 2000 20:51:01 -0500, David L. Nicol said:
What if its a method of anything in an array? $_ is already
a reference to the object on the array in for loops rather
than a copy of it. What if we make change be not something
I don't understand this desire to not want anything to change.
You misread.
This is an
opportunity to clean up the language, make it more useable, and more fun.
I would have a lot more fun if perl were a better performer and if it was
easy for me to expand it, contract it, reshape it, improve
At 09:12 AM 8/25/00 -0400, Stephen P. Potter wrote:
As you say, 200 lines isn't much. But combine that with the IPC, the
environment, the system, etc it all adds up.
Not to much, though. We've been down this road for perl 5. You'd be
surprised at how little code gets removed if you yank most
--- "Stephen P. Potter" [EMAIL PROTECTED] wrote:
Lightning flashed, thunder crashed and Tom Christiansen
[EMAIL PROTECTED]
m whispered:
| Unless that's done completely transparently, you'll
pretty much screw the
| pooch as far as "Perl is the Cliff Notes of Unix"
notion. Not to
|
Not to much, though. We've been down this road for perl 5. You'd be
surprised at how little code gets removed if you yank most of the functions
under discussion. (They're generally trivial wrappers around library calls,
with very little code involved)
Thaniks -- I wish people wouldn't forget
cut
Perl is *not* fun when it supplies nothing by default, the way C does(n't).
cut
If you want a language that can do nothing by itself, fine, but don't
call it Perl. Given these:
cut
I agree!
Removing some of the things mentioned would turn Perl into an environment
well suited for computer
Dan wrote:
At 09:12 AM 8/25/00 -0400, Stephen P. Potter wrote:
As you say, 200 lines isn't much. But combine that with the IPC, the
environment, the system, etc it all adds up.
Not to much, though. We've been down this road for perl 5. You'd be
surprised at how little code gets removed if
Lightning flashed, thunder crashed and Tom Christiansen [EMAIL PROTECTED]
m whispered:
| Unless that's done completely transparently, you'll pretty much screw the
| pooch as far as "Perl is the Cliff Notes of Unix" notion. Not to
| mention running a very strong risk of butchering the
At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
Dan Sugalski writes:
One of the current plans is for the parser to have access to a list of
functions that trigger autoloading modules.
Isn't dynamic loading really slow?
Not particularly, at least not as far as I know. There's some extra
Lightning flashed, thunder crashed and Michael G Schwern [EMAIL PROTECTED] wh
ispered:
| However, since those funtions take up about 200 lines in the core, are
| very stable and relatively easy to document, what do we win by
| removing them?
|
| PS The idea of adding acos, asin and tan is good.
Oh geez! I'm sorry, I forgot to mention David Nicol in the REFERENCES,
who also gave great input, especially on the BOOLEAN accessor. Thanks
David! I swear I'll put you in v2. :-{
-Nate
Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
On Fri, Aug 25, 2000 at 03:23:25PM -, Perl6 RFC Librarian wrote:
Operator Overloading
-
PLUS Called in + context
MINUSCalled in - context
TIMESCalled in * context
DIVIDED
Everything in Perl becomes an object, using existing object-syntax. Out of
plain sight, there would be essentially three base classes: Scalar, List,
and Hash.
Arg! You beat me to it. :-) This was the next RFC on my list.
Stricter typing would be imposed (as needed) at the object level
Is it accurate to say that the list of things that would have to be
addressed is table 3-3 on p. 97 of Camel III (unlabelled table on p. 84 of
Camel II)?
Well, mostly. (Note that FH for readline(FH) also is *.c) for
glob('*.c')). I suppose we could forbid pick-your-own-quotes.
But remember
With threading coming, would having a () and () syntax be useful?
So within the () and () constructs STDIN and STDOUT (or perhaps only
the default filehandle) would be redirected.
sub proc_arg1 { while() { } }
sub proc_arg2 { while() { } }
while() {
({proc_arg1}, {proc_arg2})
I've RFCed making m mandatory on matches, which would remove some
of the current tokenizing confusion. I'm open to others.
Doesn't seem to be worth it -- there's so much history of
the mass convenience in Perl of being able to write
if (/foo/) { }
or
print if /foo/ /bar/
Moved to perl6-language from perl6-internals where it was "Remove
sockets from core"...
Tom Christiansen wrote:
I would like to see a set of "requirements" that make Perl what it is.
I think we all have a vague idea of what makes Perl great, but I'm also
sure there's a lot of variation.
On Fri 25 Aug, Nathan Wiger wrote:
I was sorta going under the assumption that would cause leading and
trailing whitespace to be ignored (not stripped) when looking for the
end-of-here-doc indicator. Because whitespace is ignored, I was then
proposing some new syntax for stripping
Jarkko Hietaniemi wrote:
" e q "
that breaks our long and glorious tradition of splitting tokens
on whitespace. How about e_q for this one?
That is, an operator that ignores any leading, any trailing, and treats
all intraspace as equivalent. If the embedded space is confusing, I
Tom Christiansen wrote:
print if /foo/ /bar/
Making things harder on users ...
Oh, puhlease; now you're telling us that requiring the user to
write instead
print if m/foo/ m/bar/
is "harder"? Come on; this is perl; if we tell 'em this is the way
it has to be done, and they do
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
"TC" == Tom Christiansen [EMAIL PROTECTED] writes:
TC Those weren't the scripts I was thinking about, and it is *NOT*
TC ipso facto true that something which uses $ or $` is poorly
TC written.
i wasn't claiming that. a short script using $ would be fine where you
don't care about the
There's also long been talk/thought about making $ and $1
and friends magic aliases into the original string, which would
save that cost.
Please correct me if I'm mistaken, but I believe that that's the way
they are implemented now. A regex match populates the -startp and
-endp parts of
There's also long been talk/thought about making $ and $1
and friends magic aliases into the original string, which would
save that cost.
Please correct me if I'm mistaken, but I believe that that's the way
they are implemented now. A regex match populates the -startp and
-endp parts of the
"MD" == Mark-Jason Dominus [EMAIL PROTECTED] writes:
There's also long been talk/thought about making $ and $1
and friends magic aliases into the original string, which would
save that cost.
MD Please correct me if I'm mistaken, but I believe that that's the way
MD they are
Tom Christiansen writes:
I'm just a bit concerned with the general notion that functions would under
some circumstances trigger in qq guys. It's a bit odd to explain that
things like abs() for $n+3 won't work, but $o-foo() would. Then again,
it's already curious with $a[$n+3]. :-)
those early perl3 scripts by lwall floating around in /etc were poorly
written. i am glad they are finally out of the distribution.
Those weren't the scripts I was thinking about, and it is *NOT*
ipso facto true that something which uses $ or $` is poorly
written.
--tom
Cooperative threads don't support multiple CPUs very well. If the choice is
made to do cooperative threads because it is easier, another choice should be
made to at least allow independent threads to exist, that do little sharing of
data, except via the I/O system (pipes or the equivalent), so
Dan Sugalski wrote:
At 02:49 AM 8/25/00 -0400, Steven W McDougall wrote:
Are Perl6 threads preemptive or cooperative?
Perl 6 threads will use the native threading system on each platform. To do
otherwise means an enourmous amount of mostly useless work. It's just not
worth it.
Nonsense.
At 12:51 PM 8/25/00 -0500, David L. Nicol wrote:
Dan Sugalski wrote:
At 02:49 AM 8/25/00 -0400, Steven W McDougall wrote:
Are Perl6 threads preemptive or cooperative?
Perl 6 threads will use the native threading system on each platform. To do
otherwise means an enourmous amount of
--On 25.08.2000 14:07 Uhr -0400 Dan Sugalski wrote:
Perl doesn't currently run on a system that doesn't have a reasonably
good threading library. Writing our own code would mean dedicating a few
programmer-months to do poorly what other folks have spent quite a few
programmer-years to do
Fisher Mark writes:
: For instance, if I'm running Perl on my Palm, I'd just as soon that
: index() were implemented in Perl using repeated substr() comparisons.
:
: How small do we really need to go?
It's not so much a matter of small as a matter of pluggable. But small
will continue to be
I'm not sure that we are talking about the same thing.
Probably not.
So if socket() is removed from the core (the executable). Perl upon
noticing a socket() without a user specified use that might override
it. Will transparently make it available along with all the associated
constants.
I've
I would like to see a set of "requirements" that make Perl what it is.
I think we all have a vague idea of what makes Perl great, but I'm also
sure there's a lot of variation. With a SHORT list of requirements, it
becomes much easier to address some of these issues that are radical
changes to
I don't think that you should require a use. That is too violent a
change. Moving things that were in the core of Perl5 out should be
invisible to the user.
I strenuosly object to having to add use, for every stupid module.
Anything that is part of the shipped perl should not need a use.
The
"CF" == Chaim Frenkel [EMAIL PROTECTED] writes:
CF I made the suggestino a while back, that if this is true for core. It
CF might be feasible for non-core modules (assuming some sort of registry)
CF so that an implicit use might be performed.
i am proposing such a registry which is a
On Fri, 25 Aug 2000 12:19:24 -0400, Dan Sugalski wrote:
Code you don't call won't eat up any cache space, nor crowd
out some other code. And if you do call it, well, it ought to be in the cache.
Probably a stupid question... But can't you group the code for the most
often used constructs? So
Dan Sugalski [EMAIL PROTECTED] writes:
At 10:08 PM 8/24/00 -0600, Nathan Torkington wrote:
Dan Sugalski writes:
One of the current plans is for the parser to have access to a list of
functions that trigger autoloading modules.
Isn't dynamic loading really slow?
Not particularly, at least
Tom Christiansen writes:
: Hard things should be easy, easy things should be trivial. We should try
: to keep the stuff that is commonly used in the core (excluding OS
: dependent stuff, perhaps? Non-Unix folks don't see the use for getpwent(),
: for instance).
:
: That's their problem. Perl
For instance, if I'm running Perl on my Palm, I'd just as soon that
index() were implemented in Perl using repeated substr() comparisons.
How small do we really need to go? Are we looking at implementing Perl for
microcontrollers, or are we only worrying about Perl for PDAs? The
difference
Come on Tom take it easy on us poor admins who have to live in the "Billduh"
world.
So long as such folks do nothing that will hurt those of us who
have no trek with such, then live and let live. But when Billness
starts biting those who won't have anything to do with it causing strange
Amen.
-Original Message-
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 25, 2000 3:09 PM
To: Lipscomb, Al
Cc: Joe McMahon; Stephen P. Potter; Michael Maraist;
[EMAIL PROTECTED]; 'Larry Wall'
Subject: Re: RFC 146 (v1) Remove socket functions from core
Come on
Jonathan Scott Duff wrote:
Operator Overloading
-
PLUS Called in + context
MINUSCalled in - context
TIMESCalled in * context
DIVIDED Called in / context
MODULUS
Jonathan Scott Duff wrote:
Operator Overloading
-
PLUS Called in + context
MINUSCalled in - context
TIMESCalled in * context
DIVIDED Called in / context
MODULUS
That's their problem. Perl is extremely useful to Unix systems
programmers and administrators. They are the target audience
that Perl was initially written for, whom it was made famous by,
and you will find that it continues to be very important to us.
If you relegate us to take a back seat
Tom Christiansen writes:
Also, there are many array operations (push, pop, etc) still not
supported by tie.
Eh? Either that's no longer true, or we're doing the time warp again.
Right you are. I'm still living in the 20th century :-)
Nat
Note that I am not subscribed to perl6-language-data, and that all the prior
discussion of
this RFC took place on -language. Perhaps it is better classified under -data, but
that's
not its present discussion list, according to the RFC.
"David L. Nicol" wrote:
Glenn Linderman wrote:
Looks like if we give the data type control over what
the meaning of square brackets after it is, the rest
becomes example code. I think this s covered in the
horribly misnamed http://dev.perl.org/rfc/115.pod which
covers overloading bracketing.
@reshaped = reshape $x, $y, $i, @array [,
Nathan Torkington wrote:
(1) The current
$pdl-slice("0:$n,(0)");
syntax sucks.
Would:
$pdl-[0:$n][0][:]
suffice? I figure this would translate into something like:
$pdl-subscript( 0, $n )
-subscript( 0 )
-subscript( undef, undef )
That is, you can
Nathan Torkington wrote:
Karl Glazebrook writes:
I agree with your sentiments. Most people in PDL DO come from the
number crunching/scientific background.
Whereas the rest of Perl users don't, and will probably never need the
matrix manipulation stuff. I think a happy medium would be
At 12:38 PM 8/25/00 -0600, Nathan Torkington wrote:
Dan Sugalski writes:
The operative word in that last sentence is "Currently"...
The problem is that you can tie() an array, but an object is a scalar.
Also, there are many array operations (push, pop, etc) still not
supported by tie.
Nat wrote:
5.6's regular expressions have (??{ ... }) to permit recursion and
$^R to maintain state through the parsing.
In another thread, Tomc wrote:
[...] Likewise the @+ and @- stuff.
Okay, I'm throwing my ignorance out for the whole world to see. WTF??
Sure, I'm not in the loop, as
At 08:29 PM 8/25/00 +, Nick Ing-Simmons wrote:
Benjamin Stuhl [EMAIL PROTECTED] writes:
AUTOLOAD searches are not cheap either. It can take a lot
of stat() calls to even _find_ the correct module, much
less load it. The average math function in the perl5 core
is about 13 lines of C code.
At 07:45 PM 8/25/00 +, Nick Ing-Simmons wrote:
The issue would be if you did two searches - one for Socket.so and then
_that_ had to go look for libsocket.so
So if the code is really just a thin wrapper on the system library then
taking it out will be a (small) performance hit.
This is
Besides, I'm more worried about unnecessarily loading 600k from disk,
than from main memory to cache. For short-lived scripts, this loading
overhead could be quite significant.
Why should that matter? Your kernel's VM system should compensate.
It's not like running a 3-line program really
Benjamin Stuhl [EMAIL PROTECTED] writes:
There's also the issue that _each_ symbol must be requested
manually and stored somewhere (in a MT-safe manner, of
course),
That is not the right way to do it. (I have seen the Tcl loader and
I think it is ugly.)
The loadable would export _one_
On Fri, Aug 25, 2000 at 09:20:53AM -0400, Dan Sugalski wrote:
At 09:12 AM 8/25/00 -0400, Stephen P. Potter wrote:
As you say, 200 lines isn't much. But combine that with the IPC, the
environment, the system, etc it all adds up.
Not to much, though. We've been down this road for perl 5.
perl5 sort of already has an Calways, in that DESTROY() methods
are called on any blessed lexicals when the scope closes. Taking
advantage of that for closing a file works if you hide your files
in an object class or equivalent chicanery.
Allowing user code into the list of things that perl
Benjamin Stuhl [EMAIL PROTECTED] writes:
It probably would. Dynamic loading is not cheap, and having
to do a dlopen() and a dlsym() (or a LoadLibrary() and a
GetProcAddress()) to find out the square root of 2 is not
my idea of a _useful_ lightweight programing language.
But if you add -lm to
Chaim Frenkel [EMAIL PROTECTED] writes:
I don't think that you should require a use. That is too violent a
change. Moving things that were in the core of Perl5 out should be
invisible to the user.
I strenuosly object to having to add use, for every stupid module.
Don't worry - so do Dan and I
"David L. Nicol" wrote:
Looks like if we give the data type control over what
the meaning of square brackets after it is, the rest
becomes example code. I think this s covered in the
horribly misnamed http://dev.perl.org/rfc/115.pod which
covers overloading bracketing.
Agreed. We should
Dan Sugalski wrote:
It looks like we need to be able to override operations on arrays, have
multi-dimensional arrays, and do some rather odd slicing operations that
give values still linked to the original matrices.
Has anyone asked for complex number support yet?
It's hidden in one or
At 09:56 AM 8/26/00 +1200, [EMAIL PROTECTED] wrote:
Dan Sugalski wrote:
It looks like we need to be able to override operations on arrays, have
multi-dimensional arrays, and do some rather odd slicing operations that
give values still linked to the original matrices.
Has anyone asked
David L. Nicol writes:
Looks like if we give the data type control over what
the meaning of square brackets after it is, the rest
becomes example code. I think this s covered in the
horribly misnamed http://dev.perl.org/rfc/115.pod which
covers overloading bracketing.
The big problem with
At 01:11 PM 8/25/00 -0600, Nathan Torkington wrote:
Heh, we're on the same page here. I'm just setting the framework
for that discussion. I don't think the PDL folks yet know what
they want, other than "better support for numerical structures".
I'm trying to see what's wrong with the existing
Dan Sugalski wrote:
to make foo and bar 5x5x5 matricies that you casn multiply to get baz then,
well, say it. If that means you need to define a way to provide overridden
operators in the Matrix package, then go for it and say that.
Let the -internals folks worry about the Weird Magic
Karl Glazebrook wrote:
The key from my point of view is to have enough syntactical
hooks in the core so that using it is not like wading through
treacle. Hence the PDL RFCs - especially on [] overloading and ranges.
The Numerical Python people seem to have accomplished this, and we can't
Nathan Wiger wrote:
Oh geez! I'm sorry, I forgot to mention David Nicol in the REFERENCES,
who also gave great input, especially on the BOOLEAN accessor. Thanks
David! I swear I'll put you in v2. :-{
-Nate
Whatever.
You could overload
FILE STRING
to be a print operator
You could overload
FILE STRING
to be a print operator returning a FILE so we can do C++ like
cout "hello Bjarne" eol;
That would be--and always has been--pretty darned horrible. You've
managed to hide the verb completely. It's much clearer when it
command verb is in the
eq and ne are far more confusing.
Hm. I've never had problems with this, although it does confuse me to go
back to the shell's [ ] (aka test) and have them be backwards.
Yeah, I've got them finally sorted out, it only took me about 5 years...
;-P
if ( $x == m/stuff/ ) { ... }
Tom Christiansen wrote:
So ripping all this 'cruft' would save us about 100-160 kB, still
leaving us with well over a 1MB-plus executable. It's Perl itself
that's big, not the thin glue to the system functions.
Moreover, if you rip out that 100-160 kb, allocating it to modules,
then I
or we can all darned well fake it at the very least.
More to the point, we *will* all at least fake it in public. I officially
do not care what anyone thinks of anyone else, and I am not interested in
personal animosities, snits, or grumpiness. We can all act like adults.
Adults do not call
nothing to do with 119 vs 88 discussion.
No, it isn't in any discussion, It's just how I imagine a
tokenizer/clarifier would work.
Any subroutine declaration, for instance
sub Cmp:infix($$){
return uc($_[0]) cmp uc($_[1])
};
implicitly sets up a "catch
The problem is, as long as expressions can be within each other,
and include terms that are multiple expressions, a robust deadlock
avoidance strategy is required even with cooperative threading.
In order to understand this, we need to think in more detail about how
the Perl interpreter
Are Perl6 threads preemptive or cooperative?
Last week, I asked whether Perl6 threads support SMP. There were a
handful of responses, mostly to the effect that
- we don't know
- we don't care
- we get whatever the native thread library gives us
This assumes that Perl6 uses the native thread
On Fri, 25 Aug 2000, David L. Nicol wrote:
That's what I was suggesting. And if you say $a = 1 + foo() you have
to give up your mutex on $a before calling foo(). So the programmer
would have to work these things out with the subroutines:
I would think that you'd have already called foo()
On Thu, 24 Aug 2000 21:06:30 -0700, Nathan Wiger wrote:
1. Ignore leading/trailing whitespace in here string terminators.
All of these should work:
EOL
EOL
EOL # this is the end of the here doc
I don't think a special syntax is needed just for this. Make
this the
Nathan Wiger wrote:
I do think
it's worth considering if we're dead-set on losing =~.
But are we? Have you looked at RFC139? I hope the niceities of it
for the perl programmer are more or less apparent.
--
John Porter
We're building the house of the future together.
On Thu, 24 Aug 2000 17:12:11 -0700, Peter Scott wrote:
eval {
open "some_name_for_a_file_that_does_not_exist";
# $! set to "file or directory does not exist"
undef;
}
# $! set to "" (or undef, whichever makes more sense) on
# eval block termination
Nathan Torkington [EMAIL PROTECTED] writes:
Read my lips: GOOD THING.
Do we have an RFC yet that proposes Perl to be easier parsable?
Damian?
-- Johan
[cc'ed to -regex b/c this is related to RFC 138]
Proposed replacements for m// and s///:
match /pattern/flags, $string
subst /pattern/newpattern/flags, $string
The more I look at that, the more I like it. Very consistent with split
and join. You can now potentially match on
Tom Christiansen [EMAIL PROTECTED] writes:
Keywords that *cannot* be overridden are chop, defined, delete, do,
dump, each , else, elsif, eval, exists, for, foreach, format, glob,
goto, grep, if, keys, last, local, m, map, my, next, no, package,
pop, pos, print, printf, prototype, push, q,
Well, *that* was certainly an interesting evening of emails to wade
through tonight.
On Fri, 25 Aug 2000, Dan Sugalski wrote:
Bingo! That's it in a nutshell. And every single thing that could possibly
need to be figured out would be done ahead of time so there's as little
overhead as
$a[$i][$j][$k] or $a[$i,$j,$k]
The second one has no useful meeting, "," is just an operator which
does nothing much useful in this context.
Not true, at least not in the Perl I know. :-) Here's a description of
what these do in Perl just to clarify:
$a[0][1][2]; # get a single
I'm here because:
* I think the PDL folks have valid needs
* I think a lot of people are having trouble making suggestions for
language changes that mesh well with other constructs in the
language.
* I'm not able to tell you want you need, but I will try to help
you come up
Do separate threads
- all see the same file-scoped lexicals
- each get their own file-scoped lexicals
#!/usr/local/bin/perl
use Threads;
my $a = 0;
my $t1 = Thread-new(\inc_a);
my $t2 = Thread-new(\inc_a);
$t1-join;
$t2-join;
print "$a";
sub inc_a
{
$a++;
}
What should the output
RFC1v3 says
5. Threads are a runtime construct only. Lexical scoping and
compile issues are independent of any thread boundaries. The
initial interpretation is done by a single thread. use Threads may
set up the thread constructs, but threads will not be spawned
until
At 02:49 AM 8/25/00 -0400, Steven W McDougall wrote:
Are Perl6 threads preemptive or cooperative?
Last week, I asked whether Perl6 threads support SMP. There were a
handful of responses, mostly to the effect that
- we don't know
- we don't care
- we get whatever the native thread library gives
--On 25.08.2000 2:49 Uhr -0400 Steven W McDougall wrote:
Now here's the trade off
performanceimplementation
preemptivehighhard
cooperative low easy
That's by far not that easy. Actually I've often seen cooperative threading
implemented
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Brace-matching for Perl Regular Expressions
=head1 VERSION
Maintainer: Eric J. Roode [EMAIL PROTECTED]
Date: 24 Aug 2000
Last Modified: 25 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Regular Expression Special Variables
=head1 VERSION
Maintainer: Uri Guttman [EMAIL PROTECTED]
Date: 25 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 158
=head1 ABSTRACT
Nathan Torkington wrote:
$foo-name . " says " . $bar-text . " hello to " . $baz-actor
which isn't a win!
You'll probably like RFC 103 then. It addresses this very thing. I just
didn't stop to think that m// was just a fancy qq//.
-Nate
First, $`, $ and $' will be scoped just like $1 and friends. They will
be set by the regex and be only accessible in the current block or a
block which starts with a regex like:
if ( /foo/ ) {
Good idea. $`, $, and $' will be used immediately 99% of the time.
For the rest of the time,
1 - 100 of 155 matches
Mail list logo
