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
interpolation if the
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.
--
How about a Base64 to match with uuencode?
chaim
"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
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 knowledge
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,5;
=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
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:
Let's jump in. This RFC proposes a Creshape 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
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 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
14 matches
Mail list logo
