> This is an interesting proposal, but it seems to be missing
> something, or maybe I am. It seems like once a single hash entry is
> marked private, that it is then impossible to mark future entries
> non-private...i.e. there is no corresponding unary "public"
> function.
That's r
On Sun, Sep 17, 2000 at 05:35:47AM -, Perl6 RFC Librarian wrote:
>$fo->untaint - Removes tainting from that data source
I can guarantee this will be abused and severely water down the
utility of taint mode. A discussion of easy untainting came up on
perl6-internals and fairly universa
On Sun, Sep 17, 2000 at 05:36:56AM -, Perl6 RFC Librarian wrote:
>unlink "/local/etc/script.conf";# non-portable
>unlink "file:///local/etc/script.conf"; # portable
'/local/etc/script.conf' is very unlikely to exist or be a sensible
filename on Windows or MacOS (or Unix. Shou
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> Likewise, if the "footer" option is specified with a string value, that
PRL> string is used as the footer of every page generated. If it is specified
PRL> as a reference to a subroutine, that subroutine is called at the I
PRL> of
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> On Fri, Sep 15, 2000 at 05:56:36AM -, Perl6 RFC Librarian wrote:
>> There is no way to turn obtain the value of $x from the value of $y.
>> In other words, while $foo and $bar were interpolated into $x, they
>> were not interp
> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:
BL> Therefore, crypt() should have it's own pseudo-random generator. A
BL> simple task, really: same code, but a different seed variable.
Should rand be extended to be able to support multiple random number
generators?
=item srand EXPR, RAND
> "GL" == Glenn Linderman <[EMAIL PROTECTED]> writes:
GL> That's exactly why it would be nice if index _did_ throw an exception on
GL> failure, then you could write code this way, and catch the failures
GL> without needing to check return values for the error code case before
GL> proceeding w
Tom Christiansen <[EMAIL PROTECTED]> writes:
> keys %HASH = LIST;
>
> is really
>
> @HASH{ LIST } = ();
Hmm, is it?
I'd expect the first form to set the keys, meaning that the hash will
have _only_ the indicated keys.
The second form will only add the keys, making sure they exist, and
On Sat, Sep 16, 2000 at 11:38:57PM -0400, Chaim Frenkel wrote:
> I thought he was asking for evaluating until nothing is left to interpolate.
>
> Something akin to:
> $x = eval "$x" while $x =~ /[$@]/;
> But more intelligent.
OK, fair enough; and I appreciate the point that other double qu
On 16 Sep 2000 22:40:24 -0400, Chaim Frenkel wrote:
>BL> Therefore, crypt() should have it's own pseudo-random generator. A
>BL> simple task, really: same code, but a different seed variable.
>
>Should rand be extended to be able to support multiple random number
>generators?
Not just srand().
On 16 Sep 2000 22:11:25 -0400, Chaim Frenkel wrote:
>BL>sub min {
>BL>my $min = shift;
>
>
>As I proposed, @_ would flatten the incoming arguments.
>
>But a sub with a prototype (that includes a non-trailing '@') would then
>be able to see the raw arguments.
OK. As long as flattenin
> "JP" == John Porter <[EMAIL PROTECTED]> writes:
JP> Chaim Frenkel wrote:
>>
>> Removing -1 as a valid result, could be a breakage (if someone is
>> doing something weird with a negative result)
JP> What, like using it as an index into a substr?
JP> Bad Code is its own reward, my friend.
> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes:
BL> I'll give one example.
BL> sub min {
BL> my $min = shift;
As I proposed, @_ would flatten the incoming arguments.
But a sub with a prototype (that includes a non-trailing '@') would then
be able to see the raw arguments.
mike mulligan writes:
:From: Hugo <[EMAIL PROTECTED]>
:Sent: Tuesday, September 12, 2000 2:54 PM
:
:> 3. The regexp is matched left to right: first the lookbehind, then 'X',
:> then '[yz]'.
:
:Thanks for the insight - I was stuck in my bad assumption that the optimized
:behavior was the only behav
On Sun, 17 Sep 2000, Nathan Wiger wrote:
>
> The only comments received were on my crappy examples, which have been
> clarified.
Well, sort of. More comments on "crappy" examples. :-)
>
> The key syntax benefit is #1. This lets us use URIs in any function to
> allow scripts that can be used
At 11:10 -0700 2000.09.16, Nathan Wiger wrote:
>Now, one thing that should probably be explored is creating a time
>object, similar to the date object specified in RFC 48. In fact, I'd
>just assume "All Perl core functions should return objects", and hence
>the reason I wrote RFC 73. ;-)
And it w
At 11:56 -0400 2000.09.17, Chris Nandor wrote:
>At 11:10 -0700 2000.09.16, Nathan Wiger wrote:
>>Now, one thing that should probably be explored is creating a time
>>object, similar to the date object specified in RFC 48. In fact, I'd
>>just assume "All Perl core functions should return objects",
On Sat 16 Sep, Mark-Jason Dominus wrote:
>
> > (?Q$foo) Quotes the contents of the scalar $foo - equivalent to
> > (??{ quotemeta $foo }).
>
> How is this different from
>
> \Q$foo\E
Um - not at all - think of it as a brainstorming overrun...
BTW have you any thoughts about my "Genera
At 09:39 AM 9/16/00 -0700, Nathan Wiger wrote:
> > Yet, I personally would prefer it if strict 'refs' is always on by
> > default. Would this hinder one-liners? How many one-lliners do you write
> > that depend on symbolic references? None, I hope.
>
>The problem with this is that now we're only t
On Sun, 17 Sep 2000, Tom Christiansen wrote:
> >Heh. We can change the message from:
>
> >"Division by zero error on line xx"
>
> >to
>
> >"Division by zero error somewhere around line XX, give or take a few"
>
> >:)
>
> >Yup. Worst case we can always point at where the line starts, if it st
>Heh. We can change the message from:
>"Division by zero error on line xx"
>to
>"Division by zero error somewhere around line XX, give or take a few"
>:)
>Yup. Worst case we can always point at where the line starts, if it still
>exists.
Make it:
Division by zero error on statement beg
The discussion was about optimized code. WHere the original location
would have been lost. A multiline constant, seems like something that could
keep the location information.
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> Yup. Worst case we can always point at where the line st
>This is already allowed. It's called "passing in a bareword".
>And barewords are just strings. Are you proposing
>that "a bareword should now mean a filehandle", so that
> copydata(STDIN, STDOUT);
>means something different from
> copydata('STDIN', 'STDOUT');
>or
> cop
Tom Christiansen wrote:
>
> >Scalars hold references to objects. Filehandles should, ultimately,
> >be objects, as should directory handles.
>
> I haven't yet seen anybody yet propose bifurcating {file,directory}handles.
> This would certainly be nice.
If I'm understanding what you mean, I bel
On Sun, Sep 17, 2000 at 07:16:16PM -0700, Nathan Wiger wrote:
> Well, as Tom pointed out to me this already exists in 5.6 as part of
> FileHandle:
I never liked FileHandle. ;) It appears to have gone into IO::Handle
in 5.003_07! Wow. Okay, given that its such a venerable feature and
the world i
> * 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(*).
> * Not first-class objects, so you can't subclass them.
That's not a good argument. I can't subclass a number, either, nor
>So why not allow undecorated variables a larger existence?
We already have them. You can use a sub name or a package name
where you mean an "undecorated variable". In fact, you can have
things generate/populate new subs or packages as you like it.
use Funny_Business;
frob Funny "
Michael G Schwern wrote:
>
> On Sun, Sep 17, 2000 at 05:35:47AM -, Perl6 RFC Librarian wrote:
> >$fo->untaint - Removes tainting from that data source
>
> I can guarantee this will be abused and severely water down the
> utility of taint mode.
Well, as Tom pointed out to me this alre
>> What if it's an anonymous stream?
>How do you open an anonymous stream?
Me? This way:
local(*HITHER, *THITHER);
pipe(HITHER, THITHER) ..
or, I suppose,
my($hither, $thither);
pipe($hither, $thither) ..
or even
pipe(my $hither, $thither) ..
Why, how d
Peter Scott wrote:
>
> Those of us who prefer door #2 are still out here. By way of support, I
> adduce perl.pod:
>
> =head1 BUGS
>
> The B<-w> switch is not mandatory.
Actually, I think that's door #1 :-). Warnings and strictness should
*not* be mandatory.
I think my previous email was writ
Background: RFCs should be in development until frozen or retired.
Problem: Frozen RFCs are being updated.
--
Solution #1: Ignore updates to frozen/retired RFCs
Solution #2: Allow frozen/retired RFCs to be updated,
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 'developing'.
If someone updates a frozen RFC, its obviously developing again.
> I'd rather see you drop (or footnote) the discussion of how the various
> systems are going to map content among themselves, and focus more on
> what the construct allows. For instance, returning to some of the
> original implementation ideas, that the location information be passed
> to the pr
>Nathan Wiger writes:
>> Brainstorming off the top of my head:
>>
>>sub length (($|@)) {
>>
>>}
>>
>> That is, use a regex-like "(x|y)" - or maybe [$@%] ?? - for alternative
>> context coercions.
>The only RFC on prototype extensions we have is Andy Wardley's #57.
>I suggest you ask hi
>But man, that really seems like it's not fun. And all alternatives are
>bound to be longer than this:
> my($a, $b, $c, $d, $e, $f) = getpwnam($user) || 'anonymous';
>Which is all I wanted to do in the first place! :-{
I do not think that that code that you have written there does what
you th
>> I just think it's a case of "crying wolf", especially when other
>> people's CPAN modules start spewing this stuff out from perfectly
>> reasonable code, filling up your web error logs with "uninitialized this
>> and that". As a sysadmin, that pisses me off. :-(
>Much of your problem has been
>Method calls should interpolate in double-quoted strings, and similar
>locations.
>print "Today's weather will be $weather->temp degrees and sunny.";
>Would deparse to:
>print 'Today\'s weather will be '.$weather->temp().' degrees and sunny.';
So, the -> operator is supposed to get e
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Autoaccessors for object data structures
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 1
>Or DWIM "${\foo()}" to force scalar context. Everytime I come across that
>construct I have to wonder why it's not called in scalar context. The '$'
>would seem to imply it should.
Huh? No more than
$x = scalar reverse fn();
would cause reverse() to call fn() in scalar context. The re
On Sun, Sep 17, 2000 at 07:55:43PM -0600, Tom Christiansen wrote:
> So, the -> operator is supposed to get expanded in dq strings, eh?
>
> What about class methods, like "Give him Employee->salary() again"?
Because I knew this would raise problems, "Interpolation of class
method calls" was pre
Tom Christiansen wrote:
>
> >print "Today's weather will be $weather->temp degrees and sunny.";
>
> So, the -> operator is supposed to get expanded in dq strings, eh?
It already does, or at least appears to to users:
print "Today's weather will be $weather->{temp} degrees and sunny.";
Sorry, I wasn't subscribed to perl6-language-objects and didn't even
realize there was a discussion going on. I just fixed that.
I didn't mean to hijack RFC 103, I can't remember if I'd even looked
at it before... but Nathan seems okay with that and it is a
deceptively large issue.
Version 2 of
>I think it's far more inconsistent to have the above work but not have
>methods interpolate. And yes, I realize they're different thingies but
>they're very close syntactically and cognitively,
Funny--I always think of them as function calls, and don't expect
function calls to expand.
>especia
># $inventory->pinatas returns a list of pinatas we have.
># "Yes, El Guapo, I would say I have 23 pinatas\n";
>print "Yes, El Guapo, I would say I have $inventory->pinatas pinatas\n";
>I appear to have a new version of the RFC ready without the first even
>having made it out to the p
On Sun, Sep 17, 2000 at 08:56:23PM -0600, Tom Christiansen wrote:
> While you're there, you should fix it to spell piñatas properly. :-(
> We're not talking about stands of pine trees, presumably.
Funny, I know how to type extended characters in MacOS, but I have no
idea how to do it in X. Hell,
Tom Christiansen wrote:
>
> Funny--I always think of them as function calls, and don't expect
> function calls to expand.
I doubt anyone's arguing that they're not function calls. What I find
"surprising" is that Perl doesn't DWIM here. It doesn't encourage data
encapsulation or try to make it e
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
pack/unpack C-like enhancements
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 16 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 247
Version: 1
Status: Developing
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> =head1 ABSTRACT
PRL> "%hash" should expand to:
PRL> join( $/, map { qq($_$"$hash{$_}) } keys %hash )
PRL> =head1 DESCRIPTION
PRL> Hashes do not interpolate in double-quote context in perl5. They
PRL> should, because (a) s
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
enhanced groups in pack/unpack
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 16 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 248
Version: 1
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Use pack/unpack for marshalling
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 16 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 249
Version: 1
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
hooks in pack/unpack
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 16 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 250
Version: 1
Status: Developing
=head1 ABS
We need to get our -data RFCs wrapped up. Nate said it rather well
on -objects, so rather than rewrite what he said, I'll just repeat it here.
I had planned to get RFCs frozen by this Wednesday, but that's looking
overly optimistic, so let's aim to meet the same deadlines that -objects are
working
> The idea of interpolating a hash is cool... but is seperating each
> pair by $/ really useful? A comma or $" sees to make more sense.
Yeah, I for one think %hashes should be interpolated exactly like
@arrays. It's simple and consistent.
-Nate
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
pack/unpack uncontrovercial enhancements
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 16 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 246
Version: 1
Status: De
On Sun, 17 Sep 2000, Perl6 RFC Librarian wrote:
> This example shows how much easier it would have been to write the
> example on line 170 of perltoot.pod:
>
> package Person;
> use strict;
>
> ##
> ## the object constructor (simpli
Matthew, take a look at Class::Classless.
Damian
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of class method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 17 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 251
Version: 1
Status: Developing
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Class Collections: Provide the ability to overload classes
=head1 VERSION
Maintainer: Greg Williams <[EMAIL PROTECTED]>
Date: 17 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 254
Version:
On Mon, Sep 18, 2000 at 04:58:45AM -, Perl6 RFC Librarian wrote:
> =head2 Combining attributes
>
> You can, of course, combined the C<:laccess> and C<:raccess> attributes
> on a given key to autogenerate accessors that work in both C and
> C contexts, if you simply want to hide your data.
Ho
> How about also just ":access" to do both? It would seem to be the
> most common case.
I was trying to conserve keywords, but I'm not opposed to this.
> > =head2 Mixing autoaccessors and real subs
> >
> I really don't see how this is necessary. If you have to write a
> custom accessor, you m
> print "There are Dogs->num_dogs() species of dogs.";
>
> would interpolate as:
>
> print 'There are '.Dogs->num_dogs().' species of dogs.';
I suggest that the requirement be:
print "There are Dogs::->num_dogs() species of dogs.";
I.e. use the unambiguous form
On 17 Sep 2000, Perl6 RFC Librarian wrote:
>my $name = undef;
>my($a, $b, $c, $d, $e, $f) = undef;
Well, these two get the result they want. Try this code:
my($a, $b, $c, $d, $e, $f) = undef;
my %h = ( a => $a, b => $b, c => $c, d => $d, e => $e, f => $f );
while (my ($k, $v) = each %
> > Plus, ' is already widely-used as a single-quote, so
>
> That's a good argument. Unambiguating the language and simplifying
> the parser.
I agree. I think this is a *compelling* reason to kill off ' as a
package name separator.
As for Klingon.pm, it SPURNS your PATHETIC HUMAN
> They need to learn to speak English.
>
> $line_sans_terminator = chomped ;
> $last_list_element= popee some_func();
>
> Perhaps.
Or Latin:
verso_absque_termino FHum mordementum.
elemento_ultimo somefunctementa decumulamentum.
;-)
Damian
At 10:56 AM 9/16/00 -0400, Michael G Schwern wrote:
>Pseudo-hashes are not a good/clean way to implement typed objects.
>Why? Can't do multiple inheritence (without *alot* of contortions).
>And there's also the inefficiencies of untyped pseudo-hash access.
>
>Pseudo-hashes made some sense in the
On Sun, Sep 17, 2000 at 03:37:07PM -0700, Peter Scott wrote:
> However, while we've got ways in P6 to do objects better without
> pseudo-hashes, a major benefit of them to me is nothing to do with objects,
> and that's the ability to fix the keys of a hash. I would like to see this
> retained.
On 16 Sep 2000 03:36:45 -, Perl6 RFC Librarian wrote:
>The current method in which C<__WARN__> and C<__DIE__> signal handlers are
>used is limited in 2ways:
>
>=over 8
>
>=item It does not allow them to accept robust parameter lists.
>
>=item It does not allow for multiple layers of handlers.
Chaim Frenkel wrote:
> But you would still have to catch the exception. Not a nice thing to
> terminate the program just because an expected mismatch occured.
Sometimes it is, sometimes it isn't.
> Not finding something is not exceptional.
Sometimes it is, sometimes it isn't. Why were you loo
Chaim Frenkel wrote:
> I thought he was asking for evaluating until nothing is left to interpolate.
I wasn't, just some number of iterations of interpolation, but "infinite"
iterations of interpolation is an interesting idea, and could be added as a special
case... Such would make it hard to "es
At 06:49 PM 9/17/00 -0400, Michael G Schwern wrote:
>On Sun, Sep 17, 2000 at 03:37:07PM -0700, Peter Scott wrote:
> > However, while we've got ways in P6 to do objects better without
> > pseudo-hashes, a major benefit of them to me is nothing to do with
> objects,
> > and that's the ability to fi
> PRL> Likewise, if the "footer" option is specified with a string
> PRL> value, that string is used as the footer of every page
> PRL> generated. If it is specified as a reference to a subroutine,
> PRL> that subroutine is called at the I of every page and
> PRL> its return value u
On 16 Sep 2000 08:08:05 -, Perl6 RFC Librarian wrote:
>If some special action handler needs to be registered, this should be
>done not by using a special name, but by a pragma.
>
> use tie STORE => sub { ... };
>
>not
>
> sub STORE { ... }
Hmmm... this sounds like a less efficient approach
On Sat, 16 Sep 2000 19:26:38 -0700, Nathan Wiger wrote:
>My point was more should that be
>
> 'Class'->name
>
>or
>
> Class()->name
There now is another RFC about this: RFC 244. How odd, v1 dates from the
same day as your post. But I think Tom Christiansen has brought this up
before.
The i
Tom Christiansen writes:
> and so and so forth.*That's* how people most expect functions to
> work, and when a few of them don't, this confuses them. That's
> what we get people wanting to do
>
> $line_sans_terminator = chomp ;
>
> or
>
> $last_list_element = pop some_func();
Th
Sven said:
> >As I mailed to Nathan Torkington several days ago (without getting
> >a reply), many people use chop() a lot and his perl526 substitute
> >"s/.\z//s;" will not work because it returns the number of
> >chars changed, not the char itself like chop() does (as opposed to
> >chomp()).
D
>This is the problem that currently here-doc content must be relative to
>indented code.
>> 2 Preserving sub-indentation.
>This is not _currently_ a problem. Perl _currently_ preserves indentati
>the way, that this problem is a problem. If problem 1 were solved by in
>the HERE document, t
>OK: here's a dequote_like solution that solves it--the additional soluti
>terminators allowing leading/trailing white space. Which is what I sugg
>perl5, but would require shoving "POEM" to the left margin and ensuring
>dequote Tom posted, with minor changes, and is given below. Maybe Tom c
>i
>> Frankly, I thought it was absurd when I first wrote it...
>> but then I looked at again, and now I'm not so sure I dislike it!
>>
>> =head1 CHANGES
>> =over 4
>> =item * Detailed implementation description
>> =item * Add a new pragma 'varlock' for controlling the concurrency
>> =ba
>I too would like C's one-line if/for/while syntax as a matter of
>convenience, but I grudgingly admit that Perl's way more than
>makes up in unambiguity what it loses in convenience.
You have them, if you want them.
--tom
>I find this urge to push exceptions everywhere quite sad.
Rather.
Languages that have forgotten or dismissed error returns, turning
instead to exceptions for everything in an effort to make the code
"safer", tend in fact to produce code that is tedious and annoying.
Read the new K&P: "failing
>Several OS's Perl supports prefer case insensitive file systems
>(obscure ones, like Windows and MacOS ;).
They're broken. We know that.
>On top of that, currently "use Shell" and "use shell" both mean to use
>SHELL.PM (or shell.pm, Shell.pm, sHeLl.pM) on case insensitive file
>systems.
T
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Chaim Frenkel writes:
>> I would like to have an undef returned.
NT> Ah, I see. You want subroutines to return undef if they're given it
NT> for any of their arguments. That'd break the lazy programmer practice
NT> of passing unde
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
UNIVERSAL::require()
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 17 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 253
Version: 1
Status: Developing
=head1 ABSTRACT
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of subroutines
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 17 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 252
Version: 1
Status: Developing
=head1
> Instead, this code suffices:
>
> BEGIN {
> $module->require;
> $module->import;
> }
>
> We see here how neatly the UNIVERSAL::require() syntax lines up with
> Exporter::import().
We should probably consider a UNIVERSAL::import too, perhaps to either
take over Exporter'
> "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.
GL> Now the loop works fine, but somehow, we need to get out of the
GL> loop when we
86 matches
Mail list logo
