Re: Just a thought
Vladimir Lipsky <[EMAIL PROTECTED]> wrote: > Parrot_loadbc(interpreter, pf); > Did you catch the difference between the 2nd actual parameter and > the function name? Maybe it's worth renaming? E.g. Parrot_loadpf() Sounds reasonable. Or Parrot_set_pf(). > 0x4C56 leo
Re: feature request: line numbers in errors?
Michal Wallace <[EMAIL PROTECTED]> wrote: > Is it possible to print out the line number > of the bad instruction when parrot encounters > an error and fails? Yep. I'll have a look at it. > I don't suppose there's one magic error routine > that controls all the error messages, and someone > could just add a line or two to handle this? :) Almost all runtime errors are going through internal_exception(). I'll add these two lines :) > Michal J Wallace leo
Re: More object stuff
Michal Wallace <[EMAIL PROTECTED]> wrote:
> What is the _return_cc attribute on an
> exception? Can I use it to resume the
> code as if the exception never happened?
When an exception is resumable, you can return by invoking this return
continuation. But details (i.e. is C<_return_cc> put into P1
automatically) will probably change. t/pmc/exception.t has some
examples.
> Do I have to fill it in manually? Or
> could it be automatic?
If the exception originated in the opcode-loop, it can be resumable -
but not all are changed yet. Have a look at C in
*.ops. For these, setting the return continuation is done automatically.
> I'm picturing exceptions as continuations
> with an arbitrary message attached... Right
> now that message is a string, but eventually
> it could be any PMC... Is that about right?
There will be some default information and user fields.
> So, if I throw a WarningException, could I
> just say "ignore it... go to the next line"?
You can always resume your own exceptions that you C yourself.
> As for the message, I'm trying to think of
> a good reason to standardize that attached
> PMC. For example, if I try to open a file
> in python and it fails, I get an exception
> of class IOError... But if I call a perl
> routine that throws the perl equivalent...
> What should happen? Should I just catch
> PerlException instead?
I think, that we need classified ParrotExceptions. If HLLs POV differ
they can subclass these to their own needs.
> Each HLL is going to want its own class
> hierarchy for exceptions... But it might
> be nice to have a predefined hierarchy that
> parrot uses internally.
Yep.
> I know perl uses a return value instead of
> throwing an exception ("open or die", right?)..
Where die() is the exception.
> So would parrot's internal file-opener just
> throw a ParrotFileException? So perl's
> open() command catches it and returns 0,
> while python's open() command catches it
> and throws a new IOError?
Very probably yes.
> Michal J Wallace
leo
Re: [perl #24584] [PATCH] 'in macro' vs. 'in file' in some imclexer.c error messages
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > I think the 'imclexer.c' is generated from 'imcc.l' during maintainance. So > I made the patch in both files. Just for imcc.l is enough. Thanks, applied. leo
RE: Test::Benchmark ??
I'd say a lot of the trouble comes from the fact that you're using the
automated test framework for something that isn't an automated test.
You'll probably find that easiest thing to do is stick something like this
in your Makefile.PL
sub MY::postamble {
return << 'EOM';
bench: pure_all
PERL_DL_NONLAZY=1 $(FULLPERLRUN) -Mblib benchmark.pl
EOM
}
then you can do
make bench
which will run benchmark.pl and the output will go straight to the screen.
What would be even more useful would be a Benchmark::Harness module which
would allow us to have a bench/ directory where we could lob in lots of .bm
files which will be run when you do a
make bench
F
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: [RFC] IMCC pending changes request for comments
On Tuesday, December 2, 2003, at 11:49 , Melvin Smith wrote: At 07:59 PM 12/2/2003 -0800, Steve Fink wrote: Do you really want to generate the extra unused code at the end of all the subroutines? I don't think you want to autodetect whether the code is guaranteed to return. Good point. Its easy to detect returns if the code uses high level IMC directives, but in cases where it is all low-level PASM, it could get a little troublesome. It would also add a few dead instructions here and there. Nix that idea. Maybe just pad the end of the compilation unit with the opcode equivalent of PMCNULL, to fire an exception rather than having undefined behavior? — Gordon Henriksen [EMAIL PROTECTED]
Re: python exceptions broken
Michal Wallace <[EMAIL PROTECTED]> wrote: > Looking more at exceptions here... I > used to be able to put arbitrary > stuff in the _message slot of a > ParrotException... Now we can only use > strings. Is that permanent? Depends on what exceptions finally are. But the standard entries like "_message" are not supposed to get anything different then a string for that. > PythonException will need to be able > to hold an arbitrary python object. Attach it as a property (s. setprop/getprop). > Michal J Wallace leo
Re: get_pmc_keyed() in PerlString?
Sterling Hughes <[EMAIL PROTECTED]> wrote: > Should PerlString support a get_pmc_keyed() method (according to Perl > 5/6 semantics), or is this a point where its about time to start > implementing our own PMCs? get_pmc_keyed() seems a bit heavy to handle single chars in a PerlString (Each char would create a separate PMC with a PerlString attached to it). Can you use native STRINGs for that? > -Sterling leo
Re: get_pmc_keyed() in PerlString?
Am 04.12.2003 um 15:17 schrieb Leopold Toetsch:
Sterling Hughes <[EMAIL PROTECTED]> wrote:
Should PerlString support a get_pmc_keyed() method (according to Perl
5/6 semantics), or is this a point where its about time to start
implementing our own PMCs?
get_pmc_keyed() seems a bit heavy to handle single chars in a
PerlString (Each char would create a separate PMC with a PerlString
attached to it).
Can you use native STRINGs for that?
sure, if we only knew the type of the variable we're accessing:
function dump0($a)
{
echo printf("%s\n",$a[0]);
}
dump0("hallo"); // called with a string
dump0(array("thies", "arntzen")); // with an array
would produce (in php):
h// string offset
thies// array index
how do you think we should generate "good" imc code for that?
re,
thies
Re: get_pmc_keyed() in PerlString?
Thies C . Arntzen <[EMAIL PROTECTED]> wrote:
> Am 04.12.2003 um 15:17 schrieb Leopold Toetsch:
>> Can you use native STRINGs for that?
> sure, if we only knew the type of the variable we're accessing:
> function dump0($a)
> {
> echo printf("%s\n",$a[0]);
> }
> dump0("hallo"); // called with a string
> dump0(array("thies", "arntzen")); // with an array
> would produce (in php):
> h// string offset
> thies// array index
> how do you think we should generate "good" imc code for that?
dump0() is obviously non-prototyped (or takes PMCs) which doesn't differ
here. So I would do:
.sub _subscripted
.param pmc p
.param int idx
does I0, p, "array"
if I0, handle_array
.include "pmctypes.pasm"
typeof I0, p
eq I0, .PerlString, handle_string
# unhandled type
exit 1
.local pmc elem
handle_array:
elem = p[idx];
...
handle_string:
$S0 = p
$S1 = $S0[idx] # or substr $S1, p, idx, 1
elem = new .PerlString
elem = $S1
...
absolutely untested.
But it seems, that subscripting of string PMCs yields another PMC in the
general case, so its really probably simpler to use your proposed
change. You can easily experiment with custom PMCs, if you use
dynclasses/*.
> re,
> thies
leo
Re: More object stuff
On Dec 3, 2003, at 12:03 PM, Dan Sugalski wrote: At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: > *) Exceptions we're happy with Create an Exception class hierarchy? I'm not 100% sure I want to go with a real OO style of exceptions, but that might just be the neo-luddite in me. I'm of the opinion that it's a conceptual mistake to model exceptions as objects. My main concrete argument is that it's an abuse of inheritance--you need a hierarchy of exception reasons, but using inheritance just to get a hierarchy is silly. (That is, it doesn't make sense to subclass if you are not changing behavior in some way.) In addition, I think it's overly restrictive. Fundamentally, I think raising an exception requires two things: (1) some indication of "reason" for the exception (used by the exception infrastructure to select the correct handler), and (2) a way for the originator of the exception to pass some arbitrary information to the handler (this information being opaque to the exception infrastructure). In C terms, that would mean that the signature is conceptually like: raise_exception(Reason reason, void* info); which in Parrot terms would probably shake down to: raise_exception(Reason reason, PMC* info); The "Reason" data type could either be a structured string, such as "parrot.io.staleFileHandle", or some sort of array of strings--just enough to indicate a hierarchy to be used for selecting a handler. The key point here is that the "reason" parameter is what is needed by the exception infrastructure to choose the correct handler (and to decide what to do if no handler is found), and "info" just has to be of a form agreed upon by the "thrower" and the "catcher". This sort of approach would work with languages such as Java which expect exceptions to be objects--in this case, the Java exception object would be passed as the "info", and the "reason" would be derived from the type of that object. For simpler languages (and possibly even for Perl6), "info" could just be a hash--no real need for a specialized type of object. I think the core of my thinking here is that exceptions don't really have behavior--at most they are a bag of data (which is what hashes are usually good for), and really they are a process for jumping the flow of execution, and sending along a bag of data to indicate why it just happened. That was a bit long-winded, but basically I'm saying that I'd like to see the pasm for raising an exception take the form: raise Px, .parrot.io.StaleFileHandle where Px may actually be null. No matter what approach we take, we're going to have issues throwing exceptions across language boundaries (ie, Perl exception handled by Python code), since different languages aren't going to agree on how to classify exceptions--and having exceptions be HLL objects seems to make this worse. Actually, in a sense this _might_ not be a problem: If we supply a decent reason hierarchy, then using our supplied parrot.* exception "reasons" would allow an exception thrown in one language to be handled in another; if a language-specific reason is used (e.g., perl.blah), then it's probably going to only end up being handled by code in the same language. (And that seems fine--even in Java if I create my own Exception subclass, then code I haven't written isn't expected to be catching that type of exception.) But having some standard types will make it possible to cross language boundaries meaningfully. Just some thoughts. One other thing: Long-term, it would be good to avoid having an exception handler stack which we push and pop as we do now, and instead use a variant of the zero-overhead approach used by C++ (and probably Java), wherein try-catch blocks incur zero execution overhead--CPU time is only consumed when an exception is actually thrown, and not when a "try" block is entered or exited. JEff
Re: [RFC] IMCC pending changes request for comments
On Dec 2, 2003, at 8:49 PM, Melvin Smith wrote: At 07:59 PM 12/2/2003 -0800, Steve Fink wrote: On Dec-02, Melvin Smith wrote: Do you really want to generate the extra unused code at the end of all the subroutines? I don't think you want to autodetect whether the code is guaranteed to return. Good point. Its easy to detect returns if the code uses high level IMC directives, but in cases where it is all low-level PASM, it could get a little troublesome. It would also add a few dead instructions here and there. Nix that idea. You could take the approach of putting in the return code unless you can tell for certain that it couldn't be reached, the idea being that this would lead to some unreachable code at first but as the compiler (or optimizer) becomes more sophisticated in its flow analysis this would gradually improve over time. JEff
Re: Test::Benchmark ??
On Thu, Dec 04, 2003 at 05:26:07AM -0500, [EMAIL PROTECTED] wrote: > I'd say a lot of the trouble comes from the fact that you're using the > automated test framework for something that isn't an automated test. But it could be. It would be nice to have a test like "make sure the hand optimized version is faster than the unoptimized version" or "make sure the XS version is faster than the Perl version". Another useful sort of test would be "make sure this function runs in less than N perlmips time" where a perlmip is some unit of CPU time calibrated relative to the current hardware. So a pmip on machine A would be roughly twice as long as a pmip on a machine that's twice as fast. This enables us to test "make sure this isn't too slow". -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ PS I am very handsome and I live in a castle with a pony.
Re: Test::Benchmark ??
On Thursday 04 December 2003 21:51, Michael G Schwern wrote:
> But it could be. It would be nice to have a test like "make sure the
> hand optimized version is faster than the unoptimized version" or "make sure
> the XS version is faster than the Perl version".
Yeah - this would probably be useful.
> Another useful sort of test would be "make sure this function runs in less
> than N perlmips time" where a perlmip is some unit of CPU time calibrated
> relative to the current hardware. So a pmip on machine A would be
> roughly twice as long as a pmip on a machine that's twice as fast.
> This enables us to test "make sure this isn't too slow".
Not so yeah - just like the mip, the pmip would be a bit to elusive and ever
changing for this to work quite as well as we'd like.
Anyway to do these you can do
my $res = timethese(1, {a => $a_code, b => $b_code}, "none");
which will produce no output and $res will contain all the benchmark
information and you can then perform whatever tests you like on it.
If it's exists, Test::Benchmark should support something like
is_faster(1, $XS_code, $perl_code, "XS is faster")
and maybe
is_n_times_faster(1, 5, $XS_code, $perl_code, "XS is 5 times faster")
But I don't think that was what Jim wanted, it seemed like he was trying to
display benchmark info purely for informational purposes,
F
Re: Test::Benchmark ??
On Thu, Dec 04, 2003 at 10:33:14PM +, Fergal Daly wrote:
> > Another useful sort of test would be "make sure this function runs in less
> > than N perlmips time" where a perlmip is some unit of CPU time calibrated
> > relative to the current hardware. So a pmip on machine A would be
> > roughly twice as long as a pmip on a machine that's twice as fast.
> > This enables us to test "make sure this isn't too slow".
>
> Not so yeah - just like the mip, the pmip would be a bit to elusive and ever
> changing for this to work quite as well as we'd like.
I dunno about that. It doesn't have to be terribly accurate. Its useful
for situations where someone finds a condition that makes your code run
reeally slow.
Calibration would be pretty straight forward. Just have a handful of
loops to run known snippets of Perl and calibrate the pmip based on how long
they take to run. This would change from Perl version to Perl version
and platform to platform, but you can find something that's not off by more
than 25%.
> Anyway to do these you can do
> my $res = timethese(1, {a => $a_code, b => $b_code}, "none");
>
> which will produce no output and $res will contain all the benchmark
> information and you can then perform whatever tests you like on it.
Trick is, these are for tests where you're not comparing two pieces of
code. You want to make sure a single piece of code isn't taking too long.
Again, its a rather coarse grained test.
> is_n_times_faster(1, 5, $XS_code, $perl_code, "XS is 5 times faster")
>
> But I don't think that was what Jim wanted, it seemed like he was trying to
> display benchmark info purely for informational purposes,
For that I'd recommend doing what DBI does and putting the benchmarking
code into test.pl.
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
Sometimes you eat the path, sometimes the path eats you.
Re: Test::Benchmark ??
On Thursday 04 December 2003 22:51, Michael G Schwern wrote: > Calibration would be pretty straight forward. Just have a handful of > loops to run known snippets of Perl and calibrate the pmip based on how long > they take to run. This would change from Perl version to Perl version > and platform to platform, but you can find something that's not off by more > than 25%. I'm not sure about that 25%. Say the pmip calibrator doesn't fit in the CPU cache on any machine, then if the tested algorithm fits in the CPU cache on one machine but not on another then there will be a huge difference in the number of "perl seconds" they require. Worse still, if the pmip calibrator fits in the cache on my fancy new machine I'll probably get lots of false negatives because everything seems taking "perl ages" to run. Then you have the multi user machine where the test passes when the machine is quiet but fails when's there lots of cache contention. You also have a (somewhat rarer) problem with people changing CPUs and not recalibrating their pmips. And the increasingly common laptops with varying clock speeds and voltage stepping etc. If Test::Harness had a protocol for warnings rather than just pass and fail then this would be more useful, F
Re: Test::Benchmark ??
* Michael G Schwern <[EMAIL PROTECTED]> [2003-12-04T16:51:03] > On Thu, Dec 04, 2003 at 05:26:07AM -0500, [EMAIL PROTECTED] wrote: > > I'd say a lot of the trouble comes from the fact that you're using the > > automated test framework for something that isn't an automated test. > > But it could be. It would be nice to have a test like "make sure the > hand optimized version is faster than the unoptimized version" or "make sure > the XS version is faster than the Perl version". If this isn't what he meant, it's what I thought he meant. A T::B that allowed these kinds of tests would be really sweet for a number of applications. Even without the perlmip (which seems cool but further off), this would be great. -- rjbs pgp0.pgp Description: PGP signature
Re: Test::Benchmark ??
On Thu, Dec 04, 2003 at 11:30:47PM +, Fergal Daly wrote: > I'm not sure about that 25%. Say the pmip calibrator doesn't fit in the CPU > cache on any machine, then if the tested algorithm fits in the CPU cache on > one machine but not on another then there will be a huge difference in the > number of "perl seconds" they require. > > Worse still, if the pmip calibrator fits in the cache on my fancy new machine > I'll probably get lots of false negatives because everything seems taking > "perl ages" to run. Then you have the multi user machine where the test > passes when the machine is quiet but fails when's there lots of cache > contention. I disbelieve such low level considerations will manifest themselves as large differences during a single testing process. Remember, perl runs tons of machine code for just one line of Perl. This isn't C. Also, remember this is CPU time, not wallclock. > You also have a (somewhat rarer) problem with people changing CPUs and not > recalibrating their pmips. The recalibration would happen at runtime, not install time. Yes, this will eat a few seconds, but it would be more accurate. C'est le testing. > If Test::Harness had a protocol for warnings rather than just pass and fail > then this would be more useful, print STDERR or diag(). Test::Harness doesn't need to know anything about warnings. If it can't fail its not really a test. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ It's Highball time!
RE: Properties -- distributive, predeclared, post-applied....??
How about
use Baz; # assume object type
my property foo;
my @bar of Baz is false but foo; # maybe not what you meant?
If you apply a trait like false to an array, I expect it to apply to the
"array instance object" itself and not the content, so that
push @bar, Baz.new();
if @bar{ print "stuff"; } else { print "empty"; } # oops! false!
if @bar[0] { print " oops"; } else { print " ok"; } # oops! not false!
would print "empty oops" instead of "stuff ok".
I'd *like* to be able to predeclare a trait or property to be distributed
across any values placed in this array, but only this array. For example, it
would be nice if I could have the default aspects of false and foo be
applied to any Baz that gets stuck into @bar, but obviously this isn't the
syntax to do it. I could make Baz's new() do it, but I don't want *ALL* Baz
objects to be false and foo...just the ones in @bar. So, what I need is
something more like
my @bar of Baz;
@bar.STORE.wrap { my $r = call; return $r >>but=<< (false,foo); }
But I'm not sure C<$r >>but=<< (false,foo)> works, and I really wanted to
figure out a way to do it all in the declaration. Maybe it could be
my @bar of Baz will do STORE.wrap { call >>but=<< (false,foo); }
but I'm not sure call will behave as an lvalue and still set up the
appropriate return, I don't expect @bar to accept "will do", and I don't
think "will do" is where the wrap should go. I'm just trying to wrap my
brain around this brick and I can't find all the references that tell me all
the little pieces so that I can compare them for a closer approximation,
lol
*
"The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers.61"
Re: Properties -- distributive, predeclared, post-applied....??
Hodges, Paul writes:
> How about
>
> use Baz; # assume object type
> my property foo;
> my @bar of Baz is false but foo; # maybe not what you meant?
Definitely not what you meant. Fortunately, the compiler will teach you
a thing or two about it: C is not a trait.
But indeed foo would apply to @bar itself, rather then to any element
that goes into @bar later.
> If you apply a trait like false to an array, I expect it to apply to the
> "array instance object" itself and not the content, so that
> push @bar, Baz.new();
> if @bar{ print "stuff"; } else { print "empty"; } # oops! false!
> if @bar[0] { print " oops"; } else { print " ok"; } # oops! not false!
> would print "empty oops" instead of "stuff ok".
>
> I'd *like* to be able to predeclare a trait or property to be distributed
> across any values placed in this array, but only this array. For example, it
> would be nice if I could have the default aspects of false and foo be
> applied to any Baz that gets stuck into @bar, but obviously this isn't the
> syntax to do it. I could make Baz's new() do it, but I don't want *ALL* Baz
> objects to be false and foo...just the ones in @bar. So, what I need is
> something more like
>
> my @bar of Baz;
> @bar.STORE.wrap { my $r = call; return $r >>but=<< (false,foo); }
Something likely more like:
my role property_wrap[Property [EMAIL PROTECTED] {
method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
}
@bar but= property_wrap[false, foo];
With emphasis on "something". (Extrapolating wildly the little bit I
know about roles and making up some semantics, such as C).
As for just declaring it, um... why would you want to do that? I could
see making the array default to some value with a trait, which is
trivially:
my @bar is default(undef but foo);
But automatically marking every value that ever goes into the array... I
don't see the utility.
> But I'm not sure C<$r >>but=<< (false,foo)> works, and I really wanted to
> figure out a way to do it all in the declaration. Maybe it could be
>
> my @bar of Baz will do STORE.wrap { call >>but=<< (false,foo); }
Yeah, that's definitely not right. C works as follows:
:w will
It's really just a shorthand for C, so you don't have to put parens
around the block.
> but I'm not sure call will behave as an lvalue and still set up the
> appropriate return, I don't expect @bar to accept "will do", and I don't
> think "will do" is where the wrap should go. I'm just trying to wrap my
> brain around this brick and I can't find all the references that tell me all
> the little pieces so that I can compare them for a closer approximation,
> lol
Luke
Re: Properties -- distributive, predeclared, post-applied....??
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Hodges, Paul writes:
> > How about
> >
> > use Baz; # assume object type
> > my property foo;
> > my @bar of Baz is false but foo; # maybe not what you meant?
>
> Definitely not what you meant. Fortunately, the compiler will teach
> you a thing or two about it: C is not a trait.
Duh. I knew I'd do something simple/stupid like that. :)
But you get the idea.
> But indeed foo would apply to @bar itself, rather then to any element
> that goes into @bar later.
>
> > If you apply a trait like false to an array, I expect it to apply
> to the
> > "array instance object" itself and not the content, so that
> > push @bar, Baz.new();
> > if @bar{ print "stuff"; } else { print "empty"; }
> > if @bar[0] { print " oops"; } else { print " ok"; }
> > would print "empty oops" instead of "stuff ok".
> >
> > I'd *like* to be able to predeclare a trait or property to be
> distributed
> > across any values placed in this array, but only this array.
> > For example, it would be nice if I could have the default
> > aspects of false and foo be applied to any Baz that gets stuck
> > into @bar, but obviously this isn't the syntax to do it. I could
> > make Baz's new() do it, but I don't want *ALL* Baz objects to be
> > false and foo...just the ones in @bar. So, what I need is
> > something more like
> >
> > my @bar of Baz;
> > @bar.STORE.wrap { my $r = call; return $r >>but=<< (false,foo); }
>
> Something likely more like:
>
> my role property_wrap[Property [EMAIL PROTECTED] {
> method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
> }
> @bar but= property_wrap[false, foo];
...square brackets?
...roles can have methods? duh, they'd have took
...but, *square* brackets???
And C< but [EMAIL PROTECTED] > looks like "but" is distributive.
I think that's good, but not what I inferred from your last note on the
topic.
> With emphasis on "something". (Extrapolating wildly the little bit I
> know about roles and making up some semantics, such as C [EMAIL PROTECTED]>).
lol -- oh, ok. :)
But it's *good* BS.
> As for just declaring it, um... why would you want to do that?
> I could see making the array default to some value with a trait,
> which is trivially:
>
> my @bar is default(undef but foo);
>
> But automatically marking every value that ever goes into the
> array... I don't see the utility.
Nothing that couldn't be done in a dozen other ways, but this is one
way that I like. It's perhaps a slightly contrived situation, but one I
hope might shed some light on the semantics so that I can learn to use
them when they're a better solution that the kludges I so often end up
with.
In other words, there's always the possibility of doing it another way.
Any object-oriented code functionality could be replicated by purely
functional code, but sometimes you'd end up having to design entire
paradigms to replace some of the functionalities. It's just a mindset
issue, though I will readily confess that my mind is usually set at
wierd angles.
Usually I end up keeping track of some feature by putting all things
with this feature into THIS array and all things like that into THAT
array or some such parallel silliness. It works, and is faster than
practically any object code on our poor old nag of a workhorse server,
but then if I have to know which stack something came from when I send
it to a sub I have to include another argument. There are LOTS of
alternate ways to mark things, but I like this one.
> > But I'm not sure C<$r >>but=<< (false,foo)> works, and I really
> > wanted to figure out a way to do it all in the declaration. Maybe
> > it could be
> >
> > my @bar of Baz will do STORE.wrap { call >>but=<< (false,foo); }
>
> Yeah, that's definitely not right. C works as follows:
>
> :w will
>
> It's really just a shorthand for C, so you don't have to put
> parens around the block.
But subs in A6 have a "will do", though I presume the do is optional?
Hmmstill aware that this isn't a sub declaration,
my @bar of Baz will init {
.STORE.wrap { call >>but=<< (false,foo); }
}
I still like the idea that call could set itself up as an lvalue.
~smirk~
So is it possible that this is a valid way to declare a container with
modified methods all at once?
__
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
Re: Properties -- distributive, predeclared, post-applied....??
Paul Hodges writes:
> Luke Palmer:
> > Something likely more like:
> >
> > my role property_wrap[Property [EMAIL PROTECTED] {
> > method STORE($newval) { SUPER::STORE($newval but [EMAIL PROTECTED]) }
> > }
> > @bar but= property_wrap[false, foo];
>
> ...square brackets?
> ...roles can have methods? duh, they'd have took
> ...but, *square* brackets???
Yeah. Classes use square brackets when they're parametric, so I could
only assume roles do, too. That is, if you haven't seen this before:
class RingBuffer[$size, Class ?$of = Any] {
has @.buffer of $of is dim($size);
has ($.front, $.back, $.fill);
method push($elem of $of) returns Void {
@.buffer[$.back++] = $elem;
$.back %= $size;
$.fill++;
}
method shift() returns $of {
if $.fill <= 0 { throw X::BufferEmpty } # predeclared
return @.buffer[$.front++];
LAST { $.front %= $size }
}
}
I do have one question for the almighty gods, however. Can you
explicitly use the :: sigil to make a lexical parametric class, as in:
class RingBuffer[$size, ?::of = Any] {
has of @.buffer;
}
Well, modulo the possible ambiguity of the keyword of. Perhaps ::of
would have to be there, too...?
> And C< but [EMAIL PROTECTED] > looks like "but" is distributive.
> I think that's good, but not what I inferred from your last note on the
> topic.
I didn't say anything about C not distributing over its I
argument :-) It does, after all, make sense, as you'd probably not be
allowed to mark a property with the @ sigil.
> > As for just declaring it, um... why would you want to do that?
> > I could see making the array default to some value with a trait,
> > which is trivially:
> >
> > my @bar is default(undef but foo);
> >
> > But automatically marking every value that ever goes into the
> > array... I don't see the utility.
[snip]
> Usually I end up keeping track of some feature by putting all things
> with this feature into THIS array and all things like that into THAT
> array or some such parallel silliness. It works, and is faster than
> practically any object code on our poor old nag of a workhorse server,
> but then if I have to know which stack something came from when I send
> it to a sub I have to include another argument. There are LOTS of
> alternate ways to mark things, but I like this one.
Oh, okay.
And declarative is usually much nicer to read than procedural, so that
makes sense.
As far as I can tell, it's not possible without building some machinery
yourself, like we did above. That's okay though: we should be expected
to program generic solutions every once in awhile.
> > > But I'm not sure C<$r >>but=<< (false,foo)> works, and I really
> > > wanted to figure out a way to do it all in the declaration. Maybe
> > > it could be
> > >
> > > my @bar of Baz will do STORE.wrap { call >>but=<< (false,foo); }
> >
> > Yeah, that's definitely not right. C works as follows:
> >
> > :w will
> >
> > It's really just a shorthand for C, so you don't have to put
> > parens around the block.
>
> But subs in A6 have a "will do", though I presume the do is optional?
You can leave out the C if you like, but you also have to leave out
the C in that case. For instance:
sub foo() { ... }
Is short for:
sub foo() will do { ... }
Which is in turn short for:
sub foo() is do({ ... })
Er, for some definition of 'short' :-)
> Hmmstill aware that this isn't a sub declaration,
>
> my @bar of Baz will init {
> .STORE.wrap { call >>but=<< (false,foo); }
> }
>
> I still like the idea that call could set itself up as an lvalue.
> ~smirk~
>
> So is it possible that this is a valid way to declare a container with
> modified methods all at once?
It would seem so. It's not a particularly clean one (even though it may
be clean *looking*). You might be able to do some jazz like this:
my Baz @bar but property {
method STORE($elem) { call($elem but (false, foo)) }
}
Where you're applying an anonymous property.
Luke
[COMMIT] A few imcc tweaks
As discussed in the last IMCC RFC, I've committed a few of the changes. IMCC will now generate an error if the register type is unknown rather than just assign it a PMC register. P reg types are pmc, object, or a valid classname. Use pmc or object for "generic" P register to defer type checking. I think a few compilers will now be broken but the patches should be very simple to fix them. Also allow sub names without _ prepended, and allow @ to start labels. Tweak the fixup code a bit to use flags rather than looking for _ in symbol name. Added parser stubs for .global to grammar. -Melvin
