> If =~ allowed "indirect object" notation as -> does, then we could write
>
> s $str (pat){rep};
> and
> for ( grok %db /Name/$name/g ) {
Yeah, but I'm not sure what those are supposed to do. They look way too
obscure for me.
As written I don't see an advantage in the RFC. I th
Chaim Frenkel wrote:
>
> NW> @stuff = docoolstuff(%hash, $var, @array);
> NW> @stuff = docoolstuff(%hash, $var) = @array;
>
> Then assignment arguments must be a the tail of the prototype. A bit
> of limitation.
No, that's not true:
@stuff = docoolstuff(@stuff) = %hash, $var;
@st
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
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 runtime.
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 outp
> > > $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 singl
[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 @mul
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()
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 poss
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 ea
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,
>
Tom Christiansen writes:
> further abuse as the next bandit decides to chew on you. As nobody
> else said mum about that scat, I took care of it myself.
90 minutes passed on a Friday night. That doesn't mean it wasn't
going to be dealt with.
> >(hint: grown-ups would apologise at this point)
>
Tom Christiansen writes:
: >Please act like a grown-up. Stephen cast the
: >first stone, but that's no excuse for you to reply with a boulder.
:
: Sure it is: when a hoodlum jumps you with a knife, there's no reason
: to roll over and quietly submit to the death of a thousand cuts.
: No, you pul
> But maybe the effect of $& is greatly exaggerated or is a relic from
> perl4? Has anyone actually benchmarked this recently?
Matching with $& enabled is about 40% slower.
http://www.plover.com/~mjd/perl/amper.pl
>And that's offensive.
What's offensive to one person is amusing to the next.
>Please act like a grown-up. Stephen cast the
>first stone, but that's no excuse for you to reply with a boulder.
Sure it is: when a hoodlum jumps you with a knife, there's no reason
to roll over and quietly subm
> >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 regex structure, and the elements of these items
> >are byte offsets into the original string.
>
> I haven't looked at it at all
Tom Christiansen writes:
> Your coquettish plot to reveal the desperate yearning of your
> nethermost alimentary canal for multiply redundant new egresses is
> neither charming nor
And that's offensive. Please act like a grown-up. Stephen cast the
first stone, but that's no excuse for you to re
Stephen P. Potter writes:
> =head1 TITLE
>
> Perl is Tom's private domain.
That's unproductive.
Nat
David L. Nicol writes:
> Any subroutine declaration, for instance
>
> sub Cmp:infix($$){
> return uc($_[0]) cmp uc($_[1])
> };
>
> implicitly sets up a "catch unknown-keyword:Cmp" routine; that is,
> it installs the name of the function in a place the clarifier will kno
Your coquettish plot to reveal the desperate yearning of your nethermost
alimentary canal for multiply redundant new egresses is neither charming nor
subtle--nor even innovative. Although it would be no great trouble for me
to don the vestments and sharpen the cutlery to serve as haruspex for so
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 25.08.2000 20:02 Uhr -0400 Steven W McDougall wrote:
> Others have pointed out that code inside sub-expressions and blocks
> could also assign to our variables. This is true, but it isn't our
> problem. As long as each assignment is carried out correctly by the
> interpreter, then each varia
> You could "kinda" make it look like a "real" function, as has occasionally
> been suggested:
>
> match(STRING, PATTERN, FLAGS)
>
> But before that gets too much support, that has several problems.
> First, unless you have rather clever new context coercion prototypes
> of type regex (which
Today around 5:50pm, Tom Christiansen hammered out this masterpiece:
: I've thought about it, and I believe that if were are going to require
: that the function be named every time, that is, via:
:
: m//
:
: that you should then just dispense with the slashes and make it a
: proper fu
At 11:55 PM 8/25/00 +, Ed Mills wrote:
>Having just coded some more perl resplendent with this syntax:
>
> $in{pmonth}=$usr{paidon};
> $in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/;
>
>once again I'll suggest (then I quit)
>
>$in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/,$in{paidon};
>
>
>is a LOT nic
Ed Mills wrote:
>
> Having just coded some more perl resplendent with this syntax:
>
> $in{pmonth}=$usr{paidon};
> $in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/;
>
> once again I'll suggest (then I quit)
>
> $in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/,$in{paidon};
>
> is a LOT nicer, and more Per
> 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 wor
>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 can guarantee you that it will
Having just coded some more perl resplendent with this syntax:
$in{pmonth}=$usr{paidon};
$in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/;
once again I'll suggest (then I quit)
$in{pmonth}=~s/^.+([A-Za-z]{3,3}).+$/$1/,$in{paidon};
is a LOT nicer, and more Perlish (see split) way of doing this. I'
>All in all, though, you're right that neither set of features is particularly
>well-known/used outside of p5p followers. At least from what I've seen.
>Virtually every person I've worked with since 5.6 came out has been surprised
>and amazed at the REx eval stuff.
The completely reworked regex c
I've thought about it, and I believe that if were are going to require
that the function be named every time, that is, via:
m//
that you should then just dispense with the slashes and make it a
proper function call:
m()
But then you'll find that "m" is a lame name for a functi
Markus Peter wrote:
> > 6: release all mutexes when leaving it for
> > any reason (and redoing 2 through 4 on reentry)
these reasons would include doing subroutine calls.
Which makes data loss possible, without explicit mutexes
on check points and if we've got those why bother with
implied one
>You could overload
> FILE < STRING
>to be a print operator returning a FILE so we can do C++ like
> cout << "hello Bjarne" <
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 unkn
Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED]
m> whispered:
| More of this nonsense, eh? I just fail to understand the urge
| to eviscerate. Why don't we just say that Perl isn't for
| systems work anymore, and remove everything that diddles $!,
| or $?, or anythin
perl5 sort of already has an C, 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 does on s
On Fri, Aug 25, 2000 at 03:46:59PM -0400, Eric Roode wrote:
> 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 ignor
David Corbin wrote:
> In addition to the four I posted, originally, I've added two. Here's my
> working list.
>
> native pattern matching;
> list manipulation
> aweswome text processing.
> It's application glue (thanks Tim)
> Ability to write powerful 1-line programs.
> Make easy things easy a
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 per
Dan Sugalski wrote:
> If it's decreed that fork is
> just there without having to do something special, then it will be no
> matter what magic needs to be done.
package refimpl::builtins;
sub fork {
$refimpl::threads::deepcopy_target = new refimpl::perprocglobal
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
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 w
My largely ignored RFC about "shell style redirection" suggested
pretty much this. perl5 has it as a feature hidden on the fourth page
of the perldoc for "open"
It also lets < neatly double as a compact print operator
Chaim Frenkel wrote:
>
> With threading coming, would having a >() and
You can make multidimensional containers in perl5 by settling
on a syntax for combining all the dimensions into a key value and
using that as the key in a hash.
If arrays as we know them implement by using a key space restricted to
integers, I think a reasonable way to get matrices would be to o
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
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 operato
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 any
--On 25.08.2000 16:20 Uhr -0500 David L. Nicol wrote:
>
> 1: make a list of all variables referenced w/in expression
>
> 2: obtain global mutex-setting sceptre (block for this)
>
> 3: block until allowed to set mutexes on entire list in 1
>
> 4: release sceptre
>
> 5: run expression
>
> 6: releas
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> This is good for comparison but bad for math. Epoch seconds are
NT> good for both. That's why *I* use them. You can continue to use
NT> ISO mumble and have it work for you. I'm not breaking your code.
NT> There's also the issue
Tom Christiansen wrote:
> There's also long been talk/thought about making $& and $1
> and friends magic aliases into the original string, which would
> save that cost.
I was distressed to discover that s///g does not rebuild the
old string between matches, but only at the end. It broke my
ran
Michael G Schwern wrote:
> Compare:
>
> dbmopen(%foo, 'somefile', 0644);
>
> with:
>
%foo:persistent(file=>somefile);
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 o
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 ac
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 o
"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 sh
On Fri, Aug 25, 2000 at 09:12:32AM -0400, Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and Michael G Schwern <[EMAIL PROTECTED]> wh
> ispered:
> | PS The idea of adding acos, asin and tan is good.
>
> You just answered your own question. It is very difficult to add new
> functi
At 09:28 PM 8/25/00 +0200, Bart Lateur wrote:
>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 yo
Karl Glazebrook wrote:
> "->" really sucks as something to routinely type in to a interactive shell
> all the time. I hate it.
I can not agree more. It just seems terribly unnecessary.
Just allow us to directly overload some of the braces/parentheses for
objects.
I would be happy with
$pdl(0:
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
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
Steven W McDougall wrote:
>
> Thread1 Thread2
> $a = $b;$b = $a;
>
> preemptive threading requires
> - mutexes to protect $a and $b
> - a robust deadlock avoidance strategy
I think a robust deadl. avd. strat. is something like:
1: make a list of all variables
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 exist
Bart Lateur <[EMAIL PROTECTED]> writes:
>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 th
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 a
On Fri, 25 Aug 2000 11:17:19 -0600 (MDT), Nathan Torkington wrote:
>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.
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an ope
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
hashes and regexes, and the scripting aspect (no explicit, seperate compile
step).
Its not the ONLY language with these aspects, but its the only one I know of
with ALL of them. Also I like the feeling of community and in some respect,
rebellion.
Anyhow those are what distinguish Perl for me.
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_
>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 rel
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 w
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
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 [,
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 t
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 particula
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 ce
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Split Scalars and Objects/References into Two Types
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Last-Modified: 25 Aug 2000
Version: 2
Mailing List: [EMAIL PR
Nathan Torkington wrote:
>
> moving getprotobyname()
>to a module isn't the same as moving open().
And it can be transparent, if it isn't already. Why does perl
need to be monolithic? I thought I selcted to build as shared
libraries, splitting that into several shared libraries might
be e
Last week when I wrote "everything is an exception" this is what
I was talking about.
Nathan Torkington wrote:
> This raises another issue, though:
>
> You'd obviously want to have a module that collected together your
> favourite new operators. But if they were lexically scoped, they'd
>
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
> "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 whic
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:
>
> > Ed
> Writing a threads package correctly is a non-trivial thing to do.
We don't have to write a threads package.
We just have to thread the interpreter.
There's a difference.
> Perl doesn't currently run on a system that doesn't have a reasonably good
> threading library.
I abandoned an NT -> M
>Right you are. I'm still living in the 20th century :-)
So are all of us -- just give it a few months, though. :-)
--tom
> "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>
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
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 To
>> 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 p
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 ent
>Why wouldn't you want to just get rid of the whole construct? Is there any
>need for it?
It seems safer to kill it.
--tom
>> >The problem is that you can tie() an array, but an object is a scalar.
Yes, Python unifies these.
>> >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.
--tom
Dan Sugalski writes:
> Sure, it's handwaving, but it's handwaving with a purpose. What I don't
> want is for people to get bogged down by the limits of what perl 5
> provides, or what looks to be some sort of reasonable extrapolation
> of those features.
>
> If a fully working tie's what you
>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
acti
>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'
At 02:48 PM 8/25/00 -0400, Chaim Frenkel wrote:
>My understanding of -internals (and Dan) is that all the current perl
>(or whatever Larry leaves) will continue to be there. It is an internals
>issue where it really lives.
>
>So if socket() is removed from the core (the executable). Perl upon
>not
--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
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,
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
> > >suppor
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> Perl is *not* fun when it supplies nothing by default, the way C does(n't).
TC> If you want a language that can do nothing by itself, fine, but don't
TC> call it Perl. Given these:
I'm not sure that we are talking about the same t
> 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
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 strip
1 - 100 of 218 matches
Mail list logo
