On 23 Aug 2000, Perl6 RFC Librarian wrote:
> Since versioning is a meta-implementation issue, all that is required
> is that fearless leader has to agree this is a good idea.
Very funny. I suppose you don't mind if he changes his mind someday?
I'm starting to think that you have too much time
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Enhanced Pack/Unpack
=head1 VERSION
Maintainer: Edwin Wiles <[EMAIL PROTECTED]>
Date: 22 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 142
=head1 ABSTRACT
Pack and Unpack a
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
This Is The Last Major Revision
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 22 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 141
=head1 ABSTRACT
Future perl ve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
One Should Not Get Away With Ignoring System Call Errors
=head1 VERSION
Maintainer: Jarkko Hietaniemi <[EMAIL PROTECTED]>
Date: 22 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 14
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow Calling Any Function With A Syntax Like s///
=head1 VERSION
Maintainer: John Porter <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 139
=head1 ABSTR
On Wed., Aug 16, 2000, Nate Wiger wrote:
> is good. Right now, people are hopping in 500 emails behind, replying to
> something in the middle of the stream, and only later reading the
> "please move this to -errors" post.
Actually, I'm 1283 emails behind, to be exact.
And that's just countin
-Original Message-
From: Jeremy Howard [mailto:[EMAIL PROTECTED]]
[...]
Programmers shouldn't have to know how a
computer implements things behind the scenes--which is really what requiring
explicit looping forces.
Great point, this should be in the RFC.
-Corwin
>
> Consider the following syntax:
>
> my var; # declaring a scalar
> my array[]; # declaring an array
> my hash{};# declaring a hash
For the remainder of the enclosing block, the barewords var,
array and hash are to be interpreted as references to a scalar, an
array, and a ha
This sounds like another job for the macro language.
Anyone have any idea what the macro language should look
like, aside from that the variables in it which will get
replaced might wear hats?
defining -language-macro might be premature because identifying
what suggestions and shortcuts make
>It doesn't help that Camel II's glossary defines "array" as "A named list
>of values, each of which has a unique key to identify it. In a normal
>array, the key is numeric... In a hash...the key is a string." and seems to
>go to a lot of effort to deprecate "array" in favor of "list" (array
[to you only, as this thread is now distinctly off-topic for perl6-language]
Buddha Buck wrote:
>
> @array1 = (1, 1, 3, 5, 8, 13);
> %hash1 = ('foo', 34, 'bar', "not a number", 'baz', 4);
> @array2 = %hash1;
> %hash2 = @array1;
>
> This works, and may lead to confusion because:
This is exact
At 04:11 PM 8/22/00 -0400, John Porter wrote:
>Casey R. Tweten wrote:
> >
> > There is no documentation that states:
> >
> > ``keys() just doesn't work on lists and/or arrays,
>
>Why should it bother saying that, when it already says keys() works on a
>HASH?
>
>Or is there some confusion that a H
Today around 4:07pm, John Porter hammered out this masterpiece:
: Casey R. Tweten wrote:
: >
: > Removing intermediate data structures is easy in Perl, but not this case,
:
: C, etc. must have data structures to work on. There's no "getting rid"
: of them.
Perl can create them for me.
: "I w
Casey R. Tweten wrote:
>
> There is no documentation that states:
>
> ``keys() just doesn't work on lists and/or arrays,
Why should it bother saying that, when it already says keys() works on a HASH?
Or is there some confusion that a HASH might also be an ARRAY or a LIST?
--
John Porter
Casey R. Tweten wrote:
>
> Removing intermediate data structures is easy in Perl, but not this case,
C, etc. must have data structures to work on. There's no "getting rid"
of them.
"I want find /usr to search the directory tree, but, um, I don't want to
actually *have* a directory tree..."
And at this point we seem to have run out of steam for changing perl6
in this direction. Please take dialogue on the perl5 documentation to
the perl5-porters list.
Thanks,
Nat
>There is no documentation that states:
>``keys() just doesn't work on lists and/or arrays, you must use this syntax to
>force that to work:
> @array = keys %{{@array}};
>''
>Or something like that.
keys is documented to take a hash. Likewise, push an array.
This all seems completely obvious
Today around 1:51pm, Tom Christiansen hammered out this masterpiece:
: >As a user, I should be able to expect this:
:
: I've decided I don't believe you, because despite having taught a
: zillion people Perl,
Commendable. I value your expertise.
: I have never *once* seen the misexpectation
Today around 1:41pm, Tom Christiansen hammered out this masterpiece:
: > my %hash = &func();
: > print "$_\n" foreach keys %hash;
:
: >To work just like this:
:
: > print "$_\n" foreach keys &func();
:
: >In my, 'pretending to just learn' mode, I don't understand. Perl will assign
: >the L
>As a user, I should be able to expect this:
I've decided I don't believe you, because despite having taught a
zillion people Perl, I have never *once* seen the misexpectation
and subsequent error that you're spending so much time complaining
about.
--tom
> > I think this is fraught with peril. I'd have expected:
> >
> > print (1, 2, 3, ...) or die;
> >
> > to print
> >
> > 12345678910111213141516171819202122232425262728etc
>
> No, if that's what you wanted, you'd get it with
>
>print( 1, 2, 3 ..
> my %hash = &func();
> print "$_\n" foreach keys %hash;
>To work just like this:
> print "$_\n" foreach keys &func();
>In my, 'pretending to just learn' mode, I don't understand. Perl will assign
>the LIST to the hash in example one, but in example two, it croaks.
A LIST is not a HASH. L
Today around 3:01pm, John Porter hammered out this masterpiece:
: Nathan Torkington wrote:
: > John Porter writes:
: > > I suppose that's true. But why would
: > > %( foo => 1, bar => 2 )
: > > be "working harder" than
: > > %{{ foo => 1, bar => 2 }}
: > > ??? It's few keystrokes and would
John Porter writes:
> So? Perl's not like that. Perl is diagonal. And this is just
> another corner being cut.
Cut away enough corners, and you have a black hole. Or something :-)
My point is that before you reach to invent new syntax, see if there's
a way to do what you want with the existi
Nathan Torkington wrote:
> John Porter writes:
> > I suppose that's true. But why would
> > %( foo => 1, bar => 2 )
> > be "working harder" than
> > %{{ foo => 1, bar => 2 }}
> > ??? It's few keystrokes and would be a less tricky concept
> > to remember.
>
> It's a new syntax, not ortho
I assure you that the number of people who get compile-time caught
for writing keys or each $x[$i][$j] or pop or push $x[$i][$j] is
*very* large. This is by far the most prevalent error that happens
with data structures in apprentice and perhaps even journeymen perl
programmers. Having the compi
John Porter writes:
> I suppose that's true. But why would
> %( foo => 1, bar => 2 )
> be "working harder" than
> %{{ foo => 1, bar => 2 }}
> ??? It's few keystrokes and would be a less tricky concept
> to remember.
It's a new syntax, not orthogonal to anything we already have. The
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 13:48:36 EDT
From: Jerrad Pierce
>$n
In 42 lines, of which 25 were waste, Jerrad Pierce wrote:
>
> a) why this is the Wrong Thing
It is simply not the way perl works. In these matters at least, perl is
quite consistent.
> c) something to refute Do What I Mean
DWIM is cutesy, but not actually meaningful. Perl comes closer to dw
(Off-topic for this list, but I'm not sure where else to send it)
Could we have a discussion somewhere of useful filtering rules for all
these perl6 lists? Specifically, I'm looking to steal other people's
.procmailrc snippets. I imagine that a lot of people have written their
own, and everything
Tom Christiansen wrote:
> it's already there. One just works on the compiler to
> be smarter on optimizing.
I suppose that's true. But why would
%( foo => 1, bar => 2 )
be "working harder" than
%{{ foo => 1, bar => 2 }}
??? It's few keystrokes and would be a less tricky
>Other than the issue of semantics (array is not list), I still have not
>seen:
>a) why this is the Wrong Thing
Why what is the wrong thing? Why treating an immutable list
as a mutable array is wrong? Because you can't change the length
of a list -- it doesn't have an AV to update. If you wan
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 12:58:38 EDT
From: Jerrad Pierce
>I think you are still confused as to the di
>But I do agree it would be nice if there were a way to simultaneously
>construct and dereference an anonymous array or list, perhaps something
>like
> @( 1, 2, 3 )
> %( foo => 1, bar => 2 )
>which would be equivalent to
> @{[ 1, 2, 3 ]}
> %{{ foo => 1, bar => 2 }}
>bu
Jerrad Pierce wrote:
> In reply to your message from the not too distant future: next Tuesday AD
> Reply-to: [EMAIL PROTECTED]
> Return-receipt-to: [EMAIL PROTECTED]
> Organization: a) Discordia b) none c) what's that?
> Content-Typo: gibberish, charset=ascii-art
> Date: Tue, 22 Aug 2000 11:06:21
Today around 11:06am, Jerrad Pierce hammered out this masterpiece:
: >It will show that you are doing what you *want* to do, not letting
: >automagic error-blind spoofery behind the curtains flummux up
: >your life unnecessarily.
:
: Umm no.. for what I *want* to do is take the keys of the hash
In reply to your message from the not too distant future: next Tuesday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 11:06:21 EDT
From: Jerrad Pierce
>It wil
Larry Wall wrote:
> John Porter writes:
> : Could you make it "evaporate" and compile time, just like the (proposed) qc()?
>
> Hard to make it evaporate at compile time and still give a warning at
> run time. :-)
Eh, eh... Curdle it into the appropriate warn() call!
--
John Porter
John Porter writes:
: Could you make it "evaporate" and compile time, just like the (proposed) qc()?
Hard to make it evaporate at compile time and still give a warning at
run time. :-)
Larry
Larry Wall wrote:
>
> I'd entertain a proposal that ... be made a valid term that happens
> to do nothing, so that you can run your examples through perl -c for
> syntax checks. Or better, make it an official "stub" for rapid
> prototyping, with some way of getting a warning whenever you execute
Tom Christiansen wrote:
>
> Hmm, what about CHECK blocks?
CHECK blocks would be great! But of course, they work in memory,
which is not useful for persisting program state across executions,
or moving it across machines.
--
John Porter
We're building the house of the future together.
Damian Conway wrote:
>
> Tom's opcode dumping functionality could, in principle, be added to
> Data::Dumper as it stands.
>
> My proposal was merely that C<&Data::Dumper::Dumper> body-snatch C.
But that's a crummy name for it, unix legacy not withstanding.
Is someone working on an RFC? IIRC,
Today around 10:11am, John Porter hammered out this masterpiece:
: Casey R. Tweten wrote:
: >
: > sub func {
: > return qw/KeyOne Value1 KeyTwo Value2/;
: > }
: >
: > print "$_\n" foreach keys &func();
:
: Please. There are ways -- well, just one way -- to do this, even in perl5.
:
:
>So the internals stay almost the same, but before resorting to die,
>you attempt a cast, if it works you warn that's inefficient under strict,
>and of course in the docs. If I occasionally want to be inefficient, I should
>have the license to do so. But I really don't think it'll be that less
>ef
In reply to your message from the not too distant future: next Monday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Tue, 22 Aug 2000 10:15:48 EDT
From: Jerrad Pierce
>So, you
Casey R. Tweten wrote:
>
> sub func {
> return qw/KeyOne Value1 KeyTwo Value2/;
> }
>
> print "$_\n" foreach keys &func();
Please. There are ways -- well, just one way -- to do this, even in perl5.
print "$_\n" foreach keys %{{ func() }};
--
John Porter
We're building t
Piers Cawley wrote:
>
> You forgot:
> print (1, 11, 21, 1211, ...)
print( 'M', 'MI', 'MIU', ... )
ALso, Larry, how about making the various common emoticons meaningful?
please do come from 10; :-)
I.e. "belay that command".
--
John Porter
We're building the
Damian Conway wrote:
>
> I think this is fraught with peril. I'd have expected:
>
> print (1, 2, 3, ...) or die;
>
> to print
>
> 12345678910111213141516171819202122232425262728etc
No, if that's what you wanted, you'd get it with
print( 1, 2, 3 .. ) # RFC 24
--
Jo
Larry Wall wrote:
>
> Either that, or it's a funny unary operator that can take 0 or 1 argument.
>
> But I'd be happy with just ... as a statement. Dwimming the unary
> operator may not be worth it. Especially since it might be confused
> with the binary operator.
Could you make it "evapora
On Tue, Aug 22, 2000 at 09:49:12AM -0400, John Porter wrote:
> Damian Conway wrote:
> >
> > Easy. I'll just add a C operator to Q::S. It would take no
> > arguments and return a (lazy?) list of every possible Perl subroutine.
> >
> > PS: Can you tell whether I'm joking?
>
> I think you're both
Damian Conway wrote:
>
> Easy. I'll just add a C operator to Q::S. It would take no
> arguments and return a (lazy?) list of every possible Perl subroutine.
>
> PS: Can you tell whether I'm joking?
I think you're both joking AND not joking, at the same time.
--
John Porter
We're buil
Numerical python uses "..." in the same sense for axis
lists in multi-dim arrays. (Improved syntax for multidim
arrays is one wishlist item from PDL for the perl core.
See RFC117)
NumPy allows you to say:
a[..., :];
where "..." means "however many", - so this is a slice along
the last dimen
Larry Wall <[EMAIL PROTECTED]> writes:
> If you're into dwimmery, you could make all of these work, too:
>
> print (1, 2, 4, ...)
> print (1, 4, 9, 16, 25, ...)
> print (1, 1, 2, 3, 5, ...)
> print ('a', 'b', 'c', ...)
> print (3, 1, 4, 1, 5, 9, 6, 2, 5, ...)
You forgot:
53 matches
Mail list logo
