Uri Guttman <[EMAIL PROTECTED]> writes:
> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>
> >> many systems allow for a global/local startup file for various
> >> reasons. i see a potential use of this in perl but i don't see the
> >> specific use yet. build it they will use i
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> many systems allow for a global/local startup file for various
>> reasons. i see a potential use of this in perl but i don't see the
>> specific use yet. build it they will use it.
TC> But Perl is not an interactive shell! Ca
Can't quite run perl yet.
http://www.tomshardware.com/cpu/00q3/000901/index.html
>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 before the users script was
>parsed. Looking at your example of things in the config file, well some of
>those are the things I would like to be able to get at in the new ve
>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
>Well, it only does this if it's not something like 'split', then!
Yes, it does "do it" with split. split is defined to do what it
does, how it does it. *This* is the kind of senseless harping that
annoys me, Nathan.
> So it's not 100% consistent.
Wrong: It's 100% consistent with the docume
> >Let me shift gears and instead ask whether anyone thinks this:
>
> >> > $y = ($first, $second) = grep /$pat/, @data;
>
> >Returning "5" has any value? If you're going to do this, it seems like
> >you'd want the number that were really returned (since scalar grep
> >will give you the total n
>>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 dev
>Let me shift gears and instead ask whether anyone thinks this:
>> > $y = ($first, $second) = grep /$pat/, @data;
>Returning "5" has any value? If you're going to do this, it seems like
>you'd want the number that were really returned (since scalar grep
>will give you the total number found an
>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
On Fri, Sep 01, 2000 at 05:50:52PM -0600, Tom Christiansen wrote:
> Why are you using -w instead of use warnings, and can you just imagine the
> howling? This would surely kill your system.
Okay, okay, okay. You're the nth person that brought that up. Yes,
"use warnings" makes more sense than
On Fri, Sep 01, 2000 at 05:49:05PM -0600, Tom Christiansen wrote:
> >On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote:
> >Like any other environment variable which the admin wants to be
> >everywhere, put it in /etc/profile. A well configured system will
> >handle it from there.
>
> N
Tom Christiansen wrote:
>
> % man perlfunc
> ...
> When assigning to a list, if LIMIT is omitted, Perl supplies a
> LIMIT one larger than the number of variables in the list, to
> avoid unnecessary work.
As usual I picked a bad example. And I did read the perlfunc manpage,
bu
On Sat, Sep 02, 2000 at 09:42:09AM +1100, Jeremy Howard wrote:
> I'd like to see negative numbers work. Otherwise the programmer would have
> to explicitly check whether an index into a string was positive or negative,
> take the absolute value, and use pop() or shift() as appropriate.
This has t
>many systems allow for a global/local startup file for various
>reasons. i see a potential use of this in perl but i don't see the
>specific use yet. build it they will use it.
But Perl is not an interactive shell! Can you imagine if a C
compiler allowed arbitrary amounts of text to be pre-inc
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> How are you going to enable strict in an unrelated lexical scope?
TC> Why are you using -w instead of use warnings, and can you just imagine the
TC> howling? This would surely kill your system.
like i said, i wasn't sure of
>it can be used for system specific @INC paths without
>recompiling perl
That's what PERL5LIB is for.
enforcing strict/-w/-T on all scripts, etc.
How are you going to enable -T from this file you're going to eval?
How are you going to enable strict in an unrelated lexical scope?
Why are you u
>On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote:
>> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> >> i think an environment var might be a good way. if it is set, it is the
>> >> file(s) to preload before running your code.
>>
>> TC> You've got PERL5OPT.
>>
>>
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
>> who runs one liners with -T?
MGS> That's the point. .perlrc would effect all perl, including
MGS> one-liners. What's good for big programs is not good for small.
>> what about making the rc files load only if there is cod
On Fri, Sep 01, 2000 at 07:42:32PM -0400, Uri Guttman wrote:
> > "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
> >> i think an environment var might be a good way. if it is set, it is the
> >> file(s) to preload before running your code.
>
> TC> You've got PERL5OPT.
>
> but that
>but that is the user's to set. PERL_PRELOAD
is there for the user to unset.
>allows the admin to globally
>set (in the system shell rc file) the rc files that perl will load.
And what sorts of things might the admin care to globally set?
--tom
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> i think an environment var might be a good way. if it is set, it is the
>> file(s) to preload before running your code.
TC> You've got PERL5OPT.
but that is the user's to set. PERL_PRELOAD allows the admin to globally
set (in t
On Fri, Sep 01, 2000 at 07:16:13PM -0400, Uri Guttman wrote:
> > "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
> MGS> Forcing -T on Will break most existing programs.
> MGS> Makes one-liners annoying.
>
> who runs
>i think an environment var might be a good way. if it is set, it is the
>file(s) to preload before running your code.
You've got PERL5OPT.
Heck, I bet you could do a cleverness with .perldb, too. :-)
--tom
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
MGS> Here's a little pros/cons list running through my head right now...
MGS> pro con
MGS> Customize @INC We have PERL5LIB
MGS> Forcing -T on
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: lazy
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 123
Status: Developing
>Forcing -w on Makes one-liners annoying.
>Makes running existing programs
>annoying.
>We have PERL5OPT
You forgot the con that we've supposed to be "u
On Fri, Sep 01, 2000 at 08:46:50PM -, Perl6 RFC Librarian wrote:
> Many programs have so-called "resource configuration" files (at least
> that's what I call them) that are loaded and executed upon program
> startup. Some example programs that have this ability include bash,
> mutt, and pytho
Let's take an example...
> sub *DESTROY {
> # Perl-special
> }
How would you call this manually, as you sometimes want to do?
*DESTROY $self;
$self->*DESTROY;
So you'd have to redo Perl's parsing of *? Would this override
typeglobs? How would the precedence wo
Michael G Schwern wrote:
> If pop @array, -1 == shift @array, 1 and shift @array, -1 == pop
> @array, 1, and if both Ways To Do It are almost exactly the same, then
> there's no value to allowing negative numbers. In most cases I'd
> expect passing a negative number to be a mistake on the program
On Fri, Sep 01, 2000 at 08:38:18PM -, Perl6 RFC Librarian wrote:
> =head1 IMPLEMENTATION
>
> I don't know the gory details other than it should be possible.
Thinking in perl5 terms, its going to require a modification to pp_pop
and pp_shift. The simplest way to do it would be for them to si
>> If you write
>>
>> $burp = LISTIFY( grep {EXPR} @data );
>>
>> What's in the burp?
>By this argument, then why aren't these different?
It depends on whether you think the alpha or beta are
what you want. It's highly unclear why you aren't just
using straight scalar context t
"David L. Nicol" wrote:
>
> No, that would be
>
> dog $spot;
No, it wouldn't:
$r = new CGI;# CGI->new
See?
> You can have your general consensus, I'm not in his army.
Well, unfortunately I think you're doomed to fail then. You're forcing
constraints on yourself that Perl cann
> Email from Nathan Wiger <[EMAIL PROTECTED]> that went to perl6-language
> but I can't find at www.mail-archive.com :-(
Here ya' go:
http://www.mail-archive.com/perl6-language@perl.org/msg02432.html
http://www.mail-archive.com/perl6-language@perl.org/msg02454.html
-Nate
Tom Christiansen wrote:
>
First off, thanks for taking the time to present such a thorough
document. Well-reasoned arguments is exactly what the Perl 6 project
needs, IMO.
I read this early last night, and have been postulating on it ever
since. In the process of trying what feels like 100's of
On Fri, Sep 01, 2000 at 03:13:04PM -0600, Tom Christiansen wrote:
> Can't you do this with with an environment setting?
>
> Shell people seem to think this a normal notion, but it's caused
> horrible security flaws in the past. And I couldn't imagine it of
> a C compiler, so I don't know why you
> Well, Damian is indeed the soul of good taste. Just look at the Latin
> and Klingon modules. Hmm... maybe those weren't such good examples.
I SHOULD KILL YOU FOR THAT!
;-)
I'll release the latest draft of the parameter lists RFC early next week.
I think you'll find the syntax
Can't you do this with with an environment setting?
Shell people seem to think this a normal notion, but it's caused
horrible security flaws in the past. And I couldn't imagine it of
a C compiler, so I don't know why you would do this one.
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl resource configuration
=head1 VERSION
Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 114
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposal to rename C and C
=head1 VERSION
Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECTED]
Version: 3
Number: 74
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposal to utilize C<*> as the prefix to magic subroutines
=head1 VERSION
Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Last-Modified: 1 Sep 2000
Mailing List: [EMAIL PROTECT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Optional 2nd argument to C and C
=head1 VERSION
Maintainer: Jonathan Scott Duff <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Last-Modified: 1 Sep 2000
Version: 3
Mailing List: [EMAIL PROTECTED]
Number:
>I read your message and agree. Not that I liked the idea that much even
>before considering the ramifications. But do you agree that even
>seasoned perlers have trouble anticipating how a list/array is going to
>be converted to a scalar?
A list or array? No, I don't agree. How to predict what
The thing is that so far, Perl has survived on extremely simple
variable types:
SCALAR: singular generic values
ARRAY: ordered lists of SCALARs
HASH: unordered association of SCALARs
Sure, you have special-purpose accessors like the "%" operator or
s/// or pop or exists or even v
Nathan Wiger wrote:
>
> "David L. Nicol" wrote:
> >
> > They gain us compliance with the whims of the people who like barewords
> > for variable names. You may or may not find that to be a good thing.
>
> It's not just that I don't think dropping $'s is a good idea, but that
> is the general co
On Fri, Sep 01, 2000 at 11:23:16AM -0700, Steve Fink wrote:
> I read your message and agree. Not that I liked the idea that much even
> before considering the ramifications. But do you agree that even
> seasoned perlers have trouble anticipating how a list/array is going to
> be converted to a sca
> for reality here. That should be written more like:
>
> 1 while ; $burp = $.;
>
> or even:
>
> for ($burp = 0; my $line = ; $burp++) {}
I'd go for
my $burp = 0; $burp++ while ;
> This proposal should be dropped.
I read your message and agree. Not that I liked the
Eric Roode wrote:
> I wonder if it might not be a good idea to implement a function to
> compute the intersection of two sets-as-hashes.
>
> Intersection is the only basic set function that's not trivially
> implementable with perl hashes. Sure, it's not hard to do, with
> a loop and a small bi
"David L. Nicol" wrote:
>
> They gain us compliance with the whims of the people who like barewords
> for variable names. You may or may not find that to be a good thing.
It's not just that I don't think dropping $'s is a good idea, but that
is the general consensus as well. I can't see
dog
I wonder if it might not be a good idea to implement a function to
compute the intersection of two sets-as-hashes.
Intersection is the only basic set function that's not trivially
implementable with perl hashes. Sure, it's not hard to do, with
a loop and a small bit of programming, but maybe it
Bart Lateur wrote:
>
> If you say
>
> keys %hash = 200;
>
> then `%hash' will have at least 200 buckets allocated for
> it--256 of them, in fact, since it rounds up to the next power
> of two.
This should go away, of course.
--
John Porter
On Fri, 1 Sep 2000 10:23:27 -0400, John Porter wrote:
>> keys %HASH = LIST;
>>
>> is really
>>
>> @HASH{ LIST } = ();
>
>Sure. Would you have any great objection to adding the alternative syntax?
I have some doubts. See perlfunc -f keys, from which I quote:
If you say
k
Sam Tregar wrote:
>
> On Thu, 31 Aug 2000, David L. Nicol wrote:
>
> > We're talking about making a faster Perl. C's syntax requires enough
> > clarity to compile to something quick. it is a very short hop from
> > my dog $spot;
> > to
> > dog spot;
>
> What about the second versi
Nathan Wiger wrote:
>
> "David L. Nicol" wrote:
> >
> > my dog $spot;
> > to
> > dog spot;
> >
> > If we only allow this where enough info is available to allocate dog-sized
> > pieces of memory directly, Perl can blaze through the code that deals with
> > dogs.
>
> I don't see w
Bart, until you've read my long message, you're wasting my time.
Please read it.
--tom
>To be consistent, "scalar list" should return the number of elements.
Says who? $x = ("foo", "bar") produces "bar", not 2.
It's all a big looney tune. "scalar list" makes negative sense.
If you want a count function, write one, but don't pretend that
"scalar list" is such a thing, nor that "s
On Fri, 01 Sep 2000 07:30:54 -0600, Tom Christiansen wrote:
> % man perldata
>
> List assignment in a scalar context returns the number of
> elements produced by the expression on the right side of
> the assignment:
>
> $x = (($foo,$bar) = (3,2,1)); # set $x to
Tom Christiansen wrote:
> Until you start thinking of terms of hashes, you aren't thinking
> in Perl. It serves no good to delay this epiphany. Also, remember
> that being a "novice" is a temporary and curable condition. Perl
> is designed to for long-term ease of use, not short-term learn-fre
>But, Do you really think that all these ingenuities, to not use another
>term, are really natural and easy to understand to novice programmers ?
Until you start thinking of terms of hashes, you aren't thinking
in Perl. It serves no good to delay this epiphany. Also, remember
that being a "novi
John Porter wrote:
>
> Buddha Buck wrote:
> >
> > In a hash implementation, your hash keys -are- your set elements!
> >
> > my %set;
> >
> > # add elements to %set
> > $set{'elem1','elem2'} = 1;
> >
> > # Compute union
> > $union{keys %set1, keys %set2} = 1;
>
> Oh, yeah, using native hashes for
>> keys %HASH = LIST;
>> is really
>> @HASH{ LIST } = ();
>Sure. Would you have any great objection to adding the alternative syntax?
Nope.
--tom
Tom Christiansen wrote:
> >If it were possible to assign to the keys of a hash, we'd be
> >a lot closer to our ideal:
>
> > keys(%intersection) = map { exists $set1{$_} ? ( $_ => 1 ) : () } keys
>
> >but this is not currently legal perl.
>
> keys %HASH = LIST;
>
> is really
>
> @HAS
>If it were possible to assign to the keys of a hash, we'd be
>a lot closer to our ideal:
> keys(%intersection) = map { exists $set1{$_} ? ( $_ => 1 ) : () } keys
>but this is not currently legal perl.
keys %HASH = LIST;
is really
@HASH{ LIST } = ();
--tom
Buddha Buck wrote:
>
> In a hash implementation, your hash keys -are- your set elements!
>
> my %set;
>
> # add elements to %set
> $set{'elem1','elem2'} = 1;
>
> # Compute union
> $union{keys %set1, keys %set2} = 1;
Oh, yeah, using native hashes for sets -- what could be simpler?
(Hint:
@s
Eric Roode wrote:
> Adjust your thinking a bit, not the language. Try:
>%my_fruit_set = (orange => 1, lemon => 1);
>or
>@my_fruit_set{qw/orange lemon/} = ();
Yes, probably, this could be easiest... :)
But, maybe because I'm a mulish person, I still thinking that if we
actually use such
At 03:40 PM 9/1/00 +0200, Gael Pegliasco wrote:
> >
> > Arrays are ordered.
> > Hashes are not.
> > Neither are sets.
> >
> > Arrays can have repetitions.
> > Hashes can not.
> > Neither can sets.
> >
> > etc.
> >
> > --tom
>
>
>Yes, this is true, but the natural syntax, fo
Bart Lateur wrote:
>
> $\ = "\n"; print $a = () = qw(a b c);
> -->
> 3
>
> All those who expected that the list would be evaluated in array (not
> list!) context, raise your hands.
this illustrates why the whole subject is, or can be, so confusing.
That qw() list was NOT evaluated
Gael Pegliasco wrote:
>
>Yes, this is true, but the natural syntax, for me, to manipulate sets,
>is the one of arrays.
>
>It is not natural to write :
>
>%my_fruit_set = ( 1 => 'orange', 2 => 'lemon' );
>
>but it is natural to write :
>
>@my_fruit_set = ( 'orange', 'lemon' );
>
>I don't want to ha
>
> Arrays are ordered.
> Hashes are not.
> Neither are sets.
>
> Arrays can have repetitions.
> Hashes can not.
> Neither can sets.
>
> etc.
>
> --tom
Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.
It is not natural to w
> $\ = "\n"; print $a = () = qw(a b c);
>-->
> 3
>All those who expected that the list would be evaluated in array (not
>list!) context, raise your hands. Not many, I would think.
What the devil is "array context"? You mean the thing that push expects
for its first argument? Just w
Also: have you looked at what's on CPAN for handling sets?
Here's a casual search result:
Math::Expr::MatchSet Set::Scalar
Math::Expr::VarSet Set::Scalar::Base
ObjStore::SetSet::Scalar::Null
ObjStore::SetEmulation Set::Scalar::Real
Set
>I already proposed that. Benchmarks show that reading a file with
>explicit chomp() is easily 20% slower than reading the same file with
>implicit chomp(), through the -l command line switch.
And what, pray tell, do you do about the small matter of wanting
to read some files without implicit rec
On Fri, 1 Sep 2000 08:33:24 -0400 (EDT), Eric Roode wrote:
>For that matter, let's drop chomp(), eh?
I already proposed that. Benchmarks show that reading a file with
explicit chomp() is easily 20% slower than reading the same file with
implicit chomp(), through the -l command line switch.
The
>I don't care about keys when I'm working with sets, and I don't want to
>have to deal with them.
>Then, if when implementing these new functions in perl6 you choose to
>use an invisible hash table, ok, I don't care, but when writing my perl
>script I don't want to deal with hash tables for arrays
>Bart Lateur wrote:
>>On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
>>>No. People should learn intrinsic mechanisms with which they can
>>>construct infinitely many beautiful and powerful effects. This empowers
>>>them. Making them learn yet-another-function-call merely hamstrings
> The point is that a hash of booleans (not a list of hashes) is a more direct
> way to implement a set. A set is unordered, and does not have duplicates.
> This is also true of hash keys. Furthermore, the nature of a hash makes it
> faster and easier to check for the existance of a key, which
Bart Lateur wrote:
>On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
>>No. People should learn intrinsic mechanisms with which they can
>>construct infinitely many beautiful and powerful effects. This empowers
>>them. Making them learn yet-another-function-call merely hamstrings
>>th
--On 31.08.2000 23:54 Uhr + Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Perl should support an interactive mode.
Most of what you want is already implemented in the perl shell
available at http://sourceforge
>Let's fall back to what we have already:
> $\ = "\n"; print $a = () = qw(a b c);
>-->
> 3
>All those who expected that the list would be evaluated in array (not
>list!) context, raise your hands. Not many, I would think.
Read my last letter--the one nobody commented on. What do y
Gael Pegliasco wrote:
> > First is the choice of arrays verses hashes as the choice for set
storage.
> > Arrays are obviously easier to construct, but hashes are both faster
> > implementations, and easier to determine membership.
>
> Well in fact I'm interested by such functions in order to manip
> First is the choice of arrays verses hashes as the choice for set storage.
> Arrays are obviously easier to construct, but hashes are both faster
> implementations, and easier to determine membership.
Well in fact I'm interested by such functions in order to manipulate
lists
of scalars (1, 'to
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >Doesn't that tend to lead us in the direction of pack madness where we
> >end up with yet another 'sub language' within perl. We've already got
> >pack specifiers and regexen and the 'old' prototyping stuff. I'm not
> >arguing *against* these things
On Fri, 1 Sep 2000 13:25:07 +1100 (EST), Damian Conway wrote:
>More than anything I think the inability to write C DWIMishly
>argues that we need it built-in. But we also need a *very* careful design
>of the semantics.
Well, except that it isn't clear which DWIM you want. Does DWIM mean,
the eff
83 matches
Mail list logo
