Re: Dallas.p6m
On Mar 18, 2009, at 5:26 PM, fREW Schmidt wrote: s1n and I decided that we would start Dallas.p6m as we are close to each other geographically speaking. We are meeting tomorrow (Thursday, March 19, 7:00PM) at a coffee shop with free wifi. The address is 985 W Bethany Dr Allen, TX 75013. I live in Allen, so might be there. That address is where Market Street is right? What is the name of the coffee shop? Graham.
Re: Temporal changes
On Feb 23, 2009, at 3:56 PM, mark.a.big...@comcast.net wrote: Instant Moment Point PointInTime Timestamp Event Jiffy Time Juncture
Re: WTF? - Re: method calls on $self
On Thu, July 14, 2005 10:47 am, Autrijus Tang said: If this were a straw poll, I'd say... 1. Meaning of $_ .method should mean $_.method always. Making it into a runtime error is extremely awkward; a compile-time error with detailed explanataion is acceptable but suboptimal. 2. Topicalization of $?SELF Neutral on this -- I can argue bothways. in my limited experience of writing p6 code, it is convenient but somewhat confusing to topicalize the invocant. 3. Shorthand of $?SELF.method I find ./method to be very useful in practice, and my brain gets use to it rather quickly. The association to pattern matching and division gradually fades away, at which time its novelty cease to be a problem. I have been watching perl6-language from afar and not really contributing. But I have to say that in this case I do agree with Autrijus Graham.
Re: Open and pipe
On May 4, 2005, at 8:13 AM, Uri Guttman wrote: AS Why? Because IO::Socket.new takes parameters that are built out of its AS entire inheritance tree, so a change to IO::Handle might radically AS modify the signature of the constructor. makes sense. we should look at the p5 IO:: tree and see what we want to salvage/savage from it as well as io::all. each has its good and bad points and hopefully we can figure out which is which. :) Yes. p5 IO:: has evolved a bit over time and some things have turned out to be bad choices in hindsight. For example, one thing I am still not convinced was the right thing was to create a hierarchy such that a given class only had methods that were valid for it. For example the recent issue on p5p with seek etc not being in IO::Handle but IO::Seekable and the core using IO::Handle. Also the way IO::Socket::* was done instead of all sockets created by IO::Socket-new these are all things that should be reconsidered and I am sure in all cases there will be people on both sides of the fence Graham.
Re: use English
On Apr 27, 2005, at 6:39 AM, Aaron Sherman wrote: On Tue, 2005-04-26 at 10:48, Luke Palmer wrote: Aaron Sherman writes: The reasons I don't use English in P5: * Variable access is slower Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster. (Actually they're the same: on each run a different one won, but just barely like this). Remember that I'm a Perl 3 programmer who has just gotten used to this 5 thing... ;-) I sometimes lose track of the ugly hacks that have been rationalized into workable practice over the versions. use English used to require an extra level of indirection in the implementation, but clearly no longer does. I don't have a perl older than 5.6.1 to test against, but this was probably back in the 5.002 or 5.003 timeframe. I'm guessing. It is also the fact that English.pm mentions $' and $` and that any mention of those variables flips a global switch inside perl which causes *every* regex with capturing parens to be slower. See http://search.cpan.org/~nwclark/perl-5.8.6/pod/perlvar.pod#BUGS Graham.
Re: Return with no expression
On 24 Aug 2004, at 22:14, Aaron Sherman wrote:
You don't HAVE to use auto-topicalization. You CAN always write it
long-hand if you find that confusing:
for @words - $word {
given ($chars($word) 70) - $toolong {
say abbreviate($word) ?? $word;
}
}
But, I find:
for @words - $word {
say $word ~~ abbreviate($word) ?? $word;
}
much simpler! Overall, I would discourage the use of C$_ as topic in
most situations. We spent so long in Perl 5 wanting the ability to
default to whatever variable we wanted, to keep using C$_ in the
general case now that we have that is kind of a step backwards.
But you are re-creating the same problem that we had in Perl 5.
By only allowing $_ to decide which expression to evaluate you are
prohibiting the use of anything that acts on the default topic of
the enclosing block in those expressions. This is exactly the problem
of nested maps etc. in Perl 5.
Don't get me wrong, I like the idea. But it does not come without its
own set of limitations.
Graham.
Re: L2R/R2L syntax
On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
What benefit does C ~ bring to the language?
Again, it provides not just a null operator between to calls, but
rather a rewrite of method call syntax. So:
map {...} ~ grep {...} ~ @boing;
is not:
map {...} grep {...} @boing;
But rather:
@boing.map({...}).grep({...});
This is not a for or against, but there is something that has been
bugging me about this.
Currently in Perl5 it is possible to create a sub that has map/grep-like
syntax, take a look at List::Util
If the function form of map/grep were to be removed, which has been suggested,
and the ~ form maps to methods. How would you go about defining a utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?
Graham.
Re: L2R/R2L syntax
On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote: On Tuesday, January 21, 2003, at 02:04 AM, Graham Barr wrote: If the function form of map/grep were to be removed, which has been suggested, and the ~ form maps to methods. How would you go about defining a utility module similar to List::Util that uses the same syntax as map/grep but without making the subs methods on the global ARRAY package ? If you want the method to be available everywhere, But I don't you probably _should_ make it a method of the global Array class. Thats like trying to wite a whole perl5 application in main without any packages More typically, perhaps, you'd only be using your new method to operate on certain arrays that you use, in which case you would make a new class for those particular arrays, so your new method would work only on the specific arrays you intended it to: Thats not always possible. Those Arrays may be passed to me from somewhere else, so I have no control over thier class. I don't see any problem (other than maybe a philosophical objection) with making them methods of Array, though, if they're valuable enough. That certainly would seem the common Perl thing to do. No, namespaces were invented for a reason. Graham.
Re: L2R/R2L syntax
On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote: [EMAIL PROTECTED] (Mr. Nobody) writes: I have to wonder how many people actually like this syntax, and how many only say they do because it's Damian Conway who proposed it. And map/grep aren't specialized syntax, you could do the same thing with a sub with a prototype of (block, *@list). Well, I'll go record and say I think it's Bloody Silly. It's over-cutesy, adding syntax for the sake of syntax, doesn't do anything for the readability of code, and doesn't really actually gain very much anyway. That I will agree with to some extent. But mainly because I think that IF a pipe-like syntax is added then it should do just that, pipe. What has been proposed is not a pipe, unless each part gets converted to a co-routine and its arguments are really an interator that calls the previous stage to get the next argument. But even so I dare say it'll go in because Damian likes it. That statement I dont agree with. Yes Larry has put a lot of trust in Damian, but that has not resulted in Damian always getting what he wants, just most of the time :-) Graham.
Re: purge: opposite of grep
On Fri, Dec 06, 2002 at 09:33:14AM -0500, Miko O'Sullivan wrote: For example, suppose I want to separate a list of people into people who have never donated money and those who have. Assuming that each person object has a donations property which is an array reference, I would want to classify them in this manner: (@nevers, @donors) := classify($_-[donations]) @people; According to the Cint model, that would give me people who have donated zero times, and people who have donated once, and the people who have donated more than once would be lost. Then turn donations into a boolean. (@donors, @nevers) := classify(!$_-[donations]) @people; I don't think there is the need to bloat the langauge with every special case we can think of. Graham.
Re: [RFC] Perl6 HyperOperator List
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote: Yesterday Aaron Crane wrote: Jonathan Scott Duff writes: @a `+ @b In my experience, many people actually don't get the backtick character at all. Yes. I think that might be a good reason _for_ using backtick in vector operators: A pair of backticks could be used if the vector-equals distinction is required: @a `+`= @b; @a `+=` @b; Thats ugly, IMO. Now this is going to sound wild (probably) and I have not thought too much about it and there are probably others who can see the pitfalls quicker then me. But could () be available for hyper operators ? I will sit back now and watch the firewaorks, as I wont be in the UK on Nov 5 :-) Graham.
Re: [RFC] Perl6 Operator List, Take 5
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote: unary (prefix) operators: \ - reference to * - list flattening ? - force to bool context ! - force to bool context, negate not - force to bool context, negate + - force to numeric context - - force to numeric context, negate +^- force to numeric context, complement ~ - force to string context ~^- force to string context, complement Noe that we have gained ^ back from being a hyeroperator, could we not have ^ as a polymorphic complement operator. It can always be combined with ~ or + to force context, eg $a = ^ +$b; $a = ^ ~$b; We would then have a complement operator that I would assume objects could overload and do whatever they liked with. Graham.
Re: [RFC] Perl6 Operator List, Take 5
On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s Graham.
Re: plaintive whine about 'for' syntax
On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote: *shrug* You may not like the aesthetics, but my point still stands: is rw is too long for something we're going to do fairly often. I am not so sure. If I look back through a lot of my code, there are more cases where I use the variable in a read-only fashion than I do for modifying the value. Graham.
Re: Perl6 Operator List, Take 3
On Mon, Oct 28, 2002 at 03:30:54PM -0600, Jonathan Scott Duff wrote: On Mon, Oct 28, 2002 at 01:19:05PM -0800, Michael Lazzaro wrote: On Monday, October 28, 2002, at 01:09 PM, Larry Wall wrote: No. unless reads well in English. How do your read $a ! $b ! $c? nor? Maybe it's $a nor $b? oh no! You've said nor, so now I have have to ask about nand ... and the next thing you know perl takes over the world of circuit design. :-) Then dont forget full tristate logic too :) Graham.
Re: Private contracts?
On Fri, Oct 11, 2002 at 05:50:55PM -0700, Larry Wall wrote: On Sat, 5 Oct 2002, Allison Randal wrote: : use Acme::N-1_0; # or whatever the format of the name is I don't see why it couldn't just be: use Acme::1.0; I agree thats better. But why not separate the version more by using a different separator than :: between the module name and the version. Or even something like use Acme[1.0]; After all, we don't have package names starting with numbers right now... Er, we do. http://search.cpan.org?perldoc?Pod::Simple::31337 It would seem that (currently) only the top-level namespace may not start with a number. But I would also not that CPAN only has 3 such modules, all by the same author and all ::31337 Graham.
Re: auto deserialization
On Sat, Aug 31, 2002 at 01:52:18PM +, Damian Conway wrote:
I'd suggest that redundancy in syntax is often a good thing and
that there's nothing actually wrong with:
my Date $date = Date.new('June 25, 2002');
I would say it is not always redundant to specify the type on both
sides
my Dog $dog = Greyhound.new('black');
And, furthermore, that you could easily define special semantics
for void-context constructor calls via undef'd but typed variables,
so that you could just write:
(my Date $date).new('June 25, 2002');
So that would be creating special case syntax for
a specific case of a general issue.
Graham.
Re: perl6-language@perl.org
On Thu, Aug 01, 2002 at 06:02:14PM -0400, Miko O'Sullivan wrote:
This is a small collection of ideas for the Perl6 language. Think of this
posting as a light and refreshing summer fruit salad, composed of three
ideas to while away the time during this August lull in perl6-language.
Give split an option to keep the delimiters in the returned array
I often find that I want to split an expression, but I don't want to get rid
of the delimiters. For example, I've been parsing a lot of SQL lately, and
I find myself needing to split expressions like this:
rank=?
It would be really groovy if that expression could be split with the
delimiters in place, something like this:
tokens = split _/[?=*-+]/, $sql, keep='all';
Try using
tokens = split /([?=*-+])/, $sql;
and get back an array with these values: ('rank', '=', '?')
But that raises a problem: what if the expression is this (note the spaces):
rank = ?
In that case I would want the = and ? but I wouldn't want the spaces. A
slightly different option could keep just stuff in parens:
tokens = split /\s*([?=*-+])\s*/, $sql, keep='parens';
tokens = split /\s*([?=*-+])\s*/, $sql;
already does, in perl 5, what you want.
Graham.
Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening
On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote: Sean O'Rourke [EMAIL PROTECTED] wrote: languages/perl6/README sort of hides it, but it does say that If you have Perl = 5.005_03, $a += 3 may fail to parse. I guess we can upgrade that to if you have 5.6, you lose. I notice that DBI no longer supports Perl releases 5.6. Seems enough people are happy that 5.005 is obsolete. I am not sure I agree with that. I have been met with a lot of resistance from users todo the same with my modules. Some even still want 5.004, but thats asking too much IMO. Graham.
FIRST, BETWEEN, etc.. (was Re: Loop controls)
I have been following this thread, but I would just like to inject a summary
of the various related UPPERCASE blocks
PREExecutes on block entry.
Loop variables are in a known state
POST Executes on block exit.
Loop variables are in a known state
NEXT Executes on implicit block exit or call to next()
Loop variables are in a known state
LAST Executes on implicit loop exit or call to last()
Loop variables may be unknown
And I think this thread is proposing
FIRST A PRE block that is executed only on the first itteration
of the loop
BETWEEN A PRE block that does not execute for the first iteration
of the loop.
So FIRST and BETWEEN are just shorthand for
my $count;
loop {
PRE {
if ($count++) {
# BETWEEN code here
}
else {
# FIRST code here
}
}
}
Graham.
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
On Tue, May 07, 2002 at 12:27:08PM -0500, Allison Randal wrote:
On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
LAST Executes on implicit loop exit or call to last()
Loop variables may be unknown
Not exactly unknown. It's just that, in a few cases, their values may
have changed by the time the LAST block is executed.
OK, unspecified.
And I think this thread is proposing
FIRST A PRE block that is executed only on the first itteration
of the loop
BETWEEN A PRE block that does not execute for the first iteration
of the loop.
So FIRST and BETWEEN are just shorthand for
my $count;
loop {
PRE {
if ($count++) {
# BETWEEN code here
}
else {
# FIRST code here
}
}
}
Almost. What people are pushing for is more like:
BETWEEN A NEXT block that does not execute for the last iteration
of the loop.
IMO, it cannot. That is because you cannot always know if you are at
the end of a loop until you have executed the condition. Therefore BETWEEN
would have to be a PRE block.
This may seem like a trivial difference at first glance, but it's a
matter of scope. The latter interpretation means that code such as:
for 1..3 - $thing {
print $thing _ , ;
BETWEEN {
print $thing _ \n;
}
}
Will output:
1, 1
2, 2
3,
Not:
1, 2
2, 3
3,
But consider when this is a while loop, how do you stop BETWEEN being
called before the last iteration.
Which seems intuitively right.
Not to me :-)
Graham.
Re: // in Perl 5.8?
On Wed, May 01, 2002 at 12:17:52PM -0700, David Wheeler wrote: On 5/1/02 12:11 PM, Brent Dax [EMAIL PROTECTED] claimed: It's far too late to make it into 5.8, but it looks like it'll be in 5.10 when that comes out (in a year or two). I figured. Too bad. ;-) A year or two is long time to wait! Well if the patch maintains binary compatability, I dont see why it would not go into 5.8.1. But who knows when that will be. Graham.
Re: // in Perl 5.8?
On Wed, Apr 17, 2002 at 01:09:43PM -0700, David Wheeler wrote: Anyone know what the chances are that some enterprising C hacker can/will/did get the // and //= operator into Perl 5.8? Seems like it wouldn't be a huge deal to add, and I'd love to have it sooner rather than later. It is not hard todo. If you look in the archives you can probably find it, although it will be there as ?? The problem with // is that it already has a meaning and although perl6 will redefine it can we do so in perl5 ? I don't think we can. Graham.
Re: How to default? (was Unary dot)
On Fri, Apr 12, 2002 at 09:26:45AM +0100, Piers Cawley wrote:
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec Done!;
sub printRec {
chomp;
print :$_:\n;
}
You could take advantage of subroutine signatures and multi-dispatch
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
Hm, I wonder if
sub printRec($rec=$_) { ... }
or someother way to specify that the current topic be used
as a default argument, might be possible
Graham.
Re: Unary dot
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?
Graham.
Re: Some Apocalypse 4 exception handling questions.
On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote: I think you just said the same thing I did. To be more explicit, using the terminology you seem to want to use, I'll point out that I was only talking about the case of an inherited method, not a _replacement_ method. In other words, when you inherit a method, you are taking the base implementation for that method. But if you replace a method, you are not inheriting that method, but rather replacing it; yes, the replacement method may choose to call the base implementation's method as part of the replacement implementation. When you replace a method, you have 2 subroutines, the base implementation, and the replacement implementation, but when you inherit a method, you have only 1 subroutine, which may be called 2 different ways. But the base class may be just an interface class. And thus by inheriting the pre conditions you are enforcing the API. So I can see a use for it, but I can also see where you don't want it too. Graham.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote:
: What's the chance that it could be considered so?
In most other languages, you wouldn't even have the opportunity to put
a declaration into the conditional. You'd have to say something like:
my $line = $in;
if $line ne { ... }
Since
if my $line = $in { ... }
is Perl shorthand for those two lines, I don't see how one can say that
the variable is more related to the inside than the outside of the block.
One can claim that the code after the Cif may not be interested in
C$line, but the same is true of the block itself! The conditional
only decides whether the block runs. It's not part of the block.
But are we not at risk of introducing another form of
my $x if 0;
with
if my $one = ONE {
...
}
elsif my $two = TWO {
}
if ($two) {
...
}
Graham.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 03:58:49PM -0500, Michael G Schwern wrote:
On Mon, Jan 21, 2002 at 03:43:07PM -0500, Damian Conway wrote:
Casey wrote:
So you're suggesting that we fake lexical scoping? That sounds more
icky than sticking to true lexical scoping. A block dictates scope,
not before and not after. I don't see ickyness about making that so.
Exactly!
What we're cleaning up is the ickiness of having things declared outside
the braces be lexical to the braces. *That's* hard to explain to beginners.
In this case I'll take long-term simplicity over short-term
easy-to-explain rules. Otherwise we'll be writing this all over the
place til Kingdom come.
do {
if my $foo = bar() {
...
}
}
If that is what you want then fine. But I have lost count of the number
of times I have wanted to do
if ((my $foo = bar()) eq 'foo') {
...
}
if ($foo eq 'bar') {
...
}
Personally I really don't see it as a problem.
Graham.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
Graham Barr writes:
: But are we not at risk of introducing another form of
:
: my $x if 0;
:
: with
:
: if my $one = ONE {
: ...
: }
: elsif my $two = TWO {
: }
:
: if ($two) {
: ...
: }
Then it's just undefined. It's no different from how , ||, or ??::
work when you put a declaration in something that's conditionalized.
Right. So we need to make sure that the implementation does that. In Perl5
my has a runtime part, so if it is not actually run then the lexical
can hold the value of the previous time it was executed.
Graham.
Re: Apoc4: The loop keyword
On Mon, Jan 21, 2002 at 01:38:39PM -0800, Larry Wall wrote:
Graham Barr writes:
: On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
: Graham Barr writes:
: : But are we not at risk of introducing another form of
: :
: : my $x if 0;
: :
: : with
: :
: : if my $one = ONE {
: : ...
: : }
: : elsif my $two = TWO {
: : }
: :
: : if ($two) {
: : ...
: : }
:
: Then it's just undefined. It's no different from how , ||, or ??::
: work when you put a declaration in something that's conditionalized.
:
: Right. So we need to make sure that the implementation does that. In Perl5
: my has a runtime part, so if it is not actually run then the lexical
: can hold the value of the previous time it was executed.
Well, true enough. Perhaps undefined is too meaningful. We could
borrow a phrase from Ada culture and just call it erroneous.
Either that, or instead of my having a runtime element, we just initialize
all lexicals at the start of the block in which they are declared. So the
initialize step is not controlled by runtime effects.
I guess whether or not this (bug?) arises again depends on how parrot
implements lexicals.
Graham.
Re: [A-Z]+\s*\{
On Sun, Jan 20, 2002 at 05:29:39AM -0800, Damian Conway wrote: On Saturday 19 January 2002 22:05, Brent Dax wrote: Is this list of special blocks complete and correct? Close and close. As of two days ago, Larry's thinking was: BEGIN Executes at the beginning of compilation CHECK Executes at the end of compilation INITExecutes at the beginning of run END Executes at the end of run PRE Executes at block entry. Inherited if block is a method. No side-effects allowed. POSTExecutes at block exit. Inherited if block is a method. No side-effects allowed. NEXTExecutes on (explicit or implicit) call to next() within current block If a POST is inside a loop, is it executed at the end of each iteration or only when the loop exits ? If it is only when the loop exits, will it be possible to designate a block to be multiple (eg both POST and NEXT) Graham. CATCH Executes on exception within current block LASTExecutes on any form of block exit. Not inherited (c.f. POST), even if block is a method. Side-effects allowed. KEEPSpecialized form of CATCH. Executes on control exception in the current block UNDOSpecialized form of CATCH. Executes on non-control exception in the current block Damian
Re: Apropos of nothing...
On Fri, Dec 14, 2001 at 06:39:02AM +1100, Damian Conway wrote: In the following code fragment, what context is foo() in? @ary[0] = foo() Scalar context. @ary[0] is a single element of @ary. To call foo() in list context use any of the following: (@ary[0]) = foo(); # Assign @ary[0] the first element returned @(@ary[0]) = foo(); # @ary[@(0)] = foo(); # @ary[0,] = foo(); # @ary[[0]] = foo(); # @ary[0] = @(foo()); # Assign @ary[0] a ref to the elems returned @ary[0] =()= foo(); # Hm, thats a change from perl5. In perl5 that would assign the number of elements returned from foo(). Is there a good reason for this change ? Graham. @ary[0] = [foo()]; # Damian
Re: flex perl mess
On Wed, Oct 24, 2001 at 09:06:14AM -0400, Aaron Sherman wrote:
On Tue, Oct 23, 2001 at 02:53:19PM +0200, Nadim Khemir wrote:
Don't we already have that in Perl 5?
if ( /\G\s+/gc ) {# whitespaces }
elsif ( /\G[*/+-]/gc ) { # operator }
elsif ( /\G\d+/gc ) {# term }
elsif ( /\G.+/gc ) { # unrecognized token }
Tad McClellan
The answer is NO, regexes and a lexer are totally different. I would
recommend Tad to study a bit more what parsing is before thinking it's jut
about writing regexes. Having a lexer allows perl do some kind of text
processing (raw lexing and parsing) at a much faster. If it is of some
interest I could benchmark a simple example.
So, aren't you saying, yes, but it would be slow? I can't think of
anything a lexer is capable of that I can't (and probably haven't) done
in Perl with relative ease.
Now, if you want a PARSER, that's a different matter, but a simple
lexical scanner is trivial to write in Perl with logic and regular
expressions.
In terms of speed, this is particularly ideal because you can identify
what parts of your Perl code slow the lexer down, and re-code those
using C/XS. The best of all 2,384 worlds... that's Perl!
I have always found that the perl output from byacc (with a few tweaks)
generates a sufficient parser. The addition of a switch statement
will hopefully make it more efficient.
For a lexer I try to use a single regex with /g, but that does require the
text being parsed to be all in a single scalar. Although that could be
worked around if needed.
For an example, take a look at Convert::ASN1
Graham.
Re: Per-object inheritance in core a red herring?
On Fri, Jun 29, 2001 at 08:59:59AM -0400, John Porter wrote: Michael G Schwern wrote: Second, and perhaps more importantly, we can do this perfectly well with a module. No hacks, no tricks, no filters. Class::Object uses the mini-class technique (ie. auto-generated classes Sorry, that sounds like a hack/trick if ever there was one. I would sure hope there would be a cleaner way to do it in perl6, if it's not part of the core language. Maybe, but I think it is the way to do it, even if it is behind the scenes. My reason for that is method lookup. Right now we use the package (class) stash as a cache so we don't have to search @ISA for every method call. But if there is a case where not all objects that inherit from a given class have the same superclasses, you cannot do this. This means that we will either burn a lot more memory for the caches or method lookup will take longer. It's also not without its faults. Having every instance of a class have different values of ref() could be obnoxious, for example. That could be preserved by the object holding a pointer to it's blessed stash and its method stash, which for the most case will be the same. Graham.
Re: Coupla Questions
On Mon, Jun 11, 2001 at 10:39:51PM -0500, David L. Nicol wrote:
Hopefully, we'll get a with operator and everything:
with %database.$accountnumber {
.interestearned += $interestrate * .balance
}
anything short of that, in my opinion, is merely trading old ugly for
new ugly.
Now I may be wrong here, but I thought I remembered something about
.foo being the same as $_.foo
In which case you could do
for (%database.$accountnumber) {
.interestearned += $interestrate * .balance
}
Graham.
Re: suggested properties of operator results
On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote: For the record, bwarnock pointed out to me that damian allready proposed this behavior in RFC 25... http://dev.perl.org/rfc/25.html That RFC doesn't suggest having the comparison operators set properties on their result -- instead it recomends that multiple chained comparisons should be automagically expanded to the equivalent binary conjunction. ... I think I like his way better. Mainly because I didn't consider the ramifications of scenerios like this... $input = 4; $bool = $input 22;# $bool = 1 is valueR(22) print ok! if $bool == 1; # whoops, '==' is looking at $bool.valueR Well perhaps $input 22 should yield 22 is true Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 08:15:46AM +0100, Simon Cozens wrote:
On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
Damian Conway wrote:
$ref.{a}can be $ref{a}
which can also be
$ref.a
Dereferencing a hashref is the same as accessing a property?
IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.
So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}
This would have the benefit of not loosing encapsulation and
also the performance of not having to call a method which would
just look like
sub a(Foo $self) :lvalue { $self-{a} }
(Did I get that syntax right ? probably not :)
Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote: So, to match $foo's colour against $bar, I'd say $bar =~ /$foo.colour/; No, you need the sub call parens as well: $bar =~ /$foo.colour()/; Hm, I thought Larry said you would need to use $() to interpolate a method call. So this would be $bar =~ /$($foo.colour)/; Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote: So, to match $foo's colour against $bar, I'd say $bar =~ /$foo.colour/; No, you need the sub call parens as well: $bar =~ /$foo.colour()/; Hm, I thought Larry said you would need to use $() to interpolate a method call. So this would be $bar =~ /$($foo.colour)/; That was not my understanding. At least not for (pseudo-)method calls. But with the above you still have abiguity, for example what does this do $bar =~ /$foo.colour($xyz)/; I may be remembering about interpolation into strings as $file.ext is going to be common. But I do think the $() approach is clean and unambiguous Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote: But with the above you still have abiguity, for example what does this do $bar =~ /$foo.colour($xyz)/; Looks like a method call with parens, so *is* a method call with parens. I may be remembering about interpolation into strings as $file.ext is going to be common. But I do think the $() approach is clean and unambiguous I agree wholeheartedly. Good. But it's not as *convenient* as unadorned interpolation. Sometimes convenient has to give way Expecially if we expect method calls to be frequently interpolated. I don't hear people screaming because it's difficult in perl5, so I doubt it will be very frequent. But even the $() is easier than the current perl5 way to do it. Graham.
Re: Coupla Questions
On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote: [EMAIL PROTECTED] writes: : What should $foo = (1,2,3) do now? Should it be the same as what : $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what : $foo = \@INC; does now.) Putting it another way: does a list in scalar : context turn into a reference, or is it just arrays that do that? : : Just arrays, I believe. That hasn't actually been decided yet. There are good arguments on both sides. Can someone post a few ? I am open to what are the pros/cons but right now my mind is thinking Whats the benefit of making $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something different, ie what it does in perl5 Graham.
Re: Coupla Questions
On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote: On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote: Can someone post a few ? I am open to what are the pros/cons but right now my mind is thinking Whats the benefit of making $a=(1,2,3); be the same as $a=[1,2,3]; when it could do something different, ie what it does in perl5 A reason against making the behaviours ($foo=array vs. $foo=list) different would be that you're then making lists and arrays more distinct than necessary. Does this make $foo a reference, or the number of elements: But if you change () consider, how do you do $min = (localtime(time))[1]; and if () creates a reference what does $x = (1 + 2) * 3; it's still () in a scalar context. IIRC when Larry covered this, he did not suggest changing (), but changing the meaning of the , in the scalar context. () is a grouping contruct, not a list generator. Graham.
Re: properties
On Tue, May 22, 2001 at 12:29:33PM +1000, Damian Conway wrote:
if so, then wouldn't it be safer to put properties inside a special object
associated with each object (the 'traits' object) so there would be little
namespace collision?
We actually want the possibility of that kind of namespace collision:
for polymorphism.
Many people keep bringig this up as a confusion and you give the same reply.
However there has not yet, AFAIK, been any description of how having a method
overload a property is useful.
If there is some compelling reason that this is a must, then fine. But many
people seem to be finding this a point of confusion.
Personally I don't see that the gain is greater than the confusion. I would
rather see properties be accessed via a different operator other than dot (.)
If a class wants to manipulate a property via a method they still can, the user
just has to call the method instead of accessing the property directly
With the current approach I can see most code accessing properties with $var.prop{name}
because they want to make sure they get the property and not a method, whereas
it would be shorter, in the common case, to have something like $var'name
Graham.
Re: properties
On Sun, May 20, 2001 at 01:24:29PM +0100, Simon Cozens wrote: On Sun, May 20, 2001 at 12:46:35AM -0500, Jonathan Scott Duff wrote: my $a is true = 0; # variable property my $a = 0 is true; # variable property my ($a) = 0 is true;# value property Wow. Totally ETOOCONFUSING. That has been exactly my thought as I have been reading this thread. I have been trying to think what properties would make sensible variable or value properties. So far all I can think of for variable properties are actually compile time properties like constant etc. So I am left wondering how much of an issue this really will be ? Graham.
Re: properties
On Sun, May 20, 2001 at 06:19:35PM -0400, Uri Guttman wrote:
DC == Damian Conway [EMAIL PROTECTED] writes:
DC return undef Because($borked);
hmm, that is poor code as returning a real undef will break in a list
context.
I always balk when I see someone say that. This is perfectly valid thing todo.
If the sub is defined to return a single scalar value then Creturn; is
the WRONG thing todo as it will cause problems if the result is used directly
into a list.
so how would a value property be attached passed back to an
empty list? what happens below:
Thats a good point. But on the other hand an empty list is neither
a variable or a value. You are returning nothing, so there is nothing
to attach it too.
But with the ability to return arrays in perl6 you should probably return
an empty array with a property attached.
perm_props( $foo, 'SortCode' ) = 'ST' ;
the last one assigns the prop value with an lvalue call.
If perm_props returns a hash, then you could also do
perm_props( $foo ){'SortCode'} = 'ST' ;
Graham.
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote: print keys $foo.prop; # prints NumberHeard print values $foo.prop; # prints loneliestever This is an example of one of my concerns about namespace overlap with methods. What would happen if there was a method called prop ? Have we basically said that there cannot be a method called prop ? Personally I would rather see something other than . for accessing properties. As things stand the functionality of a working program can be completely changed/broken by defining a sub that conflicts with a property. Graham.
Re: 'is' and action at a distance
On Sat, May 19, 2001 at 06:41:29PM +1000, Damian Conway wrote: Graham wrote: On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote: print keys $foo.prop; # prints NumberHeard print values $foo.prop; # prints loneliestever This is an example of one of my concerns about namespace overlap with methods. What would happen if there was a method called prop ? Have we basically said that there cannot be a method called prop ? No, we have basically said that there cannot be a method called prop if you want to access the object's properties through its prop property. Which mean that any class which defines a method prop, prevents any user from determining the properties of any of its object instances. I am not saying that this is a bad thing, but it will need to be docuemnted that doing this has such consequences. Unless there is another syntax for determining all the properties of a value. Personally I would rather see something other than . for accessing properties. As things stand the functionality of a working program can be completely changed/broken by defining a sub that conflicts with a property. Er...yes...that's rather the point of the exercise: to be able to polymorphically override the behaviour of properties by defining methods. I am just not conviced that it is a good thing todo. methods and properties are different things. Graham.
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 03:01:38PM +1000, Damian Conway wrote: Also, what's the difference between a 'property' and an 'attribute', ie, are: $fh is true; and $fh.true(1); synonyms? No. The former means: Set the true property to 1 and return an alias to $fh The latter means: Attempt to call the Ctrue method of $fh. If there is no such method, set the true property to 1 and return that value This is something that concerns me. There is no real separation between methods and properties. I can see it causing problems due to them sharing namespaces. But I have not thought about it enough to say how much of a concern. Graham.
Re: 'is' and action at a distance
On Fri, May 18, 2001 at 08:31:21AM -0500, Jarkko Hietaniemi wrote:
On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
--- Damian Conway [EMAIL PROTECTED] wrote:
It's probably just a matter of coding what you actually mean.
In Perl 5 and 6 your version means if $fh is true in *any*
possible way..., whereas you seem to want if $fh is defined,
which is:
Hmm. I can easily see this producing incomprehensible code when spread
across large systems. To wit, those developers used to 0 means false
Any feature is incomprehensible if one is not used to it. Pointers
in C are incomprehensible if one has never met the concept before.
Right, consider overloading.
As far as I understand one rationale behind the false (in Perl 5 terms)
but true (in Perl 6 terms) is that you can write code like this
if ($retval = func(@args)) {
# it worked ...
Right. Which of course can be done in Perl 5 with either 0 but true (or 0E0)
or if the value is an object, the use of overloading.
Graham.
Re: what I meant about hungarian notation
On Mon, May 14, 2001 at 12:32:37PM -0500, Me wrote: an ordered hash is common Arrays too. not wise ... to alter features just for beginners. Agreed. (PS 11 people isn't a statistic, its a night at the pub) Your round... The extra complexity of a separate hash syntax might be justified for other reasons, but not the ones given. Hm, OK. What does this access and using what method ? $foo = '1.2'; @bar[$foo]; Does it access the hash element 1.2 or the array element 1 ? Its not obvious and you cannot depend on what is in $foo, $foo = 1.2 should give identical results. and having to write @bar[$foo] or @bar[int $foo] is worse than what we have now. And solving this by saying that each variable must be declared to be hash or array does not help much as it moves the distinction from where it is useful to the reader to somewhere out of site. Having different brackets for accessing array or hash actually does help when reading code. Using the same is just adding unnecessary complexity Graham.
Re: what I meant about hungarian notation
On Mon, May 14, 2001 at 01:56:01PM -0500, Me wrote:
Hm, OK. What does this access and using what method ?
$foo = '1.2';
@bar[$foo];
This is an argument against conflating @ and %.
No it is not.
It has nothing to do with using [] instead of {}.
Yes it does. I was asking if the above is equivalent to
$bar[$foo] or $bar{$foo} in todays perl.
Having different brackets for accessing array or hash
actually does help when reading code. Using the same
is just adding unnecessary complexity
I can't tell if you mean this as a summary of your
earlier points, in which case please note response
above, or a separate point. If it is a separate point,
you don't say why, so, why?
I mean exactly what it says. Not using [] instead of {}
actually helps with readability.
Graham.
Re: what I meant about hungarian notation
On Mon, May 14, 2001 at 03:23:56PM -0400, Buddha Buck wrote:
At 08:10 PM 05-14-2001 +0100, Graham Barr wrote:
On Mon, May 14, 2001 at 01:56:01PM -0500, Me wrote:
Hm, OK. What does this access and using what method ?
$foo = '1.2';
@bar[$foo];
This is an argument against conflating @ and %.
No it is not.
It has nothing to do with using [] instead of {}.
Yes it does. I was asking if the above is equivalent to
$bar[$foo] or $bar{$foo} in todays perl.
What is the meaning of the following four expressions in Perl6?
@bar[$foo]; # A
%bar{$foo}; # B
@bar{$foo}; # C
%bar[$foo]; # D
You seem to be advocating A and B, Me is advocating A and D.
Why is one set better than the other?
You forgot
$bar[$foo]; # $bar is an array reference
$bar{$foo}; # $bar is a hash reference
Graham.
Re: what I meant about hungarian notation
On Mon, May 14, 2001 at 03:41:24PM -0400, John Porter wrote:
Damian Conway wrote [and John Porter reformats]:
@bar[$foo]; # Access element int($foo) of array @bar
%bar{$foo}; # Access entry $foo of hash %bar
@bar{$foo}; # Syntax error
%bar[$foo]; # Syntax error
And why is that superior to:
@bar[$foo]; # Access element int($foo) of array @bar
%bar{$foo}; # Syntax error
@bar{$foo}; # Syntax error
%bar[$foo]; # Access entry $foo of hash %bar
As I said in another mail, consider
$bar[$foo];
$bar{$foo};
Graham.
Re: what I meant about hungarian notation
On Mon, May 14, 2001 at 03:58:31PM -0400, John Porter wrote:
Graham Barr wrote:
As I said in another mail, consider
$bar[$foo];
$bar{$foo};
But if @bar is known to be one kind of array or
the other, where is the ambiguosity that that is
meant to avoid?
I did not say it was avoiding ambuguity, I said it helped
with readability when $foo held something like 1.2
But I really think this thread is going no where.
Is there REALLY a benefit in changing things to use only []
or is this change for the sake of change.
And rememeber this is still perl, so why change something unless
it gains extra benefit.
Graham.
Re: what I meant about hungarian notation
On Mon, May 14, 2001 at 02:51:08PM -0500, Me wrote: survey ? I never saw any survey, It was an informal finger-in-the-wind thing I sent to a perl beginners list. Nothing special, just a quick survey. http://www.self-reference.com/cgi-bin/perl6plurals.pl As someone else pointed out (I forget who). But beginners are not always the best people to ask. Beginner don't stay beginners for long I think the quote was. Graham.
Re: what I meant about hungarian notation
On Wed, May 09, 2001 at 02:04:40PM -0400, John Porter wrote: Simon Cozens wrote: A scalar's a thing. Just as the index into a multiplicity is a thing. Yes, but as Larry pointed out. Knowing if the index is to be treated as a number or a string has some advantages for optimization Graham.
Re: Apoc2 - Context and variables
On Mon, May 07, 2001 at 05:35:53PM -0400, John Porter wrote:
Edward Peschko wrote:
If
%a = @b;
does
%c = map{ ($_ = undef ) } @a;
Yep... particularly considering something neat like
keys(%a) = @b;
And what is wrong with
@a{@b} = ();
which I use all the time. But I guess in perl6 that would
be written as
%a{@b} = ();
Graham.
Re: Apoc2 - STDIN concerns
On Fri, May 04, 2001 at 07:56:39PM -0700, Larry Wall wrote: Nathan Wiger writes: : : This one. I see a filehandle in *boolean* context meaning read to $_, : : just like the current while (FOO) magic we all know and occasionally : : love. I'd expect $FOO.readln (or something less Pascalish) to do an : : explicit readline to a variable other than $_ : : It would be $FOO.next, but yes, that's the basic idea. It's possible : that iterator variables should be more syntactically distinquished than : that. One could, I suppose, make up something about $FOO or $FOO : meaning the same thing thing as $FOO.next, for people who are homesick : for the angles, but I haven't thought that out, and don't even dare to : mention it here for fear someone will take it as a promise. Er, oops... : : So, just to clarify, the thought is: : :print while ($FOO);# like Perl 5 FOO :$var = $FOO.next; # like Perl 5 $var = FOO; : : I assume that this is indicative of a more general iterator syntax, and : subject to indirect objects? : :$FH = open $file or die Can't open $file: $!; :$line = next $FH; : : If so, I can live with that. Yes, that's the reason it's Cnext, and not something more specific like Creadline, which isn't even true in Perl 5 when $/ is mungled. We do have to worry about the Cnext loop control function though. I don't know. If it had to be written as $FH.next then there should be no ambiguity. Graham.
Re: Apoc2 - STDIN concerns
On Sat, May 05, 2001 at 02:46:46AM +0100, Michael G Schwern wrote:
On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
I'm wondering what this will do?
$thingy = $STDIN;
This seems to have two possibilities:
1. Make a copy of $STDIN
2. Read a line from $STDIN
While perhaps inconsistent, I'd really rather it did #2. Here's the
basic argument... compare how often you dup a filehandle with how
often you read from one. Duping is swamped by several orders of
magnitude. Dup with $fh = $STDIN.copy; (or whatever). $line =
$STDIN.next should still work normally.
How would you pass a handle to a subroutine, or store it inside
a hash or array ?
sub my_read {
my $fh = shift; # whoops
}
I don't think it should do a dup(), but we do need to pass file handles around
Graham.
Re: Please make last work in grep
On Wed, May 02, 2001 at 11:10:22AM +0100, Michael G Schwern wrote:
On Wed, May 02, 2001 at 11:13:13AM +0200, Alexander Farber (EED) wrote:
I would like to propose adding the last statement
to the grep, which currently doesn't work:
For the record, I have no problem with this. :)
maas34: perl -e 'grep { print and $_ == 3 and last } (1,2,3,4,5)'
123
Can't last outside a loop block at -e line 1.
This way it would be possible to use such constructs:
FYI, its not hard to write a routine to do just that...
first { some_condition } @stuff;
See List::Util in perl-current
=item first BLOCK LIST
Similar to Cgrep in that it evaluates BLOCK setting C$_ to each element
of LIST in turn. Cfirst returns the first element where the result from
BLOCK is a true value. If BLOCK never returns true or LIST was empty then
Cundef is returned.
$foo = first { defined($_) } @list# first defined value in @list
$foo = first { $_ $value } @list# first value in @list which
# is greater than $value
Graham.
Re: Please make last work in grep
On Wed, May 02, 2001 at 04:30:07PM +0100, Michael G Schwern wrote:
On Wed, May 02, 2001 at 08:05:29AM -0700, Larry Wall wrote:
Michael G Schwern writes:
: (grep {...} @stuff)[0] will work, but its inelegant.
It's inelegant only because the slice doesn't know how to tell the
iterator it only needs one value. If it did know, you'd call it
elegant. :-)
I'd call it Haskel! I've just installed it and have been skimming the
docs.
Would be neat if: my($first) = grep {...} @list; knew to stop itself, yes.
Yes. This could probably fall out of the suggestion that wantarray (or want)
return how many elements are wanted in a list context
Graham.
Re: Please make last work in grep
On Wed, May 02, 2001 at 12:01:24PM -0400, Uri Guttman wrote:
GB == Graham Barr [EMAIL PROTECTED] writes:
GB On Wed, May 02, 2001 at 04:30:07PM +0100, Michael G Schwern wrote:
On Wed, May 02, 2001 at 08:05:29AM -0700, Larry Wall wrote:
Michael G Schwern writes:
: (grep {...} @stuff)[0] will work, but its inelegant.
It's inelegant only because the slice doesn't know how to tell the
iterator it only needs one value. If it did know, you'd call it
elegant. :-)
I'd call it Haskel! I've just installed it and have been skimming the
docs.
Would be neat if: my($first) = grep {...} @list; knew to stop itself, yes.
GB Yes. This could probably fall out of the suggestion that wantarray
GB (or want) return how many elements are wanted in a list context
provided the list was literal. if it is created via a function or an
expression then you have to pass the laziness and wantarray count up the
line, etc. i don't know if we (or larry) wants to make all code have a
maximum iteration/count value implicitly passed into them and have such
lazy evaluation at all times.
wantarray-ness is already passed along the call stack today. Thats
the whole point of it. So what is the difference in passing a number
instead of a boolean ?
How this cooperates with lazy is a different matter entirely.
Graham.
Re: Please make last work in grep
On Wed, May 02, 2001 at 06:29:51PM +0200, Bart Lateur wrote:
On Wed, 2 May 2001 17:05:31 +0100, Graham Barr wrote:
wantarray-ness is already passed along the call stack today. Thats
the whole point of it. So what is the difference in passing a number
instead of a boolean ?
Because you might have a wantarray situation that expects no values?
() = whateveryouwant();
I am sure that situation is handled by the 'want' RFC. I have not
read it recently, but I suspect in this case want('LIST') would
return that magical 0 but true or something similar.
You can always expect one more than is on the LHS.
How is this currently handled with split()?
split is special cased when it's assignment is directly to a list
of known length. The current perl does not pass wanted list lengths
around.
Graham.
Re: a modest proposal Re: s/./~/g
On Thu, Apr 26, 2001 at 03:35:24AM +, Fred Heutte wrote: Bart Lateur's response summarizes well what I've heard so far from responses both to the list and privately: (1) Yes, ~ *is* somewhat used in its current role as the bitwise negation (complement) operator. (2) No, that doesn't appear to overlap my proposal for its use as a successor to - as now used. You don't get it. We are not looking for a single char to replace - We WANT to use . Graham.
Re: Strings vs Numbers (Re: Tying Overloading)
On Wed, Apr 25, 2001 at 06:46:20PM +0100, Simon Cozens wrote: On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote: Doesn't ~ look like a piece of string to you? :-) It looks like a bitwise op to me, personally. That's because every time you've used it in Perl, it's been a bitwise op. Sapir-Whorf, and all that. Not just Perl. Many other languages use ~ the same as Perl does now. Graham.
Re: a modest proposal Re: s/./~/g
On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote: It seems to me that ~ relates to forces (operators, functions and methods) more than to atoms (scalars), so to speak. It's the curve of binding Perl at work here. So why not leave . alone and have ~ substitute for - $mydsn-Sql($mysqlstmt . $moresql) ; $mydsn~Sql($mysqlstmt . $moresql) ; Yes, I know ~ is the bitwise negation operator. Have you EVER used it? Yes, I use it a lot. Whether you use it probably depends on the kind of problems you try to solve with perl. Graham.
Re: Strings vs Numbers (Re: Tying Overloading)
On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote: At the moment I'm leaning toward ^ for concat, and ~ for xor. That I think that would lead to confusion too. In many languages ^ is xor and ~ is a bitwise invert. It is that way in perl now too, so perl is already quite standard in that area. Changing these just to get . for - so that we are more standard seems very strange as you are loosing two standards to gain one. To be honest though I don't think it is possible to get a single char concat operator with loosing something else, which is a shame. It would be good if we could somehow overload + to be both string and numeric, but I not sure that is possible. The other choice is not to have a concat operator but instead have Cconcat LIST, but I guess not many people would like that either. Graham.
Re: Tying Overloading
On Mon, Apr 23, 2001 at 01:02:50PM +0100, Simon Cozens wrote: Or we change the concatenation operator. $a = $b $c; # Do people really use Perl for bit fiddling? Yes, all the time. $a = $b # $c; /* Urgh */ $a = $b ~ $c; # Mmm! I like that last one a lot, because it doesn't disturb anything. You'd have to alter ~'s precedence so that binary ~ is higher than named unary operators. (It's print($a~$b), not print $a (~b).) I am not sure I do like the use of ~ here. It does not screan concatenate to me (but then again neither did . when I started perl) I am thinking that maybe it should be a 2 character operator with at least one of then being + as + is common in many other languages for doing concatenation. Graham.
Re: Tying Overloading
On Mon, Apr 23, 2001 at 02:31:55PM +0200, H.Merijn Brand wrote: On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr [EMAIL PROTECTED] wrote: $a = $b ~ $c; # Mmm! I like that last one a lot, because it doesn't disturb anything. You'd have to alter ~'s precedence so that binary ~ is higher than named unary operators. (It's print($a~$b), not print $a (~b).) I am not sure I do like the use of ~ here. It does not screan concatenate to me (but then again neither did . when I started perl) I am thinking that maybe it should be a 2 character operator with at least one of then being + as + is common in many other languages for doing concatenation. like ++ ? I don't think that would be a good choice. Try translating these statements $c = $a.++$b; $d = $a++.$b; Graham.
Re: Tying Overloading
On Mon, Apr 23, 2001 at 12:36:47PM -0400, Dan Sugalski wrote:
At 02:52 PM 4/23/2001 +0200, Davíð Helgason wrote:
H.Merijn Brand wrote:
$a = $b ~ $c; # Mmm!
I like that last one a lot, because it doesn't disturb anything.
You'd have to alter ~'s precedence so that binary ~ is higher
than named unary operators. (It's print($a~$b), not print $a (~b).)
I am not sure I do like the use of ~ here. It does not screan concatenate
to me (but then again neither did . when I started perl)
I am thinking that maybe it should be a 2 character operator with at
least one of then being + as + is common in many other languages
for doing concatenation.
Which of qw[~ ++ +~ + ] do we dislike the least? Using + would be
nice, but introduce no end of problems with number/sting behaviour. ''
is too much like a certain unpopular language. And there was no end to
the quabbling :(
What's wrong with something like:
$foo = $a :+ $b;
I was thinking along those lines too.
In fact it made me think of something Larry said (I think) about operators
operating on whole arrays. So :+ might be the addition of all elements, eg
@foo = @a :+ @b;
So if a leading : would mean the operator was an array operator, maybe we
could use something else for string operators (say ~). This would also help
disambiguate the difference of when its operands are numbers or strings
as would always be for numbers and ~ would be for strings. eg
$foo = $a + $b; # addition
$foo = $a ~+ $b; # concat
$foo = $a $b; # logical and of IVs
$foo = $a ~ $b; # bitwise and of PVs
@foo = @a :+ @b; # same as @foo = map { $a[$_] + $b[$_] } for 0..max($#a,$#b);
@foo = $a :+ @b; # same as @foo = map { $a + $b[$_] } for 0..$#b;
etc...
Graham.
Re: Tying Overloading
On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote: I do expect that @() and $() will be used for interpolating list and scalar expressions into strings, and it is probably the case the $() would be a synonym for scalar(). @() would then be a synonym for the mythical list() operator. Which probably, in Perl 6, turns out to be equivalent to [...] when used in a scalar context, and a no-op in list context. That is, $() and @() would essentially be typecasts. Hm, I would expect @() in a scalar context to give the same result as @tmp = @(...); $x = @tmp; That is, yeild the number of elements in the list. What would be the benefit of it being the same as [...] ? It would be one more character. Graham.
Re: s/./~/g
On Mon, Apr 23, 2001 at 01:16:57PM -0700, Larry Wall wrote: Branden writes: : I'm starting to be a bit worried with what I'm reading... : : 1) Use $obj.method instead of $obj-method : : : The big question is: why fix what is not broken? Why introduce Javaisms and : VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 : code (and Perl 5 programmers) for a zero net gain? It's not zero net gain, and I'm going to ignore the next person who says it. I agree it is not a zero net gain. But perhaps it needs to be spelled out for those who don't see the gain. Graham.
Re: Tying Overloading
On Mon, Apr 23, 2001 at 01:23:43PM -0600, Nathan Torkington wrote: Larry Wall writes: wanted, you still get the length. If you're worried about the delayed operation, you can force numeric context with $x = +@tmp;, just as you can force string context with a unary ~. How often are you likely to do this? Speaking as a reader of code, I've always hated unary + in that crocky this could be a block or an expression sense. I'd prefer a word operator: $x = numeric @tmp; Ig you are going to put a word there, then why not $x = length @tmp or $x = @tmp.length Graham.
Re: Larry's Apocalypse 1
On Thu, Apr 05, 2001 at 10:10:47PM +0100, Michael G Schwern wrote:
Then it might be easier to write modules that are testable without a test
driver. If you run the module directly, some distinguished block of code
could be executed that wouldn't be if the module were "included" via
"require" or "use" (or similar replacement constructs).
See also SelfTest.pm
I have not looked at SelfTest, but I have always done this with
unless (defined wantarray) {
# Self Test
}
This works because whenever a file is use'd, require'd etc. it is
evaluated in a scalar context. The main file is in a void context.
Graham.
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 01:31:40PM +0200, Paul Johnson wrote:
On Fri, Apr 06, 2001 at 10:01:47AM +0100, Graham Barr wrote:
unless (defined wantarray) {
# Self Test
}
This works because whenever a file is use'd, require'd etc. it is
evaluated in a scalar context. The main file is in a void context.
Although Gisle's recent patch changes this for "do" at least.
Hm, I did not see that. Can someone explain what the patch changed
or give me a link to the thread.
Graham.
Re: Larry's Apocalypse 1
On Fri, Apr 06, 2001 at 03:52:47PM +0100, Simon Cozens wrote: On Fri, Apr 06, 2001 at 03:48:11PM +0100, Graham Barr wrote: Although Gisle's recent patch changes this for "do" at least. Hm, I did not see that. Can someone explain what the patch changed or give me a link to the thread. @foo = do "you"; now works Ah OK. So I assume that do "you"; will do the file in a void context Graham. -- I will not suffer fools gladly, but I will gladly make fools suffer. -Bimmler
Re: Schwartzian Transform
On Wed, Mar 28, 2001 at 09:13:01AM -0500, Mark-Jason Dominus wrote:
So you can say
use Memoize;
# ...
memoize 'f';
@sorted = sort { my_compare(f($a),f($b)) } @unsorted
to get a lot of the effect of the S word.
Yes, and of course the inline version of this technique is also
common:
@sorted = sort { my $ac = $cache{$a} ||= f($a);
my $bc = $cache{$b} ||= f($b);
my_compare($ac,$bc);
} @unsorted;
Joseph Hall calls this the 'Orcish Maneuver'.
That does have the (slight) disadvantage that if f(x) returns
a false value then f(x) may be called multiple times. Of course
this can be fixed by using exists. It also has the overhead of
computing the hash value of a and b on every itteration
Personally I have found the fastest sort tends to be
my @f = map { f($_) } @unsorted;
@sorted = @unsorted[ sort { $f[$a] cmp $f[$b] } 0..$#f ];
Graham.
Re: End-of-scope actions: Background.
On Tue, Feb 20, 2001 at 03:49:13AM +, Simon Cozens wrote: On Mon, Feb 12, 2001 at 01:58:35PM -0700, Tony Olekshy wrote: Hi, it's me again, the guy who won't shut up about exception handling. I'm trying, I'm catching. And I'm thowing (up :) Graham.
Re: Autovivification behavior
This has been discussed on p5p many many times. And many times
I have agreed with what you wrote. However one thing you did not mention,
but does need to be considered is
func($x{1}{2}{3})
at this point you do not know if this is a read or write access as
the sub could do $_[0] = 'fred'. If this can be handled in someway
so that the autoviv does not happen until the assignment then OK,
but otherwise I think we would have to stick with perl5 semantics
Also we would probably need a use autoviv pragma so that perl5
scripts which are ported, and rely on the autivivify of hashes,
will still work as before.
Graham.
On Fri, Dec 22, 2000 at 03:26:03PM -0500, Deven T. Corzine wrote:
Can the autovivication behavior be changed slightly for Perl 6?
Specificly, can we suppress autovivication in read-only circumstances, and
evaluate the expression as "undef" immediately instead of autovivicating
empty data structures that didn't exist before?
The current behavior in Perl 5 is inconsistent. Attempting to reference a
hash or array element doesn't normally cause that element to spring into
existence, but attempting to reference substructures DOES suddenly cause
that substructure to spring into existence. This behavior is desirable
when writing to that substructure, but undesirable when reading from it,
and inconsistent with the normal behavior of single-level perl structures.
Referencing a nonexistent entry in a hash or array doesn't create that
entry UNLESS it's autovivified as a reference. "%x = (); $x{1};" does NOT
have the same effect as "%x = (1 = undef);"; why does "%x = (); $x{1}{1};"
have the same effect as "%x = (1 = {});"? If the programmer has never
stored any values into %x, it would be reasonable to expect it to remain
empty; why violate this reasonable expectation just because of an attempted
reference to a nonexistent structure?
Re: split() ideas
On Thu, Sep 28, 2000 at 01:02:11PM -0500, Jonathan Scott Duff wrote: I thought I had sent this the other day, but it doesn't appear to have made it through... Here are a couple of ideas that I don't have time to RFC, but some who likes them might: 1. Allow the first argument to split() to be a number such that the string is broken into chunks of that many characters. 2. Allow the first argument to split() to be an array of numbers, such that split returns a list of strings each as long as the corresponding number. Yes, I know this can be done with unpack() or substr(), but that's never stopped us before. Ah, but with them you would need a loop. One other way would be to allow \G to work in split() so you could do @ary = split(/\G(=..)/, $str) but then we can already do this with @ary = $str =~ /\G(..)/sg; Note that if #1 is adopted, $foo in "split $foo, $str" will no longer really mean "split /$foo/, $str". Right, and I think that the fact that there are already several ways to do it, we don't need to add another. Graham.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote: Russ Allbery wrote: Why on earth would you want to do this in real code? I wouldn't, of course. This is just a demonstration that I want both semantics available concurrently. If you are not going to use it, why implement it ? I don't believe you actually need both semantics active at the same time; I do. Need might be a slightly stronger word than necessary, but "want" and "convenience" sure come strongly to mind... the proposals to switch from one set of semantics to another just don't cut it for ease of use. How can you convince anyoone if you say you would not use it. For any feature enhancement to perl, unless there is a strong case for how it makes the labguage easier and better it is just not going to happen. Graham.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Tue, Sep 19, 2000 at 10:11:23PM -0700, Nathan Wiger wrote: undef null $a = undef; $a = null; $b = 1; $b = 1; $c = $a + b; $c = $a + $b; $c is 1 $c is null If you want different semantics for undef then use a pragma, that is what pragmas are for. use tristate; $a = undef; $b = 1; $c = $a + b; $c is undef I did mention this to Larry and his answer was, "you can do anything you like with pragmas" However I would suggest that many, including myself, would not like to see perls values have yet another state of null Graham.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 12:00:05AM -0700, Russ Allbery wrote: Perl already has exactly the data value that you're looking for. This RFC is proposing to fix the wrong problem; the things that need to be changed (conditionally) are the logical operators, not the data value. Absolutley, although I would not limit it to just the logical operators. Graham.
Re: RFC 262 (v1) Index Attribute
On Wed, Sep 20, 2000 at 08:05:20AM -0400, Webmaster wrote:
David Nicol Wrote in RFC 262:
foreach $item (@items){
#print "$item was at location ",$item:n,"\n";
print "$item was at location ${item:n}\n";
};
What would really be nice here is an Cindex function, similar to the
scalar version, that returns the index of the matching entry in a list. For
instance:
my $n=0;
foreach (@items){
print "Found It at position $n!\n" if /$seek/;
$n++;
}
Could be replaced by:
if (my $n = arrindex( @items, $seek )) {
print "Found It at position $n!\n" ;
}
Well if there ever is a way to shortcut grep this could be genera;ized
to
my $index = grep { break if $_ eq $seek; 1 } @items;
assuming `break' causes the shortcut
An therefore allowing more comparisons than just eq
Graham.
Re: RFC 262 (v1) Index Attribute
On Wed, Sep 20, 2000 at 09:03:39AM -0400, Webmaster wrote:
Graham Barr Wrote:
Well if there ever is a way to shortcut grep this could be genera;ized
to
my $index = grep { break if $_ eq $seek; 1 } @items;
Wouldn't this also assume that grep return the number of times the block was
NOT true,
But in that example the block is always true, thats what the 1 is for.
Graham.
Re: RFC 263 (v1) Add null() keyword and fundamental data type
On Wed, Sep 20, 2000 at 10:00:56AM -0700, Damien Neil wrote: On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote: Add null() keyword and fundamental data type I think that this is better done as a special overloaded object used Incidentally, I'm surprised that DBI hasn't added an option to use an overloaded null object, if this feature is in demand. Probably because of the performance hit it would have. Graham.
Re: RFC 76 (v2) Builtin: reduce
On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote: This RFC proposes a builtin Creduce function, modelled after Graham Barr's Creduce subroutine from builtin.pm Please refer to List::Util rather than builtin.pm the module name was changed as many did not like the name builting, as it was not. Graham. In all cases, the elements of the list are lazily evaluated. That is, any element of the list that is not a literal value is only evaluated when that element is passed to (and actually used by) the reduction subroutine. Should lists be lazy by default ? I would suggest that is a separate language issue then reduce and reduce should follow what all other list operators do. If the original list has no elements, Creduce immediately throws an exception. What do you mean by exception, die ? No other builtin dies like that at runtime. Perhaps a return of undef would be more like other operators. If the original list has a single element, that element is immediately returned (without ever calling the reduction subroutine). Otherwise, in a scalar context, the result of the final reduction call is the result returned by Creduce. In a list context, a list of all the interim values, plus the final value, would be returned. Um, if it is returning a list then it is not reducing, is it ? If the reduction subroutine is ever terminated by a call to Clast, the enclosing Creduce immediately returns the last reduction value -- or list of partial values -- to that point. If the Clast occurs during the first reduction, an exception is thrown. Again, no other builting currently throws an exception. If throwing an exception is to become the norm then that should be a separate RFC suggesting that builtins throw exceptions, but reduce should do what others do. Graham.
Re: RFC 255 (v2) Fix iteration of nested hashes
On Wed, Sep 20, 2000 at 07:06:21AM +1100, Damian Conway wrote:
This RFC proposes that the internal cursor iterated by the Ceach
function be stored in the pad of the block containing the Ceach,
rather than being stored within the hash being iterated.
Then how do you specify which iterator is to be reset when you wish
to do that? Currently, you do this by specifying the hash.
If the iterator is no longer affiliated with the hash, but the opcode node,
Just to note: in version 2 of the RFC, it's associated with the pad of
the block in which the Ceach appears.
So you are suggesting that the first itteration of the loop reset
the iterator. THis is because currently
%hash = ( aa = 1, bb = 2);
while(my($k,$v) = each %hash) { print $k,"\n" }
is no different to
foreach (1 .. keys %hash) {
while(my($k,$v) = each %hash) {
print $k,"\n";
last if $_ == 1;
}
}
No if the iterator is associated with the scope how do I reset it
so that the itterator always starts at the beginning each time
and not only when it is called after having reach the end on the
previous time
then what are you going to do?
The short answer is that there is no "manual" reset of iterators.
Then you loos the ability to exit and reenter a scope continueing where
you left off.
Graham.
Re: RFC 76 (v2) Builtin: reduce
On Wed, Sep 20, 2000 at 08:35:20AM +1100, Damian Conway wrote: No other builtin dies like that at runtime. Perhaps a return of undef would be more like other operators. That was my original proposal, but it was howled down by the mathematical elite, who vigorously insisted that it would break the fundamental mathematical properties of the entire Cosmos, leading to catastrophic rifts in the timespace continuum. Or something like that. Eventually, I gave in. Well mathematitions need to learn that not everything works in a mathematical way. Some things are just chaotic by nature. If the reduction subroutine is ever terminated by a call to Clast, the enclosing Creduce immediately returns the last reduction value -- or list of partial values -- to that point. If the Clast occurs during the first reduction, an exception is thrown. Again, no other builting currently throws an exception. If throwing an exception is to become the norm then that should be a separate RFC suggesting that builtins throw exceptions, but reduce should do what others do. Even at the risk of Destroying the Entire Universe??? What do others think? Ask me again tomorrow, I might change my mind :) Graham.
Re: RFC 76 (v2) Builtin: reduce
On Tue, Sep 19, 2000 at 04:06:00PM -0600, Tom Christiansen wrote: Why not just check @numbers? Well if the 'use trisate' pragma ever arises (did anyone RFC that ?) $a = 1; $b = undef; $c = $a + $b; $c is undef, not 1. Graham.
Re: RFC 223 (v1) Objects: Cuse invocant pragma
On Thu, Sep 14, 2000 at 08:10:54PM -, Perl6 RFC Librarian wrote: 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. One of the benefits I was hoping to get from having a variable hold the invocant is the ability for the invocant to be undef if the sub was not called as a method. Sadly this proposal does not address that :( Graham.
Re: Draft RFC: new pragma: Cuse namespace
I would suggest that anyone want to contribute to this discussion should first read the thread about the addition of this pragma to perl5 in the perl5-porters archives http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespace+pragmaerrors=0case=onmaxfiles=100maxlines=30 Graham.
Re: $a in @b (RFC 199)
On Mon, Sep 11, 2000 at 04:41:29PM -0500, Jarkko Hietaniemi wrote: Allow me to repeat: instead of trying to shoehorn (or piledrive) new semantics onto existing keywords/syntax, let's create something new. The blocks of grep/map/... are special. They are not quite looping blocks, they are not quite sub blocks, they are different. Well, to be frank they are just very plain, ordinary, blocks that return their last value, but if we want to introduce both flow control (short-circuiting) and as a derived requirement, a return value (was the last test a success or a failure), they definitely begin to become not your ordinary blocks. I do not think the existing arsenal of keywords/syntax is enough to cover all the behaviour we are after. The 'pass' keyword someone suggested has potential (when combined with allowing last -- and next -- to work on these mongrel blocks). Also it should be possible for someone to write thier own looping construct like map/grep as a sub and take advantage of this. Graham.
Re: RFC 193 (v1) Objects : Core support for method delegation
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote: The proposed delegation mechanism would work via a pragma: use delegation attr1 = [qw( method1 method2 method3 )], attr2 = [qw( method4 method5 )], attr3 = [], attr4 = [], # etc. ; This would cause method calls whose names match an element in the first list to be delegated to the "attr1" attribute of an object. Likewise, calls to a method whose name appears in the second list would be forwarded to the "attr2" attribute of the object. That is, calls like: $obj-method3(@args); $obj-method5(@other_args); Is this not just a module which creates the necessary subs in the calling package ? The catchall can be done with an AUTOLOAD sub. Graham.
Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword toforce list context (like Cscalar))
On Tue, Sep 05, 2000 at 11:16:48AM +1100, Damian Conway wrote:
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
}
And more correct as I would assume that
() = some_func();
sub some_func {
if ( ($num_to_return) = want 'LIST' ) {
# do stuff
}
}
$num_to_return would be zero, but the assignment would cause the if() to
be true.
Graham.
Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors
On Mon, Sep 04, 2000 at 11:09:18AM +0100, Piers Cawley wrote: Damian Conway [EMAIL PROTECTED] writes: 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. :-) I'm certainly not averse to a better name -- INIT would be ideal, if it weren't already spoken for -- but I think BLESS would be misleading. How about ONBLESS? Which admittedly suffers from not being a verb, but conveys the meaning rather well. I'm not entirely sure I *like* it, just tossing out another suggestion. Given that is happens when bless is called and that all other builtin methods are anmed after what is being called, not what it is being used for, then I would say that it should be called BLESS for consistancy reason. this may seem confusing because you are thinking of one particular use that you have in mind for this, but in a generic sense it is a method that is called when bless is called. Graham.
Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)
On Fri, Sep 01, 2000 at 11:23:16AM -0700, Steve Fink wrote: I read your message and agree. Not that I liked the idea that much even before considering the ramifications. But do you agree that even seasoned perlers have trouble anticipating how a list/array is going to be converted to a scalar? I would say the only place this is an issue is when the RHS is the return of a sub. You may not know if it was return (1,2,3) or return @a and there seems to be no standard way people document the difference. I'd vote for no Clist operator, but for adding a count operator and a last element operator. I suggest ()= for the first and Cpeek for the second. I wouldn't mind if the first were spelled Ccount, either. Tom, does this make sense, or am I confusing "lists" with "the comma operator in parentheses" again? perl already has a count operator, it is the only 4 charater non-alpha operator it has =()= :) Graham.
Re: Multiple for loop variables
On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
Peter Scott wrote:
Graham Barr once allowed as how he thought it would be neat if you could say
for my($x, $y, $z) (@list) { ... }
ObLanguageMinimalist:
Um. Is this so frequently-used that the above syntax is preferable to:
while ( ($x, $y, $z) = splice (@list, 0, 3) ) {...}
? (notwithstanding the destructive nature of splice)
Maybe not with 3 variables, but how many people do
my %hash = @_;
while(my($k,$v) = each %hash) { ... }
so that they can process named arguments ?
Having this would remove the need for the hash assignment. Also it hash been
suggested that it could potentially replace each
for my($k,$v) (%hash) { ... }
Also the ability to traverse multiple lists at once
for ($a,$b,$c) (zip(@a,@b,@c)) { ... }
And I should think many more uses I cannot think of.
Graham.
Re: error handling and syntax extension
On Wed, Aug 16, 2000 at 04:49:15PM -0500, David L. Nicol wrote:
or AUTOLOAD can be defined in terms of Ccatch
and overloaded that way, rather than being its own
kind of magic.
catch "AUTOLOAD-$classname-$polymorphicsignature" {...
But why should I have to know that a sub I want to call has to
be AUTOLOADed ? That is an implementation detail of a module
that I as a user should not need to know
Graham.
Re: RFC 109 (v1) Less line noise - let's get rid of @%
On Tue, Aug 15, 2000 at 05:10:34PM -0400, Dan Sugalski wrote: Let's not move backwards and force people to work like machines. Instead, lets force machines to work like us. I dred to think what kind of machine we would make :) Graham.
