[Quoting Nathan Wiger, on August 31 2000, 14:40, in "Re: RFC 132 (v3) Sub"]
> > sub param {
> > my ($self, @rest) = @_;
> > $self->{aval} = @rest if @rest; # See note
> > lreturn $self->{aval};
> > }
>
> I've been thinking about this for a couple days. The only problem I see
>
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Variable-length lookbehind: the regexp engine should also go backward.
=head1 VERSION
Maintainer: Peter Heslin <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last Modified: 1 Sep 2000
Mailing List: [EMAIL PR
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
smart container slicing
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 191
Status: Developing
=head1 ABSTRA
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Private keys and methods
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 188
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Mandatory and enhanced second argument to C
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 187
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Hierarchical calls to initializers and destructors
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : NEXT pseudoclass for method redispatch
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 190
Status
>=head2 Private methods
>The C keyword could also be applied to subroutines, to restrict
>where they may be called. Access rules similar to those for private hash
>entries would apply:
>package Base;
>
>sub new { ... }
>
>private sub check { ... }
>
>=head1 REFERENCES
>Christiansen & Torkington, I, pp. 470-472.
>Conway, I, pp. 309-326.
One might add refs to Camel-3's new OO chapter on privacy approaches.
--tom
On 31 Aug 2000 06:28:10 -, Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
Being one of world's active format users, I have to comment.
> Formats out of core / New format syntax
> Currently, the general consensus is that formats aren't widely used
> enough to justify their living in the core
On Thu, Aug 31, 2000 at 12:34:05PM -0400, Mark-Jason Dominus wrote:
>
> perl6-language-regex
>
> Summary report 2831
>
> RFC 72: The regexp engine should go backward as well as
> forward. (Peter Heslin)
>
> This topic did not attract much discussion until the very end of the
> week
Why private and not on perl6?
Posted this to both, hope you don't care.
On Fri, 1 Sep 2000 13:11:53 +0200 (CEST), [EMAIL PROTECTED] (Johan Vromans)
wrote:
> [Quoting H.Merijn Brand, on September 1 2000, 11:02, in "Re: RFC 181 (v1) For"]
> > > Is there any reason left to maintain formats as somet
Larry Wall wrote:
>
> Karl Glazebrook writes:
> : I have a lot of respect for Larry, but as a scientist I distrust all this
> : deference to one single authority.
>
> Well, sure, but someone still has to decide who gets the grants. :-)
But it's not always the same person.
> : I don't know if
Jeremy Howard wrote:
>
> The RFCs I envisage are:
>
> - Overview of matrix RFCs
> - Notation for declaring and creating matrices
> - Notation for declaring sparse matrices
> - Notation for indexing matrices with a LOL as an index
> - ';' for slicing matrices
> - @#mat for getting the dimen
Buddha Buck wrote:
>
> At 08:10 AM 9/1/00 +1200, Christian Soeller wrote:
>
> >No, at least 18. One more piece of semantics that would be appreciated
> >is optional omission of trailing dimensions in slices, e.g. for a 3-dim
> >@a:
> >
> > @a[0:1] == @a[0:1;] == @a[0:1;;]
>
> Would you go for
I would rather see one largeish RFC integrating all these. More RFCs
are not necessarily better.
"Advanced Perl Multi-dimensional notation".
And n-dim things are not necessarily matrices.
Karl
Buddha Buck wrote:
>
> If I'm stepping on toes here, please tell me...
>
> Here are some suggestion
Ken Fox wrote:
> Perl is more like lisp with a good syntax -- in other
> words about as far from C as you can get.
I agree 100%.
--
John Porter
David L. Nicol wrote:
> Ken Fox wrote:
> > . The real problems of exception handling, closures, dynamic
> > scoping, etc. are just not possible to solve using simple C code.
> >
> > - Ken
>
> I'm not talking about translating perl to C code, I'm talking about
> translating perl to machine langua
Uri Guttman wrote:
>
> the best fit is the TIL (threaded inline code) model we have
> discussed.
Yes!
--
John Porter
At 11:11 AM 9/1/00 -0400, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> Okay, here's a list of functions I think should go into variable vtables.
>DS> Functions marked with a * will take an optional type offset so we can
>DS> handle asking for various permuta
At 10:46 PM 8/31/00 +, David L. Nicol wrote:
>Dan Sugalski wrote:
> >
> > Okay, here's a list of functions I think should go into variable vtables.
>
>All the math functions are in here. Can the entries that my type does
>not use be replaced with other functions that my type does use?
That's
At 01:44 AM 9/1/00 -0400, Bradley M. Kuhn wrote:
>Dan Sugalski wrote:
> > At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
> > >At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
> > >>Okay, here's a list of functions I think should go into variable
> vtables.
> > >>Functions marked with a * will take a
At 01:49 AM 9/1/00 -0400, Bradley M. Kuhn wrote:
>Dan Sugalski wrote:
> > > > get_value
> > > > set_value
>
> > The get/set value functions are for when something knows what the SV (or
> > whatever we call it) really is and can handle the raw data. For example,
> > if my code knew a SV he
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Okay, here's a list of functions I think should go into variable vtables.
DS> Functions marked with a * will take an optional type offset so we can
DS> handle asking for various permutations of the basic type.
DS> type
DS> nam
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
>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
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
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
>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
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
Bart, until you've read my long message, you're wasting my time.
Please read it.
--tom
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
>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
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
>> keys %HASH = LIST;
>> is really
>> @HASH{ LIST } = ();
>Sure. Would you have any great objection to adding the alternative syntax?
Nope.
--tom
> On Thu, Aug 31, 2000 at 12:34:05PM -0400, Mark-Jason Dominus wrote:
> >
> > perl6-language-regex
> >
> > Summary report 2831
> >
> > RFC 72: The regexp engine should go backward as well as
> > forward. (Peter Heslin)
> >
> > This topic did not attract much discussion until the v
Buddha Buck wrote:
>
> Boy, there are a lot of people on that CC: list... Anyone want off
> this ride?
>
> How would you recommend the RFC breakdown?
>
> Use ";" for matrix index separator
> Use named iterators for matrix indices
>
> anything else?
Everyone else is way past brainstormin
Nathan Wiger wrote:
> Well, this is not bad, only it's not without its problems. Say you
> wanted to get your indices implicitly:
>
> @a[getindices()];
> @a[$r->get_x, $r->get_y];
@a["@{\(getindices())}"];
@a[join $",$r->get_x, $r->get_y];
> Either of these could ret
"David L. Nicol" wrote:
>
> @a["@{\(getindices())}"];
> @a[join $",$r->get_x, $r->get_y];
My point exactly by these statements:
> > Either of these could return an arrayref, but forcing quotes around them
> > means you'll need inbetweener variables or the @{} construct, neither
"David L. Nicol" wrote:
>
> Nathan Wiger wrote:
>
> > Well, this is not bad, only it's not without its problems. Say you
> > wanted to get your indices implicitly:
> >
> > @a[getindices()];
> > @a[$r->get_x, $r->get_y];
>
> @a["@{\(getindices())}"];
> @a[join $",$r->ge
Nathan Wiger wrote:
> I don't think array indices
> are something that we should have to go to such lengths to get. I'd
> rather have a somewhat-confusing ; or , based syntax than the above. If
> anything that's *more* confusing and harder to read.
>
> -Nate
you're right. What if they both wo
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
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
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
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
"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
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
> 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
On Fri, Sep 01, 2000 at 11:58:20AM +0200, Bart Lateur wrote:
> First: I don't like the idea of some user supplied code being called
> whenever you declare a new variable, *unless* the author of the class
> created a sub *especially written* for this purpose.
And that's what the RFC states. If th
On Fri, Sep 01, 2000 at 12:20:34PM +0100, Hildo Biersma wrote:
> Michael Fowler wrote:
> >
> > On Fri, Sep 01, 2000 at 08:31:17AM +0100, Hildo Biersma wrote:
> > > My previous concerns have not been adressed:
> > > - There may not be a default constructor
> >
> > If there is no implicit construc
On Fri, Sep 01, 2000 at 05:23:27PM +0200, Slaven Rezic wrote:
> Often, there is the case that "my" is used before actually assigning a
> value to it. For example:
>
> my Foo $foo;
> if ($cond1) {
> $foo = new Foo 1, 2, 3;
> } else {
> $foo = new Foo 2, 4, 6;
> }
>
> I
On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote:
> Michael Fowler wrote:
> >
> > my Dog $spot; # $spot is now a blessed Dog object
> > $spot->name("Fido");# $spot->{'name'} eq "Fido"
> >
> > print ref $spot;# yes, "Dog"
> >
> > $spot = new
On Fri, Sep 01, 2000 at 10:58:36AM -0800, Michael Fowler wrote:
> my $spot isa(Dog);
This should be my $spot : isa(Dog);
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
On Fri, Sep 01, 2000 at 09:09:15AM -0700, Nathan Wiger wrote:
> First off, I think everyone is reading this RFC with the wrong mindset,
>my Dog $spot;
>print ref $spot;# 'Dog'
>$spot = new Dalmation;
>
> No reason this wouldn't still work. The term 'constructor' here is
> misleadi
On Fri, Sep 01, 2000 at 10:37:04AM -0800, Michael Fowler wrote:
> I would appreciate you giving me the benefit of the doubt that I'm not
> intentially misunderstanding you.
intentionally
> my $spot isa(Foo);
This should be my $spot : isa(Foo).
Man, these typos are going to be the death o
Michael Fowler wrote:
>
> On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote:
> > Michael Fowler wrote:
> > >
> > > my Dog $spot; # $spot is now a blessed Dog object
> > > $spot->name("Fido");# $spot->{'name'} eq "Fido"
> > >
> > > print ref $spot;#
On Fri, Sep 01, 2000 at 12:35:24PM -0700, David E. Wheeler wrote:
> Well then, that makes this example rather wasteful, doesn't it?
It wasn't an example of how my Dog $spot should be used. I was explaining
to Nate what his code was doing.
> my Dog $spot;
> if ($input eq 'Collie') {
>
On Fri, Sep 01, 2000 at 10:46:50AM +0100, Piers Cawley wrote:
> Are you wilfully misunderstanding me?
I would appreciate you giving me the benefit of the doubt that I'm not
intentially misunderstanding you.
> Let's try another possible example to see if you get the point:
>
> print "What
Michael Fowler wrote:
>
> my Dog $spot; # $spot is now a blessed Dog object
> $spot->name("Fido");# $spot->{'name'} eq "Fido"
>
> print ref $spot;# yes, "Dog"
>
> $spot = new Dalmation; # now $spot is a Dalmation object
Yes, but the Dalmation $spot will *
On Fri, Sep 01, 2000 at 10:22:49AM +0100, Piers Cawley wrote:
> And then there's:
>
> - Makes factory methods impossible.
my Dog $spot;
my $pub = $spot->procreate;
Sure looks like a factory method to me. Just because you don't get to say
my Dog $pup for some optimization doesn't mean
> KF> #!/my/path/to/perl
> KF> sub foo_generator { my $a = shift; sub { print $a++ } }
> KF> my $foo = foo_generator(1);
> KF> $foo->();
> Thread-> new($foo);
> KF> Is $a shared between threads or not? If $a is not shared, we've broken
> KF> lexicals.
> Not unless it is so declar
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> Well, that depends. Often you must delay till run-time. When Perl
TC> simply sees something like:
TC> sub fn { return @blah }
TC> it can't know whether you'll use that as:
TC> $x = fn();
TC> or
TC> @x = fn();
TC> or
TC>
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> The more interesting case is this:
KF> #!/my/path/to/perl
KF> sub foo_generator { my $a = shift; sub { print $a++ } }
KF> my $foo = foo_generator(1);
KF> $foo->();
Thread-> new($foo);
KF> Is $a shared between threads or not?
> I'm not completely sure what you are trying to do with this RFC.
This RFC describes the programming interface to Perl6 threads.
It documents the function calls, operators, classes, methods, or
whatever else the language provides for programming with threads.
Perl5 has a thread interface, bu
>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>TC> Well, that depends. Often you must delay till run-time. When Perl
>TC> simply sees something like:
>TC> sub fn { return @blah }
>TC> it can't know whether you'll use that as:
>TC> $x = fn();
>TC> or
>TC> @x = fn();
>T
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:
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
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
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
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
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
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
>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
At 11:49 AM 9/1/00 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
>
> > We're shooting for speed here. Any common operation that could be affected
> > by the type of the variable should be represented so a custom function can
> > be called that does exactly what needs to be done.
> >
> >
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Dan Sugalski <[EMAIL PROTECTED]> writes:
>> is_equal (true if this thing is equal to the parameter thing)
>> is_same (True if this thing is the same thing as the parameter thing)
NI> is_equal in what sense? (String, Number, ...)
NI>
At 06:07 PM 9/1/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >is_equal (true if this thing is equal to the parameter thing)
> >is_same (True if this thing is the same thing as the parameter thing)
>
>is_equal in what sense? (String, Number, ...)
I was thin
At 10:25 AM 9/1/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Anyone got anything to add before I throw together the base vtable RFC?
>
>So how do you call a generic method?
Generic vtable method? You'd have to look up the vtable in the stash that
held it and vector in through there.
If
At 10:23 AM 9/1/00 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Type returns a magic cookie value of some sort (Not sure what sort yet),
>: name returns a string with the name of the type of the variable.
>
>Why can't the type object just stringify to the name of the type?
I'd figured that t
Karl Glazebrook wrote:
> Can we not keep calling them matrices? They are just a special
> case.
>
Normally I call them tensors, but this is only meaningful to a mathematics
audience.
I was using 'matrix' because both laypersons and mathematicians would know
what the RFCs are referring to. This wo
Karl Glazebrook wrote:
> I would rather see one largeish RFC integrating all these. More RFCs
> are not necessarily better.
>
The -language WG chair has requested that each RFC contain just one key
proposal, and that multiple related RFCs be drawn together with an overview
RFC.
>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.
>>
>>
>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
Can't quite run perl yet.
http://www.tomshardware.com/cpu/00q3/000901/index.html
>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
> "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
>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
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
> "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
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 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
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
>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
>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 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 n
>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
>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
>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
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
1 - 100 of 187 matches
Mail list logo