Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
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 row.
It's not what was proposed, anyway.
--
Bart.
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
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. would we be able to say something like: @x = @y[10..20; 1..3] for core arrays 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; Katl
Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
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 %{ is seen?
Too inconsistent. People often write dollar amounts, but we don't
only enable scalar interpolation for ${varname}.
Nat
Re: RFC 237 (v1) hashes should interpolate in double-quoted strings
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.
--
Bart.
Re: RFC 246 (v1) pack/unpack uncontrovercial enhancements
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 semantic is enhanced as much as possible under this constaint. PRL Additional changes to pack/unpack are listed in other proposals. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 246 (v1) - RFC 250 pack/unpack enhancements
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
Re: RFC 246 (v1) - RFC 250 pack/unpack enhancements
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 of "other language" data layouts. I think everyone can agree on that. The need for pack/unpack is mostly to coexist with those other languages' data structures. If you know the other language, pack/unpack becomes less obscure. If you don't, it doesn't. So maybe a good part of that is a documentation issue. Another use of pack/unpack could be to [re]store Perl data in binary form, which can sometimes be smaller than ASCII form (source that can be eval'd). For this purpose, non-other-language-knowledge documentation would be extremely helpful. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices
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; 11..64]; would denote: create two new objects for the specified submatrices, apply (overloaded) multiplication to these objects. Such a request is illegal for untie()d arrays; for tie()d arrays it is converted to a call to FETCH_SLICE in a scalar context. (Alternative: introduce two new tie()d methods: FETCH_SUBOBJECT, STORE_SUBOBJECT.) or is this supposed to be othogonal? Another questing re RFC 231. Is it really required to make the syntactical distinction between ranges (..) and bi_ranges (...)? Some more explanation would be appreciated. Christian
RFC 148 (v2) Add reshape() for multi-dimensional array reshaping
=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 Modified: 18 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 148 Version: 2 Status: Developing =head1 CHANGES 1. Altered syntax to increase flexibility 2. Removed arbitrary interleaving feature 3. Almost had a stroke trying to update all my RFC's =head1 ABSTRACT Currently, there is no easy way to reshape existing arrays into multiple arrays or matrices. This makes nifty array manipulation and complex math hard. A general-purpose tool that can do arbitrary multi-dimensional array reshaping, from which other array manipulation functions can be derived, makes data manipulation easier. =head1 DESCRIPTION Let's jump in. This RFC proposes a Creshape builtin with the following syntax: @reshaped = reshape [$x, $y, $z, ..], @a, @b ... The prototype would look something like this: sub reshape (\@;\@\@\@\@\@\@...); The first argument is an array of dimensions, where C$x and C$y are the shape of the array to produce. The order and meaning of the arguments are the same ones used by the C:shape array attribute described in BRFC 203. We only need one Creshape since it is a multipurpose tool that works in any direction, serving as its own inverse. The dimensions used are subject to the following properties: 1. Less data than specified causes Creshape to return undef 2. More data than specified is silently discarded If any of the dimensions is specified as C-1, then that indicates a wildcard and grabs enough data to fill up the list. See below. =head2 Single Array Form - SPLIT When one array is passed in, it is split up. Here, the C$x and C$y determine the dimensions of the resulting lists. The C$i determines the interleave. For example, assume reshape is called with the list (1..23) in the following forms: @a = 1..23; @results = reshape [$x,$y], @a; $x,$y @results - -- 3, 2( [1,2,3], [4,5,6] ) 2, 4( [1,2],[3,4],[5,6],[7,8] ) 14,20 undef - not enough data to fill Notice how both dimensions work together to Creshape the array. As such, the combination of the arguments is more significant than the individual arguments themselves. Also, note that any excess data left over after the dimensions have been fulfilled is discarded. In the final example, undef is returned, allowing you to easily check if you have enough data: @matrix = reshape [14,20], @input or die "Not enough data!"; In addition, wildcards can be used. With a fixed C$y, only that many lists are returned. However, with a wildcard C$y, any number of C$x-long lists are returned: $x,$y @results - -- 4, -1 ( [1,2,3,4], [5,6,7,8], [9,10,11,12], [13,14,15,16], [17,18,19,20] ) # lose 21..23 Note that we lose data here because we can't get an exact number of lists length C$x. With a fixed C$x, lists Imust be returned that fixed length. However, with a wildcard C$x, lists will be expanded to fill the number specified by C$y, even in mismatched sizes: $x,$y @results - -- -1, 2 ( [1,2,3,4,5,6,7,8,9,10,11,12], [13,14,15,16,17,18,19,20,21,22,23]) Here, all the data is guaranteed to be preserved. It is simply split into exactly the number of parts specified by C$y, even if that results in some lists being different sizes. =head1 Multiple Array Form - JOIN In this form, multiple arrays are joined back together. Here, C$x and C$y, specify the dimensions to use to rejoin the lists, not to split them up. The dimensions simply work in reverse: Rather than specifying how many lists to create, they specify which elements of the input lists are joined back together. So, we'll assume an input array of the form: ( [1,2,3,4], [5,6,7,8], [9,10,11,12] ) Which is called by Creshape with the following dimensions: $x,$y @results - -- -1,-1 ( 1,4,7,10,2,5,8,3,6,9 ) # simple concat 3, -1 ( 1,2,3,5,6,7,8,9,10 )# 3 vals from all lists -1, 2 ( 1,2,3,4,5,6,7,8 ) # all vals from 2 lists 3, 2( 1,2,3,4,5,6 ) # 3 vals x 2 lists Hopefully this is easy to understand. C$x controls how many elements of each list are used, and C$y controls how many lists are used. This is just like the splitting operation, but in reverse. Again, wildcards of C-1 can be used here as well. =head2 Matrix Calculations and Extensions It is the opinion of the author that extensive matrix calculations and manipulations be left to external modules. A function such as this should be able to take care of most of the
RFC 225 (v2) Data: Superpositions
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: Frozen
=head1 ABSTRACT
This RFC (seriously) proposes Perl 6 provide Cany and Call operators,
and, thereby, conjunctive and disjunctive superpositional types.
=head1 DESCRIPTION
The advantages and possibilities of superpositional programming were
demonstrated in well-received presentations at both YAPC'19100 and TPC 4.0.
It is proposed that the Cany, Call, and Ceigenstates operators
proposed in those talks be added to Perl 6. Adding them to the core is
suggested because the use of superpositions changes the nature of
subroutine and operator invocations that have superpositions as
arguments. This is currently impossible to reproduce in a module.
Furthermore, the fundamental utility of being able to write:
if (any(@value) 10) { ... }
or:
die unless all(@tests)-($data);
ought to be available to all Perl users.
Inclusion in the core would also allow the current module-based pure Perl
implementation to be greatly optimized (perhaps even parallelized on suitable
SIMD or other multiprocessing platforms).
A paper proposing the full semantics of superpositions (including their
effect when used as subroutine arguments and operator operands) will soon
be available from:
http://www.csse.monash.edu.au/~damian/papers/#Superpositions
=head1 MIGRATION ISSUES
The any and all functions may collide with existing user-defined
or module-exported subroutine names.
=head1 IMPLEMENTATION
See the Quantum::Superpositions module.
=head1 REFERENCES
[1] Bohr, N., On the Constitution of Atoms and Molecules, Philosophical
Magazine, s.6, v.24, pp.1-25, 1913.
[2] Einstein, A., ber einen die Erzeugung und Verwandlung des Lichtes
betreffenden heuristischen Gesichtspunkt ("On a Heuristic Viewpoint
Concerning the Production and Transformation of Light"), Annalen
der Physik, v.17, p.132-148, 1905.
[3] Lewis, G.N., The Conservation of Photons, Nature, v.118(2),
pp.874-875, 1926.
[4] Monroe, C., Meekhof, D.M., King, B.E., Itano, W.M. Wineland, D.J.
Demonstration of a Fundamental Quantum Logic Gate, Phys. Rev. Lett.
v.75, pp.4714-4717, 1995.
[7] Cirac, J.I. Zoller P., Quantum Computations with Cold Trapped
Ions, Phys. Rev. Lett. v.74, pp.4091-4096, 1995.
[8] Gershenfeld, N. Chuang, I. L. Bulk Spin-resonance Quantum
Computation, Science v.275, pp.350-356, 1997.
[9] Cory, D.G., Fahmy, A.F. Havel, T.F., Ensemble Quantum
Computing by NMR Spectroscopy, Proc. Natl Acad. Sci. USA 94,
pp.1634-1639, 1997.
[10] Deutsch, D. Quantum Theory, the Church-Turing Principle and the
Universal Quantum Computer, Proc. R. Soc. Lond., v.A400,
pp.97-117, 1985.
[11] Deutsch, D. Jozsa, R., Rapid Solution of Problems by Quantum
Computation, Proc. R. Soc. Lond., v.A439, pp. 553-558, 1992.
[12] Shor, P. Algorithms for Quantum Computation: Discrete Logarithms
and Factoring, Proc. 35th Symp. on Found'ns of Computer Science,
pp. 124-134, 1994.
[13] Grover, L.K., A Fast Quantum Mechanical Algorithm for Database
Search, Proc. 28'th ACM Symp. on the Theory of Computing, pp.
212-219, 1996.
[14] Wallace, J., Quantum Computer Simulators - A Review, Technical
Report 387, School of Engineering and Computer Science, University
of Exeter, June 1999.
Re: RFC 148 (v2) Add reshape() for multi-dimensional array reshaping
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 determine the dimensions of the resulting lists. The C$i determines the interleave. This $i definition should be removed now. So, we'll assume an input array of the form: ( [1,2,3,4], [5,6,7,8], [9,10,11,12] ) Which is called by Creshape with the following dimensions: $x,$y @results - -- -1,-1 ( 1,4,7,10,2,5,8,3,6,9 ) # simple concat I think that a simple concat is: reshape ([-1], @a); since here the rank of a list is one, so the length of the first argument to reshape is one. The -1 means 'use up the whole list'. It should be an error to have more than one arg of -1. 3, -1 ( 1,2,3,5,6,7,8,9,10 )# 3 vals from all lists That should be a rank 2 matrix of shape (3,4), i.e. ([1,2,3],[4,5,6],[7,8,9],[10,11,12]). -1, 2 ( 1,2,3,4,5,6,7,8 ) # all vals from 2 lists That's a rank 2 matrix of shape (6,2). 3, 2( 1,2,3,4,5,6 ) # 3 vals x 2 lists That's a rank 2 matrix of shape (3,2), which would discard the last 6 elements. Hopefully this is easy to understand. C$x controls how many elements of each list are used, and C$y controls how many lists are used. This is just like the splitting operation, but in reverse. Again, wildcards of C-1 can be used here as well. I don't think that there's 2 types of reshape(). There's one, and it takes an array of one shape, and returns an array of a different shape. The shape of the new array is specified by the first argument. The second argument is a list, so it succumbs to Perl's normal list flattening behaviour. The behaviour of reshape() should reflect: - PDL's reshape() - NumPy's reshape() -- which is the only one allowing '-1' in the shape - J's '$' verb which all behave the same way. Also, the examples should show reshaping into and out of arrays other than rank 1 or 2. 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?
Re: RFC 148 (v2) Add reshape() for multi-dimensional array reshaping
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 end, i.e. @results = reshape [...], @a, @b, ...; Sorry for screwing it up. Please take over as maintainer. -Nate
Re: pack/unpack is damn unperlish. Explain them as Perl.
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 without that any more than you can use numbers without understanding the range limits of integers and floating point roundoff. However, you're right, a tutorial is desperately needed. I rarely need pack/unpack but when I do, it takes me ages to figure out what to do. I don't think there's anything wrong with the interface though, it seems quite appropriate. -- Peter Scott Pacific Systems Design Technologies
Re: pack/unpack is damn unperlish. Explain them as Perl.
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 and assume that by the time users start writing programs with numbers 2**31 they'll have read that far. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
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 programmer 4. Required knowledge of OO to complete simple scripts If it's any or all of these, I'm *with you*. I think OO should be transparent, under the hood, you don't have to know it's there. See RFC 159 and RFC 73 for fairly good explanations of this. But if you've got other concerns, I'd love to hear them (honestly). -Nate
Re: RFC 99 (v3) Standardize ALL Perl platforms on UNIX epoch
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. Speed 2. Bloat 3. Excess burden on the programmer 4. Required knowledge of OO to complete simple scripts Yes. If it's any or all of these, I'm *with you*. I think OO should be transparent, under the hood, you don't have to know it's there. See RFC 159 and RFC 73 for fairly good explanations of this. I think it shouldn't exist in core functions. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: Final draft of RFC 120: Implicit counter in for statements
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 order of the items for map() and
grep() isn't layed down in stone. So an independent running counter with
an external variable ($i++) is a bit of a no-no. This loop counter
would, without any doubt, tell you what item number you've got now.
For example, a stable sort (original order if items are equal) using a
Schwartzian Transform (it's in the 3rd line):
@stablesort = map { $_-[0] }
sort { $a-[0] cmp $b-[0] || $a_-[1] = $b-[1] }
map { [ $_, $# ] } LIST_OF_STRINGS;
Er, provided that stable sort wasn't going to be part of Perl6, that is.
--
Bart.
Re: RFC 100 (v2) Embed full URI support into Perl
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 protocol handler, which will then DWIM, as determined by the platform, protocol, etc, etc. Getting DOS and Unix to look at a portable construct. Sure. Needed, one way or another. Getting them to Do The Right Thing based a single, uberportable input string just ain't gonna happen, so I'd address that either separately (with the file:// implementation) or not at all. Something tells me you should have written this RFC. ;-) Great points, I'll have to unfreeze this and redo it. Thanks. One of the big draws (to me) for URI support isn't even mentioned in the RFC, although it was discussed following v1, and that is adding DWIMmery to the open to support more than files and pipes. (We recently added URI support to one of our projects for this reason.) Check out RFC 14. At the bottom it talks all about this. However, I'm going to add this into here as well because y'know, it's probably the place it should really be. -Nate
Re: RFC 181 (v1) Formats out of core / New format syntax
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 perl6 should only consider perl5 syntax in perl526 as conversion issues. 2) is it a problem in practice? None of the format code I've written would work differently do to such a semantic change in the time of compilation, but I'm just one novice. I tend to think that code that uses formats is really pretty simple code... Bad thinking ;-) As an example, I've converted a 4GL/RPT script of over 1500 lines to a format using perl script of less than 150 lines being able of lots and lots more. OK, it has since than grown to about 400 lines being able of using headers, margings, footers and dynamic (nested) formats, but even than is wasn't the most simplistic code. if it were more complex, it would probably use sprintf rather than format... as simple code, it tends not to have many scopes and reused variable names. Using sprintf I could have reached the same results, but it would have been a lot harder to document and maintain. If it is, p52p6 could handle this situation by renaming the inner scope's $foo to avoid the conflict. Just look at Damian's proposal. Even the most heavily format using perl5 programmers (like me) will switch sooner or later. I'm looking at the consequences of changing *ALL* my format scripts to using the format part of Text::Autoformat right now. -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.005.03, 5.6.0, 5.7.1 516 on HP-UX 10.20 11.00, AIX 4.2 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: RFC 181 (v1) Formats out of core / New format syntax
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 way, that I think you must be wrong. -- Bart.
Re: RFC 181 (v1) Formats out of core / New format syntax
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, not dynamic scoping, and that the binding of the variable to the format occurs as the format is declared, not when a write executed. This is exactly the same thing as occurs with closures in terms of declaration/creation versus their execution. All that matters is what's in scope when the format or closure template is brought into existence. It doesn't matter what happens later, which would be dynamic scoping, not static scoping. And this is surely not considered "not supporting lexicals". Badly chosen words/phrasing. My fault, core dumped. -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.005.03, 5.6.0, 5.7.1 516 on HP-UX 10.20 11.00, AIX 4.2 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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.
=head2 Mixing autoaccessors and real subs
The final case is where these become really powerful, but also makes the
implementation a little tricky. Here, we want to create an lvalue sub
that does something productive, but an rvalue autoaccessor:
I really don't see how this is necessary. If you have to write a
custom accessor, you might as well write the whole thing. Doesn't
save much programming effort to be able to still use the default for
one context and custom for other, and it would greatly simplify the
implementation without it.
I also don't see that the optimization of one half of the accessor vs
the other is worth the trouble.
=head1 IMPLEMENTATION
In order for this to work, a couple things have to be true:
1. Autoaccessor methods have to take precedence over declared
methods in some way.
2. A means for duplication of method namespace has to exist.
If we eliminate the thing about mixing, this goes away.
4. There must be a way to set attributes on individual hash keys
in Perl 6.
While in general this might be a good idea, is it really necessary for
this proposal? How about this:
package Foo;
use laccess qw(this);
use raccess qw(foo);
use access qw(up);
sub new { bless {} }
my $foo = Foo-new;
$foo-this = 'that';
$foo-foo('bar');
$foo-up = 'down';
$foo-up('sideways');
This also means accessors are defined on a per class basis rather than
per object (which is potentially extremely confusing and difficult to
implement).
Although this makes your C$self-{DATA}-{NUMERIC}-{S_size} :raccess('size') =
undef; case tricky to emulate. It also makes
combining attributes difficult. Will ponder.
Bingo. So, implementationally, it seems all of these could be satisfied
by having this:
$r-method;
Do the following in order:
1. Look for a declared autoaccessor for the given context.
Context. I hope this means context of the object $r?
2. readonly rvalue subs
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00096.html
implies that this isn't needed because of the proposed :constant hash
attribute. This isn't enough. There is a distince difference between
an attribute that is constant, and one which is read-only. That
difference being that a read-only value should be able to be written to
*privately*.
Consider the case of an accessor which returns a list of object fields
which have changed since the last time the object was changed
(Class::DBI does this). The list of obviously not constant, yet the
accessor should be read-only.
3. mutators
I suspect the first one should not be solved. The real idea behind
autoaccessors, as James pointed out, is speed and simplicity. As such,
requiring you to pass stuff around by reference:
$r-autoaccessor = \@stuff;
$r-autoaccessor(\@stuff);
@stuff = @{$r-autoaccessor};
I was about to say that :deref wouldn't be a bad idea, but that would
just be shifting the problem from pass-by-reference to pass-by-value.
$r-autoaccessor = @stuff;
@stuff = $r-autoaccessor;
If this is made equivalent to your code above, it makes pass-by-value
icky.
$r-autoaccessor = @{[@stuff]};
If we make it copy the value of @stuff first (like $r-autoaccessor =
[@stuff] currently does) then this all encourages inefficiencies.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
GuRuThuG make a channel called Perl, and infest it with joking and
funit doesnt make alot of sense.
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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 well write the whole thing.
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 repeatedly, then
this makes sense. But if the autoaccessor is about the same as a sub
speed-wise, then screw it, I agree.
While in general this might be a good idea, is it really necessary for
this proposal? How about this:
package Foo;
use laccess qw(this);
use raccess qw(foo);
use access qw(up);
I think attributes are a nicer way of handling stuff attached to data,
because it's right there by the data looking at you. But this:
This also means accessors are defined on a per class basis rather than
per object (which is potentially extremely confusing and difficult to
implement).
Is a good point. I could see something like:
use accessor (name = '$SELF-{DATA}-{C_name}', 'lvalue');
But I'll have to think about this a little more.
$r-method;
1. Look for a declared autoaccessor for the given context.
Context. I hope this means context of the object $r?
Yep. Will clarify.
2. readonly rvalue subs
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00096.html
implies that this isn't needed because of the proposed :constant hash
attribute. This isn't enough.
Yeah, check out this email:
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00099.html
The idea I originally had was that :raccess would specify something was
an rvalue accessor which only returned a value, and couldn't take
arguments. I think this is probably the way to go, otherwise we have to
start adding other keywords, properties, etc, which really complicate
things too much.
I was about to say that :deref wouldn't be a bad idea, but that would
just be shifting the problem from pass-by-reference to pass-by-value.
Couldn't quite see what you were getting at here - maybe a little
clarification. I'm pretty sure I understand ("autoderef bad, but forced
copy bad too") but want to make 100% sure.
-Nate
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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 repeatedly, then
this makes sense. But if the autoaccessor is about the same as a sub
speed-wise, then screw it, I agree.
I dunno, its going to be alot of work for an optimization. Hell, if
you implement that, you might as well go all the way and implement
polymorphic functions.
2. readonly rvalue subs
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00096.html
implies that this isn't needed because of the proposed :constant hash
attribute. This isn't enough.
Yeah, check out this email:
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00099.html
The idea I originally had was that :raccess would specify something was
an rvalue accessor which only returned a value, and couldn't take
arguments. I think this is probably the way to go, otherwise we have to
start adding other keywords, properties, etc, which really complicate
things too much.
Saw that email, its not enough. The usefulness of an automated
accessor is hamstrung if you can only get with it and never set. The
vast majority of cases wil be read/write.
You need not have :raccess, :rvalue, :laccess and :lvalue. Just
:raccess, :rvalue and :readonly (not :ronly, looks like :rightonly).
For an idea of how complicated this can all get, look at
Class::MethodMaker. Has a *bewildering* array of options. What
you've got so far looks down right boney by comparison.
Couldn't quite see what you were getting at here - maybe a little
clarification. I'm pretty sure I understand ("autoderef bad, but forced
copy bad too") but want to make 100% sure.
That's about it. *grunt*
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would be normally be terminated by detonation.
-- Larry Wall in [EMAIL PROTECTED]
Re: RFC - Interpolation of method calls
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.";
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 upon it.
If method calls interpolated, this would be easier. Instead, it
encourages you to provide direct hash access to your data since it's
much easier to use that way.
I find myself wanting to say:
print "Thanks, $cgi-param('name') for your order!";
print "It matched" if /$config-get_expression/;
Oh joy: now Perl has nested quotes. I *hate* nested quotes.
They're terrible. See the shell for how icky this is.
Rather than:
print "Thanks, " . $cgi-param('name') . " for your order";
What's the big deal? How does it hurt you to do that? And why
are you catting it instead of simply passing a list?
--tom
Re: RFC 254 (v1) Class Collections: Provide the ability to overload classes
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
objects, DBI-prepare() returns DBI::st. If you want to override the
behavior for statement handles and connections, its not enough to just
subclass DBI::st and DBI::db, you must also subclass DBI and override
connect() and prepare() (and hope DBI doesn't use DBI::st or DBI::db
anywhere else.)
DBI-init_rootclass() is a fairly hairy workaround to this problem.
It works like this:
package Ima::DBI::db;
@ISA = qw(DBI::db);
package Ima::DBI::st;
@ISA = qw(DBI::st);
package Ima::DBI;
use base qw(DBI);
Ima::DBI-init_rootclass;
# $dbh is an Ima::DBI::db object, $sth is an Ima::DBI::st
$dbh = Ima::DBI-connect(...);
$sth = $dbh-prepare(...);
Ima::DBI-init_rootclass() informs the DBI that Ima::DBI is a subclass
and that Ima::DBI::db and Ima::DBI::st objects should be used. It
does this by just appending '::db' onto the classname, which means the
names of the classes are fixed. A Bad Thing.
[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';
}
It works, but to quote Tim Bunce there... *sigh*.
So anyhow, yes, this is a big, icky problem.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN
sChWErn ScHWeRn schweRn sCHWErN schWeRn
scHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN
sChwern scHWerNscHWeRn scHWerNScHwerN
SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN
sChWeRn
Re: RFC - Interpolation of method calls
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 upon it.
I think the issue is: *what* tempted them to be so wicked and wrong.
It is the fact that iniquitous direct access interpolated easily, whereas
virtuous accessor access didn't.
Perhaps this RFC should be subtitled: "Ne nos inducas in tentationem..."
:-)
Damian
Re: RFC 254 (v1) Class Collections: Provide the ability to overload classes
[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';
}
It works, but to quote Tim Bunce there... *sigh*.
So anyhow, yes, this is a big, icky problem.
I wonder if this problem couldn't be solved with a proper combination of
@ISA, SUPER::, NEXT::, and use delegation? (calling Damian... :-)
http://dev.perl.org/rfc/190.pod (NEXT:: pseudoclass)
http://dev.perl.org/rfc/193.pod (use delegation)
Or perhaps a @HASA array or a better way of specifying multiple
inheritance than a serial @ISA array are needed. Perhaps we need
something as flexible as use delegation for inheritance?
use inheritance parent = DBI;
{
use inheritance parent = DBI::db;
SUPER-do_stuff;
}
use inheritance peer = DBI::st
That's just braindump, and I'm not sure what it even means, but figured
I'd write it down before I forgot.
-Nate
Re: RFC 218 (v1) Cmy Dog $spot is just an assertion
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 had to do:
my Dog $self = fields::new('Dog');
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
cares about either A) its type or B) what's in $ph-[0]. I don't know
if this is a good thing or a bad thing, but there's nothing on the
table to change it (yet).
my Dog $ph = [];
$ph-{this} = "that";
deparses at compile-time to:
my Dog $ph = [];
$ph-[$Dog::FIELDS{this}] = "that"; # actually the %FIELDS lookup is also
# done at compile time, but I left
# it in for illustration.
Hmm... it still feels like undocumented behaviour. I'd definitely be
inclined to tighten up the base/fields behaviour. My feeling is that
the proposal makes them closer to the Right Thing.
--
Piers
Re: RFC 218 (v1) Cmy Dog $spot is just an assertion
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' consisting of nothing but: package Interface; sub virtual_method; sub virtual_method2 (#prototype); ... 1; You and I must have been separated at birth, Piers. Here's what I wrote to Nat just yesterday: [ Neat 'interfaces' sketch ] If you'd like to run with it, be my guest (but check with Nat first, in case he wants it). I'm not going to have time to produce an RFC on this in time for the cutoff point. (Which seems painfully soon tbh). It's a shame there's no way to put down a marker (maybe a title + summary) for an RFC that one intends to flesh out Real Soon Now, but which won't be ready for the deadline... -- Piers
Re: RFC 218 (v1) Cmy Dog $spot is just an assertion
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
cares about either A) its type or B) what's in $ph-[0].
Hmm... it still feels like undocumented behaviour. I'd definitely be
inclined to tighten up the base/fields behaviour. My feeling is that
the proposal makes them closer to the Right Thing.
Its plenty documented. But if we simply put a bullet into
pseudo-hashes, as per RFC 241, this all goes away.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
Re: RFC - Interpolation of method calls
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
implementation and then relied upon it.
I think the issue is: *what* tempted them to be so wicked and wrong.
It is the fact that iniquitous direct access interpolated easily, whereas
virtuous accessor access didn't.
Don't forget the fact that direct access is much faster than a method
call in Perl 5. This will be fixed in Perl 6, of course...right? :)
-John
Re: RFC - Interpolation of method calls
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 works fine and
the world spins on.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
Re: RFC - Interpolation of method calls
As Nate pointed out: print "$hash-{'f'.'oo'}" already works fine and
the world spins on.
That is no argument for promoting illegibility.
--tom
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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;
$self-[4]-[1] :laccess('name') = undef;
return bless $self, $class;
}
Although an arrayref is usually not the best data representation for
direct-access objects.
This is an interesting comment to be made about an interesting side effect of
this proposal.
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 items.
Granted, hashes allow additional keys to be added (although collision
problems can exist) to the _same_ data structure with conceptual ease.
However, you can always make an array bigger too.
I suspect that the primary reason to use hashes for object data members is
the ease of named access to the individual members. Remembering the position
of the data item by number in an array would be much harder on the
programmer.
Now you use a complex data structure in your above example, but let's look at
a simple one:
package Smith;
sub new {
my $class = shift;
my $self = [];
$self -[0] = 10;
$self -[1] = 20;
$self -[2] = 30;
return bless $self, $class;
}
$x = new Smith;
print $x-[0].'/'.$x-[1].'/'.$x-[2];
Now augment this with accessors (maybe some should be private, some public?),
and we get:
package Smith;
sub new {
my $class = shift;
my $self = [];
$self -[0] :raccess('month')= 10;
$self -[1] :raccess('day')= 20;
$self -[2] :raccess('year')= 30;
return bless $self, $class;
}
$x = new Smith;
print $x-month.'/'.$x-day.'/'.$x-year;
Suddenly...
(1) array elements can be accessed by name
(2) member data can be looked up quicker (by array index, rather than by
hashed name)
[Granted, this means the compiler looks it up once per reference, but the
runtime uses it potentially many times per reference]
Some additional syntactic sugar might eliminate the need to even code the
explicit array indexes in new... especially if we make this a general feature
of arrays, rather than being OO specific... how about...
new RFC:
The syntax
$foo['element']
would be interpreted as a reference to @foo. If the namespace for @foo
contains 'element', that member of @foo is the interpretation. If the
namespace for @foo does not contain 'element', then 'element' is added to the
namespace for @foo, the size of @foo is increased by 1, and the member
'element' refers to the newly added item in @foo.
So, starting with
my @foo; # empty array
$foo ['month'] = 10; # $#foo == 1, $foo[0] == 10
$foo ['day'] = 20; # $#foo == 2, $foo [1] == 20
$foo ['year'] = 30; # $#foo = 3, $foo [2] == 30
We achieve the same effect. There is a clear parallel between this and
my %foo;
$foo{'month'} = 10;
$foo{'day'} = 20;
$foo{'year'} = 30;
However, the lookups for @foo are done at compile time, the lookups for %foo
are done at runtime.
Getting back to RFC 163 (v2), for arrays which have namespaces, the :raccess
and :laccess would use those default names, if not overridden by a user
specified one.
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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 items.
The speed differences between hashes and arrays are not the problem.
C$val = $array[$idx] and C$val = $hash{$key} both cost the same.
Beyond that, hashes start to lose, but not by much.
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 the same.
Now while it is _totally_ true from your numbers that the lookup (read reference)
costs are the same, it would seem that the variability in write references could still
make this pay off. The set_const is about 40%
slower for hash, and set_var is about 166% slower.
N.B. I wonder if the hash accessor is faster because the array accessor is
referencing past the end of the array? (not apples to apples here, you use index 0
everywhere else, and index 1 in the accessor.)
The real problem is the overhead of accessor method calls. This by
far swamps any little fluctuation between hash and array access.
I agree, based on your numbers, that the overhead of accessor method calls is a bigger
problem, but am not yet sure, based on your numbers for *_set_*, that there wouldn't
be an observable benefit to this idea.
I know, lets call it a pseudo-hash!
Been there, done that, worn the scars proudly.
Is _that_ what a pseudo-hash is? Then it sounds like a good idea. But maybe there
are some differences between today's pseudo-hash and my proposal, even though they
might be similar. I think mine is pretty general,
and the discussion on this list made it sound like pseudo-hash has some other
restrictions?
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
NetZero Free Internet Access and Email_
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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 the same. Similar mistaken logic leads to "globals are faster than lexicals". Now while it is _totally_ true from your numbers that the lookup (read reference) costs are the same, it would seem that the variability in write references could still make this pay off. The set_const is about 40% slower for hash, and set_var is about 166% slower. Accessor overhead swamps all. N.B. I wonder if the hash accessor is faster because the array accessor is referencing past the end of the array? (not apples to apples here, you use index 0 everywhere else, and index 1 in the accessor.) Its just benchmarking flutter. I reran it with 1 everywhere else and the same results. Besides, because $aobj is global, the first call would extend the array and the following 899_999 wouldn't worrry about it. I know, lets call it a pseudo-hash! Been there, done that, worn the scars proudly. Is _that_ what a pseudo-hash is? Then it sounds like a good idea. But maybe there are some differences between today's pseudo-hash and my proposal, even though they might be similar. I think mine is pretty general, and the discussion on this list made it sound like pseudo-hash has some other restrictions? Read RFC 241 for a brief overview of pseudo-hash problems. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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 of the lookup is done at compile time rather than runtime, and this would be true of psuedo-hashes as well. it would seem that the variability in write references could still make this pay off. The set_const is about 40% slower for hash, and set_var is about 166% slower. Accessor overhead swamps all. So let's posit you've cured the accessor overhead problem. Now we're left with set_const being 40% slower for hash, and set_var 166% slower for hash. Still want to ignore it? Why? Its just benchmarking flutter. I reran it with 1 everywhere else and the same results. Besides, because $aobj is global, the first call would extend the array and the following 899_999 wouldn't worrry about it. OK. Just checking. I know, lets call it a pseudo-hash! Been there, done that, worn the scars proudly. Is _that_ what a pseudo-hash is? Then it sounds like a good idea. But maybe there are some differences between today's pseudo-hash and my proposal, even though they might be similar. I think mine is pretty general, and the discussion on this list made it sound like pseudo-hash has some other restrictions? Read RFC 241 for a brief overview of pseudo-hash problems. I've already read RFC 241. Re-reading in this context results in the following comments/quests for information. The remaining quotes here come from RFC 241... Doesn't play well with multiple inheritance I can sure believe this. There'd be indexes from multiple base classes. I don't know how Perl does multiple inheritance anyway, so I can't comment effectively on whether this is or would be a problem. If Perl does multiple inheritance, I haven't stumbled across the documentation for it, but neither have I looked. I don't use multiple inheritance. Muddles the behavior of typed variables Not sure what this means. Requires significant extra documentation and complication of hash operations. I've used perl for some years, and never noticed pseudo-hashes from the user perspective. Is this an internals only issue? Or what else have I missed? My proposal is different, because it would require additional complication of array operations. Hashes wouldn't be affected at all. Arrays would be augmented with an internal hash (probably) to do the key to index translation at compile time, the run-time code wouldn't notice that. If the key comes in as a var, then the run-time code would have to deal with that. There'd be some complication regarding string indexes that contain numbers: probably the names used as keys should not be allowed to start with a digit, in my proposal, to disambiguate proper processing. Inconsistencies between typed and untyped access. I don't know what this means, either. Pseudo-hashes, unless used very carefully, often turn out slower than hashes. Maybe so. I'm not sure why, or why not, or what all the restrictions on pseudo-hashes are. Pseudo-hashes were added to solve three problems: restrict keyspace, Not part of my proposal. reduce memory usage Not part of my proposal. May be a side effect, I doubt it, though. and increase speed of hashes. My proposal would allow name to key lookups, as an alternative to hashes, as a hopefully faster alternative to hashes, but would not affect the speed of hashes. There are many RFCs which address these issues with less caveats. After looking at these points, I'm missing how you jumped to the conclusion that I'm proposing pseudo-hashes they seem quite different than my proposal in many details. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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 not
sure what is similar about the mistaken logic...
A better one would be "dereferences are slower than using the variable
directly". ie. its a common misconception that $href-{key} should
be slower than $hash{key} because you have to dereference $href. This
mostly comes from C where dereferencing a pointer is slower than using
the variable directly.
Turns out references edge out globals. Why? A global variable has to
look up its symbol at run-time, get a *reference* out of it and
dereference it. Most of the time if you're using a reference, its
lexical. All a lexical reference has to do is dereference itself,
thus avoiding the symbol table lookup.
I've see this done:
sub foo {
my($href) = shift;
local(*hash) = $href;
}
as an "optimization". Turns out that slows things down even further!
Declaring the local version of %hash is much, much more work than
everything else altogether.
I guess I'm trying to say something about micro-optmizations being
more trouble than they're worth and usually hurt more than they help.
So let's posit you've cured the accessor overhead problem. Now
we're left with set_const being 40% slower for hash, and set_var
166% slower for hash. Still want to ignore it? Why?
Well, the fixed accessors would be using constant key lookups, so we
only have to worry about 40%, and this is 40% of a tiny, tiny fraction
of the actual overhead of a typical class. So going nuts about making
it faster probably won't gain us much overall. Certainly not worth
the effort of making arrays as easy to use as objects.
Take a class you've written that uses thin accessors and run it
through a profiler. Look at the time spent in the accessors and
reduce it by 80% (the expected efficiency increase for built-in
accessors) and recalculate its overall effect on your performance. If
its more than 5% I would be surprised.
Bascially, if accessor methods are currently eating less than 25% of
your total overhead, they will eat 5% if they are made built-in.
After that, diminishing returns kicks in. A further 40% reduction
results in a 2% overall increase. Who cares? Spend the time elsewhere.
(This is the classic argument against early/micro optimizations)
I know, lets call it a pseudo-hash!
Been there, done that, worn the scars proudly.
Is _that_ what a pseudo-hash is? Then it sounds like a good idea.
Yeah, it *sounds* like a good idea, but there's lots and lots of
little problems.
Doesn't play well with multiple inheritance
I can sure believe this. There'd be indexes from multiple base classes. I
don't know how Perl does multiple inheritance anyway, so I can't comment
effectively on whether this is or would be a problem. If Perl does multiple
inheritance, I haven't stumbled across the documentation for it, but neither
have I looked. I don't use multiple inheritance.
The phrase "multiple inheritance" only comes up in perlboot, perltoot and
perltootc. perlobj only implies that MI works because otherwise it
would be $ISA, not @ISA.
I use MI alot and really couldn't see a language without it.
Muddles the behavior of typed variables
Not sure what this means.
Currently, the only thing really using the Cmy Dog $spot syntax is
psuedo-hashes.
my Dog $ph;
$ph-{cat} = 'Mrs. Chippy'; # $ph-[$Dog::FIELDS{cat}]
and there have been several RFCs about clarifying what typed variables
mean (usually in reference to objects). Pseudo-hashes get in the way
of alot of those proposals.
Requires significant extra documentation and complication of
hash operations.
I've used perl for some years, and never noticed pseudo-hashes from the user
perspective. Is this an internals only issue? Or what else have I missed?
Its both an internals and a doc issue. In the guts, there's a bunch
of special cases for them in the guts (though not nearly so
troublesome as, say, threading) although most of the functionality is
restriected to av.c. The documentation is the bigger issue,
pseudo-hashes involve alot of caveats when explaining hashes, though
much of them have gone away in 5.6.0.
Also, the whole fields and base modules are troublesome. If you wish
to write a subclass but use a pseudohash for your object instead of a
hash, you really can't unless the class author was careful enough to
declare all their fields (a rare occurance). Also, consider the case
of a pseudo-hash friendly class, but with a subclass that uses @ISA
directly instead of base.pm and hashes instead of pseudo-hashes. A
subclass of that subclass will no longer see the fields and thus the
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
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
RFC 137 (v2) Overview: Perl OO should Inot be fundamentally changed.
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]
Number: 137
Version: 2
Status: Frozen
=head1 ABSTRACT
This RFC proposes that the OO model and mechanisms present in
Perl 5 Inot be changed significantly in Perl 6. It provides
an overview of a suite of forthcoming RFC proposals that will
provide the features, convenience, and safety that are missing
from Perl 5, without compromising the essential flexibility of
the existing Perl OO model.
=head1 EXECUTIVE SUMMARY
It ain't broken. Don't fix it.
=head1 DESCRIPTION
Perl's current OO model has a number of well-known deficiencies:
lack of (easy) encapsulation, poor support for hierarchical method
calls (especially constructors and destructors), limited (single)
dispatch mechanism, poor compile-time checking. More fundamentally,
many people find that setting up reliable OO class hierarchies requires
too much low-level coding.
But these very deficiencies are also Perl's great strength, compared
to other, more restrictive, OO languages. The non-prescriptive,
non-proscriptive nature of Perl's OO model makes it possible to
construct am enormous range of OO systems within the one language:
from archetype-based classless OO (Class::Classless), to formal
Design-By-Contract models (Class::Contract). Effectively, Perl's
OO mechanism spans the range of metaphors from Self to Eiffel --
an astonishing achievement.
It is proposed that modules like Class::Classless, Class::Struct,
and Class::Contract continue to be the preferred method of constraining
and simplifying the creation of Perl classes, and that a better
range of such modules (at very least, Class::Contract) be included in
the standard distribution.
To deal with the existing deficiencies without losing the remarkable
power, I intend to propose the following extensions to OO Perl:
=over 4
=item *
A Cprivate keyword that lexically scopes hash keys to the current
package, and allows hashes to contain two or more identically named (but
differently scoped) entries. This would solve the problem of
encapsulation in OO Perl for the vast majority of (predominantly
hash-based) class structures.
=item *
A new special subroutine name -- CSETUP -- to separate construction
from initialization. CSETUP methods would be automatically -- and
hierarchically -- called whenever an object is created.
=item *
Changes to the semantics of Cbless so that, after associating an
object with a class, the class's CSETUP methods are automatically
called on the object. An additional trailing C@ parameter for
Cbless, to allow arguments to be passed to CSETUP methods.
=item *
Changes to the semantics of DESTROY, so that all inherited destructors
are, by default, automatically called when an object is destroyed.
=item *
Pre- and post-condition specifiers, which associate code blocks with
particular subroutine/method names. These blocks would be automatically
called before and after the subroutine/method of the same name, and
trigger an exception on failure. For methods, pre- and post-conditions
would be inherited and called hierarchically (with disjunctive
short-circuiting, in the case of post-conditions).
=item *
Class invariant specifiers, which associate code blocks with a particular
package/class. These blocks would be called automatically after the the
execution of subroutine/method of the same name, and trigger an
exception on failure. For methods, invariants would be inherited and
called hierarchically.
=item *
Optional, configurable, multiple dispatch of methods, based upon typed
parameters.
=item *
A CNEXT pseudo-class, enabling resumption of the dispatch search
from within an invoked method, as well as the "rejection" of invocation
(e.g. by an CAUTOLOAD).
=item *
Constraints on lexical variables such that Cmy Dog $spot can only
be assigned a value $v if C$v-isa('Dog').
=item *
An optional constraint (Cuse strict 'objvars'?), making it a fatal
error to store a object reference in a non-typed lexical.
=item *
A new pragma -- Cdelegation -- that would modify the dispatch
mechanism to automatically delegate specific method calls to specified
attributes of an object.
=back
Collectively these extensions would significantly reduce the amount
of code required to construct safe OO classes, whilst leaving
available the existing "unconstrained" OO model where it might
be needed.
There will also be one additional -- and far more radical -- proposal
that does not form part of the above suite. It would greatly enhance the
reusability of OO Perl software, but at the cost of existing
flexibility and greater migration effort.
The proposal is:
=over 4
=item *
That in Perl 6, only hashes (and perhaps pseudohashes) may be blessed.
=back
This would result in no loss of
RFC 190 (v2) Objects : NEXT pseudoclass for method redispatch
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
Version: 2
Status: Frozen
=head1 ABSTRACT
This RFC proposes a new pseudoclass named CNEXT.
This pseudoclass would provide a way of correctly redispatching a method
or an autoloaded method.
=head1 DESCRIPTION
Perl 5 provides a pseudoclass named CSUPER that allows a method to
redispatch a call to the next available method in one of its parent
classes. This redispatch mechanism works by searching for an inherited
method in any of the ancestors of the Icurrent package (but not
necessarily the invocant's package). This works well in many cases, but
not when the next most appropriate method is actually in a sibling class
of the current package, rather than in an ancestor.
For example, consider invoking a debugging method named Cdump_info
on a derived class object:
$obj-dump_info();
In order to ensure that all the object's ancestral information
was also dumped, its Cdump_info method might be structured like so:
package Derived;
use base qw(Base1 Base2);
sub dump_info {
my ($self) = @_;
$self-SUPER::dump_info();
print $self-{derived_info};
}
The various ancestral classes would then be structured similarly:
package Base1;
use base qw(GrandBase1);
sub dump_info {
my ($self) = @_;
$self-SUPER::dump_info();
print $self-{base1_info};
}
package Base2;
use base qw(GrandBase2 GrandBase3);
sub dump_info {
my ($self) = @_;
$self-SUPER::dump_info();
print $self-{base2_info};
}
# etc.
Unfortunately, this does not result in the derived object's complete
information being dumped, since each call to CSUPER::dump_info
will only call a single (left-most) ancestral Cdump_info. Thus only the
Cdump_info methods in the left-most inheritance branch will ever
be called.
What is required here is a mechanism to resume the Ioriginal dispatch
process, rather than initiate a new one from the current point.
It is proposed that Perl 6 provide a new pseudoclass -- CNEXT --
to facilitate exactly that.
A method invocation in which the method name is explicitly qualified
with CNEXT:: (e.g. C$self-NEXT::method(@args)) would cause the
original dispatch that invoked the current method to be restarted and
the next suitable method called.
Another way of thinking of the effect of such a redispatch would be that
it repeats the original dispatch of C$self-method(@args), but ignores
all dispatch candidates until it has reached (and by-passed) the current
method. Of course, the mechanism wouldn't actually be implemented in
this inefficient manner.
Note that, after the redispatch, control returns to the original method.
=head2 Redispatch of CAUTOLOAD methods
The CNEXT pseudoclass also solves the problem of how to allow
CAUTOLOAD methods to "decline" to handle particular invocations.
For example, with CNEXT it is possible to implement an CAUTOLOAD
method that only handles method calls of the form Cget_... and
Cset_... and is effectively invisible to any other method requests
(which might then trigger other CAUTOLOADs elsewhere in the
object's inheritance tree).
The implementation would look like this:
sub AUTOLOAD {
$AUTOLOAD =~ s/.*:://;
if ($AUTOLOAD =~ /^get_\w+$/) {
# Handle getting...
}
elsif ($AUTOLOAD =~ /^set_\w+$/) {
# Handle setting...
}
else {
# Decline to handle,
# passing the request on to someone else...
shift-${\"NEXT::$AUTOLOAD"}(@_);
}
}
Note that the same trick could be applied by any method, to selectively
refuse certain invocations, handing them on to some other inherited
method instead. For example:
package IO::URL;
use base 'IO::File';
sub open {
my ($self, $filename, @args) = @_;
if ($filename !~ /^(http|ftp):/) {
$self-NEXT::open($filename, @args);
}
else {
# Open URL...
}
}
=head1 MIGRATION ISSUES
None.
=head1 IMPLEMENTATION
Presumably it would be necessary to cache the dispatch stack until
the dispatched method finishes executing.
Alternatively, implementing the method dispatcher as a coroutine
would make this very easy.
=head1 REFERENCES
Conway, IObject Oriented Perl, pp. 183-184.
RFC 8: The AUTOLOAD subroutine should be able to decline
RFC 224 (v2) Objects : Rationalizing Cref, Cattribute::reftype, and Cbuiltin:blessed
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 PROTECTED]
Number: 224
Version: 2
Status: Frozen
=head1 ABSTRACT
This RFC proposes that rather than three separate mechanisms (in three
separate namespaces) to determine object typing information, Perl 6
simply extend the Cref function to return all the necessary
information in a list context.
=head1 DESCRIPTION
In Perl 5, the class into which an object is blessed is returned by
calling Cref on a reference to that object. To determine the
underlying implementation type of the object, Cattribute::reftype is
used. To determine whether or not a reference refers to a blessed
object, builtin::blessed is used.
It is proposed that the behaviour of Cref be altered in Perl 6 so that
in a list context it returns up to two values: the underlying
implementation type of the object (always returned), and the class into
which the object is blessed (only if the object Iis blessed).
Thus:
if (builtin::blessed $ref) {
$type = attribute::reftype $ref;
$class = ref $ref;
}
else {
$type = ref $ref;
$class = "no class";
}
print "Object of type $type, blessed into $class\n";
Would become:
($type, $class) = ref($ref);
$class ||= "no class";
print "Object of type $type, blessed into $class\n";
=head1 MIGRATION ISSUES
All existing calls to Cref in a list context would have to be
translated to Cscalar ref.
=head1 IMPLEMENTATION
Trivial.
=head1 REFERENCES
None.
RFC 256 (v1) Objects : Native support for multimethods
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: Developing
=head1 ABSTRACT
This RFC proposes that Perl natively support multiply dispatched
subroutines (multimethods).
=head1 DESCRIPTION
Multimethods solve a class of problems in which objects of two or more
hierarchies must interact polymorphically, but where the nature of the
interaction is determined by the run-time type of Iboth (Iall) the
objects.
=head2 Theoretical model
It is proposed that calls to certain (explicitly marked) subroutines be
dispatched using a different mechanism from that used for regular Perl 5
subroutines, or that used for Perl 5 methods.
These explicitly marked subroutines would share the same name, but
provide unique parameter lists. Collectively all marked subroutines
with the same name but different parameters lists would be known
as a Imultimethod, with each individual subroutine known as a
Ivariant of the multimethod.
The new dispatch mechanism would look at the classes or types of each
argument to the subroutine (by calling Cref on each) and determine
the "closest" matching variant of the multimethod, according to the
parameter types specified in the variants' parameter list.
The result would subsume the behaviour of function overloading (e.g. in
C++) but in a more sophisticated manner, since multimethods take the
run-time inheritance relationships of each argument into account.
Another way of thinking of the mechanism is that it would perform
polymorphic dispatch on every argument of a multimethod, not just on
the first.
=head2 Defining multimethods
A single variant of a multimethod would be defined by specifying a
subroutine with a full parameter list (as per RFC 128), and
appending the attribute C:multi. Two or more such subroutines
could be defined with the same name, in the same package namespace, provide
they were both defined with the C:multi attribute, and their parameter
lists were not identical.
For example:
package LargeNum;
package LargeInt;use base 'LargeNum';
package LargeFloat; use base 'LargeNum';
package LargeMath;
sub divide(LargeInt $a, LargeInt $b) : multi {
...
}
sub divide(LargeInt $a, LargeFloat $b) : multi {
...
}
This creates a (single) multimethod called CLargeMath::divide with two
variants. If the multimethod is called with two references to LargeInt
objects as arguments:
$x = LargeInt-new(1234567890);
$y = LargeInt-new(9876543210);
$quotient = divide($x, $y);
then the first variant is invoked. If the multimethod
is called with a LargeInt reference and a LargeFloat reference:
$x = LargeInt-new(1234567890);
$y = LargeFloat-new(9876543210.12345);
$quotient = divide($x, $y);
then the second variant is called.
Calling the multimethod with any other combination of LargeNum-derived
reference arguments (e.g. a reference to a LargeFloat and a reference
to a LargeInt, or two LargeFloat references) results in an exception
being thrown, with the message:
No viable candidate for call to multimethod divide
To avoid this, a "catch-all" variant could be specified:
sub divide(LargeNum $b, LargeNum $b) : multi {
...
}
Now, calling Cdivide with (for example) a LargeFloat
reference and a LargeInt reference causes this third variant to be
invoked. That's because a LargeFloat Iis-a LargeNum (so the first
argument is compatible with the first parameter), and a LargeInt Iis-a
LargeNum too (so the second argument is compatible with the second
parameter). Note that adding this third variant doesn't affect calls
to the other two, since multiple dispatch always selects the nearest
match.
=head2 Finding the "nearest" multimethod
The usefulness of multiple dispatch depends on how intelligently the
dispatcher decides which variant of a multimethod is "nearest" to a
given set of arguments. That decision process is called Idispatch
resolution, and it is proposed that it be done (or Iappear to be done,
modulo optimization) like this:
=over 4
=item 1.
If the types of the arguments given (as determined by applying Cref
to each in turn) exactly match the set of parameter types
specified in any variant of the multimethod, that variant is
immediately called.
=item 2.
Otherwise, the dispatch mechanism compiles a list of viable targets.
A viable target is a variant of the multimethod with the same
number of parameters as there were arguments passed. In addition,
for each parameter the specified parameter type must be a base
class of the actual type of the corresponding argument in the
actual call (i.e. each argument must belong to a subclass of the
corresponding parameter
Specific RFC comments for -objects
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 been said. Below are specific suggestions as to what should be done with specific RFCs. These are my suggestions; you may feel free to disagree with or ignore them. I am basing these suggestions off what I have seen on the list and other RFCs. Please do not take offense if I suggest your RFC be retracted. This email is an attempt to pare down the number of conflicting RFCs based on community consensus and/or reality. Note: Some of the RFCs discussed here are do not have -objects as the Mailing-List because they predate it. However, I will still comment on these where they're relevant to OO. RFCs that should be Retracted --- RFC 95: Object Classes The consensus appeared to be against this, which provided for radical changes to Perl OO and use of . to separate classes. Many of the key points were covered by later RFCs on private methods and class delegation. RFC 171: my Dog $spot should call a constructor implicitly Again, the overwhelming consensus was against this. The later RFC claiming "my Dog $spot is just an assertion" was accepted as the way this should work. RFC 77: Suggested isa() operator Most of these changes are already handled by UNIVERSAL::isa, albeit with a different syntax. If an inline-style assertion is desired, the indirect object syntax can be used. RFC 108: Scope of Polymorphic References and Objects No discussion was recorded on either version of this RFC, and it appears to duplicate features that were more fully explored in subsequent -objects RFCs. If this is incorrect, a clarified version should be reposted by Wed. Otherwise, it should be retracted. RFC 103: Fix C$pkg::$var precedence issues with parsing of C:: This is unrealistic and unimplementable without causing major problems. And that last one's mine, just so you know I don't consider myself above honest evaluation. RFCs that should be Frozen --- RFC 153: Replace $self in @_ with self() builtin (not $ME) Some clarification of usage, syntax, and scope must be added. RFC 161: Everything in Perl becomes an object This is a philosophical document which has garnered no true support nor detraction. Some clarification of *why* this would be good should be added. RFC 128: Cmy Dog $spot is just an assertion Pretty much everyone seems to be in agreement. RFC 223: Objects: Cuse invocant pragma The mailing list should be changed to -objects, but I did not hear any specific clarifications that were needed. The remaining -objects RFCs should be clarified and reposted by Wednesday. Finally, in the only effort towards facism I will take on this issue, if I do not hear otherwise by next Friday, Sep 30th, I will request that the above RFCs be retracted/frozen under the assumption that you implicitly agree with my analyses. This is not an attempt to force my will on others, but rather try to wrap things up and present Larry with a set of at least somewhat cohesive RFCs. Thanks, Nate
RFC 93 (v3) Regex: Support for incremental pattern matching
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: [EMAIL PROTECTED]
Status: Frozen
=head1 ABSTRACT
This RFC proposes that, in addition to strings, subroutine references may be
bound (with =~ or !~ or implicitly) to a regular expression.
=head1 DESCRIPTION
It is proposed that the Perl 6 regular expression engine be extended to
allow a regex to match against an incremental character source, rather than
only against a fixed string.
Specifically, it is proposed that a subroutine reference could be bound
to a regular expression:
sub {...} =~ /pattern/;
As the regular expression is matched, it would make calls to the subroutine
to request additional characters to match, or (after it has matched) to
return any unused characters.
When the regex engine requires additional characters to match, the
subroutine would be called with a single argument, and would be expected
to return a character string containing the extra characters. The single
argument would specify how many characters should be returned (typically
this would be 1, unless internal analysis by the regex engine can deduce
that more than one character will be required). Returning fewer than the
requested number of characters would typically indicate a premature
end-of-string and would probably trigger backtracking and/or failure to
match.
When the match is finished, the subroutine would be called one final time,
and passed two arguments: a string containing the "unused" characters (what
would be $' for a fixed string), and a flag set to 1. The subroutine
could use this call to push-back (or cache) unused data. In the case of
a failure to match (or success of the !~ operator), every character requested
during the match would be sent back.
A typical structure for a subroutine against which a regex was matched
would therefore be:
sub s {
if ($_[1]) {# "putback unused data" request
recache($_[0]);
}
else { # "send more data" request
return get_chars(max=$_[0])
}
}
=head2 Examples
The most obvious example would be matching against an input stream:
sub { $_[1] ? $fh-pushback($_[0]) : $fh-getn($_[0]) } =~ /pat/;
which could also be written:
^1 ? $fh-pushback(^0) : $fh-getn(^0) =~ /pat/;
Of course, it would often be useful to have a subroutine that returns a
closure on a particular filehandle:
sub fhmatch { ^1 ? $_[0]-pushback(^0) : $_[0]-getn(^0) }
fhmatch($fh) =~ /pat/
fhmatch(\*STDIN) =~ /pat/
# etc.
In fact, this might be so commonly useful that matching against a
file handle should be made to work directly. That is:
$fh =~ /pat/
\*STDIN =~ /pat/
One could then do interactive lexing cleanly:
until (eof $fh) {
switch ($fh) {
/^\s*/; # skip leading whitespace
case /^(lexeme1)/ { push @tokens, $1=LEX1 }
case /^(lexeme2)/ { interact_somehow }
case /^(lexeme3)/ { push @tokens, $1=LEX3 }
# etc.
}
}
Note the use of the proposed PAIR data structure to store tokens
in the above example.
Because the character source is a subroutine, one could also match against
data coming out of a socket:
my $cache = "";
sub matching_socks {
if ($_[1]) { $cache .= $_[0]; return } # putback
if (length($cache) $_[0]) { # not enough cached
my $extra; # so get some more
recv(SOCKET, $extra, $_[0]-length($cache));
$cache .= $extra;
}
return substr($cache,0,$_[0],"");
}
switch (\matching_socks) {
case /pat1/ { action1() }
case /pat2/ { action1() }
case /pat3/ { action1() }
#etc.
}
or any other source:
sub mega_ape {
return join "", map {['a'..'z',(' ')x6]-[rand 32]} (1..$_[0])
unless $_[1]
}
\mega_ape =~ /Now is the Winter of our discontent.../i;
print "Art after ", length($`), "chars\n";
=head1 IMPLEMENTATION
Dammit, Jim, I'm a doctor, not an magician!
Probably needs to be integrated with IO disciplines too.
=head1 REFERENCES
RFC 22: Builtin switch statement
RFC 23: Higher order functions
RFC 84: Replace = (stringifying comma) with = (pair constructor)
RFC 31 (v2) Subroutines: Co-routines
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: Frozen
=head1 ABSTRACT
This RFC proposes the addition of a new function return command:
Cyield. Unlike Creturn, Cyield preserves the execution state of
the subroutine in which it's called, allowing the execution to be
resumed at the following statement, next time the subroutine is called.
It is also proposed that Cyields may nest, to simplify the
construction of recursive co-routines and iterators.
=head1 BACKGROUND
Normally, when a subroutine returns, its execution terminates
and it final context is completely lost. The next time the subroutine
is invoked, it recommences executing from its first statement.
In a coroutine, a value may be returned in such a way that the
execution of the routine is Isuspended, along with all its
local context. The next time the routine in invoked, its execution
resumes from the statement after the previous point of return.
=head1 DESCRIPTION
It is proposed to add a new control statement to Perl: Cyield.
A Cyield acts very much like a Creturn in that it terminates
execution of the enclosing subroutine and returns a value to its calling
context. However, when a value is Cyield'ed, the subroutine's execution
is suspended in such a way that it resumes from the following statement
next time the subroutine is invoked.
Note that any subroutine containing a Cyield is implicitly a co-routine.
There is no explicit keyword or attribute proposed.
Coroutines make it very easy to implement generic parameteric closures
and iterators:
package Tree;
sub next_inorder ($self) {
yield $self-{left}-next_inorder if $self-{left};
yield $self;
yield $self-{right}-next_inorder if $self-{right};
return undef;
}
# and later...
while (my $node = $root-next_inorder()) {
print $node-{data};
}
Note that the above example implies (correctly) that yielding a result
which itself was yielded leaves the suspended execution of the
subroutine at the same Cyield statement (Inot the following
statement). Furthermore, yielding an Cundef is a no-op (i.e. it
doesn't cause the subroutine to return, but passes control to the next
statement).
Note that the arguments of a co-routine are ignored when it is resumed.
Hence:
sub every_second ( @vals ) {
yield (splice @vals, 0, 2)[0] while @vals;
return;
}
Another interesting application is to make a Cmap block a coroutine,
to allow it to process hashes in a natural manner. For example, instead
of writing:
@newhash{map {transform_key($_)} keys %oldhash} =
map {transform_val($_)} values %oldhash;
one could write:
%newhash = map {yield transform_key($_); transform_val($_)} %oldhash;
This flattens the %oldhash to a sequence of key/value pairs. Then the
first time the map block is called (i.e. on a key) it transforms the
key and immediately yields it. On the second iteration of the map,
the block resumes after the Cyield and transforms the value.
That normal return resets the block so that for the next
iteration (another key) it applies the key transform and yields,
then tranforms the second value, etc., etc.
=head1 IMPLEMENTATION
Tricky.
=head1 REFERENCES
None.
Re: RFC 23 (v5) Higher order functions
=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 $x, $y^x, ^y positional$0, $1, $2^0, ^1, ^2 default $_^_ As I voiced before, this is incorrect. $0 is not a positional scalar. $1 is the first positional scalar. Either we need to change $1 to $0, or change ^0 to ^1. Considering $0 has been around a little while longer than HOFN, I strongly suggest we change ^0 to ^1 to be consistent. I realize this RFC has been frozen, but this is an important issue. And remember, Mike Pastore and I were the ones who suggested this whole ^ notation, y'know. ;-) Other than this issue the RFC is excellent^Wamazing. -Nate
Re: RFC 252 (v1) Interpolation of subroutines
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 don't *know* whether it's a built-in? I cannot but wonder what kind of childhood abuse leads programmers to expect that double quotes shouldn't count for squat anymore. If you don't like 'em this much, you should quit using them. --tom
Re: RFC 252 (v1) Interpolation of subroutines
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) frobbles.\n"; print "I have abs($n) frobbles.\n"; print "I have $x+$y frobbles.\n"; What's the use of quotes these days anyway? --tom
Re: RFC 252 (v1) Interpolation of subroutines
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 interpolated). They should be able to be called like any other subroutine and even take a reference. They can continue to be differenciated from defined funtions with the CORE:: prefix. The caveats and special cases surrounding built-ins are argument enough for their syntactical unification with functions. Hasn't anyone RFC'd this? And yes, the distinction between quoted and unquoted context is beginning to blur. This is not necessarily a Bad Thing. I'm sure Old School C programmers thought it was the End Of The World when it was proposed that scalars and arrays should interpolate. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse I'm not cute, I'm evil. -- Diablo www.goats.com
Re: RFC 230 (v1) Replace Cformat built-in with pragmatically-inducedCformat function
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
Re: RFC 223 (v1) Objects: Cuse invocant pragma
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 PROTECTED]
Number: 223
Version: 1
Status: Developing
=head1 ABSTRACT
This RFC proposes that, as in Perl 5, the invocant of a method should be
normally available to the method as $_[0], but that it can be
automaticaly stripped from @_ and accessed via either a subroutine
or a variable, using the Cuse invocant pragma.
Dang, this means that the obfuscatorily appealing:
sub factorial {
my $arg = shift;
sub {
return $_[0] unless $_[1];
$_[0] *= $_[1]--;
goto $SELF;
}-(1,$arg);
}
Goes out of the window. This may not be a bad thing.
--
Piers
Re: RFC 223 (v1) Objects: Cuse invocant pragma
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 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. altering *anything* about Perl to make something easier is quite in keeping with Perl's philosophy. Perl should not make bad design or bad practice easier. That's why we are looking at adding more (though optional) strict-ness, type checking, compile-time safety, etc. Well, the current situation is suboptimal. Either we should add a warning for "mixed module paradigms", or make it easier to write mixed-paradigm modules. But hey, I know this is a religious issue. I'll be able to live with Larry's final decision... Me too. -- John Porter We're building the house of the future together.
Re: Backtracing contexts with self($n) (was Re: RFC 223 (v1) Objects: Cuse invocant pragma)
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 state internally,
then you can only have one active caller at a time. If another module
also uses the procedural interface, and also expects to be the only
user, things break.
But that is all highly module-implementation dependent.
{
local $Foo::current_object = $my_obj;
Foo::splut();
}
Also, as in the case of CGI, you can mix safely:
if ( param('name') ) {
print $q-b( "howdy" );
}
Sounds to me like you're really arguing against procedural modules
in general, because they lack the strengths OO provides.
my $dup = open("/etc/motd")-dup();
for (1..2) { $dup-readline(); }
And now, suddenly, the readline() method breaks, because it doesn't have
two levels of caller.
Actually, Hildo, you've found the fault in the whole proposal:
there is no "call stack" of objects here, even in constructs like
open("/etc/motd")-dup-readline;
By the time readline is called, dup and open have both exited.
All readline can see is the value that dup returned.
--
John Porter
We're building the house of the future together.
Re: Beefier prototypes (was Re: Multiple for loop variables)
[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, that is pretty much the most important
feature of Perl. IMO. Perl would not be Perl without it.
Well, "most important" is an interestingly strong way of phrasing it.
But how to deal with variadicity in an intuitive fashion is hard.
You seem to have to sacrifice compile-time knowledge, or else
programmer-convenience. Tim Bunce had some ideas on this once.
I still almost always end up first using no protos and then employing
extensive run-time comparisons, such as this sequence might illustrate:
confess "need args" unless @_;
confess "need even args" unless @_ % 2 == 0;
confess "keys mustn't be refs"
if grep { ref }, @_[map { 2*$_} 0.. int($#_/2)] }
confess "values must be hashrefs"
if grep { reftype($_) ne 'HASH' }, @_[map {1+2*$_} 0.. int($#_/2)] }
confess "values must be Frobulants"
if grep { $_-isa("Frobulant") }, @_[map {1+2*$_} 0.. int($#_/2)] }
I should like to see the context coercer née prototype that satisfies
criteria such as these. Yes, I cannot imagine that Damian doesn't already have
a syntax for such :-) but what about compile-time versus run-time issues?
Could the prototype people please report whether Tim Bunce's issues with
prototypes have been intentionally/adequately addressed?
--tom
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
'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 $baz, $coon I can see no ambiguity in this call, but it not always works with Perl5. But [proposal:] Method calls should respect prototypes just like normal subs. So that if bar is prototyped as bar($$), then the call is parsed as foo-bar($baz), $coon -- John Porter We're building the house of the future together.
Re: RFC 244 (v1) Method calls should not suffer from the action on a distance
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 op. STDOUT-print $foo, $bar, $glarch; is not, and, in fact, is a syntax error. You *must* use parens for the arrow invocation's arguments. You *may* use them with I/O style. --tom
RE: $a in @b (RFC 199)
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", tend in fact to produce code that is tedious and annoying.
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?
sub mygrep (@) { ... }
@results = mygrep { $_ == 1 } (1..1_000_000);
How would you do it with out exceptions?
People have been quick to shoot down the various proposals for a standard
mechanism to short-circuit built-in and user-defined subroutines. Is this
because it shouldn't be done... or do people just not like ideas being
proposed to do it?
Garrett
P.S. I'm curious. is the Creturn control implemented as macro for throwing
an exception that is caught and handled by a subroutine? I.e., is there a
parallel between how Cnext/Clast/Credo and Creturn are implemented?
Re: $a in @b (RFC 199)
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", tend in fact to produce code that is tedious and annoying.
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
Loop controls don't work in an Cif or Cunless, either, since
those aren't loops. But you can always introduce an extra set
of braces to give yourself a bare block, which Idoes count
as a loop.
if (/pattern/) {{
last if /alpha/;
last if /beta/;
last if /gamma/;
# do something here only if still in if()
}}
--tom
Re: RFC 252 (v1) Interpolation of subroutines
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 could be exceptional wrt this RFC as well, i.e. not interpolable.) (Note, I'm not arguing in favor of the RFC.) -- John Porter We're building the house of the future together.
Re: RFC 253 (v1) UNIVERSAL::require()
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 UNIVERSAL::require() is called as an object method? Should it Ceval "require ".ref $obj or should it be an error? Because the situation is very rare when you will have an object from a class which has not yet been required, UNIVERSAL::require() should only work as a class method. C$obj-require should be an explicit run-time error. No. Any reason not to let the error arising from Ceval "require ".ref $obj to do its normal thing? The case may be rare, but it should be allowed: UNIVERSAL::require() should DTRT given an object ref. -- John Porter We're building the house of the future together.
Re: RFC 253 (v1) UNIVERSAL::require()
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?
Huh? All classes inherit from UNIVERSAL implicitly. It's the same reason
you can write:
$module-can('dance');
For any class, even one that doesn't exist.
-Nate
RE: $a in @b (RFC 199)
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
Loop controls don't work in an Cif or Cunless, either, since
those aren't loops. But you can always introduce an extra set
of braces to give yourself a bare block, which Idoes count
as a loop.
if (/pattern/) {{
last if /alpha/;
last if /beta/;
last if /gamma/;
# do something here only if still in if()
}}
Totally accurate, but it still doesn't allow me to short-circuit Cgrep and
return a value.
The only way I know to do that currently requires:
eval { grep { $_ ==1 and die "$_\n" } (1..1_000_000) };
chomp($@);
my $found = $@;
Re: RFC 253 (v1) UNIVERSAL::require()
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
We're building the house of the future together.
Re: pack/unpack is damn unperlish. Explain them as Perl.
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, functions, methods, loops, contexts. These are Perl. "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." You've pretty much nailed the primary use of pack/unpack - bridging the gap between scalars and the various binary formats of Le Monde Cyber. I used pack recently in order to get Perl talking with Glimpse, a search engine written in C. For some bizare reason the Glimpse server won't talk to you unless you send your PID to it. As if that weren't strange enough, it needs your PID split into 4 bytes in reverse order. If you can think of a better solution to this problem than pack then by all means propose it. I think pack is pretty good at what it does! Maybe you don't get to know how good it is until you need it? -sam
Re: pack/unpack is damn unperlish. Explain them as Perl.
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 prior knowledge of C necessary.
: Those are not Perl. Scalars, arrays, hashes, functions, methods,
: loops, contexts. These are Perl.
:
: "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."
:
: You've pretty much nailed the primary use of pack/unpack - bridging the
: gap between scalars and the various binary formats of Le Monde Cyber.
:
: I used pack recently in order to get Perl talking with Glimpse, a search
: engine written in C. For some bizare reason the Glimpse server won't talk
: to you unless you send your PID to it. As if that weren't strange enough,
: it needs your PID split into 4 bytes in reverse order. If you can think
: of a better solution to this problem than pack then by all means propose
: it. I think pack is pretty good at what it does!
:
: Maybe you don't get to know how good it is until you need it?
I think pack/unpack are perlish enough. Especially if we believe that
printf/sprintf are perlish.
An example:
Take a MySQL time stamp ( $ts = '2918123847' ) and 'unpack' it into an
array and print in in a pretty manner.
printf(
"%4d/%02d/%02d %02d:%02d%02d\n",
unpack( 'A4A2A2A2A2A2', '2918123847' )
);
If printf is perlish, so is unpack, IMHO ;-)
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
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 mori. POEM save for the whitespace on " POEM". 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 didn't like the '!' bit. So I'm not sure how you'd have written that if you'd have done it to the specification. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and Here Docs)
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 you write #goes nicely right here # If you want it to print #sans mungeing to fear is the nicest way to heredoc, where "#" is some distinctive string. --tom
Re: RFC 223 (v1) Objects: Cuse invocant pragma
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 like to second John here. I've got a couple of modules where
the OO and functional interfaces happen to mesh together beautifully
(Class::Fields is one). CGI.pm isn't exactly the greatest example of
a combination of the two styles... but from the holy wars which rage
between C$cgi-param('foo') and Cparam('foo') regularly, I can see
why it is desired.
But it doesn't have to be easy.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
But why? It's such a well designed cesspool of C++ code. Why wouldn't
you want to hack mozilla?
-- Ziggy
Re: RFC 213 (v1) rindex and index should return undef on failure
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 exceptional. The idea of a _normal_ situation being considered exceptional is raised when the code written inappropriately handles some of the normal return values. The original example of bad code John Porter wrote: $foo = "flabergasted"; substr($foo, index($foo, 'abc'), 20); # Returns undef contains errors. Clearly the current index, or even index modified to return undef, doesn't produce the desired results. The inappropriate value of -1 (or undef) passed as the 2nd parameter to substr will produce erroneous results. In order to make the above line useful, index would need to alter the _normal_ flow of control by throwing an exception. However, this is a different index function than we have today. The author of lines like the above should use a wrapper around index that throws exceptions for the normal cases that are not desirable for his application. Then the above terse code could be usefully employed. The real question boils down to who decides what is normal and what is exceptional. This is the conundrum of programming today. I don't want to sprinkle my code with try/catch just to handle a 'normal' situation. I don't want you too, either. (1) RFC 119 only requires the "catch", not the "try". This solves half the problem :) (2) I want you to use the appropriate code in the appropriate ways, so that your catch blocks only catch the abnormal (exceptional) situations. And for abnormal situations, the default catch handlers might serve you just fine, solving the other half of the problem, much of the time. GL I agree with your concern that exception handling is (generally) GL more expensive than error codes. However, I see it as a good GL expenditure of the fast CPUs of today, as a tradeoff towards GL reliable processing. And maybe in Perl6 exception handling could GL be less expensive than it is (by comparison to error codes) in GL other languages? That's a question for the internals guys, of GL course. A cycle here a cycle there, and soon the program becomes bloatware. Right. Different people have different opinions about this, too. Where to spend those cycles most usefully. My preference (but only a preference) is to see cycles expended toward making simple things more reliable. Smart programmers can solve the complex problems, but in doing so often overlook or assume away error handling... by making error handling noisier (via exceptions) but also moving it out of the main code path (via catch blocks) produces a result that pleases me, and avoids cluttering the main path of code with the handling of abnormal things. The cost then is paid only when something abnormal happens, not for every normal thing that might happen but wasn't expected here. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers NetZero Free Internet Access and Email_ Download Now http://www.netzero.net/download/index.html Request a CDROM 1-800-333-3633 ___
Re: RFC 213 (v1) rindex and index should return undef on failure
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. Perl undefined is a different concept--that of an uninitialized variable. This is proven from its earliest versions where the value is coerced to 0 or '' (specific values) when used (without warnings on). Some Perl programs modules (including DBI) attempt to correlate NULL and undefined, for lack of a better match of concepts (Perl is missing the concept of NULL, SQL is missing the concept of undefined, but that doesn't correctly imply that the concepts each language _does_ have are correlated, or should be). If you want NULL, RFC it is a new concept. DBI could then be ported to Perl 6, and the power of using NULL in its operators (perhaps together with transactional variables) could make Perl an extremely powerful database manipulation language and would make the language, complementary to and augmenting SQL in ways no other language currently does. Do not attempt to further the inappropriate correlation between undefined and NULL. Any OO language with full operator overloading could write objects/operators that behave like SQL values, and implement tristate logic for those objects, just like SQL does. Perhaps you should attempt that, and RFC the failures. I would recommend, however, that you not attempt to use the concept of undefined to implement the concept of NULL, at least not visibly... -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Re: RFC 226 (v2) Selective interpolation in single quotish context.
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
Re: RFC 253 (v1) UNIVERSAL::require()
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 concept of an undefined package, any valid package name is a valid class (I'm sure there are exceptions). It all works. Run the prototype code on any module. No. Any reason not to let the error arising from Ceval "require ".ref $obj to do its normal thing? The case may be rare, but it should be allowed: UNIVERSAL::require() should DTRT given an object ref. The case is so rare for one having an object *before* loading its class that most of the time C$obj-require will be a programming mistake. If C$obj-require is made to work, the mistake will become silent and not be noticed until much futher on down in the code. Garbage In, Error Out. If you really want it, the wrapper require() is trivial. DTRT? Data Terminal Ready, Tim? Document Filing and Retrieval Tedium? -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse If you only hear one song this year there's something terribly wrong with you.
Re: RFC 253 (v1) UNIVERSAL::require()
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
Re: RFC 213 (v1) rindex and index should return undef on failure
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 practice.
$foo = "flabergasted";
substr($foo, index($foo, 'abc'), 20); # Returns undef
contains errors. Clearly the current index, or even index modified to return
undef, doesn't produce the desired results. The inappropriate value of -1 (or
undef) passed as the 2nd parameter to substr will produce erroneous results.
Right. But this is not so much an argument for making index throw, as for
encouraging programmers to write good code, i.e.
$foo = "flabergasted";
if ( defined my $i = index($foo, 'abc') ) {
substr( $foo, $i, 20 );
}
else {
# do what you want with this condition.
}
The whole point, IMHO, is that index() should return a value which cannot
be used as an index. -1 clearly does not meet this criterion.
If it returns undef, that can be used since it will get coerced to 0, but
at least it will elicit a warning from perl. Perhaps under some kind of
very-strict it will elicit an error instead.
--
John Porter
We're building the house of the future together.
Re: RFC 213 (v1) rindex and index should return undef on failure
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
Re: pack/unpack is damn unperlish. Explain them as Perl.
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 scientific notation". People don't trip over s/printf as much for several reasons: Anyone who's written even the slightest amount of C has used printf(). Even if you haven't, there's high odds that someone around you has and can help. printf() has a direct analogy to print(). "printf is like print, except..." which makes it much easier to explain. It provides that bit of mental runway to get the reader's mind off the ground. The differences between sprintf and printf are very easy to explain. "Equivalent to Cprint sprintf" -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse I SEE A RED ASS AND I WANT TO PASTE IT BLACK WON'T OPEN ANYMORE I PASTED UP THE CRACK -- swansong
Re: pack/unpack is damn unperlish. Explain them as Perl.
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 in before paying for them. It rolls around on wheels and keeps one hand free for more important things like holding your beer." 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. Maybe you don't get to know how good it is until you need it? 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 fixed-width data parsing. Most people reach for substr() or a regex, but the best solution (as pointed out in perlfaq5) is pack. Yet it still remains obtuse and I'm largely cargo-culting when I use it. Think about a user who does not understand regexes. They typically have no idea what they're missing. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse GuRuThuG make a channel called Perl, and infest it with joking and funit doesnt make alot of sense.
Re: pack/unpack is damn unperlish. Explain them as Perl.
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 documentation and education discussion off the language list. We get enough traffic already without this. Nat
Re: RFC 252 (v1) Interpolation of subroutines
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 actual double quotes, it would be hard to pass parameters that also used double quotes, but within qq// that would be less of a problem. I suspect that it would be easier to use . concatenation rather than this form of interpolation if the arguments to the interpolated function were complex string functions, but that certainly can be a programmer's choice. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers _NetZero Free Internet Access and Email__ http://www.netzero.net/download/index.html
Re: RFC 213 (v1) rindex and index should return undef on failure
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, no doubt, many possible interpretations of why your example
line of code was bad, all couched in different justifications for using it.
I think it's better to correct the bad coding practice.
That was actually my goal too.
$foo = "flabergasted";
substr($foo, index($foo, 'abc'), 20); # Returns undef
contains errors. Clearly the current index, or even index modified to return
undef, doesn't produce the desired results. The inappropriate value of -1 (or
undef) passed as the 2nd parameter to substr will produce erroneous results.
Right. But this is not so much an argument for making index throw, as for
encouraging programmers to write good code, i.e.
$foo = "flabergasted";
if ( defined my $i = index($foo, 'abc') ) {
substr( $foo, $i, 20 );
}
else {
# do what you want with this condition.
}
Clearly with the $foo = "flabergasted" ; line in place, the whole example could be
replaced with
substr ($foo, -1, 20 );
or even
undef;
So removing that line and allowing for variability in the possible values for $foo,
the question is whether the programmer so strongly believes that 'abc' will be found
that he wishes to return it and the next 17 characters, and take extreme risk with his
code if it is not found, or whether there is really a useful alternative action to be
done in the "normal" case that 'abc' is not found in $foo.
If the intention is that 'abc' is really expected to be found in all $foo, and is just
the demarcation of the next 17 useful characters, then your "better code" costs
several extra lines, and the exception which wouldn't be taken most of the time,
resulting in little additional cost or complexity, would allow the single line
solution you originally proposed, which is nice and concise for the case where not
finding 'abc' is unexpected.
Only you, of course, can supply the intentions behind your example, but by omitting
the "do what you want with this condition" part, you clearly left it up for grabs to
be interpreted as abnormal.
The whole point, IMHO, is that index() should return a value which cannot
be used as an index. -1 clearly does not meet this criterion.
I totally agree that having index return undef on failure to find the string would be
an improvement to index. Then in could be wrapped by Fatal.pm, or Throw.pm, etc., and
we could all have and eat our cake.
--
Glenn
=
Even if you're on the right track,
you'll get run over if you just sit there.
-- Will Rogers
___
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
Re: RFC 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat function
"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 kind of weird
DC monitoring option.
DC That's probably beyond the scope of this RFC at present.
Why not add it? The formating code is seeing all the values going
through. So why not save them?
If you don't want to do the monitoring, then some hook that is called
just after the header or before the first line, and just after the
last or before the footer.
I must of missed it but what is the mechanism to force a page break?
And is there a way of keeping a format emission either together or
to allow them to be spread across a page break? (keep together/ widow
control)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 213 (v1) rindex and index should return undef on failure
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
Re: RFC 230 (v1) Replace Cformat built-in with pragmatically-induced Cformat function
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 you please explain what's the difference between a module and a pragma, and more particular, why it is important that this would become a pragma? Pragma's influence the behaviour of the Perl parser. That's all I know. -- Bart.
Re: Beefier prototypes (was Re: Multiple for loop variables)
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 specified range of repetitions.
I still almost always end up first using no protos and then employing
extensive run-time comparisons, such as this sequence might illustrate:
confess "need args" unless @_;
sub foo( $arg: repeat{1,} ) {...}
confess "need even args" unless @_ % 2 == 0;
sub foo( %args ) {...}
confess "keys mustn't be refs"
if grep { ref }, @_[map { 2*$_} 0.. int($#_/2)] }
One can't express negative conditions via parameter list.
I suppose that if user-definable attributes were available one
might be able to write:
sub foo( ( $key:notref, $value) : repeat{1,} ) {...}
confess "values must be hashrefs"
if grep { reftype($_) ne 'HASH' }, @_[map {1+2*$_} 0.. int($#_/2)] }
sub foo ( ($key, \%hash) : repeat{1,} ) {...}
# or:
sub foo ( ($key, HASH $hashref) : repeat{1,} ) {...}
confess "values must be Frobulants"
if grep { $_-isa("Frobulant") }, @_[map {1+2*$_} 0.. int($#_/2)] }
sub foo ( (Frobulant $key, $value) : repeat{1,} ) {...}
Could the prototype people please report whether Tim Bunce's issues with
prototypes have been intentionally/adequately addressed?
I'm not a prototype person (in fact RFC 128 makes it a hanging offence
to use that confusing word in connection with parameter lists! ;-)
Could someone please recapitulate Tim's issues?
Damian
RFC 24 (v2) Data types: Semi-finite (lazy) lists
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: 2
Status: Withdrawn
=head1 ABSTRACT
This RFC proposes that the right operand of a C.. operator
may be omitted in a list context, producing a lazily evaluated
semi-finite list. It is further proposed that operations on
such lists also be carried out lazily.
=head1 DESCRIPTION
It is proposed that the right operand of a list context range operation
be made optional. If omitted, the resulting range would become semi-infinite:
for (1..) {
print "The next number is: $_\n";
}
@odds = grep { $_%2 } (1..);
switch ($n) {
case [32..] { print "Two many characters in filename" }
case (@odds){ print "That's odd!" }
}
Note that the values in @odds would also be lazily generated
(otherwise the Cgrep would never finish).
=head1 IMPLEMENTATION
Ask MJD.
=head1 REFERENCES
RFC proposing a co-routine mechanism
The thoughts and writings of Mark-Jason Dominus.
RFC 25 (v2) Operators: Multiway comparisons
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
Status: Frozen
=head1 ABSTRACT
This RFC proposes that multiway comparisons such as:
if ( 0 = $x 10 ) {
print "digit"
}
should do what the user means.
=head1 DESCRIPTION
It is proposed that expressions involving multiple chained comparisons
should be automagically expanded to the equivalent binary conjunction. That is:
0 = $x 10
is DWIMmed to:
0 = $x $x 10
Furthermore, it is proposed that any operations, function calls, or subroutine
invocations should only be performed once in such expansions and that such
expansions should short-circuit on failure. That is:
$min nextval() $x+$y length $string
should become:
do {
my $tmp1, $tmp2;
$min do{$tmp1=nextval}
$tmp1 do{$tmp2=$x+$y}
$tmp2 length $string;
}
=head1 IMPLEMENTATION
As described above
=head1 REFERENCES
None.
RFC 42 (v3) Request For New Pragma: Shell
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 Status: Frozen =head1 CHANGES Added the heavy footnoting about name-clobbering with CShell.pm. =head1 ABSTRACT Perl 6 should add a new pragma, previously thought to be called Cshell, but now called something else, although I don't know what. So I'll stick with Cshell. Although quite frankly CBob would be just fine with me. =head1 DESCRIPTION The shell that Perl uses for shell interpretation is defined at compile time. Furthermore, it is optimized away when no metacharacters are found within the command string. There are times when one may need (or desire) to change the shell used for interpretation, as well as force shell interpretation, regardless of optimization, for consistency's sake. Perl runs on many platforms. Many of these platforms, either by default, desire, or need, may have multiple command interpreters that Perl may want to interface with by default. (ie, through the use of backticks or system().) Perl is not just a glue language, but a SuperGlue language. I ab^H^Huse Perl to interact with a lot of home-grown command interpreters as either a driver, a hardware controller, or Expect-type engine. It's a lot more DWIMmer when I can operate in that environment, vice the standard OS one. Furthermore, there are times when speed be damned! I need every `` to go through the command interpreter in order to get back consistent results, and I don't want to have to mangle the output string in order to force a metacharacter. It is important, however, that this be lexically scoped. One can't really afford to have some unknown module expect /bin/sh and accidentally send the command to turn on a robot's "Kill Human" mode, for instance. =head1 MOTIVATORS Laziness, and perhaps a bit of Hubris. =head1 IMPLEMENTATION This was an easy hack in Perl 5, except for the scoping issue. Ideally, there'd be a -force flag to check, and a method to change the location of the shell, the shell arguments, and perhaps what is defined as a shell metacharacter. =head2 SUMMARY OF IMPLEMENTATION See above. I hacked this for Perl 5 in about two minutes, minus the scoping, which I never could figure out. :-( The scoping lament is continued in RFC 40. =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of Cuse shell and the semantics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What if the interfaced modules return things that `` and system() don't expect? =back =head1 STATUS Frozen. There has been little discussion, other than pointing out that Shell is already a module, and on platforms that are case insensitive, the two would clobber. Furthermore, it was agreed that this Cshell doesn't fit well into that CShell. Hence, this pragma is more or less the ubiquitous "player to be named later." =head1 REFERENCES RFC 40: Module Scope Control.
RFC 55 (v2) Compilation: Remove requirement for final true value in require-d and do-ed files
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 List: [EMAIL PROTECTED] Number: 55 Version: 2 Status: Frozen =head1 ABSTRACT This RFC proposes that files compiled via a Crequire or a Cdo no longer be required to end in a true value. =head1 DESCRIPTION It is proposed that the final value in a file that is compiled using Crequire or Cdo no longer be significant. Instead it is proposed that files that wish to fail during compilation should throw an exception. Furthermore, any valueless exception (i.e. thrown with a simple Cdie;) that propagates through a Crequire or Cdo should automatically take the appropriate message string: "require failed: file "%s" threw an exception" "do failed: file "%s" threw an exception" Note that exceptions with some value would be passed through unchanged, allowing a compiled file to signal exactly why it failed. =head1 IMPLEMENTATION Dammit, Jim, I'm a doctor, not an engineer! =head1 REFERENCES None.
RFC 70 (v4) Allow exception-based error-reporting.
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: 4 Status: Frozen =head1 CHANGES 1. Status frozen. 2. Added NOTES ON FREEZE section. 3. Dropped glob from the list of non-wrappable builtins. =head1 ABSTRACT Allow full implementation of Fatal.pm, for programmers who prefer exceptions for error reporting. To enable this, ensure that all builtins (like e.g. print()) that return errors can be wrapped. In addition, ensure that builtins like e.g. integer division, which currently throw exceptions on errors, can have that behavior switched off. At least print, and printf should be wrappable. =head1 DESCRIPTION Perl has traditionally reflected the Unix syscall and library tradition for error reporting: errors are indicated by otherwise-impossible return values, which must be checked for explicitly, lest system error events be ignored. Some programmers prefer to have errors print a message and exit with non-zero status, by default, rather than having to always code " || die ...". In perl5 this has proven elusive of implementation. Fatal.pm has been the attempt made to date, and it suffers from two problems. One can be fixed with further development: it should have various lists of builtins available, e.g. :io, :system, :all for including all calls affecting I/O, all system calls of any sort, and all calls that can have error returns. If these were a success, then the requested category could also be posted into a testable variable, allowing module authors who wished to to automatically support this functionality as well. In addition, for classes of errors that currently throw exceptions, Fatal could be taught to disable them, allowing e.g. no Fatal qw(:arithmetic); my $result = 1 / 0; # $result now contains undef, w/ # error posted in $! or maybe $@ But Fatal.pm development stalls out early, because some builtins, which report testable error conditions, cannot be wrapped. A conspicuous example is print(). =head1 IMPLEMENTATION Ensure that every perl builtin that can return an error, can be wrapped. Perhaps in addition ensure that routines that currently die on error, can have their behavior changed as well. For the first part, tchrist posted a nice list of non-overridable builtins; running my eye down it, it looks like the gross offenders here are: print, printf I don't know whether this is purely an implementation issue (and so lies solely in the domain of perl6-internals) or whether any programmer-visible changes may be necessary to allow this (justifying posting to perl6-language). =head1 NOTES ON FREEZE This RFC drew very little discussion. It simply proposes a fix to the core, allowing a couple of existing routines to be wrapped, which would allow the completion of an already-existing external module to allow exception-style error handling. Other RFCs have gone far further in requesting that exceptions and/or objects representing them be welded into the core. The changes during its life were additions of references, just below, and specifics about the currently-unwrappable core routines that can return errors, deduced from a list posted by tchrist. =head1 REFERENCES Fatal.pm, as included with recent perls. Error.pm, available from CPAN, and cited by RFC 63: if this proposal should carry, then Fatal.pm will see some very active development, and if RFC 63 should also prevail, then Fatal's development should be guided by RFC 63/Error.pm. RFC 80 Proposes a taxonomy for exception objects; should it prevail, it should guide the structure of exceptions thrown when Fatal.pm gets worked on.
RFC255: Fix iteration of nested hashes
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, will no longer work at all:
%a = ...;
%b = ...;
sub make_iterator {
my $hashref = shift;
return sub { each %$hashref }
}
my $a_iterator = make_iterator(\%a);
my $b_iterator = make_iterator(\%b);
for (1 .. 100) {
push @a, $a_iterator-();
push @b, $b_iterator-();
}
We want to get the data from %a into @a, and the data from %b into @b.
With your proposal, this code must fail. The most likely failure mode
is that you get 100 copies of %a's first key and value in @a, and 100
copies of %b's first key and value in @b.
The code fails because you said to attach the iterator state to the op
node, and there is only a single op node here. Unless that op node
has room for an arbitrarily large number of states, the call to
$b_iterator-() is going to destroy the iterator information that was
saved during the call to $a_iterator-().
The solution to this is that the iterator state should be stored in
the pad for the block in which the each() appears. The op node can
hold the index of this pad element. Since the two closures do not
share pads, the code will continue to work.
So your proposal can be saved, but it needs to be fixed.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC 230 (v2) Replace Cformat built-in with pragmatically-induced Cformat function
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 something like Correct. As I've already replied to someone: this will be fixed in the next draft. The exportable function CFormat::break_TeX use Format qw( break_TeX ); Nitpick: I hate MixEd CaSe names, they're hard to read and remember. Methinks break_tex is sufficient. But that's just my opinion. I ain't gonna argue with Donald Knuth! ;-) Damian
Re: pack/unpack is damn unperlish. Explain them as Perl.
"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. Actually not. You need to do some extra nasties to get an integer from a binary record into a perl scalar and have it be a number. If you use substr it will be a string. Useless. Pack takes binary data chops it into bitesize pieces so that perl can use it correctly. binary integers stay integers if they are in the wrong endiness the bits get flipped properly. un so weiter. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 213 (v1) rindex and index should return undef on failure
"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) when used (without
GL warnings on).
Sorry, as far as I'm concerned
$foo = undef
and
select @foo = NULL
Are both initialized.
And what do you consider
sub foo { ; return }
$status = foo;
Uninitialized? Very clearly initialized.
And lets look at the name and functions
defined($foo)
undef($foo)
Both seem clearly to mean _undefined_ or perhaps unknown or NULL
The use of undef meaning 0 or '' is quite useful.
But under some programing styles having tristate logic and NULL propogation
would make some programming task a bit more straightforward.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
state of the language WG
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 along reasonably well and I have no objections to stuff that's happening. "Silence is consent," and all that. As everyone's aware, the RFCs just keep pouring in, and it seems that people are rushing to get their final ideas in before closing time. Traffic on -language is up somewhat, but hasn't got unreasonable. Everyone still seems to be playing nice, for which I am eternally grateful. Likewise, the language sublists are moving along at a steady pace. I really should be keeping in touch more with the sublist chairs, but they all seem to be doing such a good job that I've mostly left them to it :) Things that still need doing include: - contact RFC authors to encourage moving RFCs towards Frozen/Withdrawn - wrap up sublists as their RFCs are finalised - get more tuits On the "get more tuits" note, I should mention why I've been a bit absent lately. Basically the company I work for, Netizen, has been going through some Interesting[0] Times lately. In fact, we've been wrapping up the business. This wasn't intended to be a total closing down... we were expecting our staff to be hired as a team by another company, and were looking forward to that. However, that doesn't seem to have eventuated, so we've got a few people out of work -- myself included. If anyone wants to know more about it, my diary at http://infotrope.net/diary/2000-09.html should explain a bit more. So, this means I've been a tad distracted. I'm also about to become *more* distracted as I head off around the world for job interviews, starting this coming weekend. I will be gone 2 weeks, and while I will have net access for most of it, it will be difficult for me to keep up with everything. I also won't be making it to YAPC::Europe :-( However, if anyone in Ottawa, Montreal, or Stockholm would like to get together for a few drinks or something, email me. Because of this, I'd like to ask the sublist chairs to take responsibility for wrapping up RFCs for their sublists, leaving me with only the actual "-language" ones. I'd also like to ask the -language members to bear with me and, if possible, to help bring all our RFCs to their final states. I think we've all done a really good job so far, and it shouldn't be too hard to bring it all to fruition over the next few weeks. My Netizen email address will continue to function, however I would prefer most correspondence to be addressed to me at my home address, [EMAIL PROTECTED] Thank you in advance for your forbearance, K. -- Kirrily "Skud" Robert [EMAIL PROTECTED] http://infotrope.net/
Accessing a variable's attributes (was Re: RFC 241 (v1) ...)
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 if it could be done at all, it would only be in extension (formerly XS) code. -- John Porter We're building the house of the future together.
Re: Accessing a variable's attributes (was Re: RFC 241 (v1) ...)
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 programmer wants to do. 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 easy things hard and hard things impossible. You'll note that that isn't the motto of Perl. (The deadline for collecting ideas passed two weeks ago. Why is this all still going on?) Simon -- I cannot and will not cut my conscience to fit this year's fashions. -- Lillian Hellman
Re: Accessing a variable's attributes (was Re: RFC 241 (v1) ...)
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 easy things hard and hard things impossible. You'll note that that isn't the motto of Perl. I'd rather this sort of thing be visible everywhere as well. I don't see any reason that we should force folks to write extensions to get this stuff. (The deadline for collecting ideas passed two weeks ago. Why is this all still going on?) Who meets deadlines anyway? :) This is more a question of ramifications than anything else, and those are bound to show up in chunks as development proceeds. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Accessing a variable's attributes (was Re: RFC 241 (v1) ...)
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.
