> > Should I point out that RFC 225 (Superpositions) actually covers
> > most of this?
> >
> > C is equivalent in semantics to C or C.
>
> I'd love to read your not yet available paper to which the RFC
> refers. However, until it is available, and I have time to read it,
>
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Russ Allbery wrote:
>> I agree with Tom; I think it's pretty self-evident that they're the
>> same thing. undef means exactly the same thing as null; that's not the
>> problem. The problem is that Perl doesn't implement the tri-state
>> logic semant
On Tue, 19 Sep 2000, Glenn Linderman wrote:
> > I agree that undef and NULL have different semantics. However, this is
> > clearly SQL's fault and not Perl's. We shouldn't repeat their mistake
> > just because we occasionally have to interface with their system.
>
> They are different. Neithe
Damian Conway wrote:
> Should I point out that RFC 225 (Superpositions) actually covers most of this?
>
> C is equivalent in semantics to C or C.
I'd love to read your not yet available paper to which the RFC refers. However,
until it is available, and I have time to read it, I'll spend my time
Russ Allbery wrote:
> I agree with Tom; I think it's pretty self-evident that they're the same
> thing. undef means exactly the same thing as null; that's not the
> problem. The problem is that Perl doesn't implement the tri-state logic
> semantics that most users of null are used to, which is
Sam Tregar wrote:
> Does it really make it more difficult? I would argue that having NULLs
> mapped to undefs is actually better than having real NULLs in Perl. An
> undef is a rather concrete and easily dealt with value - simply test with
> defined(). Plus, if you're careless enough to try to
Glenn Linderman <[EMAIL PROTECTED]> writes:
> Tom Christiansen wrote:
>>> Currently, Perl has the concept of C, which means that a value
>>> is not defined. One thing it lacks, however, is the concept of
>>> C, which means that a value is known to be unknown or not
>>> applicable. These are two s
Tom Christiansen wrote:
> >Currently, Perl has the concept of C, which means that a value is
> >not defined. One thing it lacks, however, is the concept of C,
> >which means that a value is known to be unknown or not applicable. These
> >are two separate concepts.
>
> No, they aren't.
>
> --tom
At 10:11 PM 9/19/00 -0700, Nathan Wiger wrote:
>Tom Christiansen wrote:
> >
> > >Currently, Perl has the concept of C, which means that a value is
> > >not defined. One thing it lacks, however, is the concept of C,
> > >which means that a value is known to be unknown or not applicable. These
> > >
On 20 Sep 2000, Perl6 RFC Librarian wrote:
> The absence of a C concept and keyword in Perl makes it more
> difficult to interface with relational databases and other medium which
> utilize C. Modules such as C must map C to C,
> which is an imperfect match.
Does it really make it more difficult
Tom Christiansen wrote:
>
> >Currently, Perl has the concept of C, which means that a value is
> >not defined. One thing it lacks, however, is the concept of C,
> >which means that a value is known to be unknown or not applicable. These
> >are two separate concepts.
>
> No, they aren't.
Uhhh, y
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: reduce
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 10 August 2000
Last Modified: 20 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 76
Version: 3
Status: Froze
>Currently, Perl has the concept of C, which means that a value is
>not defined. One thing it lacks, however, is the concept of C,
>which means that a value is known to be unknown or not applicable. These
>are two separate concepts.
No, they aren't.
--tom
>Currently many programs handle error returns by examining the text of
>the error returned in $@. This makes changes in the text of the error
>message, an issue for the backwards compatibility police.
eval { fn() };
if ($@ == EYOURWHATHURTS) { }
sub fn { die "blindlesnot" }
Should I point out that RFC 225 (Superpositions) actually covers most of this?
C is equivalent in semantics to C or C.
Except, of course, the superpositional versions work...In Constant Time!
;-)
Damian
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Provide a standard module to simplify the creation of source filters
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 20 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 264
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add null() keyword and fundamental data type
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 263
Version: 1
Status: De
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Index Attribute
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 262
Version: 1
Status: Developing
=head1 ABSTRACT
An attr
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Pattern matching on perl values
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 261
Version: 1
Status: Developing
=head1 ABST
>The warning for the use of an unassigned variable should be "use of
>uninitialized variable C<$x>".
The problem with that idea, now as before, is that this check happens
where Perl is looking at a value, not a variable. Even were it possible
to arduously modify Perl to handle explicitly named
On Tue, Sep 19, 2000 at 08:14:24PM -0600, Tom Christiansen wrote:
> >Following Glenn's lead, I'm in the process of RFC'ing a new null()
> >keyword and value
>
> As though one were not already drowning in a surfeit of subtly
> dissimilar false values.
Hear, hear.
Three-valued logic is enough.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
All perl generated errors should have a unique identifier
=head1 VERSION
Maintainer: Chaim Frenkel <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
N
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
variable usage warnings
=head1 VERSION
Maintainer: Steve Fink <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 12
Version: 2
Status: Deve
> Ummm...Maybe I'm missing something, but how does reduce() know the
> difference between
>
> $sum = reduce ^_+^_, 0, @values;
>
> unshift @values, 0;
> $sum = reduce ^_+^_, @values;
There *isn't* any difference. Both versions guarantee that the list
Ilya Zakharevich wrote:
>
> $_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on
> its way to its grave already, see C.
Yeah, but you're still just sidestepping my point. Your position seems
poised on the hope that no more special variables get introduced, or
that some of the exi
>Ummm...Maybe I'm missing something, but how does reduce() know the
>difference between
>$sum = reduce ^_+^_, 0, @values;
>unshift @values, 0;
>$sum = reduce ^_+^_, @values;
You know, I really find it much more legible to consistently write
these sorts of thing with brac
> In any case, the preferred option should be to provide a default value:
>
> $sum = reduce ^_+^_, 0, @values;
>
> which is always cleaner *and* shorter. :-)
Ummm...Maybe I'm missing something, but how does reduce() know the
difference between
$sum = reduce ^_+^_, 0, @values;
> > $sum = @numbers ? reduce ^_+^_, @numbers : 0;
>
> Although we're back to the pain of what happens when @numbers is
> really fn(). This is unsatisfactorily nonidempotent (aliapotent? :-)
>
> $sum = fn() ? reduce ^_+^_, fn() : 0;
It would seem likely that most would tr
>> $IO::STDERR->print @stuff;
>> print $IO::STDERR @stuff;
You know, I already resent having to use STDERR instead of stderr.
Adding five noisy characters, or seven, is way, way over the top.
As for system globals, when one suggested to Larry that these be
something on the order of SYS::ARGV
>Tom suggested:
> > Why not just check @numbers?
>Hear, hear:
> $sum = @numbers ? reduce ^_+^_, @numbers : 0;
Although we're back to the pain of what happens when @numbers is
really fn(). This is unsatisfactorily nonidempotent (aliapotent? :-)
$sum = fn() ? reduce ^_+^_, fn() : 0
>Following Glenn's lead, I'm in the process of RFC'ing a new null()
>keyword and value
As though one were not already drowning in a surfeit of subtly
dissimilar false values.
--tom
On Tue, Sep 19, 2000 at 06:39:49PM -0700, Nathan Wiger wrote:
> > The presence of a method STORE is visible outside of the module, and
> > may be &required* if the module follows some published (non-Perl) API.
> > Variables are of different ilk.
>
> I think you're overlooking they can both be equ
Ilya Zakharevich wrote:
>
> The presence of a method STORE is visible outside of the module, and
> may be &required* if the module follows some published (non-Perl) API.
> Variables are of different ilk.
I think you're overlooking they can both be equally visible:
$Foo::DEBUG = 1;
Foo::S
Thanks to everyone for their valuable feedback on this RFC.
Clearly the proposed solution is not adequate, perhaps because
it does not address the central issue that iterators really ought
to be stateful objects, rather than statefree functions.
I don't have time to rework the proposal from scra
At 04:57 PM 9/19/00 -0700, Nathan Wiger wrote:
>Following Glenn's lead, I'm in the process of RFC'ing a new null()
>keyword and value that will do this:
>
> $a = 1;
> $b = null;
> $c = $a + $b;
>
>$c is null, not 1.
>
>Since undef() has established semantics, I don't think these should
>chan
On Tue, Sep 19, 2000 at 04:52:12PM -0700, Nathan Wiger wrote:
> Ok, you should clarify this. You're not suggesting that indirect object
> syntax be removed. You're suggesting that it should not accept
> barewords. These are two separate things.
Agreed. I realized the ambiguity only after I poste
On Tue, Sep 19, 2000 at 04:50:04PM -0700, Nathan Wiger wrote:
> Ilya Zakharevich wrote:
> >
> > On the other hand, there are only 5 names, not hundreds of them, and
> > they do not "get in the way", as ADD would do (prohibiting a method
> > named ADD). So letting them be may be also a solution..
Graham Barr wrote:
>
> On Tue, Sep 19, 2000 at 04:06:00PM -0600, Tom Christiansen wrote:
> > Why not just check @numbers?
>
> Well if the 'use trisate' pragma ever arises (did anyone RFC that ?)
Following Glenn's lead, I'm in the process of RFC'ing a new null()
keyword and value that will do th
Ilya Zakharevich wrote:
>
> On Tue, Sep 19, 2000 at 04:26:47PM -0700, Nathan Wiger wrote:
> > > $IO::STDERR->print @stuff;
> > > print $IO::STDERR @stuff;
> >
> > Ok, something here is extreme confused. Is not the second form an
> > instance of indirect object syntax?
>
> It is not with a ba
Ilya Zakharevich wrote:
>
> On the other hand, there are only 5 names, not hundreds of them, and
> they do not "get in the way", as ADD would do (prohibiting a method
> named ADD). So letting them be may be also a solution...
Uhhh, I think you should check the Camel. These variables certainly d
On Tue, Sep 19, 2000 at 04:06:00PM -0600, Tom Christiansen wrote:
> Why not just check @numbers?
Well if the 'use trisate' pragma ever arises (did anyone RFC that ?)
$a = 1;
$b = undef;
$c = $a + $b;
$c is undef, not 1.
Graham.
In message <[EMAIL PROTECTED]>
Perl6 RFC Librarian <[EMAIL PROTECTED]> wrote:
> =head1 MIGRATION ISSUES
>
> Minimal. No-one nests iterators now because it doesn't work.
Indeed. It is just concievable though that somebody might write
each more than once as part of a single iteration - s
On Tue, Sep 19, 2000 at 04:26:47PM -0700, Nathan Wiger wrote:
> > $IO::STDERR->print @stuff;
> > print $IO::STDERR @stuff;
>
> Ok, something here is extreme confused. Is not the second form an
> instance of indirect object syntax?
It is not with a bareword at the second place, so is not caus
> "Perl6" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
Perl6> If the reduction subroutine has a prototype, that prototype
Perl6> determines how many items are reduced at a time. If the reduction subroutine
Perl6> is a block or has no prototype, two items are reduced each time.
... is i
On Tue, Sep 19, 2000 at 04:22:31PM -0700, Nathan Wiger wrote:
> > What ALLCAPS variables?
>
> Well, @ARGV comes to mind.
I see, and @INC, %INC, %ENV, %SIG.
> Maybe we should provide a special namespace for these as well,
> besides main::?
This is a nice possible solution. There may be many ot
Ilya Zakharevich wrote:
>
> Why not use ->?
>
> $IO::STDERR->print @stuff;
> print $IO::STDERR @stuff;
Ok, something here is extreme confused. Is not the second form an
instance of indirect object syntax?
> ==
> This would cau
Tom suggested:
> Why not just check @numbers?
Hear, hear:
$sum = @numbers ? reduce ^_+^_, @numbers : 0;
Moreover, I suspect that the usual idiom will be:
$result = reduce $reducer, $default, @list;
That is:
$sum = reduce ^_+^_, 0, @numbers;
in which case the "emp
Ilya Zakharevich wrote:
>
> ==
> > No special UPPERCASE_NAME subroutines
>
> Whoa! What about ALLCAPS variables? Should we axe all of them as well?
> They're the exact same idea.
> ===
Just as a data point, I have now removed this short-circuiting bits
from the C RFC. You may take that as a deferral to -- and
endorsement of -- the more general mechanism mooted in RFC 199.
Damian
==
Please show me how to write:
print STDERR @stuff;
without it, while keeping it a method of the STDERR filehandle, and
without requiring ->.
==
Why not use ->?
==
> No special UPPERCASE_NAME subroutines
Whoa! What about ALLCAPS variables? Should we axe all of them as well?
They're the exact same idea.
==
What ALLCAPS variables
On Tue, Sep 19, 2000 at 08:06:58AM -0700, Nathan Wiger wrote:
> If exports() could take arbitrary symbols, just like @EXPORT
Yes, that's the idea.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee
a) I do not subscribe to Perl6 lists, so please consider including me
on the Cc lines;
b)
==
* From: Nathan Wiger
> There are several proposals to switch the meaning of C
basing on
> the whether $arg is an array reference
On Tue, Sep 19, 2000 at 01:19:05PM -0400, John Porter wrote:
> Michael G Schwern wrote:
> > Would anyone find it useful to have a UNIVERSAL method which reports
> > on what sybols a given module exports?
>
> I don't see any reason why this should be anything other than a module.
> A module in t
After an initial spark of interest, discussion related to RFC199 has
dropped off considerably. I'd like to gather any last comments anyone would
like to contribute and then freeze the RFC at the end of the week.
I'm particularly interested in commentary for and against:
- the proposal as a whole
Why not just check @numbers?
--tom
> > $sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
>
> >Note with the || that way, it'll die immediately if @numbers is empty,
> >even before destroying the universe.
>
> Yes, but why are you passing the size of the array in there?
:-)
And even if you wrote:
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> >This RFC proposes that the internal cursor iterated by the C
>> >function be stored in the pad of the block containing the C,
>> >rather than being stored within the hash being iterated.
>>
>> Then how do you specify which ite
Tom Christiansen wrote:
>
> > $sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
>
> >Note with the || that way, it'll die immediately if @numbers is empty,
> >even before destroying the universe.
>
> Yes, but why are you passing the size of the array in there?
'Cause I'm an idiot, ap
> $sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
>Note with the || that way, it'll die immediately if @numbers is empty,
>even before destroying the universe.
Yes, but why are you passing the size of the array in there?
--tom
> Even at the risk of Destroying the Entire Universe???
>
> What do others think?
I dunno, seems awfully extreme. Returning undef and testing with "||
die" seems sufficient to me...
$sum = reduce {$_[0]+$_[1]} 0, @numbers || die "Chaos!!";
Note with the || that way, it'll die immediately if
> These raise an exception whenever they're feeling curmudgeonly:
>
> glob require substr sysread syswrite write
>
> I presume this would fall in the lattermost category.
Very nicely expressed :-)
Damian
* Damian Conway ([EMAIL PROTECTED]) [20 Sep 2000 08:35]:
[...]
> Even at the risk of Destroying the Entire Universe???
> What do others think?
Return a specified value (such as 'undef'). It would allow for more
elegant code, I think. The universe is old enough to cope by itself.
cheers,
--
ia
On Wed, Sep 20, 2000 at 08:35:20AM +1100, Damian Conway wrote:
>> No other builtin dies like that at
>> runtime. Perhaps a return of undef would be more like other operators.
>
> That was my original proposal, but it was howled down by the
> mathematical elite, who vigorously insisted tha
> > This RFC proposes a builtin C function, modelled after
> > Graham Barr's C subroutine from builtin.pm
>
> Please refer to List::Util rather than builtin.pm
Noted. Thanks.
> the module name was changed as many did not like the name builting,
> as it was not.
Bah. I liked
On Wed, Sep 20, 2000 at 08:22:38AM +1100, iain truskett wrote:
> I'd believe so. I think I mentally assumed that Damian was grabbing a
> syntax trick from another RFC.
Heh, I think the exact same thing is what confused me :-)
> I must say that the ^0, ^1 style notation really makes some expres
On Tue, Sep 19, 2000 at 03:23:30PM -0600, Tom Christiansen wrote:
> >> If the original list has no elements, C immediately throws an
> >> exception.
>
> >What do you mean by exception, die ? No other builtin dies like that at
> >runtime.
>
> Well, more can trigger run-time exceptions than peopl
[...]
Original:
$sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] } [[],[]], @numbers;
Transformed, and made erroneous:
$sorted = reduce { push @{ ^0[ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
Transformed correctly:
$sorted = reduce { push @{ ^0->[ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @number
> From [EMAIL PROTECTED] Wed
Sep 20 07:43:36 2000
> Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25])
>by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id HAA27221
>for <[EMAIL PROTECTED]>; Wed, 20 Sep 2000 07:43:36 +1100 (EST)
> Received
>> If the original list has no elements, C immediately throws an
>> exception.
>What do you mean by exception, die ? No other builtin dies like that at
>runtime.
Well, more can trigger run-time exceptions than people usually notice,
but I don't know of one that does so on an empty list.
These
* Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:43]:
> On Wed, Sep 20, 2000 at 07:31:35AM +1100, iain truskett wrote:
[...]
> > $sorted = reduce { push @{ ^0 [ ^1 % 2 ] }, ^1; ^0 }, [[],[]], @numbers;
> I guess I'm confused with the syntax. Shouldn't there be an -> in
> there?
> $sort
> > Collection:
> >
> > @triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
>
> You've a typo there
Noted. Thanks.
Damian
> > $primary_context = want 'LIST', 2, 'LVALUE';
>
> So these arguments can be passed in any order, and want checks them? I
> like it. But I worry if you say something like:
>
>my 42 @stuff = get_data;
>
> And get_data looks like:
>
>sub get_data {
>Tim Conrow wrote:
>>
>> Tom Christiansen wrote:
>> > Perhaps what you're truly looking for is a generalized tainting mechanism.
>>
>> Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers?
>> RFCs? Examples? Hints?
>Sorry for the clutter, but I didn't want to come off too
>Just to note: in version 2 of the RFC, it's associated with the pad of
>the block in which the C appears.
> > then what are you going to do?
>The short answer is that there is no "manual" reset of iterators.
I am concerned about that.
sub fn(\%) {
my $href = shift;
whi
Tim Conrow wrote:
>
> Tom Christiansen wrote:
> > Perhaps what you're truly looking for is a generalized tainting mechanism.
>
> Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers?
> RFCs? Examples? Hints?
Sorry for the clutter, but I didn't want to come off too clueles
On Wed, Sep 20, 2000 at 07:31:35AM +1100, iain truskett wrote:
> * Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:15]:
> > On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> > > =head1 TITLE
> > >
> > > Builtin: reduce
> [...]
> > > Separation:
> > >
> > > $s
Tom Christiansen wrote:
> Perhaps what you're truly looking for is a generalized tainting mechanism.
Sounds cool, but I have only the vaguest idea what you (may) mean. Pointers?
RFCs? Examples? Hints?
--
-- Tim Conrow [EMAIL PROTECTED] |
* Jonathan Scott Duff ([EMAIL PROTECTED]) [20 Sep 2000 07:15]:
> On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> >
> > Builtin: reduce
[...]
> > Separation:
> >
> > $sorted = reduce { push @{$_[0][$_[1]%2]}, $_[1]; $_[0] }
> >
On Wed, Sep 20, 2000 at 07:06:21AM +1100, Damian Conway wrote:
>> >This RFC proposes that the internal cursor iterated by the C
>> >function be stored in the pad of the block containing the C,
>> >rather than being stored within the hash being iterated.
>>
>> Then how do you s
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> This RFC proposes a builtin C function, modelled after Graham Barr's
> C subroutine from builtin.pm
Please refer to List::Util rather than builtin.pm
the module name was changed as many did not like the name builting, as it
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Builtin: reduce
...
> Collection:
>
> @triples = @{ reduce sub($;$$$){ [@{shift},[@_] }, [], @singles };
You've a typo there, it should be:
@triples = @{ reduce sub($;$$$){ [@{shift},[@_]]
> >This RFC proposes that the internal cursor iterated by the C
> >function be stored in the pad of the block containing the C,
> >rather than being stored within the hash being iterated.
>
> Then how do you specify which iterator is to be reset when you wish
> to do that? Curr
Andy Dougherty wrote:
>
> > Perl should be able to distinguish between printable strings and
> > packed binary data stored as strings (presumed to not be printable
> > text)
>
> All strings are "printable" in perl, since print just calls fwrite(). I
> can and do use perl to "print" binary data.
Perhaps what you're truly looking for is a generalized tainting mechanism.
--tom
Sam Tregar wrote:
>
> On 19 Sep 2000, Perl6 RFC Librarian wrote:
>
> > Distinguish packed binary data from printable strings
>
> What defines a "printable" string? What if I'm working in an environment
> that can "print" bytes that yours can't?
Usage DWIMishly defines a printable string. As I
>This RFC proposes that the internal cursor iterated by the C function
>be stored in the pad of the block containing the C, rather than
>being stored within the hash being iterated.
Then how do you specify which iterator is to be reset when you wish
to do that? Currently, you do this by specif
Nathan Wiger wrote:
>
> Tom Christiansen wrote:
> >
> > Perl should fly far and fast from starting down the bumpy road where
> > that data is strongly typed in the mythical and deceptive text-vs-binary
> > sense ... Heed the wisdom of the Unix ...
I shouldn't have used the term "binary" in the p
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
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 255
Version: 2
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtin: reduce
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 10 Aug 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 76
Version: 2
Status: Frozen
Nathan Wiger wrote:
>
>One thing that Nat will soon be releasing is an RFC on strict typing.
>I'll also have one (hopefully) on an embedded tie-like solution that
>will allow you to create your own variable types. With these you would
>conceivably be able to say:
>
> use strict 'types';
> my p
Michael G Schwern wrote:
> Would anyone find it useful to have a UNIVERSAL method which reports
> on what sybols a given module exports?
I don't see any reason why this should be anything other than a module.
A module in the core, if it's that important.
--
John Porter
We're building
Tom Christiansen wrote:
>
> Perl should fly far and fast from starting down the bumpy road where
> that data is strongly typed in the mythical and deceptive text-vs-binary
> sense ... Heed the wisdom of the Unix ...
Tom's exactly right. Data should be data, at least by default.
One of the beau
On Tue, 19 Sep 2000, H.Merijn Brand wrote:
> On 19 Sep 2000 09:23:00 +0300, Ariel Scolnicov <[EMAIL PROTECTED]> wrote:
> >
> > I'm planning to withdraw RFC184 ("Perl should support an interactive
> > mode"), due to lack of interest. There was little discussion of it,
I seem to have m
> Perl should be able to distinguish between printable strings and
> packed binary data stored as strings (presumed to not be printable
> text)
All strings are "printable" in perl, since print just calls fwrite(). I
can and do use perl to "print" binary data. print $a is perfectly fine
even if $
On Tue, Sep 19, 2000 at 09:23:00AM +0300, Ariel Scolnicov wrote:
>
> I'm planning to withdraw RFC184 ("Perl should support an interactive
> mode"), due to lack of interest.
I'd say leave it in. What could it hurt?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On 19 Sep 2000 09:23:00 +0300, Ariel Scolnicov <[EMAIL PROTECTED]> wrote:
>
> 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, a
Great changes, Damian! I'm just going to check on some clarification:
> When C is called with arguments in a scalar context:
>
> $primary_context = want 'LIST', 2, 'LVALUE';
So these arguments can be passed in any order, and want checks them? I
like it. But I worry if you say something
Michael G Schwern wrote:
>
> Would anyone find it useful to have a UNIVERSAL method which reports
> on what sybols a given module exports? For example:
> With an argument, it would be analgous to can():
>
> print "Yes" if Foo->exports('this');
If exports() could take arbitrary symbols
At 07:29 AM 9/19/00 -0700, Dave Storrs wrote:
> I guess, if I had to write an explanation of pack/unpack based on
>my limited understanding, it would be something like:
>
> "Unpack takes binary data in some particular format and
>disassembles it, assigning various pieces of it to v
1 - 100 of 112 matches
Mail list logo
