Re: Vocabulary
Larry Wall wrote in perl.perl6.language : > On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote: >: When you say CHECK time, do you mean there'll be a CHECK phase for >: code that gets required at run time? > > Dunno about that. When I say CHECK time I'm primarily referring > to the end of the main compilation. Perl 5 appears to ignore CHECK > blocks declared at run time, so in the absence of other considerations > I suspect Perl 6 might do the same. This has proven to be inconvenient except for a few specialized usages, such as the B::/O compiler framework. There's a need (more or less) for special blocks that can be run at the end of the compilation phase of any arbitrary compilation unit.
[perl #24683] [PATCH] P6C update concat and bitwise operators
# New Ticket Created by Allison Randal
# Please include the string: [perl #24683]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=24683 >
This patch updates the following operators and their assignment
counterparts:
_ becomes ~ (concatenation)
& becomes +& ~& (bitwise AND, numeric and string)
| becomes +| ~| (bitwise OR, numeric and string)
~ becomes +^ ~^ (bitwise XOR, numeric and string)
Unary +^ (bitwise negation, a.k.a. ones complement) is not implemented
yet.
I've added two test files, bitwise.t and concat.t, which go in t/op/
(the op/ directory doesn't exist yet).
(My code for bitwise string operators was greatly simplified when Leo
implemented the bitwise_xors, bitwise_ands, and bitwise_ors (string
versions) vtable functions for PerlString. Hip-hip-hooray!)
Allison
Index: languages/perl6/P6C/Addcontext.pm
===
RCS file: /cvs/public/parrot/languages/perl6/P6C/Addcontext.pm,v
retrieving revision 1.21
diff -u -r1.21 Addcontext.pm
--- languages/perl6/P6C/Addcontext.pm 27 Nov 2003 19:43:20 - 1.21
+++ languages/perl6/P6C/Addcontext.pm 17 Dec 2003 01:07:07 -
@@ -40,13 +40,13 @@
# type => [list-of-ops].
my %opmap =
( # Ops that work differently for different scalar types:
-PerlUndef => [ qw(| & ~ // ..),
+PerlUndef => [ qw(| & +^ ~^ // ..),
# Unfortunately, these work differently on ints and nums:
qw(+ - * / % **)],
PerlInt => [ qw(<< >>) ],
-PerlString => [ qw(_) ],
+PerlString => [ qw(~) ],
# NOTE: Actually, according to apo 3, boolean operators
# propagate values in their surrounding context (even though
@@ -900,7 +900,7 @@
@ PerlArray
* PerlArray
$ PerlUndef
- _ PerlString
+ ~ PerlString
? bool
+ PerlNum);
}
Index: languages/perl6/P6C/IMCC.pm
===
RCS file: /cvs/public/parrot/languages/perl6/P6C/IMCC.pm,v
retrieving revision 1.30
diff -u -r1.30 IMCC.pm
--- languages/perl6/P6C/IMCC.pm 27 Nov 2003 19:43:20 - 1.30
+++ languages/perl6/P6C/IMCC.pm 17 Dec 2003 01:07:11 -
@@ -1341,16 +1341,6 @@
use P6C::Util ':all';
use P6C::Context;
-# Create generic code for $a op $b.
-sub simple_binary {
-my $x = shift;
-my $ltmp = $x->l->val;
-my $rtmp = $x->r->val;
-my $dest = newtmp 'PerlUndef';
-my $op = imcc_op($x->op);
-code("\t$dest = $ltmp $op $rtmp\n");
-return $dest;
-}
# '=' assignment op.
sub do_assign {
@@ -1392,12 +1382,14 @@
'>>' => \&simple_binary,
'<<' => \&simple_binary,
- '|' => \&simple_binary,
- '&' => \&simple_binary,
- '~' => \&simple_binary,
+ '+&' => \&simple_binary,
+ '~&' => \&simple_binary_pasm,
+ '+|' => \&simple_binary,
+ '~|' => \&simple_binary_pasm,
+ '+^' => \&simple_binary,
+ '~^' => \&simple_binary_pasm,
-# '_' => \&simple_binary, # PMC concat broken.
- '_' => \&do_concat,
+ '~' => \&do_concat,
'=' => \&do_assign,
'||' => \&do_logor,
'&&' => \&do_logand,
@@ -1413,7 +1405,7 @@
use vars '%op_is_array';
BEGIN {
-my @arrayops = qw(= .. x // ^^ && || _);
+my @arrayops = qw(= .. x // ^^ && || ~);
push(@arrayops, ',');
@[EMAIL PROTECTED] = (1) x @arrayops;
}
Index: languages/perl6/P6C/Parser.pm
===
RCS file: /cvs/public/parrot/languages/perl6/P6C/Parser.pm,v
retrieving revision 1.28
diff -u -r1.28 Parser.pm
--- languages/perl6/P6C/Parser.pm 27 Nov 2003 19:43:20 - 1.28
+++ languages/perl6/P6C/Parser.pm 17 Dec 2003 01:07:13 -
@@ -251,22 +251,23 @@
$VCLOSE= qr/<|[<>=!]=|<|>};
-$CONTEXT = [EMAIL PROTECTED]&*_?]|\+(?!\+)};
+$CONTEXT = [EMAIL PROTECTED]&*?]|\+(?!\+)|~(?![~\&\|\^])};
$MULDIV= qr{[\%*x]|/(?!/)};
$MATCH = qr{[=!]~};
$INCR = qr{\+\+|--};
-$PREFIX= qr{ [!~\\] |# logical negation '!', bitwise negation '~',
create a reference '\'
+$PREFIX= qr{ [!\\]|# logical negation '!', create a reference '\'
+ \+\^ |# unary bitwise XOR (bitwise negation)
\+(?!\+) |# posification '+', but not increment '++'
-(?![->]) # negation '-', but not decrement '--', but not
dereference '->'
}x;
-$ADDSUB= qr{[-+_]};
+$ADDSUB= qr{[-+~](?![\&\|\^])};
$BITSHIFT = qr{<<|>>};
$LOG_OR= qr{(?:x?or|err)\b};
$LOGOR = qr{\|\||\^\^|//};
-$BITOR = qr{(?:\|(?!\|)|~(?!~))};
-$BITAND= qr{&(?!&)};
+$BITOR = qr{(?:\|(?!\|)|[~\+][\|\^])};
+$BITAND=
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
On Tue, Dec 16, 2003 at 11:54:27PM -0500, Dan Sugalski wrote: > At 12:00 AM + 1/1/04, Allison Randal (via RT) wrote: > ># New Ticket Created by Allison Randal > ># Please include the string: [perl #24682] > ># in the subject line of all future correspondence about this issue. > ># http://rt.perl.org:80/rt3/Ticket/Display.html?id=24682 > > > > > > >I can't compile parrot on Mac OS 10.3.1 tonight. It's been about a week > >since I last compiled it, so it's a fairly recent change. The error > >message just before the compile dies is: > > > >... > >fastcall.o > >pcc.o > >cc -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm > >ld: warning -L: directory name (/usr/local/lib) does not exist > >ld: warning prebinding disabled because of undefined symbols > >ld: Undefined symbols: > >_Parrot_set_sighandler > >make: *** [parrot] Error 1 > > Try resync-ing with CVS, then reconfigure and build. The events patch > added more platform-dependent signal handling to parrot, and the > darwin files didn't get updated. (Since fixed) Excellent. It compiles now. I do have two failing tests which may be related (catching SIGFPE): Failed Test Stat Wstat Total Fail Failed List of Failed --- t/op/hacks.t2 512 22 100.00% 1-2 25 subtests skipped. Failed 1/59 test scripts, 98.31% okay. 2/1001 subtests failed, 99.80% okay.
Re: restore N via win32 CreateProcessA
On Tue, 16 Dec 2003 19:54:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: >At 11:38 PM + 12/16/03, Pete Lomax wrote: >>Hi, >>I've hit a very strange problem: >> >> set N18, 86 >> save N18 >> restore N18 Solved. I forgot I was using -O2 when executing via CreateProcessA, which I wasn't when running at the DOS prompt. Under -O2 the above code outputs: set N18, 86 save 86 restore N18 which explains things. I'll stop using -O2 (for now). Maybe pushing an int and popping a num should be allowed? Pete
Re: [perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
At 12:00 AM + 1/1/04, Allison Randal (via RT) wrote: # New Ticket Created by Allison Randal # Please include the string: [perl #24682] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=24682 > I can't compile parrot on Mac OS 10.3.1 tonight. It's been about a week since I last compiled it, so it's a fairly recent change. The error message just before the compile dies is: ... fastcall.o pcc.o cc -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm ld: warning -L: directory name (/usr/local/lib) does not exist ld: warning prebinding disabled because of undefined symbols ld: Undefined symbols: _Parrot_set_sighandler make: *** [parrot] Error 1 Try resync-ing with CVS, then reconfigure and build. The events patch added more platform-dependent signal handling to parrot, and the darwin files didn't get updated. (Since fixed) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #24682] [BUG] parrot compile fails on MacOS 10.3.1 - possibly dynaloading patch?
# New Ticket Created by Allison Randal # Please include the string: [perl #24682] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=24682 > I can't compile parrot on Mac OS 10.3.1 tonight. It's been about a week since I last compiled it, so it's a fairly recent change. The error message just before the compile dies is: ... fastcall.o pcc.o cc -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm ld: warning -L: directory name (/usr/local/lib) does not exist ld: warning prebinding disabled because of undefined symbols ld: Undefined symbols: _Parrot_set_sighandler make: *** [parrot] Error 1 I also get this error several times when I run Configure.pl with --verbose: ld: warning -L: directory name (/usr/local/lib) does not exist (I can send the captured output from Configure.pl if anyone's interested.) I don't have a /usr/local/lib in 10.3.1. My 10.2.x drive does have a /usr/local/lib, and it contains: libdl.a and libdl.dylib. In 10.3.1, libdl.dylib lives in /usr/lib. I haven't found libdl.a. Allison
Re: Vocabulary
Michael Lazzaro writes: > I agree, it is frequently the case that the question of speed is made > critical by people who most assuredly do not need it. But they still > decide that way, and I have found that asserting to them that speed is > not important has been... well, less than effective. I do not doubt > that P6 will be much more competitive, speed-wise, than P5 -- but if it > could actually _win_ a few benchmarks, it would turn my company's use > of Perl from a PR problem to a PR advantage. In the presence of parrot's JIT, competing should be no problem. I'm not entirely sure Perl 6 will be faster than Perl 5 on the average. But the difference is that Perl 6 will allow you to make fast code where you need it. For instance (and the main one, probably), using native (lowercase) types allows you to JIT, and using JIT is just... well, you have to see it for yourself. Amazing. But since, as I've said, I don't do speed-critical work, I won't be usually using lowercase types. And that trades me flexibility for speed. And from what I've seen of Java, if you need speed, hand-optimizing your inner loop to parrot assembly should blow Java out of the water. Without needing a C compiler (I despise XS). Luke > >your usage patterns may be irrelevant to Perl in the big picture. > > The thought has crossed my mind repeatedly, believe me. > > MikeL >
Re: Vocabulary
On Tuesday, December 16, 2003, at 05:36 PM, Chip Salzenberg wrote:
Speed is for users. PR is for non-users.
You want speed? OK, we can talk about the actual speed you actually
need based on your actual usage patterns. But from a design
perspective you're a collection of anecote, not a user base; so your
usage patterns may be irrelevant to Perl in the big picture.
In a separate matter, non-users may perceive Perl {5,6} to be too slow
for their needs; more to the point, they may *assume* that it is too
slow without research and testing. That assumption is a public
relations issue -- ironically, one which is fundamentally disconnected
from the question of Perl's _actual_ efficiency.
Well, just for clarification; in my anecdotal case (server-side web
applications), the speed I actually need is "as much as I can get", and
"all the time". Every N cycles I save represents an increase in peak
traffic capabilities per server, which is, from a marketing
perspective, essential.
If a potential client company needs to decide between two server-based
products -- my Perl based product, and a competing Java-based one --
one of the first questions they ask is "how much traffic can it handle
for X dollars of hardware and software". I don't have to win that
benchmark, but I have to be close. Otherwise I don't get to play.
I agree, it is frequently the case that the question of speed is made
critical by people who most assuredly do not need it. But they still
decide that way, and I have found that asserting to them that speed is
not important has been... well, less than effective. I do not doubt
that P6 will be much more competitive, speed-wise, than P5 -- but if it
could actually _win_ a few benchmarks, it would turn my company's use
of Perl from a PR problem to a PR advantage.
your usage patterns may be irrelevant to Perl in the big picture.
The thought has crossed my mind repeatedly, believe me.
MikeL
Re: Vocabulary
On Wed, Dec 17, 2003 at 12:11:59AM +, Piers Cawley wrote: : When you say CHECK time, do you mean there'll be a CHECK phase for : code that gets required at run time? Dunno about that. When I say CHECK time I'm primarily referring to the end of the main compilation. Perl 5 appears to ignore CHECK blocks declared at run time, so in the absence of other considerations I suspect Perl 6 might do the same. Larry
Re: Vocabulary
According to Michael Lazzaro:
> On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote:
> >... an anecdote ...
> >... and a public relations issue.
> >Let us not confuse them.
>
> I'm not sure I understand which part of that is in conflict.
Speed is for users. PR is for non-users.
You want speed? OK, we can talk about the actual speed you actually
need based on your actual usage patterns. But from a design
perspective you're a collection of anecote, not a user base; so your
usage patterns may be irrelevant to Perl in the big picture.
In a separate matter, non-users may perceive Perl {5,6} to be too slow
for their needs; more to the point, they may *assume* that it is too
slow without research and testing. That assumption is a public
relations issue -- ironically, one which is fundamentally disconnected
from the question of Perl's _actual_ efficiency.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Re: Vocabulary
On Wed, Dec 17, 2003 at 12:15:04AM +, Piers Cawley wrote: > There's still a hell of a lot of stuff you can do with 'cached' > optimization that can be thrown away if anything changes. What the > 'final' type declarations would do is allow the compiler to throw away > the unoptimized paths and the checks for dynamic changes that mean the > optimization has to be thrown out and started again. As Luke pointed out in an earlier message, you can encounter grave difficulty (i.e. halting problem unsolvable sort of difficulty) in trying to unoptimize a piece of code that is in the middle of being executed. Just about any subroutine call might (but almost always won't :-) happen to execute code that makes the current subroutine have to revert to unoptimized (or differently optimized) form. When that subroutine call returns after such a rare occurrence, it can't return to the unoptimized code (because there could be missing context because the calling routine got this far using the optimized code and may have skipped stuff that is (now) necessary) and it can't return to the old code (because its optimization might now be wrong).
Re: Vocabulary
On Tuesday, December 16, 2003, at 04:01 PM, Chip Salzenberg wrote: According to Michael Lazzaro: As someone who has 90% of their projects relying very critically on speed ... an anecdote ... Yes. and who has had to battle a number of clients' IT departments over the years in defense of said speed compared to other popular languages which, out of spite, I will not name, ... and a public relations issue. Yes, again. Let us not confuse them. I'm not sure I understand which part of that is in conflict. Is it the premise that some people use Perl in environments in which speed is an issue, the premise that Perl5 has a public relations issue about being inappropriate for speed-critical environments, or the conflation that someone that works in speed-critical environments, and wishes to use Perl, is going to run up against the public-relations issue? MikeL
Re: restore N via win32 CreateProcessA
At 11:38 PM + 12/16/03, Pete Lomax wrote: Hi, I've hit a very strange problem: set N18, 86 save N18 restore N18 if I run this from a DOS prompt, it works fine, however if I run it via the kernel32.dll function CreateProcessA, the restore N18 line fails with "Wrong type on top of stack!". If I change the first line to set N18, 86.0 then it works fine. Is that something I should be doing, appending a '.0' when setting an N reg with a literal integer value? Try doing an "nmake disassemble", assemble that fragment to bytecode, and then disassemble it to see what the assembler's generating. Something odd might be going on there. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Vocabulary
Michael Lazzaro <[EMAIL PROTECTED]> writes: > On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote: >> finally by default? None for me; thanks, though. > > I don't think so; we're just talking about whether you can extend a > class at _runtime_, not _compiletime_. Whether or not Perl can have > some degree of confidence that, once a program is compiled, it won't > have to assume the worst-case possibility of runtime alteration of > every class, upon every single method call, just in case you've > screwed with something. There's still a hell of a lot of stuff you can do with 'cached' optimization that can be thrown away if anything changes. What the 'final' type declarations would do is allow the compiler to throw away the unoptimized paths and the checks for dynamic changes that mean the optimization has to be thrown out and started again. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Vocabulary
Larry Wall <[EMAIL PROTECTED]> writes: > On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote: > : Michael Lazzaro writes: > : > > : > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: > : > >But the agreement could be implied by silence. If, by the time the > : > >entire program is parsed, nobody has said they want to extend an > : > >interface, then the interface can be considered closed. In other > : > >words, if you think you *might* want to extend an interface at run > : > >time, you'd better say so at compile time somehow. I think that's > : > >about as far as we can push it in the "final" direction. > : > > : > That seems a very fair rule, especially if it adds a smidge more speed. > : > Runtime extension will likely be very unusual > : > : Unless you're me. Or Damian. Or a fair number of other programmers who > : like to dive into the Perl Dark Side on a regular basis. > : > : > -- requiring it to be explicit seems reasonable. > : > : It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I > : definitely want to be able to declare in a module "I'm going to be > : screwing with stuff; keep out of my way," so that I don't impose any > : awkward declarations on my module users. If that request can be made > : more explicit in the cases where that's possible, great, but the general > : declaration should be available. > > Okay, we'll call the general declaration: > > use $& > > or some such. :-) > > Seriously, I hope we can provide a framework in which you can screw > around to your heart's content while modules are being compiled, > and to a lesser extent after compilation. But we'll never get to a > programming-in-the-large model if we can't limit most of the screwing > around to the lexical scope currently being compiled, or at least > to a known subset of the code. Modules that turn off optimization > for all other modules are going to be about as popular as $&. Or the debugger. Or a refactoring tool. Or a Class browser... > So the general declaration should probably be something easy to see > like: > > use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN; No question about that. > That will encourage people to be more specific about what they want > to pessimize. Certainly, your fancy module should be encouraged > to declare these things on behalf of its users if it can. I'm not > suggesting that Lukian or Damianly modules force such declarations onto > the users unless it's impossible for the module to know. And it seems > to me that with sufficient control over the user's grammar, you can > often get that information into your own fancy module somehow. > Might take a few macros though, or analysis of the user's code at > CHECK time (or maybe just before). When you say CHECK time, do you mean there'll be a CHECK phase for code that gets required at run time? -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: This week's summary
Luke Palmer <[EMAIL PROTECTED]> writes: > Piers Cawley writes: >> The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: >> > >> > http://groups.google.com/[EMAIL PROTECTED] >> >> This should, of course, read: >> >> http://groups.google.com/[EMAIL PROTECTED] > > Or even: > > http://groups.google.com/[EMAIL PROTECTED] We have a winner!
Re: Vocabulary
According to Michael Lazzaro: > As someone who has 90% of their projects relying very critically on > speed ... an anecdote ... > and who has had to battle a number of clients' IT departments > over the years in defense of said speed compared to other popular > languages which, out of spite, I will not name, ... and a public relations issue. Let us not confuse them. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
restore N via win32 CreateProcessA
Hi, I've hit a very strange problem: set N18, 86 save N18 restore N18 if I run this from a DOS prompt, it works fine, however if I run it via the kernel32.dll function CreateProcessA, the restore N18 line fails with "Wrong type on top of stack!". If I change the first line to set N18, 86.0 then it works fine. Is that something I should be doing, appending a '.0' when setting an N reg with a literal integer value? Pete
Re: Vocabulary
On Tuesday, December 16, 2003, at 03:00 PM, Luke Palmer wrote: But Perl hinges on laziness, doesn't it? Eh, I trust that Perl 6 will make it easy to figure that out in most cases. I was coming from the perspective that 90% of my projects don't need speed; but I can say no such thing on account of my users. And what about that un-accounted-for 10%? As someone who has 90% of their projects relying very critically on speed, and who has had to battle a number of clients' IT departments over the years in defense of said speed compared to other popular languages which, out of spite, I will not name, I beg you to never speak or think that sentence again. ;-) MikeL
[ANNOUNCE] Test::Benchmark
Hi,
since no one else has done it, here it is. Not sure exactly how useful it is,
benchmarks being the fickle things they are but maybe someone will find it
useful.
Comments, patches, flames welcome. Docs are below file will be on CPAN
shortly, until then
http://www.fergaldaly.com/computer/Test-Benchmark/
F
NAME
Test::Benchmark - Make sure something really is faster
SYNOPSIS
use Test::More test => 17;
use Test::Benchmark;
is_faster(-10, sub {...}, sub {...}, "this is faster than that")
is_faster(5, -10, sub {...}, sub {...}, "this is 5 times faster than that")
is_n_times_faster(5, -10, sub {...}, sub {...}, "this is 5 times faster than
that")
is_faster(-10, $bench1, $bench2, "res1 was faster than res2");
DESCRIPTION
Sometimes you want to make sure that your "faster" algorithm really is
faster than the old way. This lets you check. It might also be useful to
check that your super whizzo XS or Inline::C version is actually faster.
This module is based on the standard Benchmark module. If you have lots of
timings to compare and you don't want to keep running the same benchmarks
all the time, you can pass in a result object from "Benchmark::timethis()"
instead of sub routine reference.
USAGE
There are 2 functions exported: "is_faster()" and "is_n_times_faster()".
Actually "is_n_times_faster()" is redundant because "is_faster()" can do the
same thing just by giving it an extra argument.
Anywhere you can pass a subroutine reference you can also pass in a
Benchmark object.
# call as
# is_faster($times, $sub1, $sub2, $name)
# is_faster($faster, $times, $sub1, $sub2, $name)
is_faster()
is_faster($times, $sub1, $sub2, $name)
is_faster($factor, $times, $sub1, $sub2, $name)
This runs each subroutine reference $times times and then compares the
results. Instead of either subroutine reference you can pass in a Benchmark
object. If you pass in 2 Benchmark objects then $times is irrelevant.
If $times is negative then that speicifies a minimum duration for the
benchmark rather than a number of iterations (see Benchmark for more
details). I strongly recommend you use this feature if you want your modules
to still pass tests reliably on machines that are much faster than your own.
1 iterations may be enough for a reliable benchmark on your home PC but
it be just a twinkling in the eye of somebody else's super computer.
If the test fails, you will get a diagnostic output showing the benchmark
results in the standard Benchmark format.
is_n_times_faster()
is_n_times_faster($factor, $times, $sub1, $sub2, $name)
This is exactly the same as the second form of is_faster but it's just
explicit about the "n times" part.
DANGERS
Benchmarking can be slow so please consider leaving out benchmark tests from
your default test suite, perhaps only running them if the user has set a
particualr environment variable.
Some benchmarks are inherently unreliable.
BUGS
None that I know of.
DEPENDENCIES
Benchmark, Test::Builder but they come with most Perl's.
HISTORY
This came up on the perl-qa mailing list, no one else.
SEE ALSO
Test::Builder, Benchmark
AUTHOR
Written by Fergal Daly <[EMAIL PROTECTED]>.
COPYRIGHT
Copyright 2003 by Fergal Daly <[EMAIL PROTECTED]>.
This program is free software and comes with no warranty. It is distributed
under the LGPL license. You do not have to accept this license but nothing
else gives you the right to use this software.
See the file LGPL included in this distribution or
http://www.fsf.org/licenses/licenses.html.
Re: Vocabulary
On Tuesday, December 16, 2003, at 12:20 PM, Gordon Henriksen wrote: finally by default? None for me; thanks, though. I don't think so; we're just talking about whether you can extend a class at _runtime_, not _compiletime_. Whether or not Perl can have some degree of confidence that, once a program is compiled, it won't have to assume the worst-case possibility of runtime alteration of every class, upon every single method call, just in case you've screwed with something. They still aren't "final" classes, in that you can subclass them at will. You just can't subclass them _runtime_, via C, unless you've specifically marked that you want to allow that for that _specific_ class. As Larry hypothesized: The other reason for "final" is to make it easy for the compiler to optimize. That's also problematical. As implemented by Java, it's a premature optimization. The point at which you'd like to know this sort of thing is just after parsing the entire program and just before code generation. And the promises have to come from the users of interfaces, not the providers, because the providers don't know how their services are going to be used. Methods, roles, and classes may never declare themselves final. They may be declared final only by the agreement of all their users. But the agreement could be implied by silence. If, by the time the entire program is parsed, nobody has said they want to extend an interface, then the interface can be considered closed. In other words, if you think you *might* want to extend an interface at run time, you'd better say so at compile time somehow. I think that's about as far as we can push it in the "final" direction. -and- Actually, I think making people declare what they want to extend might actually provide a nice little safety mechanism for what can be modified by the eval and what can't. It's not exactly Safe, but it's a little safer. -and- Seriously, I hope we can provide a framework in which you can screw around to your heart's content while modules are being compiled, and to a lesser extent after compilation. But we'll never get to a programming-in-the-large model if we can't limit most of the screwing around to the lexical scope currently being compiled, or at least to a known subset of the code. So, if I may interpret that; it might not be so bad to have to declare whether or not you were going to extend/alter a class at runtime, in order that Perl could optimize what it knows at compile-time for the 99.5% of the classes that you wouldn't be doing that for. MikeL
Re: Vocabulary
Larry Wall writes: > On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote: > : Michael Lazzaro writes: > : > > : > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: > : > >But the agreement could be implied by silence. If, by the time the > : > >entire program is parsed, nobody has said they want to extend an > : > >interface, then the interface can be considered closed. In other > : > >words, if you think you *might* want to extend an interface at run > : > >time, you'd better say so at compile time somehow. I think that's > : > >about as far as we can push it in the "final" direction. > : > > : > That seems a very fair rule, especially if it adds a smidge more speed. > : > Runtime extension will likely be very unusual > : > : Unless you're me. Or Damian. Or a fair number of other programmers who > : like to dive into the Perl Dark Side on a regular basis. > : > : > -- requiring it to be explicit seems reasonable. > : > : It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I > : definitely want to be able to declare in a module "I'm going to be > : screwing with stuff; keep out of my way," so that I don't impose any > : awkward declarations on my module users. If that request can be made > : more explicit in the cases where that's possible, great, but the general > : declaration should be available. > > Okay, we'll call the general declaration: > > use $& > > or some such. :-) > > Seriously, I hope we can provide a framework in which you can screw > around to your heart's content while modules are being compiled, > and to a lesser extent after compilation. But we'll never get to a > programming-in-the-large model if we can't limit most of the screwing > around to the lexical scope currently being compiled, or at least > to a known subset of the code. Modules that turn off optimization > for all other modules are going to be about as popular as $&. So > the general declaration should probably be something easy to see like: > > use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN; Hmm, I guess that's true. A module author shouldn't have the the freedom to say that his classes are completely untouchable, because he doesn't know what you're going to be doing with them. But correspondingly, I guess, a module author shouldn't have the freedom to slow everybody down because he was lazy about figuring out what needed to be declared "open". But Perl hinges on laziness, doesn't it? Eh, I trust that Perl 6 will make it easy to figure that out in most cases. I was coming from the perspective that 90% of my projects don't need speed; but I can say no such thing on account of my users. And what about that un-accounted-for 10%? Perhaps the real detterent to using such a thing would be making it generate a warning when -w is on. You get the peer pressure thing; people frown upon you when you use the pragma unwisely. So, yeah, I agree with you now. Luke
Re: Vocabulary
Chip Salzenberg writes:
> According to Jonathan Scott Duff:
> > Those classes that are "closed" can be opened at run-time and the
> > user pays the penalty then when they try to modify the class [...]
>
> The optimization that can be reversed is not the true optimization.
While poetic and concise, I think that statement needs to be driven into
the ground a bit more.
Over on p6i, I think we're basically in agreement that the ability to
undo optimizations is nothing we can count on. Unless there is a
breakthrough in computer science any time soon, this while loop:
sub one() { 1 };
sub go() {
my $x = 0;
while $x++ < one { # loop optimized away
%main::{'&one'} = sub { 10 };
print "Boing!\n";
}
}
Is not something that can can be re-inserted when we find out one() has
changed. While it's possible to make it so go() is unoptimized on the
next call, that's not good enough. We expect changes to act instantly.
But if you separate parsing and code-generation time, you can make
optimizations earlier based on declarations later, which is just fine.
It allows you to say:
use PresumptuousModule << SomeClass >>;
class SomeClass is extensible { };
Then even if the writer of PresumptuousModule thinks you'll be better
off with the optimization, you can tell him otherwise. But you have to
do it before the code is generated.
Luke
Re: Vocabulary
According to Jonathan Scott Duff: > Those classes that are "closed" can be opened at run-time and the > user pays the penalty then when they try to modify the class [...] The optimization that can be reversed is not the true optimization. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K
Re: Vocabulary
On Tue, Dec 16, 2003 at 12:06:46PM -0800, Michael Lazzaro wrote:
> As far as users of your class being able to specify that they want
> something runtime-extensible, when your original module didn't call for
> it, I don't see that as a problem, if they can just add the trait to
> your class shortly after they C the package containing it, if such
> things are possible
I think it kind of hinges on the ability to undo optimizations.
Just to restate things a bit to make sure I understand ... when perl
compiles a class, it assumes it's closed and accordingly applies
whatever optimizations it can unless it sees that the programmer
explicitly asked otherwise. Those classes that are "closed" can be
opened at run-time and the user pays the penalty then when they try to
modify the class (and pays twice because of the compile-time
optimizations that perl applied and are now undoing).
But does everybody pay some penalty because of it? I hope not.
Presumably we keep the source around for a reparse if necessary
anyway? Or perhaps we have "unoptimized" bytecode laying around ready
to be switched in for the optimized bytecode when necessary.
> class Wombat { ... }; # Not runtime extensible
> class MyWombat is Wombat
> is runtime_extensible { ... }; # Runtime extensible
>
> Now, it might be that declaring MyWombat to be runtime_extensible
> actually silently disables some compile-time optimizations not only for
> it, but for all its superclasses/roles/etc., depending on how
> intelligent and far reaching those optimizations may be.
I hope not.
> Not sure.
> Still, the fact that you are _requesting_ that happen is specific to
> the particular class that needs it -- and should be associated with
> that class,
Yep.
> such that if that class later falls into disuse, the
> optimizations silently reappear.
That would be *some* trick!
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
RE: Vocabulary
finally by default? None for me; thanks, though. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
RE: Namespaces, part 2
> From: Dan Sugalski [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 16, 2003 6:56 AM > To: [EMAIL PROTECTED] > Subject: Namespaces, part 2 > > load_global $P1, ['foo'; 'bar'] '$baz' > load_global $P2, ['foo'; 'bar'] '$xyzzy' I'm not at all familiar with the intricacies of Parrot internals anymore, things having gone flying over my head long ago, but may I humbly suggest that there might be some merit to creating some kind of shortcut to a namespace stored in a Px register? load_namespace $P1, ['foo'; 'bar'] load_global $P2, $P1, '$baz' Might be a good place to specialize the code for language constructs like Python's from module import * Or something Perl6-ish involving "given". Subsequent "load_global" usage wouldn't have to do the work of actually finding that 'foo::bar' namespace each time. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.545 / Virus Database: 339 - Release Date: 11/27/2003
Re: Vocabulary
On Tue, 2003-12-16 at 12:06, Michael Lazzaro wrote: > My own first instinct would be that the run-time extensibility of a > particular interface/class would simply be a trait attached to that > class... by default, classes don't get it. That doesn't sound very dynamic. At the post-OSCON design meetings, Larry suggested that the user of a class or library could say "I'm not going to muck about with this at runtime and any extra optimization would be nice, so go ahead and do whatever you can do it." Putting that opportunity on the user has several advantages: - the library writer isn't responsible for getting the library completely perfect, because library users can make changes if necessary - the common case (run-time extension and manipulation) needs less code (that is, you don't have to say "Mother, may I take advantage of the features of the dynamic language I'm supposed to be?" to take advantage of those features) - the user of the library can choose specific optimizations when and where he needs them -- c
Re: Vocabulary
On Tuesday, December 16, 2003, at 09:07 AM, Larry Wall wrote:
Seriously, I hope we can provide a framework in which you can screw
around to your heart's content while modules are being compiled,
and to a lesser extent after compilation. But we'll never get to a
programming-in-the-large model if we can't limit most of the screwing
around to the lexical scope currently being compiled, or at least
to a known subset of the code. Modules that turn off optimization
for all other modules are going to be about as popular as $&. So
the general declaration should probably be something easy to see like:
use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN;
That will encourage people to be more specific about what they want
to pessimize. Certainly, your fancy module should be encouraged
to declare these things on behalf of its users if it can. I'm not
suggesting that Lukian or Damianly modules force such declarations onto
the users unless it's impossible for the module to know. And it seems
to me that with sufficient control over the user's grammar, you can
often get that information into your own fancy module somehow.
Might take a few macros though, or analysis of the user's code at
CHECK time (or maybe just before).
And in general, it's probably not necessary to declare all the new
interfaces, but only those interfaces known at compile time that want
to stay open. Any interfaces added at run time are probably assumed
to be open. So in some cases you might find yourself deriving a
single open class at compile time from which you can derive other
open classes later.
Exactly, assuming I correctly understand. :-)
My own first instinct would be that the run-time extensibility of a
particular interface/class would simply be a trait attached to that
class... by default, classes don't get it. By limiting or not limiting
the amount of runtime screwin' around you can do with the class, it is
therefore able to control the level of optimization that calls to
methods, etc., are given -- but specific to that particular
interface/class, not to the module and certainly not to the program in
general.
class Wombat is runtime_extensible { ... };
So everything is closed, except the specific classes which are not.
Even when you are (to use an example from my own code) making runtime
subclasses on-the-fly, you're almost always starting from some common
base class. (And 'almost' is probably an unneeded qualifier, there.
As is 'probably'.)
As far as users of your class being able to specify that they want
something runtime-extensible, when your original module didn't call for
it, I don't see that as a problem, if they can just add the trait to
your class shortly after they C the package containing it, if such
things are possible -- or, for that matter, simply subclass your
original into a runtime_extensible class:
class Wombat { ... }; # Not runtime extensible
class MyWombat is Wombat
is runtime_extensible { ... }; # Runtime extensible
Now, it might be that declaring MyWombat to be runtime_extensible
actually silently disables some compile-time optimizations not only for
it, but for all its superclasses/roles/etc., depending on how
intelligent and far reaching those optimizations may be. Not sure.
Still, the fact that you are _requesting_ that happen is specific to
the particular class that needs it -- and should be associated with
that class, such that if that class later falls into disuse, the
optimizations silently reappear.
(At first glance, I am less sure of the need to have similar
functionality for entire modules, as opposed to classes, but perhaps
someone out there can come up with an example.)
MikeL
Re: Yet another keyed ops proposal.
At 11:56 AM +0100 12/12/03, Leopold Toetsch wrote: Yet another keyed ops proposal[1] Given the Perl6 expression: @a[$i] = @b[1] + $k; This should translate to add P0[I0], P1[1], I2 But having multi-keyed variants of all relevant opcodes would burst our opcode count to #of-keyed-opcodes * #of-key-permutations. That's not feasable. Definitely not. Here's an alternative. I'd originally planned on there being a single keyed variant of each op, so the above would be written: add P0[S0], P1[S1], P2[] Note that a key is passed in for $k, just a NULL key, all keys were meant to be in S registers, and there weren't going to be constant keys or pure-integer. Things have changed a bit. :) Note that I'm perfectly OK mandating the following: 1) All keys must be of the same type (integer key or key struct keys) 2a) No constant keys or 2b) All keys must be constant or register based 3) If one parameter is keyed they all are I'm comfortable with 1, 2a, and 3, though I can see the case for 2b. Doubles the number of keyed ops, though. (At least only for PMC-based operations, which is something) So here is another proposal to implement these ops. 1) The assembler splits above PASM statement into two: This is the one thing that I'll grumble about -- we can argue over other things, but the assembler should *not* implicitly split stuff out like this. Maybe (Only maybe!) IMCC should, but I'd argue not there as well. It should be explicitly specified in the source where the keys should be fetched. 5) These returned pointers are stored in REG_PMC(x) .. REG_PMC(z) (x = 32, y = 33, z = 34) [2] struct PReg hasPMC *registers[NUM_REGISTERS + 3]; This would be the clever bit -- key registers. I'm fine with key registers however... if we're going to add them, why not just have a separate set of key registers and be done with it? This adds one opcode dispatch and increases code size a bit, but we we wouldn't need any additional keyed vtables. And all the checks for passed NULL keys (i.e. no key) aren't necessary. Comments welcome, leo [1] And I hear Dan groaning: ONNTA :) Groan or not this needs a final decision. Nobody ever told me I had to *like* the job... -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Namespaces, part 2
I lost track of this a bit (sorry, work intruded) so lets pick it back up again. As we last left it, I'd proposed we access namespaces via a multidimensional key to dodge the whole "What separator does *this* language use?" problem. I'd also proposed that we split the namespace and thing name into separate parameters. Turning the namespace selector into a multidimensional key just seems to make sense. I'd originally hoped we could keep things unidimensional, in one really big hash, but that idea now seems charmingly naive, and if we're going to be multidimensional we might as well do it right. I don't see any reason to not just do this. The reason for splitting the lookup into two parameters, namespace and name, instead of one combined parameter, is a bit less solid, so I'm up for arguments here. Consider, however, the case where we're accessing multiple named globals, a not uncommon thing. If we go with the single parameter case it looks like: load_global $P1, ['foo'; 'bar'; '$baz'] load_global $P2, ['foo'; 'bar'; '$xyzzy'] but if we go with the split parameter case it looks like: load_global $P1, ['foo'; 'bar'] '$baz' load_global $P2, ['foo'; 'bar'] '$xyzzy' The difference there being that, rather than having two separate constant keys we have one constant key and two string constants. This should result in less memory usage and a faster startup time for bytecode that accesses globals (which should pretty much be all of it). It has the additional advantage of *not* needing to construct an extra key when doing symbolic access to symbol tables. Code like: $$foo = 12; where $foo has a string in it won't need to have a key constructed -- the bytecode would look like: load_global $P1, CURRENT_PACAKGE_CONSTANT, $foo $P1 = 12 assuming the string in $foo has no package qualifications. If it does a key needs to be created, of course, but it makes one of the access legs (the leg with no qualification) faster without impacting the speed of the less-common package-qualified leg. Time for discussion, and this time I promise to keep up. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #24667] IMCC not handling some integer constant parameters properly
At 9:52 AM +0100 12/16/03, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: If, as part if a prototyped .pcc_begin/.pcc_end function call set, you try and set an integer parameter equal to the register number the integer would go into. .pcc_begin prototyped .arg 1 .arg 6 .arg 7 A simple test case works correctly (test committed). But I can imagine, if the code is evaled (I6, I7 already used previous), that it could fail. For this case I've checked in a small (hopefully) fix. Fix works. I didn't have a small test case, hence the vague-ish bug report. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Vocabulary
On Tue, Dec 16, 2003 at 07:05:19AM -0700, Luke Palmer wrote: : Michael Lazzaro writes: : > : > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: : > >But the agreement could be implied by silence. If, by the time the : > >entire program is parsed, nobody has said they want to extend an : > >interface, then the interface can be considered closed. In other : > >words, if you think you *might* want to extend an interface at run : > >time, you'd better say so at compile time somehow. I think that's : > >about as far as we can push it in the "final" direction. : > : > That seems a very fair rule, especially if it adds a smidge more speed. : > Runtime extension will likely be very unusual : : Unless you're me. Or Damian. Or a fair number of other programmers who : like to dive into the Perl Dark Side on a regular basis. : : > -- requiring it to be explicit seems reasonable. : : It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I : definitely want to be able to declare in a module "I'm going to be : screwing with stuff; keep out of my way," so that I don't impose any : awkward declarations on my module users. If that request can be made : more explicit in the cases where that's possible, great, but the general : declaration should be available. Okay, we'll call the general declaration: use $& or some such. :-) Seriously, I hope we can provide a framework in which you can screw around to your heart's content while modules are being compiled, and to a lesser extent after compilation. But we'll never get to a programming-in-the-large model if we can't limit most of the screwing around to the lexical scope currently being compiled, or at least to a known subset of the code. Modules that turn off optimization for all other modules are going to be about as popular as $&. So the general declaration should probably be something easy to see like: use STRANGE_SEMANTICS_THAT_SLOW_EVERYONE_DOWN; That will encourage people to be more specific about what they want to pessimize. Certainly, your fancy module should be encouraged to declare these things on behalf of its users if it can. I'm not suggesting that Lukian or Damianly modules force such declarations onto the users unless it's impossible for the module to know. And it seems to me that with sufficient control over the user's grammar, you can often get that information into your own fancy module somehow. Might take a few macros though, or analysis of the user's code at CHECK time (or maybe just before). And in general, it's probably not necessary to declare all the new interfaces, but only those interfaces known at compile time that want to stay open. Any interfaces added at run time are probably assumed to be open. So in some cases you might find yourself deriving a single open class at compile time from which you can derive other open classes later. But still, the principle remains that original declarer of an interface doesn't know in general whether its users are going to want to extend it. At some point the users have to take responsibility if they want their code to run fast. Or run at all... So we need to make it very easy for users to provide this kind of information when it's needed. Larry
perl6-all@perl.org
# New Ticket Created by "Jose S. Plummer" # Please include the string: [perl #24677] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=24677 >
Re: Vocabulary
Michael Lazzaro writes: > > On Sunday, December 14, 2003, at 06:14 PM, Larry Wall wrote: > >But the agreement could be implied by silence. If, by the time the > >entire program is parsed, nobody has said they want to extend an > >interface, then the interface can be considered closed. In other > >words, if you think you *might* want to extend an interface at run > >time, you'd better say so at compile time somehow. I think that's > >about as far as we can push it in the "final" direction. > > That seems a very fair rule, especially if it adds a smidge more speed. > Runtime extension will likely be very unusual Unless you're me. Or Damian. Or a fair number of other programmers who like to dive into the Perl Dark Side on a regular basis. > -- requiring it to be explicit seems reasonable. It seems so. Knowing Larry, I'm sure this is an ungrounded fear, but I definitely want to be able to declare in a module "I'm going to be screwing with stuff; keep out of my way," so that I don't impose any awkward declarations on my module users. If that request can be made more explicit in the cases where that's possible, great, but the general declaration should be available. Luke > > >I'm probably spouting nonsense. I just hope it's good-sounding > >nonsense... > > It's beyond good-sounding, it's frickin' awesome. > > MikeL >
Re: Object Order of Precedence (Was: Vocabulary)
Jonathan Lang writes: > Larry Wall wrote: > > Well, nothing much really supercedes the class. Even traits have > > to be requested by the class, and if you have an entirely different > > metaclass, it's probably declared with a different keyword than > > C. (But sure, multiple traits will have to applied in order > > of declaration, and I don't doubt there will be ordering dependencies.) > > My apologies; I'm apparently a bit weak on my object-oriented terminology. > I'm not quite sure what's being meant here by "metaclass", other than a > vague concept that it's somehow similar to the relationship between logic > and metalogic. Also, I was under the impression that the writers of the > "tTraits" paper that you referred us to disliked "mixins" largely because > they _did_ use an order-of-precedence conflict resolution scheme; surely > their concerns would apply equally well to what we're calling traits? I think metaclass is referring to the thing that knows how to associate attributes with their corresponding objects, how do dispatch methods to their corresponding code objects, and whatnot. > > I think the normative way to supercede a class should be to > > subclass it. That's what OO is supposed to be all about, after all. > > If we can keep that orthogonal to role composition, we stand a good > > chance of being able to do a lot of what AOP claims to do without > > the downsides of AOP's own slatheron approach. Or more precisely, > > we can resort to AOP-style wrappers where we really need them, and > > avoid them where we don't. > > As I don't know what AOP is, this is largely lost on me. But I'm all for > keeping various aspects of perl orthogonal to each other if it's > reasonable to do so. Likewise, my main concern isn't so much "how to > supercede a class" as it is "how to keep a class from superceding a role > that it doesn't know about". C does a pretty good job of introducing one to AOP, at least the extent to which Perl is capable of it (which is quite a lot). > > I'm probably spouting nonsense. I just hope it's good-sounding > > nonsense... > > More importantly, it seems to be _useful_ nonsense. I just hope that _my_ > nonsense is more useful than it is annoying. :) Luke
Re: This week's summary
Piers Cawley writes: > The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: > > Vocabulary > > If you're even vaguely interested in the workings of Perl 6's object > > system, you need to read the referenced post. > > > > Luke Palmer, worrying about people using Object related vocabulary in > > subtly inconsistent ways, posted a glossary explaining how OO > > terminology is used in a Perl 6 context. Casey West wrapped it up in a > > POD, which will, I hope, end up on dev.perl.org soon. > > > > Of course, there were a few corrections for subtleties, a few rethinks > > of the design so far, and general gratitude for at least having a > > baseline document that people could refer to. > > > > http://groups.google.com/[EMAIL PROTECTED] > > This should, of course, read: > > http://groups.google.com/[EMAIL PROTECTED] Or even: http://groups.google.com/[EMAIL PROTECTED] :-p Luke
Re: This week's summary
The Perl 6 Summarizer <[EMAIL PROTECTED]> writes: > Vocabulary > If you're even vaguely interested in the workings of Perl 6's object > system, you need to read the referenced post. > > Luke Palmer, worrying about people using Object related vocabulary in > subtly inconsistent ways, posted a glossary explaining how OO > terminology is used in a Perl 6 context. Casey West wrapped it up in a > POD, which will, I hope, end up on dev.perl.org soon. > > Of course, there were a few corrections for subtleties, a few rethinks > of the design so far, and general gratitude for at least having a > baseline document that people could refer to. > > http://groups.google.com/[EMAIL PROTECTED] This should, of course, read: http://groups.google.com/[EMAIL PROTECTED] Apologies for the confusion. -- Beware the Perl 6 early morning joggers -- Allison Randal
This week's summary
The Perl 6 Summary for the week ending 20031214
It looks like things are starting to slow down slightly as we run up to
Christmas, but the quality of discussion remains high. We'll start with
the usual trawl through perl6-internals.
Testing for null
Dan ruled on last week's discussion of testing for undef in Parrot.
We're getting a new "isnull" branch op along with a new Undef PMC. Leo
Tötsch implemented it with his usual alacrity.
http://groups.google.com/[EMAIL PROTECTED]
How many comparison ops do we need again?
One of the annoyances of writing something that's really going to be
used is that you can't get away with the equivalent of outlining your
proof on the blackboard, waving your hands and saying "The details are
left as an exercise for the interested reader". A case in point is
Parrot's array of comparison branch operators. For a while now we've
been getting by with a sparsely populated array of such beasties. This
week saw people (well, okay then, Leo, but he has the productivity of
people) doing the detail work to get the full range implemented.
http://groups.google.com/[EMAIL PROTECTED]
Incorrect scoping of constants in IMCC
Dan wasn't happy with the scoping of the ".const" directive in IMCC
(essentially constants are sub/block scoped, which makes them pretty
much useless for the things constants are normally used for). Melvin
Smith made the fix.
http://groups.google.com/[EMAIL PROTECTED]
Objects and Namespaces
Dan had mandated that the Parrot internal equivalent of the Perlish
"Package::Name" should be "Package\0Name". Nobody (Dan included) liked
the embedded nulls mandated in Dan's original spec. After some
discussion he posted a description of a new hierarchical namespace
design.
Dan pointed out that the use of hierarchical namespaces would probably
mean that the semantics (and syntax) of "find_global" would need to be
adjusted.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
-- The New Namespace
Dan Sugalski, IMCC Bugfinder General
Dan's been writing more PIR code by hand, and is discovering
infelicities as he goes.
http://groups.google.com/[EMAIL PROTECTED]
http://groups.google.com/[EMAIL PROTECTED]
Macros, PIR and PASM
Following his bout of IMCC bug spotting, Dan announced a decision about
macros in PIR and PASM code. Essentially, Parrot's built in PIR and PASM
parsers do not need to do macros as 'macro assemblers are for people,
not compilers'. Because of this, Dan would like to see any macro
processing moved out of the core binary and into an external tool.
(Which can always be invoked via the hypothetical macro-parrot.pl).
Melvin Smith suggested that it would probably be worth extracting the
existing macro processor from imcc.l and moving it into a separate
library.
http://groups.google.com/[EMAIL PROTECTED]
Meanwhile, in perl6-language
The language list continues to fascinate (and not in the 'car crash' way
it has done on occasions in the past) with an ongoing conversation
between Larry on the one hand (seemingly designing on the hoof and
certainly doing a great deal of thinking aloud) and everyone else on the
other hand getting clarification or extrapolating to the point where
Larry has to step in and do a little bit more design.
I'm finding it hard to do a proper summary of what's going on because so
much is changing (and because so much of what seems to be set in quick
drying concrete now is so novel.)
Essentially the discussion revolves around Roles, which are sort of like
Java interfaces, sort of like mixins and nothing like either. In his
'Vocabulary' post, Luke Palmer describes a Role as 'A collection of
methods [and/or attributes] to be incorporated into a class sans
inheritance [...]. Used with "does"'. In this new world, a property
("$bar but Red" etc) is a kind of degenerate role.
At the same time though, we're getting other gems. For instance, Perl 6
is going to get something a little like "final", but instead of it being
a declaration made in a type's implementation ("This is the one, the
only Integer and you may not inherit from it or ever alter it!"), it
will become a promise made by a type's user not to attempt to monkey
with it come run time, which should set the code generator free to use
optimizations that aren't safe when everything's dynamic.
So, if you're interested in how Perl 6's OO system is going to work, now
is the time to get involved in the language list. If there's something
you've always wanted to do or something about Perl's current OO that you
love and want to retain, it's time to speak up for it. The odds are good
that you'll be able to do what you want using the mechanisms being
designed, bu
Re: [perl #24667] IMCC not handling some integer constant parameters properly
Dan Sugalski <[EMAIL PROTECTED]> wrote: > If, as part if a prototyped .pcc_begin/.pcc_end function call set, > you try and set an integer parameter equal to the register number the > integer would go into. > .pcc_begin prototyped > .arg 1 > .arg 6 > .arg 7 A simple test case works correctly (test committed). But I can imagine, if the code is evaled (I6, I7 already used previous), that it could fail. For this case I've checked in a small (hopefully) fix. Please always provide a minimal but complete test case exhibiting the bug - thanks, leo
