On Sun, 17 Sep 2000 21:59:47 -0700, Nathan Wiger wrote:
Yeah, I for one think %hashes should be interpolated exactly like
@arrays. It's simple and consistent.
Simple and consistent would be behaviour like
"@{[%hash]}"
However, convenient it is not, getting all key/value pairs in one
Hi Ilya,
I have three questions about your RFC:
Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
a stride of 2) ?
If not is there an easy way to incorporate that?
Secondly, what about having multidim support in the core so that the
tie-tokenisers get optimised away? i.e.
Chaim Frenkel writes:
What about formating the output as a value that can be used by eval?
%hash = (a = 1, b = 'the world');
print "%{hash}\n";
('a' = 1, 'b'= 'the world')
Interesting.
And as for having to escape % in printf strings. Why not enable the
interpolation if the
On 17 Sep 2000 23:54:05 -0400, Chaim Frenkel wrote:
What about formating the output as a value that can be used by eval?
%hash = (a = 1, b = 'the world');
print "%{hash}\n";
('a' = 1, 'b'= 'the world')
So, what about arrays? Or scalars?
We have Data::Dumper for that.
--
How about a Base64 to match with uuencode?
chaim
"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
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
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 knowledge
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,5;
=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
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:
Let's jump in. This RFC proposes a Creshape 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
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
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 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
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 of?
1. Speed
2. Bloat
3. Excess burden on the
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 of?
1.
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
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
On Thu, 14 Sep 2000 12:41:04 -0700, Glenn Linderman [EMAIL PROTECTED] wrote:
1) do perl6 formats need to have exactly the same scoping rules as perl5
formats in this regard?
perl5 formats do NOT support lexicals, so this is not a very interesting
question. (Re-)implementation of formats in
On Mon, 18 Sep 2000 10:57:49 +0200, H.Merijn Brand wrote:
perl5 formats do NOT support lexicals
Eh? It looks like it, though.
my $foo;
format STDOUT =
@
$foo
.
$foo = 123;
write;
$foo = 45;
write;
It looks *so much* that
On Mon, 18 Sep 2000 08:43:05 -0600, Tom Christiansen [EMAIL PROTECTED] wrote:
I do not think you two are arguing about the same thing.
Certainly as Bart has shown, formats *can* see lexicals. Your
illustration does not disprove that. It simply shows that lexical
scoping is static scoping,
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 Clvalue and
Crvalue contexts, if you simply want to hide your data.
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 might as
On Sun, Sep 17, 2000 at 11:25:49PM -0700, Nathan Wiger wrote:
I also don't see that the optimization of one half of the accessor vs
the other is worth the trouble.
Well, it depends on how much faster the autoaccessor is. If it is much
faster, and you need to access a whole bunch of data
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 easy:
my $weather = new Schwern::Example;
print "Today's weather will be $weather-{temp} degrees and sunny.";
On Mon, Sep 18, 2000 at 05:49:28AM -, Perl6 RFC Librarian wrote:
Here's where the problem lies. Even though we now have a subclass
of Frog, the Forest class is still referencing the original Frog
class and not Frog::Japanese.
The DBI has this very problem! DBI-connect() returns DBI::db
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
implementation and then relied
[From DBI-connect()]
# XXX this is inelegant but practical in the short term, sigh.
if ($installed_rootclass{$class}) {
$dbh-{RootClass} = $class;
bless $dbh = $class.'::db';
my ($outer, $inner) = DBI::_handles($dbh);
bless $inner = $class.'::db';
Michael G Schwern [EMAIL PROTECTED] writes:
On Thu, Sep 14, 2000 at 02:19:38PM +0100, Piers Cawley wrote:
Michael G Schwern [EMAIL PROTECTED] writes:
package Dog;
use fields qw(this night up);
my Dog $ph = [];
$ph-{this} = "that";
That works? I thought you
Damian Conway [EMAIL PROTECTED] writes:
Piers wrote:
I'm kind of tempted to look at adding another pragma to go with 'use
base' along the lines of:
use implements 'Interface';
Which is almost entirely like Cuse base 'Interface' but with
'Interface'
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 Cbless
[\%{"$class\::FIELDS"}], $class, but the current pseudohash
implementation doesn't care if something is an object or not. It just
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
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'}" already
As Nate pointed out: print "$hash-{'f'.'oo'}" already works fine and
the world spins on.
That is no argument for promoting illegibility.
--tom
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') = undef;
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 data
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 be
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
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 I'm
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
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Overview: Perl OO should Inot be fundamentally changed.
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 21 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
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: 190
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Rationalizing Cref, Cattribute::reftype, and Cbuiltin:blessed
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 14 Sep 2000
Last Modified: 18 Sep 2000
Mailing List: [EMAIL
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:
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
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:
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:
=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
Subroutines calls should interpolate in double-quoted strings and similar
contexts.
print "Sunset today is at sunset($date)";
interpolates to:
print 'Sunset today is at '.sunset($date);
Huh? And what if it's a built-in? What if it's not quite a built-in,
but an import? What if you
Surely the next request will be to make anything that works outside
of quotes work inside of them, completely erasing the useful visual
distinction. Why should operators, after all, be any different
from functions?
print "I have Fooey-fright($n) frobbles.\n";
print "I have snaggle($n)
On Mon, Sep 18, 2000 at 01:16:43AM -0600, Tom Christiansen wrote:
Huh? And what if it's a built-in? What if it's not quite a built-in,
but an import? What if you don't *know* whether it's a built-in?
Easy enough, built-ins shouldn't be special (I'm speaking in general,
not just when
print format $fmt, @stuff;
Early brain-dump. This should be it.
That's what I've done for the second version (on its way soon).
Damian
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects: Cuse invocant pragma
=head1 VERSION
Maintainer: Damian Conway [EMAIL PROTECTED]
Date: 14 September 2000
Mailing List: [EMAIL
Hildo Biersma wrote:
I think such modules are a bad idea, because their functionality is
typically restricted.
An example of this is the CGI module.
You consider CGI.pm an example of a module with restricted functionality?
IMHO, mixing procedural and OO interfaces to the same module
Hildo Biersma wrote:
Look, there's a reason we have objects - they encapsulate state. If a
module supports objects and procedural calls, in the latter case it will
either need a handle to the state (objects by anoither name), or will
store the state internally. If the module stores the
[This somewhat elderly draft was found lying about an edit
buffer, but I do not believe it was ever sent yet.]
Now, the possibility to either pass individual scalars to a sub, or an
array, (or several arrays, or a mixture of arrays and scalars) and Perl
treating them as equivalent,
'foo'-bar($baz)
looks visually clattered, but Cfoo()-bar($baz) looks as if it expresses
its meaning. The default choice is done so that if you need other
choice, your code does not look artificial.
Hear, hear!
foo-bar($baz, $coon)
should be made synonymous with
foo-bar
foo-bar($baz, $coon)
should be made synonymous with
foo-bar $baz, $coon
I can see no ambiguity in this call, but it not always works with Perl5.
Arrow invocation does not a listop make. Only indirect object invocation
style does that.
print STDOUT $foo, $bar, $glarch;
is a list
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
From: Jarkko Hietaniemi
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",
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
From: Jarkko Hietaniemi
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",
Tom Christiansen wrote:
And what if it's a built-in? What if it's not quite a built-in,
but an import? What if you don't *know* whether it's a built-in?
I would hope that the distinction (at the syntactic level) goes away.
(Except for the small set of exceptional built-ins, which clearly
As a solution, a UNIVERSAL:::require() method can be added with the following
syntax:
$module = "Some::Module";
$module-require;
Seems to me that it would need to be written as
$module-UNIVERSAL::require;
How do you propose to avoid that?
What should happen if
John Porter wrote:
As a solution, a UNIVERSAL:::require() method can be added with the following
syntax:
$module = "Some::Module";
$module-require;
Seems to me that it would need to be written as
$module-UNIVERSAL::require;
How do you propose to avoid that?
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
From: Garrett Goebel
There seems to be some general consensus that some people
would like to be able to short-circuit functions like
grep. Do you see no need for the code
block equivalent of Cnext/Clast/Credo?
What, you mean like
Nathan Wiger wrote:
Huh? All classes inherit from UNIVERSAL implicitly.
Yes, but at that point in the execution, $module is not a class.
It's the same reason you can write:
$module-can('dance');
Once upon a time this was not possible. I guess it has changed.
--
John Porter
On Mon, 18 Sep 2000, 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.
Those are not Perl. Scalars, arrays, hashes,
Today around 12:32pm, Sam Tregar hammered out this masterpiece:
: On Mon, 18 Sep 2000, 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
Tom Christiansen wrote:
I am certainly in strong favor of a simple and visually distinctive
solution, and find that the leading bit helps a lot. But I would probably
have written that as:
die POEM =~ /[^!]*/g;
!The old lie
! Dulce et decorum est
! Pro patria
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 didnSNIP
'!' bit. So I'm not sure how you'd have written that if you'd have doneSNIP
specification.
Yeah, ok. I still think
# Your stuff that
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 BD
language.
I'd just
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 is considered
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.
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 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
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
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
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
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
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
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 this
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
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. There are,
"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 Cformat by itself is the
DC right solution for this problem, unless I add some
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 15 Sep 2000 19:18:18 -, Perl6 RFC Librarian quoted Damian Conway:
I propose that the existing Cformat mechanism be removed from Perl 6
and be replaced with a pragma-induced add-in function, based on
the semantics of CText::Autoformat::form, as described in
the following sections.
Can
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
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:
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
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
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
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 RFC proposes that the internal cursor iterated by the Ceach function
be attached to the instance of Ceach (i.e. its op-tree node),
In the past, this has been a mistake, because it breaks the identity
of closures. For example, with your proposal, the following code,
which works now,
The function itself would be called Cformat and would be
imported with a Cuse Format pragma.
Much better, but I don't think you mean "pragma", and in fact I'm pretty
sure you know that, but you still need to s/pragma/module/g. I think the
title should be changed to
"ST" == Sam Tregar [EMAIL PROTECTED] writes:
ST I think you're talking about unpack() here, which I've only used once. I
ST think unpack() is usually replaceable by substr() or regexes. Contrast
ST that with pack() for which no equivalent replacement is possible, as far
ST as I know.
"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 value is coerced to 0 or '' (specific values)
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
Peter Scott wrote:
Brainstorming How about an attribute for hashes:
my %foo : fixed;
Has anyone talked about the ability to access the
attributes attached to a variable?
Are all the possible attributes going to be predefined, or can the
user define new ones? I would think that
On Mon, Sep 18, 2000 at 10:51:52AM -0400, John Porter wrote:
Are all the possible attributes going to be predefined, or can the
user define new ones?
The user should be able to do anything they damn well like. This is,
allegedly, Perl, which means it's about making it easy to do what the
At 04:04 PM 9/18/00 +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. That smacks of
making
Simon Cozens wrote:
(The deadline for collecting ideas passed two weeks ago. Why is this all
still going on?)
Because there are still many worthy ideas which have not surfaced yet.
Which is the higher priority?
--
John Porter
We're building the house of the future together.
1 - 100 of 102 matches
Mail list logo
