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
At 03:40 AM 9/19/00 -0400, Michael G Schwern wrote:
>As I understand it, there is currently no agreed upon common event
>loop architecture in Perl. This means that if two event-based modules
>are used together (say, Net::IRC and POE) the one who's main loop
>starts up first will win.
>
>So the qu
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More modules
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 260
Version: 1
Status: Developing
=head1 ABSTRACT
Perl s
> This RFC proposes two new keywords -- C and C -- that limit
> the accessibility of keys in a hash, and of methods.
I still think these should be attributes across the board:
my $hash{$key} : private = $val;
my @hash{qw(_name _rank _snum)} : public;
sub dostuff : private { }
I'd be in
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Private keys and methods
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 188
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
On Tue, 19 Sep 2000, Adam Turoff wrote:
> On Tue, Sep 19, 2000 at 08:07:33AM -0700, Dave Storrs wrote:
>
> > I think I would be
> > guardedly in favor of changing the default scope from global to local
> > (although I have the feeling there is something I'm not considering). What
> > does every
On Tue, Sep 19, 2000 at 08:07:33AM -0700, Dave Storrs wrote:
> On Tue, 19 Sep 2000, Nathan Wiger wrote:
> > And then there's the lexical variable issue too:
> >
> >The default variable scope rules for Ruby (default: local) are
> >much better suited for medium-to-large scale programming ta
At 04:57 PM 9/18/00 +0100, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > As for the language we implement perl in (and thus ultimately need to
> > translate to the compiler-target language), I'm thinking of something like
> > Chip's PIL
At 06:58 PM 9/15/00 +0100, Simon Cozens wrote:
>On Fri, Sep 15, 2000 at 12:53:29PM -0400, Dan Sugalski wrote:
> > The only reason I can see nice winning over fast is if nice brings in
> whole
> > new concepts to the language. (Like, say, matrix ops or Damian's
> currying > > stuff)
>
>Well, taki
Michael G Schwern wrote:
> All these techniques have their strengths and weaknesses which I'm
> sure we're all aware of (and this is the wrong place to debate them).
> What I'm concerned is that Perl 6 has a clean, reliable, free and
> straightforward way(s) to use Perl without perl. How clean,
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
MGS> As I understand it, there is currently no agreed upon common event
MGS> loop architecture in Perl. This means that if two event-based modules
MGS> are used together (say, Net::IRC and POE) the one who's main loop
MGS> star
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
Dave Storrs wrote:
>
> >The default variable scope rules for Ruby (default: local) are
> >much better suited for medium-to-large scale programming tasks;
> >no "my, my, my" proliferation is needed for safe Ruby programming
>
> Actually, this is the bit that interests me. Mos
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
[in Ruby documentation:]
> > The default variable scope rules for Ruby (default: local) are much
> > better suited for medium-to-large scale programming tasks; no "my,
> > my, my" proliferation is needed for safe Ruby programming
* Dave Storrs ([EMAIL PROTECTED]) [20 Sep 2000 02:08]:
> Actually,
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
On Tue, 19 Sep 2000, Nathan Wiger wrote:
> And then there's the lexical variable issue too:
>
>The default variable scope rules for Ruby (default: local) are
>much better suited for medium-to-large scale programming tasks;
>no "my, my, my" proliferation is needed for safe Ruby prog
> What sets Ruby apart is a clean and consistent
> language design where everything is an object.
I like this part. Assuming I ever finish my last RFC I'd like Perl to
have embedded objects as well. The difference being Perl's wouldn't get
in the way, unlike Python's.
Of particular interest seem
On Mon, 18 Sep 2000, Bart Lateur wrote:
> On 13 Sep 2000 07:07:42 -, Perl6 RFC Librarian wrote:
>
> >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
On Tue, 19 Sep 2000, Dave Storrs wrote:
> "Unpack takes binary data in some particular format and
> disassembles it, assigning various pieces of it to variables according to
> formatting that you supply. Pack does the opposite, using your supplied
> formatting to crunch Perl scalar variabl
>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? Specifically I'm wondering how
>this proposal handles Unicode.
Perl should f
On Mon, 18 Sep 2000, Michael G Schwern wrote:
> I'm sure there are many times when pack should have been used but it
> got hacked together with something else. The prime example is [...]
I must admit I'm with Michael on this one. I've been writing Perl
on and off for two or three ye
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? Specifically I'm wondering how
this proposal handles Unicode.
-sam
On Mon, 18 Sep 2000, Glenn Linderman wrote:
> This is an interesting comment to be made about an interesting side effect of
> this proposal.
[snip]
> (1) array elements can be accessed by name
> (2) member data can be looked up quicker (by array index, rather than by
> hashed name)
[snip]
> new
On Mon, Sep 18, 2000 at 08:54:30AM -0600, Tom Christiansen wrote:
> >This RFC proposes that rather than three separate mechanisms (in three
> >separate namespaces) to determine object typing information, Perl 6
> >simply extend the C function to return all the necessary
> >information in a list co
On Mon, Sep 18, 2000 at 12:53:32PM -0400, Michael G Schwern wrote:
> 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
On Tue, Sep 19, 2000 at 06:57:07AM -, Perl6 RFC Librarian wrote:
> =head1 OUTSTANDING ISSUES
>
> A few people mentioned that using memoize() as a function has some
> action-at-a-distance qualities, although it is useful for caching
> builtin functions such as cos() and sin().
But those co
I don't like OOP, you folks obviously do. Maybe docs/specs/... are interesting
for you ...
Have fun.
From: [EMAIL PROTECTED]
Newsgroups: fm.announce
Subject: Ruby 1.6.0 - An object-oriented language for quick and easy programming
Date: 19 Sep 2000 09:58:15 GMT
application: Ruby 1.6.0
aut
>It's hard to remember the sequence of values that the following
>builtins return:
>stat/lstat
>caller
>localtime/gmtime
>get*
>and though it's easy to look them up, it's a pain to look them up
>Every Single Time.
>Moreover, code like this is far from self-docume
Unless I hear otherwise, I plan on freezing RFC 204 and RFC 206 this
evening (17:30 New York time), and issue a revised version of 207. The
frozen versions will be substantially identical to the versions ow
released.
On RFC 204 (LOL refs as indices), I have followed the discussion from
Ilya
Adam Turoff <[EMAIL PROTECTED]> writes:
> On Tue, Sep 19, 2000 at 08:47:11AM +0100, Piers Cawley wrote:
> > > That *shouldn't* be hard. If you're getting hung up on details like
> > > =over 4, =item, L<> and C<>, then leave them out.
> >
> > No, I'm getting hung up on the fact that it'll take
On Tue, Sep 19, 2000 at 07:47:58AM -, Perl6 RFC Librarian wrote:
> Subroutines: Replace C with a generic C function
Just as long as I can still say:
return want 'LIST' ? @some_array
: $some_scalar;
I'll be happy. And, of course, want 'LVALUE'.
--
Michael G Sch
On Tue, Sep 19, 2000 at 08:47:11AM +0100, Piers Cawley wrote:
> > That *shouldn't* be hard. If you're getting hung up on details like
> > =over 4, =item, L<> and C<>, then leave them out.
>
> No, I'm getting hung up on the fact that it'll take a bunch of time to
> flesh out the RFCs beyond a s
Adam Turoff <[EMAIL PROTECTED]> writes:
> 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' RF
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Replace C with a generic C function
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 6 Aug 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 21
Some of oriental characters in Japanese and Korean are usually
aligned as if they have 2 columns per character. Jperl has been
patched on format built-in so that Japanese characters get
special treatments:
- 2-byte characters occupy 2 columns
* this assumption is not strictly correct, but g
As I understand it, there is currently no agreed upon common event
loop architecture in Perl. This means that if two event-based modules
are used together (say, Net::IRC and POE) the one who's main loop
starts up first will win.
So the question I put to you all is, would it make sense for Perl t
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
>
> NC> $htdoc = open uri "http://www.yahoo.com" or die; with uri in the
> NC> standard library and also make it easy to stack the module that
> NC> does uri at the top of 'file' so that the defa
All RFCs must fall into one of three status categories:
Developing (RFC is incomplete; commments requested)
Frozen (Comments received; nothing more to say)
Retracted (Comments received; author is removing idea from
consideration.)
(NB: 'Retracted'
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Mon, Sep 18, 2000 at 09:48:27AM +0100, Piers Cawley wrote:
> > Michael G Schwern <[EMAIL PROTECTED]> writes:
> > > Nope. fields::new() basically just does C > > [\%{"$class\::FIELDS"}], $class>, but the current pseudohash
> > > implementation do
Would anyone find it useful to have a UNIVERSAL method which reports
on what sybols a given module exports? For example:
package Foo;
@EXPORT = qw(this @that);
@EXPORT_OK = qw($up down);
# this, @that, $up, down
print join ", ", Foo->exports;
With an arg
On Tue, Sep 19, 2000 at 07:00:36AM -, Perl6 RFC Librarian wrote:
> =head1 REFERENCES
>
> This RFC explains the mechanism by which HASHREF context would be detected:
>
> RFC 21: Replace C with a generic C function
>
>
> These RFCs propose alternative solutions to this problem:
>
> RFC 37:
On Tue, Sep 19, 2000 at 07:00:35AM -, Perl6 RFC Librarian wrote:
> =head1 IMPLEMENTATION
>
> I know almost nothing about internals, so this is probably wrong, but
> see if I convey my meaning anyway.
Well, I have nothing to say about the utility of this module, but I
can say that for your bi
A not uncommon question arises, "I want to write a Perl program and
distribute it to my customers/users/co-workers, but what if they don't
have Perl?" This may be someone wanting to ship out their code to
Windows and Mac machines, or maybe they're in some company gripped in
the clutches of Java a
In order to trim the large number of RFCs that have not been updated in
many weeks, yet are still "in development", I've prepared a report
of which RFCs are most overdue.
http://dev.perl.org/rfc/overdue.html
Here is the current status, broken down by group:
Report generated: Tue Sep 19 07:06
101 - 154 of 154 matches
Mail list logo
