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
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
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:
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
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
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", and
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.
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 on
* 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 already
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 do
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
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 believe
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 expanded
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
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,
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 (simplistic
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
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 him to add this
"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.
Is that a for
"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.
chaim
--
"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 Istart
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 interpolated into
"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, RANDGEN_REF
"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 with the
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
not
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 quotes
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:
BLsub min {
BLmy $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 flattening a list
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. I
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 idea
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()).
Dammit, I
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
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.
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
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
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 Istart of every page and
PRL its return value used
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 concurrencySNIP
=back 4
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 KP: "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.
This is the problem that currently here-doc content must be relative to SNIP
indented code.
2 Preserving sub-indentation.
This is not _currently_ a problem. Perl _currently_ preserves indentatiSNIP
the way, that this problem is a problem. If problem 1 were solved by inSNIP
the HERE
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
48 matches
Mail list logo
