/--- 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
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,
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
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
>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
>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
> >I don't understand this desire to not want anything to change.
>
> You misread.
I sympathise. There are definate goals and focuses that each language is
built around.. Change these too much, and you have a different language,
while at the same time, alienating the people that chose that langu
At 10:53 AM 8/25/00 -0400, [EMAIL PROTECTED] wrote:
>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
At 11:55 AM 8/25/00 -0400, Michael Maraist wrote:
> > You will *not* improve the performance of the inner interpreter
> > loop by having fewer opcodes to switch on. Whether the number is
> > 20 or 200, it's the same thing--*think* aboutit.
>
>Well, not strictly true. Though the raw code will not
>Or, more succinctly, we're not going to screw with perl without a *darned*
>good reason.
This is the most beautiful thing I've read in days.
--tom
Dan Sugalski writes:
: Or, more succinctly, we're not going to screw with perl without a *darned*
: good reason.
Er, perl is already screwed--it's Perl we're trying to preserve and grow.
Larry
Dan Sugalski wrote:
>
> Or, more succinctly, we're not going to screw with perl without a *darned*
> good reason.
Well, in the big picture, we *are* screwing with perl, and we know
that we have darned good reason to.
But to apply this metric to every fine-grained aspect of perl5 is silly.
Perl
Tom Christiansen writes:
: >Or, more succinctly, we're not going to screw with perl without a *darned*
: >good reason.
:
: This is the most beautiful thing I've read in days.
Bear in mind there are lots of darned good reasons. :-)
Larry
Larry Wall wrote:
> Dan Sugalski writes:
> : Or, more succinctly, we're not going to screw with perl without a *darned*
> : good reason.
>
> Er, perl is already screwed--it's Perl we're trying to preserve and grow.
Man; leave it to Larry to say the right thing, in the best way. :-)
--
John P
>But to apply this metric to every fine-grained aspect of perl5 is silly.
>Perl6 should be a well-designed, consistent, integrated opus.
>If it goes against the grain of perl6's design to have system-specific
>system calls built in, then they shouldn't be built in, regardless of
>how it was in pe
Tom Christiansen wrote:
> >But to apply this metric to every fine-grained aspect of perl5 is silly.
> >Perl6 should be a well-designed, consistent, integrated opus.
> >If it goes against the grain of perl6's design to have system-specific
> >system calls built in, then they shouldn't be built in,
>Well, duh. So what? Did you really miss my point by so many furlongs?
Whatever.
>> You'll take my fork when you pry it out of my cold, dead hands.
>Perl will ship with fork. But maybe in a loadable library, eh?
More of this nonsense, eh? I just fail to understand the urge
to eviscerate.
You don't beneficially make Perl any more anything by ghettoizing
its useful systems functionality. You certainly don't make it
more "portable". I still can't use any of my myriad useful systems
hackery script if I try to run them on CP/M, and you aren't going to
change that one whit. So what
Tom Christiansen wrote:
>
> Why don't we just say that Perl isn't for
> systems work anymore, and remove everything that diddles $!,
> or $?, or anything that might call anything from the C library.
As in "remove mountains", yes.
--
John Porter
We're building the house of the future
At 10:52 AM 8/25/00 -0600, Tom Christiansen wrote:
> >But to apply this metric to every fine-grained aspect of perl5 is silly.
> >Perl6 should be a well-designed, consistent, integrated opus.
> >If it goes against the grain of perl6's design to have system-specific
> >system calls built in, then t
Tom Christiansen wrote:
>
> >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 t
Folks,
I know everyone's got their own opinions on yanking functions (or not) from
the core interpreter image, but I'd like to remind everyone that this is
the *internals* list, not the language list. Our primary purpose is to
build a system that runs Perl fast and provides a platform others c
At 09:38 AM 8/25/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Or, more succinctly, we're not going to screw with perl without a *darned*
>: good reason.
>
>Er, perl is already screwed--it's Perl we're trying to preserve and grow.
Hey, look! A good reason! :)
At 09:39 AM 8/25/00 -0700, Larry Wall wrote:
>Tom Christiansen writes:
>: >Or, more succinctly, we're not going to screw with perl without a *darned*
>: >good reason.
>:
>: This is the most beautiful thing I've read in days.
>
>Bear in mind there are lots of darned good reasons. :-)
You'll notic
On Thu, 24 Aug 2000, Stephen P. Potter wrote:
> I have several RFCs I need to write about removing certain functionality
> out of the core (math functions, IPC, networking, "user"). I don't want to
> go too overboard. I don't know that we want to go so far as to remove
> printing and such. It
>If the behind-the-scenes shenanigans are invisible and performance is at
>worst acceptable, does it really matter how things are implemented?
So long as you can still say things like
perl -le 'print scalar getpwuid(1)'
and that script still continue to work unaltered, then I suppose
not--
Imagine a combined hash/array CONTAINER type. The difference between
hashes and arrays becomes that arrays are restricted to non-negative integer
key values. @grumpy and %grumpy can even have the same head node in their
data structure, but the accessors will, unless told otherwise, only pick o
Tom Christiansen wrote:
>
> >If the behind-the-scenes shenanigans are invisible and performance is at
> >worst acceptable, does it really matter how things are implemented?
>
> So long as you can still say things like
>
> perl -le 'print scalar getpwuid(1)'
>
> and that script still contin
Tom Christiansen writes:
: More of this nonsense, eh?
Please don't use fighting words in here.
: 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 anything that might call anyt
At 01:34 PM 8/25/00 -0400, Joe McMahon wrote:
>In my opinion, Perl6 should still be a language in which
>it is easy to write powerful and useful programs on the command line.
A very nice opinion it is, too. I fully agree.
It lies, however, within the purview of the -language list, not -internals
At 11:36 AM 8/25/00 -0600, Tom Christiansen wrote:
> >If the behind-the-scenes shenanigans are invisible and performance is at
> >worst acceptable, does it really matter how things are implemented?
>
>So long as you can still say things like
>
> perl -le 'print scalar getpwuid(1)'
>
>and that
>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 is extremely useful to Unix systems
(voice over)
When we last left our heroes,
Dan Sugalski-Walker , Master Larry Wall
Damian-3P0, and FurB-D2
were on their way to find a fast ship.
With the plans for perl 6 in the memory banks of FurB-D2,
they were going to the Monterey System to announce the
start of Perl 6 and to marshal togethe
Joe McMahon writes:
: On Thu, 24 Aug 2000, Stephen P. Potter wrote:
:
: > I have several RFCs I need to write about removing certain functionality
: > out of the core (math functions, IPC, networking, "user"). I don't want to
: > go too overboard. I don't know that we want to go so far as to re
>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
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
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 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
>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
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_
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
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
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
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
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
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
>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
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
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
Stephen P. Potter writes:
> =head1 TITLE
>
> Perl is Tom's private domain.
That's unproductive.
Nat
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
>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
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
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 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,
>
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
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
At 02:06 PM 8/25/00 -0400, Uri Guttman wrote:
>i like that. but is that only platform implementation specific? i see a
>possibility of requesting (via a pragma) an alternative implementation of
>binary (see i used the new term!).
I'd like to get overridable opcode functions and function functions
i cc'ed to language as this issue spans then as well as internals.
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> We're fighting multiple definitions of "core" here. Please distinguish
LW> the core of the language from the core of the implementation--they're
LW> two entirely di
85 matches
Mail list logo
