/--- 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 mislead
Chaim Frenkel wrote:
>
> NW>$old = assign($var, $val);
> NW>$old = assign($var) = $val;
> NW>$old = assign = $var, $val;
>
> I don't think that the assigned values should be moved by perl into
> the argument list.
> You are reintroducing another version of the list flattening problem
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 ABS
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 differe
> "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 = doc
Peter Scott wrote:
>
> At 06:48 PM 8/24/00 -0600, Tony Olekshy 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 {
> sys
Watch the behaviour of this code snippet in a current Perl (5.6):
eval {
print STDERR "Testing...\n";
warn "Oops!";
print STDERR "Still going...\n";
die "Argh!!!";
print STDERR "I died, didn't I?\n";
};
print STDE
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();
>
Lightning flashed, thunder crashed and [EMAIL PROTECTED] (Johan Vromans) whi
spered:
| Do we have an RFC yet that proposes Perl to be easier parsable?
| Damian?
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 curr
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
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
Adv
Peter Scott wrote:
>
> So what about the possibility of user-defined q[a-z]// (using a letter that
> hadn't already been taken), where you get to specify the actions of =~ and
> probably more operators? Sounds like it has a lot in common with operator
> overloading - maybe even just an extens
[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 a
>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, imp
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 mos
--- "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
> 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 k
>That's the basic goal behind my RFCs for moving things to modules. In
>general, I hope to make the language cleaner, easier to learn and use, and
>easier to extend.
"Clean"? What is "clean"? Huh? And since when has Perl ever been
supposed to be "clean"? I've got plenty of quotage from La
Lightning flashed, thunder crashed and Jarkko Hietaniemi <[EMAIL PROTECTED]> whispered
:
| Is there are a problem with Math::Trig I've not been told about?
| Well, sqrt() is not strictly speaking just for trigonometry.
| But I wonder what log() is doing in the proposed list.
I wanted to write th
>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 forg
At 06:27 AM 8/25/00 -0700, Benjamin Stuhl wrote:
> > 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
>Perl is *not* fun when it supplies nothing by default, the way C does(n't).
>If you want a language that can do nothing by itself, fine, but don't
>call it Perl. Given these:
I agree!
Removing some of the things mentioned would turn Perl into an environment
well suited for computer science
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 remove
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 performan
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
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
>
I'm not sure which is the best mailing list to send this to, so forgive
me if I'm off.
I'll be glad to RFC this if there is interest.
There are several modules I've run across that require you to edit them
after you've installed them. I consider this to be a very bad thing.
What I'm thinking is
>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 for readline(FH) also is <*.c) for
glob('*.c')). I suppose we could forbid pick-your-own-quotes.
But remember
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
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}, <{
>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/
Perl6 RFC Librarian wrote:
> =head1 IMPLEMENTATION
>
> Probably has to be added to perl internals...
>
> I wonder what will happen with overloads though - is eq/i a new operator
> to overload or is the case-insensitivity somehow magically done by the
> Perl interpreter even though eq was overl
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. With a SHORT list of requirements, it
>
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
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,
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 th
At 10:57 AM 8/25/00 -0600, Tom Christiansen wrote:
>If your primary goal is trivial parsing, there's a *LOT* of other
>stuff you have to change. For example, no more pick your own quotes.
>And you can't have an angle operator, since it could be a less-than,
>nor can you have here docs, which migh
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
> "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 ab
> 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
>> 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
> "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:
> 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]. :-)
Var
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> $`, $& and $' are useful variables which are never used by any
>> experienced Perl hacker since they have well known problems with
>> efficiency.
TC> That's hardly true. I could show you plenty of code from
TC> inexperienc
Steven W McDougall writes:
> To express nesting, you need a context-free grammer; to recognize
> nested constructs, you need a stack machine.
>
> Going from REs to CFGs is a huge jump in the complexity of Perl, and
> trading in state machines for stack machines is a huge jump in the
> complexity
>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 t
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.
No
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
--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
> 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
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
[EMAIL PROTECTED] writes:
: "I'm Nathan, captain of the Metaperl Falcon. Tom Christian-bacca here
: is my first mate."
: "RRRWW!" Tom roars.
: Dan looks shocked.
: "Does he speak english?"
: Nathan shrugged.
: "Yeah, but he mostly prefers to just scream and shout."
This is not ter
> "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
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
>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'
>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
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
> "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
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
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
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
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. Per
> 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
Larry Wall writes:
> Tom Christiansen writes:
> : More of this nonsense, eh?
>
> Please don't use fighting words in here.
On the subject of fighting words, I owe everyone an apology for my
language on the subject of Perl being the only thing that can parse
Perl. I've been banging my head agains
>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
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
Jonathan Scott Duff wrote:
>
> >Operator Overloading
> >-
> >PLUS Called in + context
> >MINUSCalled in - context
> >TIMESCalled in * context
> >DIVIDED Called in / context
> >
>Jonathan Scott Duff wrote:
>>
>> >Operator Overloading
>> >-
>> >PLUS Called in + context
>> >MINUSCalled in - context
>> >TIMESCalled in * context
>> >DIVIDED Called in / context
Tom Christiansen wrote:
>
> I encourage one to examine how Python does this. Particularly attractive
> is the way one does not have to distinguish between tie and operator
> overloading there.
I'll check it out.
But just to clarify: This proposal means we won't be distinguishing
between tie a
>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 sea
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
>Right you are. I'm still living in the 20th century :-)
So are all of us -- just give it a few months, though. :-)
--tom
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
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
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. tie makes assumptions about arrays that are perha
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
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
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
>> >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
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
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
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
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
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 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
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
>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
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
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
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 per
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
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
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
"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
1 - 100 of 218 matches
Mail list logo
