RE: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Al
>I entreat you to explain to me *anything* that you'd want to tweak >with this that you already can't do right now. When I need to move Perl files from a default location to a new one. For example messing with @INC (and its like). THis could be used for example on a machine that has both develop

RE: RFC 114 (v2) Perl resource configuration

2000-09-01 Thread Al
>That's a fine answer, but a completely different concern. Sorry, you are correct. I looked up the RFC (there are getting to be so many I cannot trust memory any more). What I am thinking of is a file that, if present and sane (i.e. read-only root), would be involked by the interpreter just bef

RE: Proposal: chop() dropped

2000-08-30 Thread Al
>>I'll second that motion. We already have lots of ways of removing the >>last character of a string if that's what we really need. >But they're slow and hard to read. I would actualy like to see chop expanded to allow a variable number of characters to be removed and a sister function to cut

RE: Apoc2 - concerns

2001-05-07 Thread Lipscomb, Al
> > $$STDIN # Return one element regardless of context. > @$STDIN # Return number of element wanted by context. > *$STDIN # Return all element regardless of context. > How about $STDIN.$ # Return one element regardless of context.

RE: RFC 146 (v1) Remove socket functions from core

2000-08-24 Thread Lipscomb, Al
>No idea what the internals reasons are. Here are my reasons: It would be a good idea to work over the way sockets are used and maybe come up with a better model than the C/Unix like way things are now. Having sockets in the core makes as much sense as having the ability to open and read disk

RE: RFC 146 (v1) Remove socket functions from core

2000-08-25 Thread Lipscomb, Al
>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

RE: RFC 146 (v1) Remove socket functions from core

2000-08-25 Thread Lipscomb, Al
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

RE: RFC 146 (v1) Remove socket functions from core

2000-08-25 Thread Lipscomb, Al
>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

RE: RFC 146 (v1) Remove socket functions from core

2000-08-26 Thread Al Lipscomb
I wonder if you could arrange things so that you could have statically linked and dynamic linked executable. Kind of like what they do with the Linux kernel. When your installation is configured in such a way as to make the dynamic linking a problem, just compile a version that has (almost) every

RE: Do we really need eq?

2000-08-29 Thread Lipscomb, Al
>>I'd like to see every number bundled with a "precision" attribute. >That's not what I call a high-level language feature. People don't >want to think about that, nor about machine-level precision issues. >See REXX. >In fact, I'd rather to see a painless and transparent int->float->bignum >