Thanks, Ziggy. You rock!
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
>Not every (natural) language does it that way; some place the most
>important thing -last-. A Japanese Perl might want to say
> "darn" STDERR print;
>for instance (Japanese is a subject-object-verb language).
Sure; Latin had SOV, and you still see SOV in Romance
when pronouns are involved.
A handful of long overdue updates to http://dev.perl.org/rfc have been made:
- All RFCs are now maintained in both POD and HTML.
HTML conversion is courtesy of pod2html.
- More detailed summaries of all RFCs are available, organized by
RFC number and working group. See http://dev.
>What are these proposed radical changes? Ok, we have the slicing syntax
>issue and how to write 2D/3D matrices. Does it stop there? What are the
>other issues?
Actually nothing radical. I take it back. I am not disaggreeing with
current RFC's. And probably simple syntax parsing can be achieved w
Which kind of "difference"?
>Perl supplies an operator for line input - angle brackets. This is no
>analogous operator for output. I propose "inverse angle brackets":
>>"Print this line.\n"<;
Perl already *has* a print operator: "print". :-)
The problem with what you have there is that it hides the act of
output wit
>=item Complex filehandle references
>my %filesystem;
>my $filename = '/etc/shells';
>open $filesystem{$filename}, $filename
>or die "can't open $filename: $!";
>print <$filesystem{$filename}>;
>__END__
>GLOB{0xa042284}
This goes hand-in-glove with the issue tha
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Formats out of core / New format syntax
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 30 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 181
Status: Develop
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Object Class hooks into C
=head1 VERSION
Maintainer: Mark Biggar <[EMAIL PROTECTED]>
Date: 30 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 180
=head1 ABSTRACT
There needs to be a
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More functions from set theory to manipulate arrays
=head1 VERSION
Maintainer: Gael Pegliasco <[EMAIL PROTECTED]>
Date: 30 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 179
=head
>> You don't want do have a postfix { ... } if condition. It's evil
>I don't see how this is any worse than a postfix while()
Look closer: do { ... } while does not require the reader to
scan down to find out the condition *BEFORE* the loop is
entered. With an if, it does.
>> Because it hide
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Lightweight Threads
=head1 VERSION
Maintainer: Steven McDougall <[EMAIL PROTECTED]>
Date: 30 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 178
=head1 ABSTRACT
A lightweight thread
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should have a print operator
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 5 August 2000
Last-Modified: 30 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 3
Number:
>We're talking about how we'll write Perl 6 programs, not PDL programs. We
>need to ensure that the syntax we create is Perlish.
Aggreed.
But there is nothing wrong with making the syntax user friendly, or am I
totally missing what perl is?
Why do we have qw()?
Why do we have "=>" as an alias f
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Angle brackets should not be used for file globbing
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 4 August 2000
Last-Modified: 30 August 2000
Mailing List: [EMAIL PROTECTED]
Ver
> You don't want do have a postfix { ... } if condition. It's evil
I don't see how this is any worse than a postfix while()
do {
asd;
asdf;
asdf;
asf;
asdf;
asdf;
sad;
fasdfa;
sdf;
asdf;
asdf;
asf
Damian Conway wrote:
>
> And has anyone pointed out that C is just:
>
> sub list {@_}
Hey, an easy IMPLEMENTATION section! I like it. ;-)
No, I hadn't gotten that far. But you're right (surprise :). The above
sub is an list constructor just like "() =" is. Awesome. I guess that
throws
Jeremy Howard wrote:
>
> Baris wrote:
> > First of all I know that perl syntax has limitations and I understand why
> > the reasons of the new syntax proposals. And I think the syntax proposals
> > are pretty good if you accept the syntax limitations. I don't think any of
> > them do consider tha
Baris wrote:
> First of all I know that perl syntax has limitations and I understand why
> the reasons of the new syntax proposals. And I think the syntax proposals
> are pretty good if you accept the syntax limitations. I don't think any of
> them do consider that if somebody will write a PDL pro
Christian Soeller wrote:
> Jeremy Howard wrote:
>
> > 14,17;...20,29). What if we created a new operator ';' that works within
a
> > list that creates a cartesian product?:
> >
> > (10:20:2; 11:30:3); # Cartesian product of 10:20:2 and 11:30:3 as a
LOL
>
> A possible approach. Two issues: (1)
Ok. How about:
@a([$i,$j,$k], [$x,$y,$z]);
as far as I know this should be ok?
Baris.
*** REPLY SEPARATOR ***
On 8/31/00 at 3:02 PM Jeremy Howard wrote:
>Baris wrote:
>> > @a[[$i,$j,$k], [$x,$y,$z]]
>>
>> I think it is more readable if you have different type of parantheses:
>>
Hello,
First of all I know that perl syntax has limitations and I understand why
the reasons of the new syntax proposals. And I think the syntax proposals
are pretty good if you accept the syntax limitations. I don't think any of
them do consider that if somebody will write a PDL program he will u
Jerrad Pierce wrote:
>
> Since everyone seems intent on breaking backward compatibility
I don't think this is at all true, but I also don't think the overall
idea of a Perl5 module is necessarily a bad one.
However, my hope would be that we do Perl 6 smoothly enough and get the
docs written wel
Jeremy Howard wrote:
> 14,17;...20,29). What if we created a new operator ';' that works within a
> list that creates a cartesian product?:
>
> (10:20:2; 11:30:3); # Cartesian product of 10:20:2 and 11:30:3 as a LOL
A possible approach. Two issues: (1) others might argue that we should
use
On Wed, Aug 30, 2000 at 04:35:31AM -0400, Bradley M. Kuhn wrote:
> My patch had other changes, too, that we cam to a consensus on. Any chance
> they'll be added, or is Ziggy just plain too busy? ;-)
Ziggy is busy, and he's working on having the by-number.html, by-group.html
and by-author.html p
[EMAIL PROTECTED] wrote:
>
> (yes, I'm in an RFC-commenting mood today...)
>
> On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
> >Add C keyword to force list context (like C)
>
> Makes sense to me. Does it connect in any way with Damian's generic
> want() function?
Implic
> On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
> >Add C keyword to force list context (like C)
>
> Makes sense to me. Does it connect in any way with Damian's generic
> want() function?
Only in that it would explicitly cause C to return true.
And has anyo
Tom Christiansen wrote:
>
> >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 think the word "drop" should be clarified as "dropped from the core
binary".
In a very cool
On Wed, Aug 30, 2000 at 04:43:56PM -0400, Jerrad Pierce wrote:
>Since everyone seems intent on breaking backward compatibility
>(Okay, so no one is explicitly setting out to do so, it is merely often
>dismissed as a non-issue). How about an RFC be done proposing that
>perl6 ship with a module name
(yes, I'm in an RFC-commenting mood today...)
On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
>Add C keyword to force list context (like C)
Makes sense to me. Does it connect in any way with Damian's generic
want() function?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> --
On Wed, Aug 30, 2000 at 02:21:19AM -, Perl6 RFC Librarian wrote:
>
>Allow for a list of loop variables in for(each) statements, i.e. & e.g.,
>
> foreach my ($x, $y, $z) (@list) { ... }
Hear, hear. I like this one :)
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Buddha Buck wrote:
> I'm willing to put this proposed compromise in RFC169v2 -- I like it,
> too -- but I'm not willing to put $a[$i][$j][$k] as equivilant to
> $a[[$i,$j,$k]] or $a[$i;$j;$k] into any RFC with me as the maintainer.
> I welcome Jeremy writing an RFC that does that, though.
>
This w
On Wed, Aug 30, 2000 at 04:53:46PM -0400, Bryan C . Warnock wrote:
>On Wed, 30 Aug 2000, Michael Maraist wrote:
>
>> Good idea, but you have it backwards.. If anything, there should be an
>> "explicit" keyword..
>> Remember, we want
>>
>> % perl -p -e 's/foo/bar/g' file.txt
>
>Oh, I know. I thr
On Wed, Aug 30, 2000 at 10:31:48AM -0400, Michael Maraist wrote:
>> Request For New Pragma: Implicit
>
>Good idea, but you have it backwards.. If anything, there should be an
>"explicit" keyword..
This resonates well with me. I had a funny feeling about "use Implicit"
and I wasn't sure what it w
Tom Christiansen wrote:
>
> >So, the first one will always be MyPackage::func, and the last one will
> >always be $object->func, because there is no main::func.
>
> But when would you know that? You have to look inside at run-time.
> This precludes precomputing where *func lives, as current occ
Buddha Buck wrote:
> I think that once you have LOL's automagically padded to size, and that
> size stored as an intrinsic part of the LOL, you no longer have a
> traditional LOL. You have something that looks, walks, and quacks like
> a matrix and doesn't walk or quack like an LOL. Why not call
Tom Christiansen wrote:
>
> Please print to STDERR some "darn" thing.
>
> I know Damian never inflected it this way, but I always find the
> leading object a bit (e)vocative. It's more natural to me in regular
> coding to put the verb first; call me Imperative.
I absolutely, positively, 10
On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote:
>chomp() is best used for chop()s main raison d'etre, removing $/
>from a string. I say we drop chop().
Works for me. Are you going to RFC it?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source
tchrist speaketh:
> Damian Conway
> > print {STDERR} "darn"
>
> Natha Wiger:
> > STDERR->print("darn")
> >
> >Same amount of typing.
>
> But those are actually significantly different from one
> another, but in a way you might not have considered (but
> ought to). Yours in my ear reads
> > @a[[$i,$j,$k], [$x,$y,$z]]
>
> I think it is more readable if you have different type of parantheses:
> @a[($i,$j,$k), ($x,$y,$z)]
The trouble is that that already has a meaning (although perhaps not a
particularly useful one).
The list ($i,$j,$k) in scalar context evaluates to its final e
Christian Soeller wrote:
> I think a combination of yours and Budda's proposal is actually very
> nice:
>
> @a[10:20:2; 11:30:3]; # ; implies cartesian product of indices
> @a[10..20:2; 11..30:3]; # same with .. syntax
> @a[[10,20,2],[@index], [0,0,0]] # comma-separated index refs means
>
The big thing I find missing from this RFC is compelling examples.
You are proposing a major change to the regex engine but you only have
two examples. Both involve only fixed strings and one of them is
artificial. I really think you need to discuss in more detail why
this feature would be usef
> I feel that -> should autoquote its LH operand, just as => does.
^
bareword
(I know you know, Tom, but wanted it to be explicit)
I agree entirely.
Damian
>I would actualy like to see chop expanded to allow a variable number of
>characters to be removed and a sister function to cut the head off. Yes I
>know you can do this with substr but sometimes when you want the performance
>and need to cut up a string into fields. Lets say the new function is c
>I find the Y()->X() vs Y::->X() confusion of Y->X() to be simply a bug
>in the "precedence" of symbolic refs vs bareword classnames. I think
>that people very rarely mean the former.
Agreed. I feel that -> should autoquote its LH operand, just as => does.
--tom
Damian Conway
> print {STDERR} "darn"
Natha Wiger:
> STDERR->print("darn")
>
>Same amount of typing.
No: the spaces don't count, as they aren't even needed.
So it takes two more non-whites Damian's way, four more your way.
And you just lost being a listop, should that concern you.
> @a[[$i,$j,$k], [$x,$y,$z]]
I think it is more readable if you have different type of parantheses:
@a[($i,$j,$k), ($x,$y,$z)]
Also:
[[$i,$j,$k], [$x,$y,$z]]
kind of resembles to creating a piddle where all these variables are the
values, whereas in your example of accessing two elements
@a[[$i,
> Jeremy Howard wrote:
>
> > Sorry--I need to correct this. The correct syntax for a list slice under my
> > proposal would actually be:
> >
> > @a[10:20:2][11:30:3]
> >
> > It needs the '@' of course since it's returning an array, and it needs to
> > use the standard LOL notation with the ex
> Actually this is pretty cool, add a = and turn it into a variable
> declaration:
>
>my format $FORMAT = <<'.';
> @, @
> $stuff, $junk
> .
>
> And that looks pretty similar to Perl 5. ;-)
Yah, but it's frought with the possibility of confusion. I can easily
s
Jeremy Howard wrote:
> Sorry--I need to correct this. The correct syntax for a list slice under my
> proposal would actually be:
>
> @a[10:20:2][11:30:3]
>
> It needs the '@' of course since it's returning an array, and it needs to
> use the standard LOL notation with the extension to multipl
> Karl Glazebrook wrote:
> > There is a difference between a List of Lists and a multi-dimensional
> array - the
> > latter is rectangular, e.g. the rows are all the same size so you don't
> have to
> > store the sizes of individual ones. So the latter needs much less storage
> overhead.
> > How w
Dan Sugalski wrote:
> On Thu, 31 Aug 2000, Jeremy Howard wrote:
> > Karl Glazebrook wrote:
> > > To access a single element we want
> > >
> > > $a[$i,$j,$k]
> > >
> > But this already means "the $i, $j, and $k" elements of a list. It is a
very
> > frequently used construct--I think that changing i
>>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
I wrote:
> Karl Glazebrook wrote:
> > for a slice we want
> >
> > $a[10:20:2, 11:30:3]
> >
> As opposed to:
>
> $a[[10:20:2], [11:30:3]]
>
Sorry--I need to correct this. The correct syntax for a list slice under my
proposal would actually be:
@a[10:20:2][11:30:3]
It needs the '@' of course s
Damian Conway wrote:
>
> Nor I. That's why I'd advocate mandatory braces on indirect objects.
> I'd rather:
>
> print {STDERR} "darn"
>
> any day.
Sorry, I'm way against that. If you're going to force that, then just
enforce:
STDERR->print("darn")
Same amount of typing.
Indirect
On Wed, 30 Aug 2000, Bradley M. Kuhn wrote:
> Dan Sugalski wrote:
> > At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote:
> > > > 2) Having a mechanism to automagically load in chunks of executable code
> > > > only when needed would be nice
> > >
> > >I would take this one a bit further:
> > >
> >
Tom Christiansen wrote:
>
> But I will *not* relish typing
>
> STDERR->print("darn")
Agreed. The day this is required is the day Perl stops becoming fun and
starts becoming C++.
No matter what, I think that any basic script should be able to be
written without any ->'s.
One goal of my RFC
>As far as I can tell reset %x currently tries to reset any
>variables which start with either % or x even though no variable
>can start with %...
~/perl
${"%percent"} = "Quoth the raven";
print ${"%percent"}, "\n";
reset("%");
print ${"%percent"}, "\n";
Quoth the raven
Sure looks like it starts
On Thu, 31 Aug 2000, Jeremy Howard wrote:
> > To access a single element we want
> >
> > $a[$i,$j,$k]
> >
> But this already means "the $i, $j, and $k" elements of a list. It is a very
> frequently used construct--I think that changing it will be impossible, and
> that creating a new data type th
> yet even that is not sufficient for some cases, where
>
> Y::->X
>
> instead. Blech.
I find the Y()->X() vs Y::->X() confusion of Y->X() to be simply a bug
in the "precedence" of symbolic refs vs bareword classnames. I think
that people very rarely mean the former.
The c
> This whole thing is actually a deep and complicated imbroglio--as I know
> you, Damian, are aware. I don't know your ideas for untangling it.
Sure you do: indirect objects MUST DIE! ;-)
But I freely admit that's not a satisfactory solution.
Meanwhile, thank-you for the masterly summa
> I think these are both doable. Hopefully this clarifies what I'm trying
> to get at.
Okay. That's much clearer. Thanks.
Damian
>I would be happier of we just let the whole nightmare that is the
>indirect object syntax die the death it deserves! :-)
If functions, not indirect object methods, *always* took parens,
then I think without deep thought that this, too, would solve that
problem--amongst others. I'm not ready to
Dan Sugalski wrote:
> At 02:16 PM 8/30/00 -0400, Karl Glazebrook wrote:
> >subgroups should iron out there differences among themselves and come up
> >with a coherent set of proposals.
> >
> >the final decision should not be in the hands of one person.
>
> Someone ultimately has to make the in or
I have been thinking about what has come up on this list so far and was
wondering if there isn't a strategy so that we all benefit and come up
with a number of very strong proposals. The following seems to be a
constructive approach to me:
1) There is nothing wrong with having many RFCs
What rem
Dan Sugalski wrote:
> At 04:25 AM 8/30/00 -0400, Bradley M. Kuhn wrote:
> > > 2) Having a mechanism to automagically load in chunks of executable code
> > > only when needed would be nice
> >
> >I would take this one a bit further:
> >
> > 2a) It should be possible, at compile-time, to detect wha
> package main;
> sub somefunc { ... }
> use MyPackage;
> my $mypkg = new MyPackage;
> func($mypkg, @args); # $mypkg->func(@args)
>So, the first one will always be MyPackage::func, and the last one will
>always be $object->func, because there is no main::func.
But when would y
> I'm truly not clear on what you're yucking there.
I'm objecting to the subtlety that a string in a scalar as the first
argument creates a method call, whereas a *stringified* string in a scalar
as the first argument creates a subroutine call.
> Would you be any happier if one were to
Buddha Buck wrote:
> RFC 169 says it would be nice if:
>
>@a[^i;^j] = @b[^j;^i];
>
> did a transpose operation.
>
> Should the syntax also allow:
>
># fill a 10x10 array with 0-99
>my @table: bounds(10,10);
>@table[^i;^j] = ^i*10 + ^j;
>
I think it should--it seems a natural e
Karl Glazebrook wrote:
> There is a difference between a List of Lists and a multi-dimensional
array - the
> latter is rectangular, e.g. the rows are all the same size so you don't
have to
> store the sizes of individual ones. So the latter needs much less storage
overhead.
> How would you be prop
This whole thing is actually a deep and complicated imbroglio--as I know
you, Damian, are aware. I don't know your ideas for untangling it.
To review for others, if one is to require
$fh->print("blah")
or
$STDOUT->print("blah")
or
STDOUT->print("blah")
then people will truly balk.
> So this:
>
> my $class = "My::Class";
> print("$class");
>
> is:
>
> main::print("My::Class");
>
> ???
Not actually what I was suggesting. I'm going to have to go back to
Clear Examples School because somehow mine always end up confusing
issues inadvertently.
Remembe
On Wed, 30 Aug 2000 18:27:04 -0400, Buddha Buck wrote:
>Do you really mean to suggest that $SPECIALVARS be (by convention)
>uppercase but built in types be (by grammar) lowercase?
Guess what is currently the case with all built-in functions. Lowercase.
Guess what is currently the custom with bu
On Wed, 30 Aug 2000 16:14:35 -0600, Tom Christiansen wrote:
>>I say we drop chop().
>
>So code that says
>
>chop($k,$v)
>
>will need to say
>
>for ($k,$v) { s/.\z//s }
>
>or else something like:
>
>for ($k, $v) { substr($_, length() - 1) = '' }
>
>I'm not sure I find either of those
> we are after SIMPLE syntax. This means like C, Fortran, IDL and Matlab.
> Perl is about working like most people expect.
>
Yes, we are after simple syntax. We also want to make to hard things
possible. Therefore we want a syntax that is also flexible.
> To access a single element we want
>
> $a
>Doesn't this move compile time work into run-time?
If you can't know till run-time what function to call, then yes.
In which case Perl's dispatch will start being as slow as Python's--and
for the same underlying reason. Infinite flexibility means infinite
slowness.
Oh, and look at this crud:
Tom Christiansen wrote:
> format $fh < @, @
> $stuff, $junk
> EO_FORMAT
Actually this is pretty cool, add a = and turn it into a variable
declaration:
my format $FORMAT = <<'.';
@, @
$stuff, $junk
.
And that loo
This is making the index variable into an a wrapper object.
Since the underlying value can't (or shouldn't) know which of the n
containers it is in.
> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
JSD> Interesting. I must have missed this. I'm not wild about the syntax,
JSD>
>So this:
> my $class = "My::Class";
> print("$class");
>is:
> main::print("My::Class");
Oh, I don't know. *If* you assume that f(x) is always x->f(), then,
it would invoke some STRING::print method--being there as one would
be in an all-the-world's-an-object world. I supp
Doesn't this move compile time work into run-time?
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> This should be made to work correctly. The following order of function
PRL> parsing should apply to Perl 6:
PRL>1. The current package should be checked for a function
PR
> > >print("$stuff"); # main::print($stuff)
>
> >How does it know that the second version isn't:
>
> > $stuff->print();
>
> [coming in on the middle of this, so context may be muddled]
>
> But for the double quotes, it wouldn't.
So this:
my $
Tom Hughes writes:
> I must admit it had never occurred to me that somebody might
> deliberately use keys or values to achieve that, but I guess
> somebody might be relying on it without realising it.
while (($k,$v) = each %foo) {
last if ...;
}
keys %foo;# reset the iterator
w
In message <[EMAIL PROTECTED]>
Nathan Torkington <[EMAIL PROTECTED]> wrote:
> Resetting an each() should be done in some other way than calling
> keys() or values(). Perhaps reset(%hash)? I'm subfond of the current
> reset() semantics (symbol table crackheadery + single-match regexp
>
You are now biting off quite a bit. This is the generic problem that
all database systems have to do to handle transactions.
I believe that this will increase the deadlock possibilities. Without
a transaction, it might have been possible to get in and out of a subroutine
without holding the lock
Dan Sugalski wrote:
> I do want to have a set of C/XS/whatever sources as part of the test suite
> as well--right now perl's test suite only tests the language, and I think
> we should also test the HLL interface we present, as it's just as
> important in some ways.
I want to see Perl become a f
>I presume that line disciplines will be object-oriented and inherit from
>some base class; therefore a bare chomp will use the line terminator from
>that base class and for the others, you could do something like
>$fh->chomp($line) to do chomping specific to a particular filehandle. Make
>se
>Tom Christiansen writes:
>> But %hash->BUCKET_USE() should return what's currently there.
>Do you really use this information? Really? I have no objection
>to supplying a way to discover it, but this might even be in an
>external module rather than built into the language given how rarely
>it'
At 04:36 PM 8/30/00 -0600, Tom Christiansen wrote:
> >the reason that they're duplicatable with other features, while I want
> >to drop chop because its main purpose has now been replaced with the
> >far superior chomp.
>
>Except that chomp() relies upon the ueberglobal $/ variable,
>irrespective
Tom Christiansen writes:
> But %hash->BUCKET_USE() should return what's currently there.
Do you really use this information? Really? I have no objection
to supplying a way to discover it, but this might even be in an
external module rather than built into the language given how rarely
it's used
Tom Christiansen writes:
> So code that says
>
> chop($k,$v)
>
> will need to say
>
> for ($k,$v) { s/.\z//s }
>
> or else something like:
>
> for ($k, $v) { substr($_, length() - 1) = '' }
I don't think chop() is an operation that's done often enough for
either of the things ab
>the reason that they're duplicatable with other features, while I want
>to drop chop because its main purpose has now been replaced with the
>far superior chomp.
Except that chomp() relies upon the ueberglobal $/ variable,
irrespective of the source of the data being chomped.
--tom
Ed Mills writes:
> Duck & cover Nate- I sugested that weeks ago and the flames are just dying
> down in my mailbox..
Whoops, sorry. I didn't realize that had already been submitted.
I just read through the mail archive and didn't see much in the way of
flames there. J.S. Duff wants to keep th
> > Just wanted to clarify this, as I think this may be the part that
> > overlaps with what you're doing. Under this syntax, the object would be
> > called for you automatically, so your prototypes wouldn't have to deal
> > with optional first arguments at all:
> >
> >print($FILE
>Do you really mean to suggest that $SPECIALVARS be (by convention)
>uppercase but built in types be (by grammar) lowercase?
Absolutely. That's how it's already worked. The pragmata are lowercase module
names are reserved to the Core. The type name is the class name, which
is the package nam
> > No-one AFAICT has yet brought up formats, and what would happen
> > to them if bareword filehandles go the way of the dodo.
I'm about to propose that formats be replaced with a mechanism of
Text::Autoformat::form (with some extensions).
Damian
> Just wanted to clarify this, as I think this may be the part that
> overlaps with what you're doing. Under this syntax, the object would be
> called for you automatically, so your prototypes wouldn't have to deal
> with optional first arguments at all:
>
>print($FILE, "$st
At 04:20 PM 8/30/00 -0600, Tom Christiansen wrote:
> >Or if clearly make basic types look *very* different from user-defined
> >types:
>
> > my Dog $spot;
> > my *int $i; # types that start with * are "basic"
>
>Intrinsics (basic types) are in lower-case.
>User-defined type
>I was against the idea of hash context, but I'd love it if:
> foreach ($k,$v) (%hash) {
>...
> }
I'd like for Perl to emit a warning if people try
for (%hash)
or its aliases. That is, if a foreach loops sole content is
a %{...} at compile time, grinch.
--tom
>%hash in scalar context should return what scalar(keys(%hash))
>currently does.
But %hash->BUCKET_USE() should return what's currently there.
And a simple boolean (read: don't care) use shouldn't waste time
looking for keys, really, but should be internally optimized to do
the current reasonabl
>Or if clearly make basic types look *very* different from user-defined
>types:
> my Dog $spot;
> my *int $i; # types that start with * are "basic"
Intrinsics (basic types) are in lower-case.
User-defined types aren't.
our num $Count;
my Word @verbs;
One wonde
1 - 100 of 275 matches
Mail list logo
