This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins : Make use of hashref context for garrulous builtins
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 19 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 259
Versi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Distinguish packed binary data from printable strings
=head1 VERSION
Maintainer: Tim Conrow <[EMAIL PROTECTED]>
Date: 18 Sept 2000
Mailing List: [EMAIL PROTECTED]
Number: 258
Version: 1
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Extend the window to turn on taint mode
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 227
Versio
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add memoize into the standard library
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 228
Version:
I'm planning to withdraw RFC184 ("Perl should support an interactive
mode"), due to lack of interest. There was little discussion of it,
and the consensus seemed to be that C is "good enough" for
most purposes, and C for all others. While I do not agree, it
does mean there is no call for this R
Damian Conway wrote:
>
> That's it! I'm gonna take that whole section out and burn it!
;-)
> $1 is the *only* place in Perl where an index starts at 1. *It's* the one
> that's inconsistent. Fix *it*.
I'd love to. But we're stuck, unless we make a $CMD which holds what $0
currently holds, whic
Chaim Frenkel wrote:
> > "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> GL> There is a difference between "undefined" and "unknown".
>
> GL> Perl undefined is a different concept--that of an uninitialized
> GL> variable. This is proven from its earliest versions where the
> GL> valu
> 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
Morning all,
This email forms my latest semi-official report on the state of the Perl
6 Language WG, and also begs the forbearance of the Perl 6 community as
I go through a slightly difficult time personally.
I've been fairly quiet on -language and -meta because everything seems
to be moving alo
Nathan Wiger wrote:
>
> Either we need to change $1 to $0, or change ^0 to ^1. Considering $0
> has been around a little while longer than HOFN, I strongly suggest we
> change ^0 to ^1 to be consistent.
>
> I realize this RFC has been frozen, but this is an important issue. And
> remember, Mike
> > =head2 Choice of notation
> >
> > The placeholder notation has been chosen to be consistent with the
> > eisting Perl scalar notation (but using a ^ prefix rather than a $):
> >
> > RoleScalar Placeholder
> > var
> 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
> =head2 Choice of notation
>
> The placeholder notation has been chosen to be consistent with the
> eisting Perl scalar notation (but using a ^ prefix rather than a $):
>
> RoleScalar Placeholder
> var analog
>
> named
On Mon, 18 Sep 2000 23:11:28 +0100, John McNamara wrote:
> foreach $item (@array) {
> print $item, " is at index ", $#, "\n";
> }
Maybe I'm a little late... But I just thought how neat it would be if
this would also extend to map() and grep().
Remember, officially the processing
All-
In an attempt to nudge things in the right direction (wrap-up), I've
gone through and made some specific comments on RFC's. These are my
opinions from monitoring the discussions on this list since its
inception. I do not claim to be infallible, but feel I have a pretty
good idea of what's be
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Native support for multimethods
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 18 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 256
Version: 1
Status: Deve
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
UNIVERSAL::import()
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 257
Version: 1
Status: Developing
=head1 ABSTRACT
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 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
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 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 19
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Rationalizing C, C, and C
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 224
Version:
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 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numbe
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Fix iteration of nested hashes
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 255
Version: 1
Status: Developing
=head1 A
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace C built-in with pragmatically-induced C function
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 15 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
N
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Retire chop().
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: 5 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 195
Version: 3
Status: Froze
=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 Modi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Overview: Perl OO should I be fundamentally changed.
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 21 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numbe
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Regex: Support for incremental pattern matching
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 11 Aug 2000
Last Modified: 18 Sep 2000
Number: 93
Version: 3
Mailing List: [EMA
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Replace => (stringifying comma) with => (pair constructor)
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow exception-based error-reporting.
=head1 VERSION
Maintainer: Bennett Todd <[EMAIL PROTECTED]>
Date: 8 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 70
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Compilation: Remove requirement for final true value in require-d and do-ed files
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Last Modified: 18 Sep 2000
Mailing Lis
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Operators: Polymorphic comparisons
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 54
Version: 2
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Request For New Pragma: Shell
=head1 VERSION
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Date: 5 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 42
Version: 3
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Co-routines
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Number: 31
Version: 2
Mailing List: [EMAIL PROTECTED]
Status:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Higher order functions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Number: 23
Version: 5
Mailing List: [EMAIL PROTECTED]
Status: Fr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Operators: Multiway comparisons
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 25
Version: 2
S
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Control flow: Builtin switch statement
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 22
Version
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data types: Semi-finite (lazy) lists
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 24
Version:
Eryq wrote:
> And all that I am saying is that this syntactic complication,
> this special case where "the filehandle name *is* the object",
> should be gotten rid of. Unlike some other special Perl syntactic
> constructs (e.g., regular expressions, "here-is" documents),
> the current filehandl
All-
As the sublist chair, I politely ask you to please table this
discussion. Time is running short and this is really a digression.
Glenn, if you have a proposal, please put one together in RFC format and
post it to -objects.
-Nate
Michael G Schwern wrote:
> I guess I'm trying to say something about micro-optmizations being
> more trouble than they're worth and usually hurt more than they help.
>
> > So let's posit you've cured the accessor overhead problem. Now
> > we're left with set_const being 40% slower for hash, and
On Mon, Sep 18, 2000 at 01:26:45PM -0700, Glenn Linderman wrote:
> Michael G Schwern wrote:
> > Similar mistaken logic leads to "globals are faster than lexicals".
>
> Maybe so, but I'd think lexicals would be faster, because more of
> the lookup is done at compile time rather than runtime... so
The following is intended as a draft of the final draft of RFC 120
"Implicit counter in for statements, possibly $#".
It includes summarised alternatives based on discussions in this list. It
is not intended that this post should revive these discussions. It is a
chance for the contributing pa
Tom asked how we'd deal with variadic subroutines without sacrificing
compile-time information (i.e. parameter lists).
Below I've indicated how RFC 128 would handle the cases he lists.
To recap: RFC 128 proposes that parameters may be given a C<:repeat>
attribute to make them variadic within a
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> $htdoc = open uri "http://www.yahoo.com" or die;
NC> with uri in the standard library
NC> and also make it easy to stack the module that does uri at the top of 'file'
NC> so that the default is to call the uri stuff.
Is it just me, but
> >I propose that the existing C mechanism be removed from Perl 6
> >and be replaced with a pragma-induced add-in function, based on
> >the semantics of C, as described in
> >the following sections.
>
> Can you please explain what's the difference between a module and a
> pr
> 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,
On 15 Sep 2000 19:18:18 -, Perl6 RFC Librarian quoted Damian Conway:
>I propose that the existing C mechanism be removed from Perl 6
>and be replaced with a pragma-induced add-in function, based on
>the semantics of C, as described in
>the following sections.
Can you please explain what's t
At 9:08 -0700 2000.09.18, Nathan Wiger wrote:
>Chris Nandor wrote:
>>
>> >just assume "All Perl core functions should return objects", and hence
>> >the reason I wrote RFC 73. ;-)
>>
>> And it would make me stop using Perl faster than your object method could
>> be resolved.
>
>Is your concern one
Michael G Schwern wrote:
> Similar mistaken logic leads to "globals are faster than lexicals".
Maybe so, but I'd think lexicals would be faster, because more of the lookup is
done at compile time rather than runtime... so I'm not sure what is similar
about the mistaken logic... for arrays, more
Let's table this discussion, please. There are two different concerns
here:
1. IO::Handle et al *are* too damn big and slow.
2. Bareword filehandles *are* a pain to deal with.
Perl 5.6 already has a lot of this solved by allowing lexically-scoped
variables to hold filehandles. We should
On Mon, Sep 18, 2000 at 01:02:31PM -0700, Glenn Linderman wrote:
> OK, thanks for the info. I'm not an internals guy, but I guess I
> should have written the benchmark. It just _seemed_ they should be
> slower, because there is more work to do the hashing. The actual
> lookup, I agree, should b
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
Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 11:01:12AM -0700, Glenn Linderman wrote:
> > One of the big complaints about today's perl objects is their slowness at
> > accessing member data, which is a direct result of hashes being used as the
> > base data type for the underlying member da
On Mon, 18 Sep 2000, Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 12:32:08PM -0400, Sam Tregar wrote:
>
> If I grok'd the bastards, I'd write the explaination myself.
If you grok'd the bastards I bet you'd realize how useless such an
explanation would be. The chief reason for using pack/
Ken Fox wrote:
>
> "David L. Nicol" wrote:
> > Hey, none of those are better than "It would be nice"
> >
> > They're all reasons why it would be nice
>
> I'm a little hazy on what you think is a "better" reason if all
> of mine were variants of "it would be nice."
> ...
> i.e. It would be nice.
On Mon, Sep 18, 2000 at 11:37:50AM -0700, Glenn Linderman wrote:
> > Parens are also mandatory if
> > arguments are to be passed.
>
> And I guess the balancing of the parens would solve many of the
> problems of argument parsing for the function, which is a concern to
> me. Within actual double
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
At this point, I think the whole thread on functions throwing
exceptions should either be:
(a) turned into an RFC
or
(b) abandoned.
This discussion is going around and around like a piece of toilet
paper in a weakly-flushing toilet.
Nat
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
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> This would work:
DC> footer => sub { "$From - $To" }
DC> except there's no way of setting the $From and $To variables as
DC> each page is formatted. I don't think C by itself is the
DC> right solution for this problem, unless I add
On Mon, Sep 18, 2000 at 11:01:12AM -0700, Glenn Linderman wrote:
> One of the big complaints about today's perl objects is their slowness at
> accessing member data, which is a direct result of hashes being used as the
> base data type for the underlying member data items.
The speed differences b
John Porter wrote:
> Glenn Linderman wrote:
> >
> > The idea of a _normal_ situation being considered exceptional is raised when the
> > code written inappropriately handles some of the normal return values.
>
> You would throw exceptions at the problem of bad coding practice.
Not the goal. The
On 13 Sep 2000 07:07:42 -, Perl6 RFC Librarian wrote:
>Make length(@array) work
One more thought:
>Many newbies think of the number of
>elements in an array as its "length"
Doesn't this reflect C's idea of "a string is an array of characters"?
Which isn't the idea behind strings in Perl.
Adam Turoff writes:
> I want to assert to the reader that there have been no substantive
> changes since v3 if an RFC was frozen at v3, but is currently v5.
>
> A "Frozen Since: v3" attribute should make this apparent.
Sure. And rather than rediddling all the other RFCs, only introduce
this whe
Perl6 RFC Librarian wrote:
> The & is mandatory.
Which makes me happy with this proposal
> Parens are also mandatory if
> arguments are to be passed.
And I guess the balancing of the parens would solve many of the problems of
argument parsing for the function, which is a concern to me. Within
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
Perl6 RFC Librarian wrote:
> =head1 IMPLEMENTATION
>
> The tokenizer will have to watch for /\s[a-z_]\w*->/i. A following
> /[A-Z_]\w*\(\)/ indicates a class method call.
>
Don't forget about including "::" parsing in the class method name.
I register negative on this one, since there is no "$
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
On Mon, Sep 18, 2000 at 12:18:19PM -0600, Nathan Torkington wrote:
> I'm against fractional version numbers on the grounds that it's
> another piece of knowledge that must be held before someone can
> understand the system (think of 5.004_54 and how hideous that system
> was). Integers imply all
Adam Turoff writes:
> >From here on out, Frozen RFCs shall remain Frozen. Should the maintainer
> wish to clarify them after they have been frozen, the version number
> will increment by some fractional value (.01?), and a
> "Clarified: DD MMM " header will be added to the metadata.
>
> Obj
Michael G Schwern writes:
> You can do it! While it seems "food" and "supermarket" are critical
> to the understanding of a shopping-cart, they're really just
> incedental. I'm saying the same thing about un/pack!
>
> If I grok'd the bastards, I'd write the explaination myself.
Please take thi
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
On Mon, Sep 18, 2000 at 12:32:08PM -0400, Sam Tregar wrote:
> "Describe to me how you use a supermarket shopping-cart in terms of a
> hardware store. Don't mention any words for food. Just talk about nuts
> and bolts."
"When shopping for tools, a shopping-cart is the thing you carry your
tools
On Mon, Sep 18, 2000 at 12:31:34PM -0400, Casey R. Tweten wrote:
> I think pack/unpack are perlish enough. Especially if we believe that
> printf/sprintf are perlish.
Interpolation is perlish. printf and sprintf are not. And for
similar reasons as pack/unpack. "%e a floating-point number, in
Glenn Linderman wrote:
>
> There is a difference between "undefined" and "unknown".
Can you explain this difference, briefly?
If not, could you give me something off-list?
Thanks,
John Porter
Glenn Linderman wrote:
>
> The idea of a _normal_ situation being considered exceptional is raised when the
> code written inappropriately handles some of the normal return values.
You would throw exceptions at the problem of bad coding practice.
I think it's better to correct the bad coding p
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 02:04:51AM -0400, Bennett Todd wrote:
> 2000-09-18-01:35:42 Adam Turoff:
> > Background: RFCs should be in development until frozen or retired.
>
> An interesting puzzle. As the author of RFC 70, I've felt like I
> should make some updates, but they've been utterly trivial
Michael G Schwern wrote:
>
> It all works.
Mokay...
> DTRT? Data Terminal Ready, Tim? Document Filing and Retrieval Tedium?
Do The Right Thing, of course.
--
John Porter
On Mon, Sep 18, 2000 at 10:12:33PM +1100, Jeremy Howard wrote:
> Some background would help--how is Larry being fed these RFCs?
By pointing his browser to http://dev.perl.org/rfc/. Just like the
rest of us.
I seriously doubt he's using Grail or tkWeb as his browser though. :-)
Z.
Perl6 RFC Librarian wrote:
> Which again, can be used in the appropriate contexts. Note this allows
> you to maintain arrayref objects automatically as well:
>
>package Johnson;
>sub new {
>my $class = shift;
>my $self = [];
>$self->[0]->[2]->[3] :raccess('size') =
On Mon, Sep 18, 2000 at 11:20:15AM -0400, John Porter wrote:
> Seems to me that it would need to be written as
>
> $module->UNIVERSAL::require;
>
> How do you propose to avoid that?
What is a class but a package? And what is the name of a class but a
package name? And since there's no c
On Mon, Sep 18, 2000 at 02:18:50AM -0400, Michael G Schwern wrote:
> On Mon, Sep 18, 2000 at 01:35:42AM -0400, Adam Turoff wrote:
> > Background: RFCs should be in development until frozen or retired.
> >
> > Problem: Frozen RFCs are being updated.
>
> Solution #4: Slip the RFC status back to '
I will never, ever, ever possibly begin to process all this mail.
It's completely impossible. I have three days before I leave the
country for three weeks, and nothing is done. Therefore, my answer
to you will be short and underdone. One can type on p6 lists *all*
day and get no nearer to closu
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 04:04:56PM +0100, Simon Cozens wrote:
> On Mon, Sep 18, 2000 at 10:51:52AM -0400, John Porter wrote:
> > I would think that if it could be done at all,
> > it would only be in extension (formerly XS) code.
>
> Why? I don't want to go to C just to add a flag to a variable.
On 15 Sep 2000, at 11:25, Steve Fink wrote:
> Does it strike anyone else as odd that 'foo\\bar' eq 'foo\bar'?
While 'foo\\' ne 'foo\' :-) (specifically, the former is not a syntax error
:-)
Cheers,
Philip
On Mon, Sep 18, 2000 at 01:01:55PM -0400, John Siracusa wrote:
> Don't forget the fact that direct access is much faster than a method
> call in Perl 5. This will be fixed in Perl 6, of course...right? :)
RFC 163
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
>Okay, we get the idea! Only very simple things should interpolate.
>Do you have any other objections to the RFCs?
Yes: to the mail volume. And I'm about to fix that.
On Mon, Sep 18, 2000 at 07:30:37AM -0600, Tom Christiansen wrote:
> >So what about
>
> > print "Thanks, $user->{'first name'} for your order!";
>
> >Which needs nested quotes already?
>
> printf() is more readable in such cases.
Okay, we get the idea! Only very simple things should interpol
On Mon, Sep 18, 2000 at 10:18:41AM -0600, Nathan Torkington wrote:
> Piers Cawley writes:
> > The idea here is to allow people to get ideas on the lists in a rough
> > form where they can get some initial comments (which may blow the
> > 'real' RFC out of the water...). There should be some very s
>As Nate pointed out: print "$hash->{'f'.'oo'}" already works fine and
>the world spins on.
That is no argument for promoting illegibility.
--tom
On Mon, Sep 18, 2000 at 07:23:41AM -0600, Tom Christiansen wrote:
> >> Oh joy: now Perl has nested quotes. I *hate* nested quotes.
> >Those are single-quotes inside double-quotes.
>
> Yep: nested, with varying semantic effects. Completely nasty.
As Nate pointed out: print "$hash->{'f'.'oo'}"
Chaim Frenkel wrote:
> What about a hypothetical, use tristate. This would give undef some
> extra special powers.
There is a difference between "undefined" and "unknown".
SQL NULL, and the resultant tristate operators used in SQL, specifically is based
on NULL representing the "unknown" value.
Chaim Frenkel wrote:
> > "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
>
> >> Neither is EOF on a file, or working with an empty list. Adding all these
> >> exceptions for non-exceptional and quite common scenerios is bothersome.
>
> I don't know where this idea of a _normal_ situation
On 9/18/00 3:44 AM, Damian Conway wrote:
>>> my $weather = new Schwern::Example;
>>> print "Today's weather will be $weather->{temp} degrees and sunny.";
>>> print "And tomorrow we'll be expecting ", $weather->forecast;
>>
>> You are wicked and wrong to have broken inside and peeked at the
Tom Christiansen wrote:
>
> > * Have to use ugly globref syntax to pass them around reliably.
>
> No, you don't. You can use globs. But only if you don't have
> prototypes, like sub opt(*).
I would argue that many Perlers don't use prototypes.
Whether they should or not is another issu
On Mon, Sep 18, 2000 at 10:16:46AM -0400, John Porter wrote:
> Hildo Biersma wrote:
> > IMHO, mixing procedural and OO interfaces to the same module is a bad
> > idea. Promoting it in the language is not wise.
>
> O.k., but that's not the same as disallowing it. Perl is not a B&D
> language.
I
>But Tom, that preserves all the white space both before and after the '!'!
>Michael's goal is to eliminate the leading white space, although he didn
>'!' bit. So I'm not sure how you'd have written that if you'd have done
>specification.
Yeah, ok. I still think
# Your stuff that you w
1 - 100 of 180 matches
Mail list logo
