On Sun, 17 Sep 2000 21:59:47 -0700, Nathan Wiger wrote:
>Yeah, I for one think %hashes should be interpolated exactly like
>@arrays. It's simple and consistent.
Simple and consistent would be behaviour like
"@{[%hash]}"
However, convenient it is not, getting all key/value pairs in one
Hi Ilya,
I have three questions about your RFC:
Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
a stride of 2) ?
If not is there an easy way to incorporate that?
Secondly, what about having multidim support in the core so that the
tie-tokenisers get optimised away? i.e.
Chaim Frenkel writes:
> What about formating the output as a value that can be used by eval?
>
> %hash = (a => 1, b => 'the world');
> print "%{hash}\n";
>
> ('a' => 1, 'b'=> 'the world')
Interesting.
> And as for having to escape % in printf strings. Why not enable the
> interpola
On 17 Sep 2000 23:54:05 -0400, Chaim Frenkel wrote:
>What about formating the output as a value that can be used by eval?
>
> %hash = (a => 1, b => 'the world');
> print "%{hash}\n";
>
>('a' => 1, 'b'=> 'the world')
So, what about arrays? Or scalars?
We have Data::Dumper for that.
Perl6 RFC Librarian wrote:
> RFC 246: pack/unpack uncontrovercial enhancements
> RFC 247: pack/unpack C-like enhancements
>
> RFC 248: enhanced groups in pack/unpack
>
> RFC 249: Use pack/unpack for marshalling
>
> RFC 250: hooks in pack/unpack
>
> The following enhancement covers almost all the
How about a Base64 to match with uuencode?
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> =head1 ABSTRACT
PRL> This RFC proposes simple enhancements to templates of pack/unpack builtins.
PRL> These enhancements do not change the spirit of how pack/unpack is used.
PRL> The
On Mon, Sep 18, 2000 at 11:32:39AM -0700, Glenn Linderman wrote:
> > Its just damn unperlish. Perhaps that's in its nature, being that its
> > for converting data from things which are Perl, but we've got to be
> > able to do better.
> >
>
> RFC 142 may not be perfect, but it results in similar f
Michael G Schwern writes:
> RFC 142 may help out existing un/pack users, but does nothing to help
> in the understanding of un/pack by native speakers of Perl.
>
> I'm starting to think this is largely a documentation issue.
Yes. Please put this thread out of our collective misery.
Nat
Michael G Schwern wrote:
> RFC 142 may help out existing un/pack users, but does nothing to help
> in the understanding of un/pack by native speakers of Perl.
>
> I'm starting to think this is largely a documentation issue.
The existing documentation of pack/unpack is terse, and assumes a knowle
> Finally as an overload expert what do you think about the proposals
> to make arrays overloadable objects so one can say things like:
>
> @x = 3 * @y;
Is this where RFC 231's suggestion for OO slicing comes in (see quote)?
> For example,
>
>$matrix1->[2..5; 2..4] * $matrix2->[1,3,
=head1 VERSION
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add reshape() for multi-dimensional array reshaping
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 24 Aug 2000
Last Modif
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Superpositions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 225
Version: 2
Status: Fr
> Let's jump in. This RFC proposes a C builtin with the following
> syntax:
>
Err... this syntax isn't what I expected at all! I thought the first
argument would define the shape of the result, like NumPy or PDL...
> When one array is passed in, it is split up. Here, the C<$x> and C<$y>
> determi
> Sorry Nate--I know we thought we were on the same wavelength here, but it
> looks like we weren't at all! Would you like me to redraft this for you, or
> create a new RFC?
It's all yours. My brain is toast, and I'm totally RFC'ed out. The only
thing I care about is that the lists wind up on the
At 02:53 AM 9/18/00 -0400, Michael G Schwern wrote:
>Perhaps someone could attempt to write an explaination of pack and
>unpack in completely Perl terms. No bits, no ints, no nybbles, no
>IEEE floating point arithmetic, no prior knowledge of C necessary.
I don't see how you could possibly do it
On Mon, Sep 18, 2000 at 11:23:21AM -0400, John Porter wrote:
> Uh huh... Are you prepared to write an explanation of Perl arrays
> without making any mention of Perl scalars?
"An array is a container for a list. Items in the list can be added,
changed and removed, taken off and put onto both en
On Mon, Sep 18, 2000 at 10:54:04AM -0700, Peter Scott wrote:
> I don't see how you could possibly do it without that any more than you can
> use numbers without understanding the range limits of integers and floating
> point roundoff.
You ignore that incidental detail until later on in the docs
17 matches
Mail list logo
