Michael wrote:
I wouldn't mind an optional OO contract system in the core of Perl,
but this may be a case of "why do it in core when a module will work?"
Since OO contracts are typically turned off in production code any
performance gains from adding it to the core wouldn't
I'd like to say that I whole-heartedly endorse the sentiments expressed in
this RFC (and *not* just because it likes my book! ;-)
It will definitely underpin my thinking when I finally put together my
own OO RFCs.
Well done, John.
Damian
Yes. MacOS and VMS. (Though VMS' localtime() uses the UNIX definition,
just to be portable.) MacOS' epoch zero is 1900 (or was it 1901?),
1904 (if it matters).
Damian
I hate to add a "me too" but I think this is right on. I also think that
Nat's proposal and several other discussions overlook some stuff about
lvalue subs. Most of the places I've seen them used really well is if
they walk and talk like other forms:
$cgi-param($var,
An argument would be associated with a named parameter by
prefixing it with a standard Perl label (i.e. an identifier-colon
sequence). For example:
@mapped = doublemap(args: @list, mapsub: ^a+^b);
I persoanlly would prefer '=' to be used here instead of
So what you want is for overloading to become easier, probably via
predefined methods? Excellent topic for an RFC.
I'm already writing it (and exactly that way, too).
Damian
[EMAIL PROTECTED] (Randal L. Schwartz) writes:
So is that something we've agreed, that lvalue subs are *always*
scalars? That'd mean we can move on to the various implementation
details. :)
Err, I for one would like to see *any* data types lreturn-able.
If a subroutine can return a list,
It's an idea that within a method call, the object reference would
not be passed as the first argument (or maybe, not *just* as the
first argument), but in a variable named $ME. I was pushing that
envelope a little.
Is this RFC'ed yet?
It may have been mentioned
Since there is a run-time component we could probably write a
proof-of-concept parser for some of this in perl5 now:
use NamedParameters;
This would certainly be an interesting and useful module. I
encourage someone to create it. Of course, it couldn't (easily)
include all the
Here is a few throw away thoughts - they don't constitute RFC
material yet, I am not sure if they would be that useful and have
not yet thought of any syntax, but any others? All of these can be
done today but are not necessarily "easy".
* Embeded patterns that do not
: Text::Balanced has to track in order to parse almost any Perl code.
It's a good thing you said "almost".
Ah, that Jesuit education finally pays off! ;-)
Does it parse [*]] correctly?
No, but only because Cextract_variable ignores punctuation vars entirely.
It would be a
If there are any RFC's which you have in mind and could send me your
notes on, I'd be *more* than happy to help out.
This is actually an excellent idea, because then Damian can
concentrate on coming up with the key ideas. However, rather than
having to shuffle notes
So perhaps you should ask people to contribute implementation notes
sections to your RFCs rather than entire RFCs? And no sense in requiring
that for the initial version, though a solicitation in the text of the
RFC itself might hasten their appearance.
I thought that was what
/\A(?s:(?!and).)*\Z/
/pattern returned from ${\some_function} as part of a regex/
/match any of (${\join'|',@list}) here/
I am not saying these things can't be done, in fact I was saying they can
but was rather asking what should be made easier?
Perhaps I
[Apologies for following-up my own post]
I wrote:
You're error is in assuming I have time *now*.
With 30+ RFCs still to write, I've been seriously contemplating
just abandoning the Perl 6 effort, because added to the demands
of my full-time job, my O'Reilly and other
Except that Perl 6 people will know all about numbered parameters, so they
will write:
@out = sort ^2 cmp ^1, @in;
and it will work just as they expect!
As long as they expect it to fail miserably! :-(
Now, go home and write it out 100 times:
"Array and
%professors{ $a-name cmp $b-name };
%students{ $$students{$b}{GPA} = $$students{$a}{GPA} };
These already mean something. Please don't "special-case" them.
No they don't.
Apologies. You're quite correct.
Isn't this better handled with a
Glenn Linderman wrote:
If a curried subroutine is truly generated because of seeing an
expression containing placeholders, then that expression contains some
finite number of placeholders. Each placeholder turns into a parameter
of the generated subroutine. The generated subroutine has, I
On Thu, Aug 17, 2000 at 10:48:25PM -0500, David L. Nicol wrote:
Lets use hats again then.
%ws{
print ^$height; #prints $ws{height}
print $height; # perl5 visibility rules
};
But no $ for the keys of %ws.
%ws {
Lets use hats again then.
%ws{
print ^$height; #prints $ws{height}
print $height; # perl5 visibility rules
};
AFAIK, the entirety of %name{something here} is unplowed ground, as
far as perl syntax goes.
For good reason, AFAIAC.
What if the hash keys we want to use are not valid scalar names? For example,
I've had keys like "total - female" as keys, but using the ^ syntax
would fail on this...
^{"total - female"}, just like $ variables.
Damian
The interesting thing about ... is that you have to be able to
deal with it a statement with an implied semicolon:
print "foo";
...
print "bar";
We already have plenty of statements with implied semicolons:
print "foo";
for @list {}
: In a void context, Cdump dumps the program's current opcode
: representation to its filehandle argument (or STDOUT, by
: default).
It's not clear to me that reusing a lame keyword for this is the
highest design goal. Let's come up with a real interface, and then if
[EMAIL PROTECTED] writes:
: We already have plenty of statements with implied semicolons:
:
: print "foo";
: for @list {}
: print "bar";
Yes, we do, and I'm trying to figure out how to write a prototype for
one of those. :-) / 2
Under RFC 128 and the
Instant program migration:
host-a:foo.pl: print SOCKET dump;
host-b:bar.pl: { local $/; eval SOCKET };
If domeone is putting this RFC together, please remember to propose
that Ceval and Cdo should handle opcodes as well as source:
host-a:foo.pl: dump
: I would like to see a compiler warning for this:
: "Spaces detected after apparent here document terminator", but
: preferably phrased better.
:
: Are there any objections?
I object, vaguely. I think it should just Do The Right Thing.
(I suspect it should
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what dump was always meant to do.
dump FILE; # dump program state as opcodes
You don't like that that should be a checkpoint resurrection at the
point in the programmer labelled with "FILE:", per the current
(semi-dis-)functionality?
Not much :-)
Maybe:
dump "FILE:"
but not just a
Uri wrote:
PRL A Cprivate keyword that lexically scopes hash keys to the
PRL current package, and allows hashes to contain two or more
PRL identically named (but differently scoped) entries. This
PRL would solve the problem of encapsulation in OO Perl for the
PRL
I think this is fraught with peril. I'd have expected:
print (1, 2, 3, ...) or die;
to print
12345678910111213141516171819202122232425262728etc
No, if that's what you wanted, you'd get it with
print( 1, 2, 3 .. ) # RFC 24
So if all I want to do is make sure that certain attributes are positive
integers, I have to do this:
[ admittedly ungainly solutions snipped ]
I'd much prefer a solution where the positive-only logic was in a method
belonging to the class, rather than being
The mythical (and insistent) 'in' operator to rescue?
I don't think so. "In" doesn't mean "matches".
$pattern in @expr
any(@expr) =~ $pattern
all(@expr) =~ $pattern
@pattern in $expr
$expr =~ any(@pattern)
$expr =~ all(@pattern)
@pattern in @expr
any(@expr) =~
And that's just too much punctuation for too little value.
How special purpose is "with"? Do people envision using it *only* on
hashes? (I did until this email) If so, I like Damian's version best:
http://www.mail-archive.com/perl6-language@perl.org/msg02649.html
One could make dump "work" by having it dump out not a core or
a.out, but rather the byte codes representing the current state of
the perl machine. This seems anywhere from somewhat to seriously
useful, and follows in the spirit of what dump was always meant to do.
I was
Larry Wall writes:
I'd entertain a proposal that ... be made a valid term that happens
to do nothing, so that you can run your examples through perl -c for
syntax checks. Or better, make it an official "stub" for rapid
prototyping, with some way of getting a warning
I'd like to see a new builtin named "in" which does the same as
"in" in SQL. Basically,
print "OK!" if $val in ("foo","bar","bla");
Wait for the superpositions RFC:
print "OK!" if $val eq any("foo","bar","bla");
print "OK!" if $val =~ any(qr/fo+/,qr/bl?ar?/);
DC However, I have given thought to allowing conditions to be grouped,
DC and de-activated by group. This would probably meet your need.
DCpre mymethod : group("safe-coding practice") { @_ 0 }
DCpre mymethod : group("debugging") { print @_, "\n"; }
Data Conversion and Access
-
STRING Called in a string context
NUMBER Called in a numeric context
BOOLEAN Called in a boolean context
Operator Overloading
Currently, the current object context is passed into a sub as the first
element of @_, leading to the familiar construct:
my $self = shift;
However, this is a big PITA. In particular, if you support lots of
different calling forms (like CGI.pm), you have to check
What I meant to say was more along the lines of "if this could be done as a
macro, does it need to be a pragma, or could it be part of a standard macro
package?"
And, secondly, "if this *is* part of a standard macro package, wouldn't it
be cool to let it shove arbitrary
The use invocant was proposed as a way to maintain backwards
compatibility and yet give everyone the invocant access syntax he
or she personally favours.
...while also giving the compiler enough information to allow such
invocant access to execute in an optimized
I was talking about the hypothetical situation where you're (re)using or
modifying a bunch of code or classes written by different people and you
constantly have to be aware of which self-thingie to use in which file or
package or whatever. Yeah, you can just glance up to the use
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
Counter-summary: Although the high and low precedence binary ops could be
rolled together, the current version of operator
(Or, was it already intended that the implementation of 'use
invocant' might be some sort of compile-time macro?)
No. I think a macro facility for Perl should be more general than just
whacking some code in at the start of every subroutine.
The use invocant was proposed as a way to
THING =~ OTHER_THING
is translated to
bind(THING,OTHER_THING)
with bind() having user-defined semantics.
I think Damian has an RFC in-the-works on operator overloading that
will address this.
That one's been passed to brian d foy and (if memory
Damian's Text::Balanced does a pretty good job of tokenizing Perl
as it is. / by itself requires a lot of lookahead, and it's still
a guess.
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an operator, or end of statement, then it's
"Array and placeholder indices both start at *zero*!"
Sorry for being late, but "why?!"
It makes more sense in a vacuum, but given $1, $2, etc, I'd *much* more
expect them to start with ^1, ^2, and so on. It's much more consistent.
But ^1, ^2, etc. have
^foo -- compact array (or whatever notation)
I seem to remember that ^ was in the process of being highjacked by some
other RFC already. Was it higher-order functions?
Yes: RFC 23 (v4): Higher order functions
Damian
And the advantage of that over
@hash{ grep /^[^_]/, keys %hash }
would be what? Brevity?
Yes.
Damian
I think it would be a good thing for user prototypes to be able to
handle this case and I wholeheartedly support the RFC; but it opens
a can of worms that should be addressed. Perhaps in another RFC. Do
any other (Damian) RFCs on (Damian) prototyping impact (Damian)
this area?
Well, $hash{/re/} would only evaluate to a single scalar.
More likely, you'd want @hash{/re/}, which would be
equivalent to @hash{ grep { /re/ } keys %hash }.
I have a draft RFC that proposes that the LIST argument of a
grep be optional in a hash slice, and default to the key list
What about
sub somename : method (@args) {...}
And leaving your$self some other way at the object?
That's the idea. By default you get the invocant in $_[0],
but you can have the compiler extract it for you via Cuse invocant.
Then you get to choose your access mechanism
Builtins: merge() and demerge()
Still think Cmerge and Cemerge are cuter. :-)
And if we have to make up an antonym to Cmerge, let's choose Cunmerge,
by analogy to Cunshift, Cunpack, Cuntie.
(And yes Tom, I *know* I'm advocating grafting a Germanic prefix to a
Latinate word and that "no
Still think Cmerge and Cemerge are cuter. :-)
Except that that pair looks like "munge" and "emunge"...
Not to mention "mail" and "email" ;-)
Damian
Nate asked me to look over this proposal and comment.
On a cursory reading, I have no objections to it, if the indirect
object syntax is to be preserved.
Damian
currently we can do
$str = "foo bar";
substr($str, 4, 0) = "baz ";
and $str will become "foo baz bar". should we be able to do
this with lvalue-subs? how can one returns "pointer" to a
portion of a scalar?
sub partial: lvalue {
http://www.csse.monash.edu.au/~damian/CPAN/Language-Pythonesque-beta.tar.gz
How close to a complete Python implementation is it? I can see shipping it
as part of perl 5.8.0 if it's close. 6.0.0, too. (And yes, I'm serious)
I'm afraid it isn't Python at all. It's Perl without
Just wanted to clarify this, as I think this may be the part that
overlaps with what you're doing. Under this syntax, the object would be
called for you automatically, so your prototypes wouldn't have to deal
with optional first arguments at all:
print($FILE,
print("$stuff"); # main::print($stuff)
How does it know that the second version isn't:
$stuff-print();
[coming in on the middle of this, so context may be muddled]
But for the double quotes, it wouldn't.
So this:
my $class =
This whole thing is actually a deep and complicated imbroglio--as I know
you, Damian, are aware. I don't know your ideas for untangling it.
Sure you do: indirect objects MUST DIE! ;-)
But I freely admit that's not a satisfactory solution.
Meanwhile, thank-you for the masterly
On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
Add Clist keyword to force list context (like Cscalar)
Makes sense to me. Does it connect in any way with Damian's generic
want() function?
Only in that it would explicitly cause Cwant 'LIST' to return
No-one AFAICT has yet brought up formats, and what would happen
to them if bareword filehandles go the way of the dodo.
I'm about to propose that formats be replaced with a mechanism of
Text::Autoformat::form (with some extensions).
Damian
You know, I would like to pass code blocks in any arg position;
I want sub foo(\@\@) to be callable as
foo { alpha() } @bravo { charlie() } @delta { echo() };
No Csubs, no commas.
Already in the RFC.
And one further note: it would be nice if, given a
And has anyone pointed out that Clist is just:
sub list {@_}
Um no. I would expect it to be
sub list { @_[0..$#_] }
It's too early in the morning.
The subtlety here escapes me.
Damian
I was thinking that the switch statement could possibly be expanded
to also behave as an operator and not just a control statement.
I had considered this, but didn't put this in because no other
Perl control statements return a value. Personally, I like the
notion a great deal.
What the
But I've gotta nitpick the name. I wonder if BLESS wouldn't be better?
print calls PRINT, printf calls PRINTF, even if the subs don't do any
printing. Sure makes it easier to see what's going on, to me at least.
But BLESS doesn't do blessing. It does set-up. So it's called SETUP. :-)
Furthermore, it proposes that both CSETUP and CDESTROY methods
should be invoked hierarchically in all base classes.
This bothers me. It leaves no way to override the behavior of a
parent's SETUP and DESTROY, you can only overlay. You mentioned that
this is normal for
What happens on reblessing?
An excellent question, and one that has been exercising my mind for
some time now.
I have come to the conclusion that a reblessing must either:
* invoke the old class's DESTROY(s) and then invoke the
new class's SETUP(s), or
* invoke
What if you want to bless something but not call all its cascading
SETUPs?
Then don't *define* cascading SETUPS in the first place. :-)
Cbless still would have the existing Perl 5 behaviour. Things
only change if you add these new-mangled SETUP methods.
The point of welding SETUP
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments. Personally, I would like to see the
indirect object syntax removed in all contexts, inclusing
this one, and filehandles simply passed as a first argument.
Damian
I intend to extend the parameter lists RFC to cover optional
(non-trailing) arguments.
Will this include having typed variadic functions, allowing you, for
example, to say something like
This function takes any number of arrays, all passed by reference.
Here is my suggestion: What if other functions were able to backtrace
context and determine how many arguments to return just like split can?
I have an RFC on that:
RFC 21: Replace Cwantarray with a generic Cwant function
Cwant takes a list of strings that describe
Ever consider then having
($a, $b, $c) = FH;
or
@a[4,1,5] = FH;
only read three lines?
I think this is a superb idea, and look forward to someone's RFC'ing it.
Damian
Also, its not entirely clear why method chaining is desired only for
constructor and destructors. What about every other method?
Constructors and destructors are special. They're not about *doing*
something; they're about *being* (or not being) something.
A "doing" method *may* wish to
=head1 TITLE
Cmy Dog $spot should simply assert that
C(!defined($spot) || $spot-Egtisa('Dog'))
And let them duke it out.
You'd have my support for that...I was intending to release an RFC in the next
day or two that is exactly along those lines.
Damian
But I agree that anything beyond that is simply horrible. You'll only
drive more people *away* from OO, because it generates so horribly
inefficient code. If you want a constructor called, than FGS *call* a
constructor. Maybe you can reduce the syntax necessary to do that, but
From [EMAIL PROTECTED]
Sat Sep 2 08:16:14 2000
Received: from ALPHA1.CC.MONASH.EDU.AU (alpha1.cc.monash.edu.au [130.194.1.1])
by indy05.csse.monash.edu.au (8.8.8/8.8.8) with ESMTP id IAA21970
for [EMAIL PROTECTED]; Sat, 2 Sep 2000 08:16:14 +1100 (EST)
Received: from
The "multiple inheritance paths" one is good. I like that part a lot.
But the rest makes me really nervous if there's no way to override or
change it.
There is. I'll try and get the Cuse delegation RFC out today.
One thing nobody's brought up is this: What if you decide you
private $self-{data} = $derdata;
should be $derdatum here?
Yes. Thanks.
Damian
Yes, welcome to the dirty, icky real world. Life sucks, people will
write bad code, you will have to inherit from it. Sometimes you have
to break a little encapsulation to make an omlet. I'd rather it was
not so, but its better to accept it and deal than deny.
Of
Should be part of the want() context.
It is. I interpreted Damian's remark to mean that it would be good if
readline() took advantage of it, and that should be RFC'ed.
That's indeed precisely what I meant. In fact, all list-returning built-ins
ought to be optimized this way.
By RFC 21, it looks like the call would be
if ( want 'LIST' ) {
$num_to_return = want;
# do stuff
}
or, more efficiently:
if ( ($num_to_return) = want 'LIST' ) {
# do stuff
}
However, at one time the discussion had
The LIST/SCALAR/VOID distinction is always the second value returned
(see the examples in the RFC). So your dispatcher is:
my $func = lc (want)[1] . "_func";
return $func(@_);
I think I'd much rather it be the first. This seems to jive much more
Is this not just a module which creates the necessary subs in the calling
package ? The catchall can be done with an AUTOLOAD sub.
That's certainly how Class::Delegation is implemented.
It isn't quite adequate however, because if you trigger the AUTOLOAD and
it *fails* to delegate, you
Will "private" be a true scoping keyword? Or under strict would you have
to do this:
private my %hash;
It's not a replacement for Cmy, though Cuse strict
*might* choose to overlook it. :-)
Damian
Modulo some superpositional silliness,
Hey! I resemble that remark!
Damian
When I see those empty arrayrefs, I think "delegate to *no* methods in
those classes stored in attr3 and att4," rather than "delegate all
method calls to those attributes." Just in the name of greater clarity,
I might like to see something like URI suggested:
attr3 =
When you want to turn off an inherited delegation in an ISA situation?
Um, I don't think I understand the question.
I'm confused by the question, too.
Delegation is not inherited. Any module you inherit from you won't
use for delegation, AFAIK. They're two different
Just to note that RFC 76 (Builtin: reduce) also proposes this
mechanism as a means of short-circuiting Creduce.
Damian
That seems reasonable--except that I don't believe exists() merits
any special treatment.
More specifically, I think all non-lvalue context use of - should be
non-autoviv, whether exists or anything else.
I agree entirely.
In fact, I shall extend RFC 128 to allow
In fact, I shall extend RFC 128 to allow subroutine parameter to specify
that they are non-autovivifying.
I'm not sure why it matters to the subroutine. We've already got
the hack so that
fn( $a[$i] )
or
fn( $h{$k} )
will only autoviv
if ( ($num_to_return) = want 'LIST' ) {
# do stuff
}
And more correct as I would assume that
() = some_func();
$num_to_return would be zero, but the assignment would cause the
if() to be true.
A scalar context Cwant would
A scalar context Cwant would also need to DWIM, presumably by returning
"0, but true" in that (unusual) situation.
Actually, given Damian's and my conversations last night, it looks like
the first return arg from want() is going to be the context after all
(since then
John wrote:
I don't know how grep works internally. I don't know if grep pushes
elements into @a one at a time, or if it returns a finished list of
elements which pass the conditional block. If it is the latter as I
assume, a short-circuited grep would return a list of all
Garrett wrote:
It almost feels like grep could have been written like this (in
another life): @a = grep (@b) { $_ 2 or last }
http://www.csse.monash.edu.au/~damian/TPC/2000/Romana/perligata.html
;-)
While I'm at it, I'm curious as to why:
$a = 2;
@b = (1, 2, 3,
I would propose that the Cgrep operation should short-circuit if the
block throws an exception, with the value of the expection determining
whether the final invocation of the block should accept the element it
was filtering:
Otherwise nice but until now die() has
@passed = grep { 2 $_ and last } (1, 2, 3, 2, 1);
I believe that unless used with a label, if someone were to use
last within a grep or map block, then further processing for that
element of the list which grep is working on would be skipped, and
it would continue with
If one were looking for the first matching item, last would work:
grep { /pat/ and last } @foo
# return()s the value of $_=~/pat/, which will be true
Huh? I can't see how that could work unless you change the existing
semantics of Cand and Clast.
Let's take a step back
Shoot chop. and chomp. Unless you add unchop and unchomp.
Cchomp *has* an inverse.
Surely you know about the unary postfix C.$/ operator?
Of course, you have to be careful. There's a known bug that
the C.$/ doesn't properly "unchomp" if you've ever used the
C$/=`` operator.
;-)
Damian
While we are here, can reduce itself generate an average? I.e. something
cuter than:
$avg = reduce { $_[0] + $_[1] } @numbers / @numbers;
Of course.
This is about as cute as it gets:
$ave = ${reduce( bless( \(((ref(^x)?$^x*ref(^x):^x)+^y)/((ref(^x)||1)+1)),
1 - 100 of 1098 matches
Mail list logo
