I scare me.
I'm sure it needs a few tweaks, but I've managed to write a hq9+ interpreter in pasm. [insert deity here] help us all. :-) Any thoughts on this? http://www.thetasigma.com/parrot/ dha -- David H. Adler - <[EMAIL PROTECTED]> - http://www.panix.com/~dha/ "It's all eggs, bacon, beans and a fried slice." - Madness
Re: Perl 6's for() signature
On Fri, Aug 01, 2003 at 11:01:15PM +0100, Simon Cozens wrote: : [EMAIL PROTECTED] (Damian Conway) writes: : > The last thought on the problem that Larry's shared with me was that there : > may need to be a special case for allowing a single &block parameter after : > the slurpy : : And the Rubyometer creeps up another few notches... It's long been planned to allow blocks anywhere in the signature, particularly at the end, because of endweight considerations. It's been on my Perl 5 wish list since long before I ever heard of Ruby. In fact, the first thing I thought when I saw how Ruby did it was, "Gee, why did he restrict it to only be the last thing?" In Ruby it's a special case syntax. We're making a general capability to put the block anywhere in the argument list. If that makes Perl more like Ruby, so be it. But Perl is not terribly worried about where it fits on the Rubyometer. Ruby will need to worry about where it fits on the Perlometer. : (Gosh, you'd almost think that Matz had already thought through some of these : issues, wouldn't you? ;) Certainly Matz thought about some of these issues. Whether he would claim to have thought them "through" is another matter. There are many throughways, and they don't all lead the same place. It's easy to tunnel into a false minimum and think you're "through". Larry
Re: Blurring the line between assertions and tests
On Friday, August 1, 2003, at 09:07 pm, Michael G Schwern wrote: [snip] I was thinking about inline testing, Test::Class and such and how it would be nice if we could just write test functions right in our code, like assertions. Like Carp::Assert::More, but I want all the Test:: stuff available. [snip] Eeen-teresting... random thoughts... - Rather than running tests at live time, I'm more often doing the opposite. I have assertions that I only want to switch on at testing time since that is when I'm exercising things that might break. - This sort of thing always makes me think of things design-by-contract... I'm sure there is some useful intersection between automated tests and DBC - but I've yet to feel bright enough to work it out. - I think the idea of being able to run tests as assertions is a cute one worth exploring. Just having a T::B subclass that died rather than log anything would be a boon. Giving us all the goodness of the T::B based functions for normal assertions. - You'd probably want an option to pop a stack trace next to the test output (maybe only for failing tests?) - Option just to log failing tests might be useful? Nice idea! Adrian
Re: Blurring the line between assertions and tests
Michael G Schwern wrote in perl.qa : > The only part missing is the ability to shut the tests off once you've > released it to production. You could perhaps use the assertion feature of perl >= 5.9.0 (assertion.pm and -A switch -- yes I know it lacks docs.)
Re: Blurring the line between assertions and tests
Make that... http://www.pobox.com/~schwern/src/Test-AtRuntime-0.01.tar.gz -- I knew right away that my pants and your inner child could be best friends.
Re: Blurring the line between assertions and tests
On Fri, Aug 01, 2003 at 01:07:15PM -0700, Michael G Schwern wrote:
> Another way is to use a TEST: block
> and have Filter::Simple strip them out.
>
> TEST: {
> cmp_ok( ... );
> }
> Questions? Comments? Approval?
Hell, why wait for wiser heads?
http://www.pobox.com/~schwern/Test-AtRuntime-0.01.tar.gz
The only problem is it requires 5.8.1. Something in either Test::Builder
or Filter::Simple (or a combination) causes the tests to segfault with
anything eariler. :(
http://www.iki.fi/jhi/perl-5.8.1-RC4.tar.bz2
http://www.iki.fi/jhi/perl-5.8.1-RC4.tar.gz
--
Stupid am I? Stupid like a fox!
Re: Junctions & Set Theory
> Hello,
>
> Do junctions have a direct representation as predicate logic statements?
Yes. Damian and I have already worked them out in a link I have
already posted today:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=3DF2FE76.6050602%40conway.org&rnum=2
> In particular, do the following logic statements correspond directly
> to the following perl6 junctions:
>
> LOGIC PERL6 JUNCTION (DESCRIP)
> =
> (forall x)(x is true) all (conjunction)
> (exists x)(x is true) any (disjunction)
> (forall x)(x is false) none (injunction)
> (exists x)(x is false) one (abjunction)
>
> I don't have a really clear understanding of junctions (which is why I'm
> posting this message, to try to clarify junctions in relation to a topic
> I'm more familiar with), but it seems that the fourth type of junction,
> "one" is inconsistent with the logic definition.
>
> Maybe "one" should be named "one_isnt", or the logic statement should
> become (exists a single x)(x is true).
Yeah, the latter. The thing about one_isnt is that it is exactly the
same as all() except for its behavior when given no arguments. I
don't see that as particularly useful...
> Either way, maybe another junction is needed!
Don't think so.
I think it's important to make it easy to add new junctive types,
however. So perhaps Junction is an abstract class which requires the
definition of the two methods prefix:? () and states(). Then, to make
one_isnt:
class Indisjunction is Junction {
method prefix:? () {
? grep { !$_ } self.args
}
method states () {
die "Not smart enough to write this one"
}
}
sub one_isnt([EMAIL PROTECTED]) {
new Nondisjunction: @args
}
Luke
>
> Derek Ross.
Re: Junctions & Set Theory
On Fri, 1 Aug 2003, Derek Ross wrote: > Do junctions have a direct representation as predicate logic statements? > In particular, do the following logic statements correspond directly > to the following perl6 junctions: > > LOGIC PERL6 JUNCTION (DESCRIP) > = > (exists x)(x is false) one (abjunction) > > I'm more familiar with), but it seems that the fourth type of junction, > "one" is inconsistent with the logic definition. > > Maybe "one" should be named "one_isnt", or the logic statement should > become (exists a single x)(x is true). Either way, maybe another > junction is needed! The logic statement should become (exists a unique x) (x is true). This is typically written (exists!)(x is true). No other junction should be necessary: If you want to say that something is *false* for at least one of the values, you can just rephrase that as not (true for all values). On the other hand, if you wanted to say "true for all except exactly one value, I can't think of a way. (but then, nor of a reason for wanting to). > Derek Ross. Abhi.
Re: [perl #23186] [PATCH] adding "yield" semantics to IMCC
From: Leopold Toetsch <[EMAIL PROTECTED]> Date: Fri, 1 Aug 2003 14:50:05 +0200 Kenneth A Graves <[EMAIL PROTECTED]> wrote: > Inside the iterator, there are three differences compared to a function: > 1) Every register in use needs to be saved to the user stack. (Anyone > have a clean way to do this?) Its the same thing as calling a subroutine in the first place. Imcc has to figure out, which registers are used (and which are persistent over the function call). With this info the register allocation as well as the necessary register save/restore opcodes can be optimized. When this is done, the same logic applies to the .pcc_*_yield block. Is there a stub of this functionality in the code somewhere? (Or some notes about how it might be approached?) I'm either going to have to put this in the CLU compiler, or in IMCC. Advantage of the first is that I'm working in Perl instead of C. (My C is *way* rusty.) Advantage of the second is that someone else will get use out of it. --kag
Re: problem with register allocation
Date: Fri, 1 Aug 2003 22:46:29 +0200 From: Stéphane Payrard <[EMAIL PROTECTED]> I am trying to learn about continuations and Parrot. I hit a problem of register allocation. I don't know if it is a miscomprehension from me or a bug. Probably the former. Apparently P16 is used both for my Perlhash and the Sub. Below are the beginning of a pdb session and the PIR listing. This is very similar to the problem I encountered using coroutines to implement iterators. My solution is to push all local variables onto the user stack before invoke, then pop them off afterwards. (Similar to how the coroutine tests are written.) I'm not following your code well enough to be sure, but something similar in the mk_one routine (save test, invoke P1, restore test) might be appropriate. --kag
Junctions & Set Theory
Hello, Do junctions have a direct representation as predicate logic statements? In particular, do the following logic statements correspond directly to the following perl6 junctions: LOGIC PERL6 JUNCTION (DESCRIP) = (forall x)(x is true) all (conjunction) (exists x)(x is true) any (disjunction) (forall x)(x is false) none (injunction) (exists x)(x is false) one (abjunction) I don't have a really clear understanding of junctions (which is why I'm posting this message, to try to clarify junctions in relation to a topic I'm more familiar with), but it seems that the fourth type of junction, "one" is inconsistent with the logic definition. Maybe "one" should be named "one_isnt", or the logic statement should become (exists a single x)(x is true). Either way, maybe another junction is needed! Derek Ross.
Re: Perl 6's for() signature
[EMAIL PROTECTED] (Damian Conway) writes: > The last thought on the problem that Larry's shared with me was that there > may need to be a special case for allowing a single &block parameter after > the slurpy And the Rubyometer creeps up another few notches... (Gosh, you'd almost think that Matz had already thought through some of these issues, wouldn't you? ;) -- Will your long-winded speeches never end? What ails you that you keep on arguing? -- Job 16:3
Blurring the line between assertions and tests
I had an idea yesterday. On more than one occassion, a I've been asked
about running tests against a live site. My usual waffle is to talk about
assertions or to build a seperate test suite which is explicitly non-modifying.
Or something Skud came up with which was to tag blocks of tests in the suite
as "modifying" and not run them against a live site.
That's always felt kind of artificial. Tests are supposed to tell you
something's wrong. Having to run a suite against a live site is more like
running the tests *after* you've found out something's wrong. And then
I was thinking about inline testing, Test::Class and such and how it would
be nice if we could just write test functions right in our code, like
assertions. Like Carp::Assert::More, but I want all the Test:: stuff
available.
I think this can be done with a simple Test::Builder subclass and
attribute changes. Turn numbering off (since you don't know what order
they'll get run in, so its kind of meaningless, or if the thing will fork).
Set no_plan, since the tests would come continuously. Redirect output to a
log file... and that should be it. Then you can write:
sub day_of_week {
...
cmp_ok( $dow, '<=', 7 );
cmp_ok( $dow, '>=', 1 );
return $dow;
}
Every time day_of_week() is run those two tests get run and go to a log file.
The only part missing is the ability to shut the tests off once you've
released it to production. That's tricky. The cheap way to do it is
what Carp::Assert uses, a constant.
cmp_ok( ... ) if DEBUG;
Its wonky, but it works without fail. Another way is to use a TEST: block
and have Filter::Simple strip them out.
TEST: {
cmp_ok( ... );
}
Filtering makes me nervous, but the syntax is clean and the code will be
100% removed (at some startup cost).
Finally, there could be a TEST function which gets passed a subroutine
reference and use Sub::Uplevel to trick it into thinking its getting called
one level up...
TEST {
cmp_ok( ... );
}
This'll work, but the TEST() function will always get called, even if its
just "return if $Not_Testing" that can get expensive in hot loops.
I could do all three. :)
Questions? Comments? Approval?
--
Beer still cheaper than crack!
Re: E6 question
Mark J. Reed wrote:
Is it possible with the new parameter declaration syntax to declare
a mandatory name-only parameter?
Probably. I think that the '?', '*', and '+ prefixes are abbreviations for
traits (C, C, C). So a named,
mandatory parameter would be:
sub foo($bar is named) {...}
Alternatively, you could just specify a mandatory parameter that has to be a Pair:
sub foo(Pair $bar) {...}
(though then you'd have to use C<$bar.value> for the value).
Damian
Re: E6: assume nothing
I wrote:
> Damian explains:
> > Trey asked:
> >
> > > To take the E6 example of currying &part:
> > >
> > >&List::Part::part.assuming(labels => <>)
> > >
> > > One had to curry in C to be the same as it was defined in C<&part>
> > > originally, i.e. C<< <> >>.
> > >
> > > What if one wanted to curry in whatever the default is, i.e., assuming
> > > "nothing" (different from "assuming nothing"), so that if List::Part::part
> > > changed its default for C to C<< <> >>, the client
> > > code would pick that up?
> >
> > If you're assuming "nothing", don't use C<.assuming> (since you aren't ;-)
> > Just write:
> >
> > sub my_part(Selector $s, [EMAIL PROTECTED]) { part $s <== *data }
> >
> > and let C<&part> do the assuming for you.
>
> Gee, that's about as helpful as saying to do &baz.assuming(foo => 'bar'):
>
> sub my_baz([EMAIL PROTECTED]) {
> baz foo => 'bar' <== [EMAIL PROTECTED]
> }
>
> Wasn't the whole idea of assuming to make it easy to curry without
> knowing the entire signature, and being tolerant to changes? I see a
> simple solution:
>
> our &my_part := &part.assuming('labels');
>
> Or, maybe if we're caught up on readability (and error checking):
>
> our &my_part := &part.assuming(none 'labels');
Here's a wacky idea. We have C for for undefined, and
C to check it. We have C to check existance, so,
(hold your breath) C.
A synonym of:
delete %h{foo};
would be
%h{foo} = nonex;
To assume that a value wasn't provided:
our &my_part := &part.assuming(labels => nonex);
And to declaratively copy a hash but delete a key:
{
%other,
baz => nonex,
}
> Luke
>
> > Damian
Re: problem with register allocation
Luke Palmer wrote: I think we should remove nested subs from imcc, because they aren't buying us anything and are only causing confusion. Yep. Melvin is for this too. I said, there are users of this "feature", so be careful, but again another one falling into the very same trap ... The user base of parrot and the PIR compiler seems currently increasing very much, so lets toss that now, before its to late. I'll change the docs into stating "code outside of compilation unit is deprecated", another announcement + actually removing this from the source will follow. Luke leo
Re: E6: assume nothing
> Trey asked:
>
> > To take the E6 example of currying &part:
> >
> >&List::Part::part.assuming(labels => <>)
> >
> > One had to curry in C to be the same as it was defined in C<&part>
> > originally, i.e. C<< <> >>.
> >
> > What if one wanted to curry in whatever the default is, i.e., assuming
> > "nothing" (different from "assuming nothing"), so that if List::Part::part
> > changed its default for C to C<< <> >>, the client
> > code would pick that up?
>
> If you're assuming "nothing", don't use C<.assuming> (since you aren't ;-)
> Just write:
>
> sub my_part(Selector $s, [EMAIL PROTECTED]) { part $s <== *data }
>
> and let C<&part> do the assuming for you.
Gee, that's about as helpful as saying to do &baz.assuming(foo => 'bar'):
sub my_baz([EMAIL PROTECTED]) {
baz foo => 'bar' <== [EMAIL PROTECTED]
}
Wasn't the whole idea of assuming to make it easy to curry without
knowing the entire signature, and being tolerant to changes? I see a
simple solution:
our &my_part := &part.assuming('labels');
Or, maybe if we're caught up on readability (and error checking):
our &my_part := &part.assuming(none 'labels');
Luke
> Damian
Re: %_ - is it available for use?
Nick Ing-Simmons wrote: We have been discussing how to pass data to Tk callbacks. In particular Entry widget validation routines. There are a number of items that they _might_ be interested in but a typical routine would only use a few. Currently it passes them all as positional parameters. One idea that occured to me/us is to have a "localized" hash for this purpose (which might be tied/magical). One choice of name for this is %_ - which fits neatly with @_ for positional args and $_ as current thing. Also *_ glob already exists to have its GvHV entry (ab-)used. What does p5p think of this use ? Basically @_ says "how" you been called $_ is "what" you are working on, and this idea gives %_ the meaning of "why". (Caller gives the "who" ;-) ) From a Perl 6 perspective, it seems likely that C<%_> will be the name commonly used for the "slurpy hash" of a subroutine. Just as C<@_> will often be the name used for the "slurpy array". See Exegesis 6 for more details. Indeed, when it comes to object constructors (all of which implicitly have a slurpy hash), C<%_> might well be the automatically provided name for that hash. See Exegesis 12 for more details. ;-) Hence, making C<%_> mean something different in core Perl 5 might possibly be "forwards incompatible". Damian
Re: E6: assume nothing
Trey asked:
To take the E6 example of currying &part:
&List::Part::part.assuming(labels => <>)
One had to curry in C to be the same as it was defined in C<&part>
originally, i.e. C<< <> >>.
What if one wanted to curry in whatever the default is, i.e., assuming
"nothing" (different from "assuming nothing"), so that if List::Part::part
changed its default for C to C<< <> >>, the client
code would pick that up?
If you're assuming "nothing", don't use C<.assuming> (since you aren't ;-)
Just write:
sub my_part(Selector $s, [EMAIL PROTECTED]) { part $s <== *data }
and let C<&part> do the assuming for you.
Damian
Re: imcc's
Joseph F. Ryan <[EMAIL PROTECTED]> wrote: > I think you should try to implement lamda through .Sub's. Take a look > at parrot/t/pmc/sub.t for some examples. However, you might not be > able to rely on IMCC to handle arguments and results so much, since I > don't think IMCC uses the new cps calling style yet. (but I'm not > sure, so don't hold me to that :) First yep, as already stated in another f'up. Regarding the state of Parrot calling conventions inside the imcc part of parrot: - calling a sub in done (prototyped, non_prototyped) - receiving params in sub too (prototyped, non_prototyped, both) - type checking for non_protoyped cases seems also to be quite fine - return values need more work (Dan promised to do more specs on that) currently prototyped return values are working. All overflow stuff (more then 11 args of one register kind) is totally untested and might kill your dog if you use it - or it works. leo
Re: imcc's "call" vs first class functions
Michal Wallace <[EMAIL PROTECTED]> wrote: > Hey all, > I've got lambda (single-expression anonymous subroutine) > working in pirate now, but I wasn't sure how to get it > to do the correct calling convention with IMCC's "call". I'm pretty sure, that you should use Parrot calling conventions for all subs, the more that subs are objects inside Pie-thon. >print (lambda x: x+1)(0) # prints "1\n" > jsr $I1 :( why can't I "call"?### The register based j* branches take an absolute address. Imcc has no way to find out where the branch will go in the general case. Using these opcodes is almost unsopported inside imcc. With Parrot calling conventions and an appropriate subroutine object you can achieve the same effect, with additional context saving as needed. While this jump opcode may be needed somewhen (what for? - or even get tossed), all effort currently goes into PCC and optimizing that stuff finally. Further information: docs/pdds/pdd03_calling_conventions.pod docs/pmc/sub.pod languages/imcc/docs/calling_conventions.pod > Sincerely, > > Michal J Wallace leo
Re: Perl 6's for() signature
FWIW, we're aware of the problem. I posed this very question to Larry a few months back, when I was writing E6. We're still mulling over the correct answer. The last thought on the problem that Larry's shared with me was that there may need to be a special case for allowing a single &block parameter after the slurpy (which would then be popped off the parsed arg list before slurpification). I don't think either Larry or I thinks that's ideal, so we'll probably keep working towards a better (more general) solution to the problem. Damian
Re: problem with register allocation
> Hi everybody, > > That was nice to meet many of you in person at YAPC::EU, > > I am trying to learn about continuations and Parrot. I hit a > problem of register allocation. I don't know if it is a > miscomprehension from me or a bug. Probably the former. > Apparently P16 is used both for my Perlhash and the Sub. > Below are the beginning of a pdb session and the PIR listing. > > -- > stef > > > (pdb) l > 1 new_p_ic P16,23 > 2 newsub_p_ic_ic P16,31,31 > > > .local PerlHash penta2d > .const string str_nm = "U" > > .sub _main > new penta2d, .PerlHash Miscomprehension, but a very common one. IMCC .local variables aren't closed upon, so you can only use them within a single sub (in this case, the outer sub which has no enclosing .sub/.end). So, either pass it as a parameter or set a global or lexical with its value. I think we should remove nested subs from imcc, because they aren't buying us anything and are only causing confusion. Luke > .local Sub sub > .local Continuation cc > newsub sub, .Sub, _mk_one > newsub cc, .Continuation, ret > .pcc_begin prototyped > .pcc_call sub, cc > ret: > .pcc_end > > end > .end > > .pcc_sub _mk_one >.local int test >exists test, penta2d[str_nm] >invoke P1 > .end
problem with register allocation
Hi everybody, That was nice to meet many of you in person at YAPC::EU, I am trying to learn about continuations and Parrot. I hit a problem of register allocation. I don't know if it is a miscomprehension from me or a bug. Probably the former. Apparently P16 is used both for my Perlhash and the Sub. Below are the beginning of a pdb session and the PIR listing. -- stef (pdb) l 1 new_p_ic P16,23 2 newsub_p_ic_ic P16,31,31 .local PerlHash penta2d .const string str_nm = "U" .sub _main new penta2d, .PerlHash .local Sub sub .local Continuation cc newsub sub, .Sub, _mk_one newsub cc, .Continuation, ret .pcc_begin prototyped .pcc_call sub, cc ret: .pcc_end end .end .pcc_sub _mk_one .local int test exists test, penta2d[str_nm] invoke P1 .end
Re: imcc's "call" vs first class functions
If I understood well, the problem is that subroutines can be saved in variables, right (or registers for that matter)? So, if there is some subroutine "f", you could just do: $I1 = addr _f# get address of subroutine f $P1 = new Sub# create a new Sub PMC $P1 = $I1# store address of f into this Sub global "f" = $P1# now the variable "f" represents this sub. When calling f, one could do: $P0 = global "f"# get current 'value' of "f" # do calling conv. stuff invoke # or invokecc? I don't know which invoke op exactly Correct me if I'm wrong, but IMCC's "call" is translated to a "bsr" op, so it's just a jump. I don't know if IMCC already has support for invoke and the like...(I'm not the expert ;-) Well, I used this solution, don't know if it's any good...(worked for me though) Klaas-Jan - Original Message - From: "Michal Wallace" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 01, 2003 10:49 AM Subject: imcc's "call" vs first class functions > > Hey all, > > I've got lambda (single-expression anonymous subroutine) > working in pirate now, but I wasn't sure how to get it > to do the correct calling convention with IMCC's "call". > > For example, pirate turns this: > >print (lambda x: x+1)(0) # prints "1\n" > > into this: (the commented line is the important one) > > .sub __main__ > setline 1 > $I2 = addr _sub1 > $I1 = $I2 > .local object arg1 > arg1 = new PerlInt > arg1 = 0 > .arg arg1 > > jsr $I1 :( why can't I "call"?### > > .result $P1 > .arg $P1 > call __py__print > print "\n" > end > .end > .sub _sub1 > # lambda from line 1 > saveall > .param object x > .local object res1 > $P1 = new PerlInt > $P1 = x > $P2 = new PerlInt > $P2 = new PerlInt # yes, this is a bug :) > $P2 = 1 > $P3 = new PerlInt > $P3 = $P1 + $P2 > res1 = $P3 > .return res1 > restoreall > ret > .end > > > This code works, but it doesn't follow the convention. > I was hoping to use call for this, but I couldn't get it > to work, because I'm not directly calling _sub1. > > Actually, in this case I probably could do that, since > it's anonymous, but python has first-class functions, > which means you can do this: > >a = b = c = lambda x: x+1 >assert a(1) == b(1) == c(1) > > And then you can call a() or b() or whatever. Basically, > python needs to look up the function's address at runtime > and I couldn't figure out how to make that happen with > call... So I just did jsr for now, hoping someone could > tell me how to fix it. > > Is that even possible with "call"? If not, we can just > hard code the instructions, but it seems like it really > ought to be in imcc. :) > > > Sincerely, > > Michal J Wallace > Sabren Enterprises, Inc. > - > contact: [EMAIL PROTECTED] > hosting: http://www.cornerhost.com/ > my site: http://www.withoutane.com/ > -- > >
RE: imcc's
I think you should try to implement lamda through .Sub's. Take a look at parrot/t/pmc/sub.t for some examples. However, you might not be able to rely on IMCC to handle arguments and results so much, since I don't think IMCC uses the new cps calling style yet. (but I'm not sure, so don't hold me to that :) You also might want to take a look at how languages/perl6 generates them, at P6C::IMCC::Sub (actually in the file perl6/P6C/IMCC.pm), although it still uses an older calling style. -Original Message- Date: Fri 08/01/03 1:49 PM From: Michal Wallace <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: Subject: imcc's "call" vs first class functions Hey all, I've got lambda (single-expression anonymous subroutine) working in pirate now, but I wasn't sure how to get it to do the correct calling convention with IMCC's "call". For example, pirate turns this: print (lambda x: x+1)(0) # prints "1\n" into this: (the commented line is the important one) .sub __main__ setline 1 $I2 = addr _sub1 $I1 = $I2 .local object arg1 arg1 = new PerlInt arg1 = 0 .arg arg1 jsr $I1 :( why can't I "call"?### .result $P1 .arg $P1 call __py__print print "\n" end .end .sub _sub1 # lambda from line 1 saveall .param object x .local object res1 $P1 = new PerlInt $P1 = x $P2 = new PerlInt $P2 = new PerlInt # yes, this is a bug :) $P2 = 1 $P3 = new PerlInt $P3 = $P1 + $P2 res1 = $P3 .return res1 restoreall ret .end This code works, but it doesn't follow the convention. I was hoping to use call for this, but I couldn't get it to work, because I'm not directly calling _sub1. Actually, in this case I probably could do that, since it's anonymous, but python has first-class functions, which means you can do this: a = b = c = lambda x: x+1 assert a(1) == b(1) == c(1) And then you can call a() or b() or whatever. Basically, python needs to look up the function's address at runtime and I couldn't figure out how to make that happen with call... So I just did jsr for now, hoping someone could tell me how to fix it. Is that even possible with "call"? If not, we can just hard code the instructions, but it seems like it really ought to be in imcc. :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ -- -- This message was sent using 3wmail. Your fast free POP3 mail client at www.3wmail.com
Set vs. Assign..?
Hi, all. I've been following Parrot development and been playing with Parrot for a...bout a year and a half, now. First time posting to the list, though, so forgive me if this has already been covered or is stupid in some way :-) Anyway, while playing around with IMCC, this kind of bugged me: P3 = 32 # tells the PMC referenced by P3 to set its value to 32 P3 = P5 # copies reference in P5 to P3 What I don't like about this is that it's not immediately obvious from looking at the code whether you're telling P3 to change its value or simply replace the PMC reference stored in P3 with another. As I understand it, this is how it works at the assmbly level: set Px, Iy# alters the PMC referenced by Px set Px, Py# only copies a reference assign Px, Py # alters the PMC referenced by Px Whether you copy a reference or just tell the referenced object to change itself depends on the type of the operands. It would be less confusing if you had to be explicit about what you were doing: assign Px, 3 # Tells Px to set its value to 3 set Px, 3 # Compile error. You can't set a PMC reference to an int! WTF? Similarly, set Sx, Ix would barf on you, while assign Sx, Ix would do what you want, and set Sx, Sy would still be perfectly legal. And assign Ix, Iy would throw a fit because you cannot really 'change' an integer, but only replace it with another, and set Ix, Iy would still be correct. So: "set" would consistantly copy references, while "assign" asks the object currently referenced to change its value, somehow. perhaps PASM's "set" <=> IMCC's "=", while PASM's "assign" <=> IMCC's "<=" or something :-P Once again, sorry if this is dumb. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
imcc's "call" vs first class functions
Hey all, I've got lambda (single-expression anonymous subroutine) working in pirate now, but I wasn't sure how to get it to do the correct calling convention with IMCC's "call". For example, pirate turns this: print (lambda x: x+1)(0) # prints "1\n" into this: (the commented line is the important one) .sub __main__ setline 1 $I2 = addr _sub1 $I1 = $I2 .local object arg1 arg1 = new PerlInt arg1 = 0 .arg arg1 jsr $I1 :( why can't I "call"?### .result $P1 .arg $P1 call __py__print print "\n" end .end .sub _sub1 # lambda from line 1 saveall .param object x .local object res1 $P1 = new PerlInt $P1 = x $P2 = new PerlInt $P2 = new PerlInt # yes, this is a bug :) $P2 = 1 $P3 = new PerlInt $P3 = $P1 + $P2 res1 = $P3 .return res1 restoreall ret .end This code works, but it doesn't follow the convention. I was hoping to use call for this, but I couldn't get it to work, because I'm not directly calling _sub1. Actually, in this case I probably could do that, since it's anonymous, but python has first-class functions, which means you can do this: a = b = c = lambda x: x+1 assert a(1) == b(1) == c(1) And then you can call a() or b() or whatever. Basically, python needs to look up the function's address at runtime and I couldn't figure out how to make that happen with call... So I just did jsr for now, hoping someone could tell me how to fix it. Is that even possible with "call"? If not, we can just hard code the instructions, but it seems like it really ought to be in imcc. :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: E6: Small Junctions
> "Mark J. Reed" <[EMAIL PROTECTED]> > > Quick, dumb question: what is an "abjunction"? How does it differ > > from a junction? > > An abjuction requires that none of its members match. For example, > ($a == none(1,2,3)) is true for any value of $a except 1, 2 or 3. Actually, no :-) disjunction: any() conjunction: all() abjunction: one() injunction: none() So an abjunction is a junction requiring that exactly one of its elements match. I don't see much use for it, but I haven't worked with Perl 6 junctions in practice yet. It'll probably come in handy about as often as logical xor does. Luke > Dave.
Re: E6: Small Junctions
> In E6, Damian write: "A junction is a single scalar value that can act like
> two or more values at once".
>
> Whenever I see a statement like this, I tend ask myself "What happenned to
> zero and one?". Perhaps its intentional; perhaps its sloppy writing. What
> issues arise with junctions of 0 or 1 members?
[snip]
> So is a junctions of zero and one elements valid? Abjunctions don't seem to
> have any problems with the concept.
See Damian's reply to "Perl 6 and Set Theory" for all the formal
logical operations.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=3DF2FE76.6050602%40conway.org&rnum=2
I'll explain here by example:
if $something > any() { "Never executed" }
if $something > all() { "Always executed" }
if $something > one() { "Never executed" }
if $something > none() { "Always executed" }
That has to do with whether the selector is universal or existential.
Basically, for any() and one(), there don't exist any elements to make
the hypothesis true. For all() and none(), there don't exist any
elements to refute the hypothesis.
For each one of these except none(), a junction of one element is
exactly equivalent to that single element itself (plus the junctive
operations).
Luke
>
> Dave.
Re: E6: Small Junctions
"Mark J. Reed" <[EMAIL PROTECTED]> > Quick, dumb question: what is an "abjunction"? How does it differ > from a junction? An abjuction requires that none of its members match. For example, ($a == none(1,2,3)) is true for any value of $a except 1, 2 or 3. Dave.
Re: E6: Small Junctions
On 2003-08-01 at 09:54:57, Dave Whipp wrote: > A junction on one element is almost always redundant, and can be cast > directly into the scalar that is its eigenstate. The only issue with doing > that is that certain junction methods might not be available. However, in > the case of a C, an abjunction of one member is meaningful. Quick, dumb question: what is an "abjunction"? How does it differ from a junction? -Mark
E6: Small Junctions
In E6, Damian write: "A junction is a single scalar value that can act like
two or more values at once".
Whenever I see a statement like this, I tend ask myself "What happenned to
zero and one?". Perhaps its intentional; perhaps its sloppy writing. What
issues arise with junctions of 0 or 1 members?
A junction on one element is almost always redundant, and can be cast
directly into the scalar that is its eigenstate. The only issue with doing
that is that certain junction methods might not be available. However, in
the case of a C, an abjunction of one member is meaningful.
Junctions of zero elements are interesting in another way. Consider:
if $a > any(@values) {...}
If there are no @values, is the condition true or false? I think intuition
says its false (because there is no value of @values for which it is true)
if $a <= all(@values) {...}
I find this one slightly harder to intuit. It appears to be a direct flip of
the previous case (there are no members of @values that are greater than @a;
so all must be less than or equal to a). But there are no members of
@values, so its never true, either. Perhaps the result is none(true,false)
which, given that we don't have true/false keywords, becomes: none(
none(0,"",undef), any(0,"",undef) ), which I think simplifies to
"none(none())".
So is a junctions of zero and one elements valid? Abjunctions don't seem to
have any problems with the concept.
Dave.
Re: Perl 6's for() signature
> [EMAIL PROTECTED] (Rod Adams) wrote in message
>
> > Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
> > are processed Left to Right. Once seen, the mapping starts over right to
> > left. Everything remaining is slurpable.
> >
> > Yes, it's more expensive to use, just like the RE version, but shouldn't
> > impact performance _too_ bad when it's not, since the behavior will be
> > detectable at compile time.
> >
> > Thoughts?
>
> There is another problem beyond efficiency: the P6 list semantics is lazy.
>
> The following is valid P6, AFAIK:
>
> for 1 .. Inf {
> print $_;
> last when 10;
> }
>
> And then most of the proposed methods (including popping off [EMAIL PROTECTED]) would
> not work.
No, popping at least would work. I can assure you of that.
> There is another problem that I see with a user defined my_for. We want to
> be able to write
>
> my_for 1 .. 5 { something }
>
> and not have to write:
>
> my_for 1 .. 5 {something };
>
> What is bothering me is the following: If we have a sub with the
> signature:
> sub very_complicated(Int $x, Code [EMAIL PROTECTED])
>
> how would the following get parsed:
>
> very_complicated 7 { print "Hello," } { print " world!"}
> # Those were the 3 args I wanted to pass
> # and the next one is outside the call
> sub next_routine {...}
>
> It seems to me, then, that calls to user defined subs will need to end
> with a semi-colon.
Semicolon syntax shortcuts are still up in the air. People constantly
get tripped up on whether or not to use a semicolon after whatever
kind of block. So, there's going to be some rule which will allow you
to omit them...
As of A4, "a } on a line by itself gets an implicit semicolon added,
if syntactically valid". But the rules might need to be a bit more
complex. We'll see.
Luke
>
> Abhi
>
>
> Abhijit A. Mahabal Home: 520 N. Grant St, Apt #2
> Graduate Student, Bloomington IN 47408
> Dept of Cog Sci and Computer Science, 812 331 2286
> Indiana University Off: LH301I; 812 855 8898
Re: E6 question
> Is it possible with the new parameter declaration syntax to declare > a mandatory name-only parameter? Not directly, no. However, some trickyness with macros would probably let you do it. I don't yet understand macros well enough to show you... Luke > Mark
Re: [imcc] objects speed, .include and file-scoped vars, and various stuff
Jerome Quelin <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> Just put a ".local" or ".sym" declaration outside/in front of your >> subs. This declares a file-scoped variable. > It does not seem to be file-scoped: .include gets pulled in inside the lexer, so its the same, as it were in that file. And is we currently have one bytecode segment (or file to compile) only the file scope looks like a global. > Not messed, but it would be nice to have the real file and line number > of the error. Yep. We need a similar thing, as with the macros. > Jerome leo
Re: approaching python
Benjamin Goldberg wrote: save $P1 restore $P2 [ ... ] $P2 = $P1 or even removed entirely, rewriting everything after the "" to refer to $P1 instead of $P2. Does imcc do anything like this? Not yet. But it will do, at least for Parrot calling conventions, where register moves should be optimized. leo
Re: [perl #23039] [PATCH] event handling-2
Benjamin Goldberg <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> OK here it is. >> Again the description for the record: >> >> 1) Initialization: >> - normal core: build op_func_table with all opcode #4 [1] >> - CG core: build ops_addr[] filled with this opcode >> - prederef cores: build a list of (backward) branch instructions >> and the opcode at that offset > I'm not sure, but I think you should also include "invoke", "call", and > "invokecc"s in that list. Yep. I just wanted to address the most difficult case (check for an event timely even in a tight loop). A subroutine call is a lot slower, so it doesn't matter too much, if there is one extra if(we_have_events) or such. But it can be done with my proposed scheme w/o that "if" too. leo
E6 question
Is it possible with the new parameter declaration syntax to declare a mandatory name-only parameter? -Mark
Re: Perl 6's for() signature
[EMAIL PROTECTED] (Rod Adams) wrote in message
> Proposed behavior of *?@ : All Arguement to Parameter mapping left of it
> are processed Left to Right. Once seen, the mapping starts over right to
> left. Everything remaining is slurpable.
>
> Yes, it's more expensive to use, just like the RE version, but shouldn't
> impact performance _too_ bad when it's not, since the behavior will be
> detectable at compile time.
>
> Thoughts?
There is another problem beyond efficiency: the P6 list semantics is lazy.
The following is valid P6, AFAIK:
for 1 .. Inf {
print $_;
last when 10;
}
And then most of the proposed methods (including popping off [EMAIL PROTECTED]) would
not work.
There is another problem that I see with a user defined my_for. We want to
be able to write
my_for 1 .. 5 { something }
and not have to write:
my_for 1 .. 5 {something };
What is bothering me is the following: If we have a sub with the
signature:
sub very_complicated(Int $x, Code [EMAIL PROTECTED])
how would the following get parsed:
very_complicated 7 { print "Hello," } { print " world!"}
# Those were the 3 args I wanted to pass
# and the next one is outside the call
sub next_routine {...}
It seems to me, then, that calls to user defined subs will need to end
with a semi-colon.
Abhi
Abhijit A. Mahabal Home: 520 N. Grant St, Apt #2
Graduate Student, Bloomington IN 47408
Dept of Cog Sci and Computer Science, 812 331 2286
Indiana University Off: LH301I; 812 855 8898
Re: [RFC] Dynamic PMC Classes
On Wednesday, July 30, 2003, at 04:28 , Dan Sugalski wrote: At 12:43 +0200 7/30/03, Leopold Toetsch wrote: I have started looking at dynamic classes. I have currently - new subdirectory /dynclasses - small hack for classes/pmc2c.pl to consider this directory too - dynclasses/foo.pmc, dynclasses/Makefile (unportable, but short ;-) Here's what I was thinking instead. We build classes as shared libraries, unless otherwise noted. PMC libraries get loaded up with an op--load_pmc or something of the sort. It takes a PMC name and tacks on the library prefix and suffix as need be. We load in the PMC library, call its setup routine, call its initialization routine, and let it do its thing. The setup routine, when called, will at the least register the PMC's class in the class name hash. There should be some code in the system to manage this, though it needs mutex protection. Eek? Forcing a new DLL for every dynamically-loaded PMC class? So many open()'s and persistent file handles and mmap regions! As if Perl 5's DynaLoader weren't bad enough already. I can hear the clatter of keyboards across the world. I can't make out the rest, but it all starts with su and then echo `perl -e 'print 2**32-1, "\n"'` > /proc/sys/ Maybe this is one way to go, but please don't make it the only one; administrators of fork()-based server programs the world over will thank you from the bottom of their hearts. I'm speaking from the side-lines, but why not have a DLL register all the PMCs it contains at load time (placing the onus of setup on the library author rather than the parrot core)? The library could put into global variables whatever identifiers/data structures support the dynamic PMC allocation. Sharing of the PMC class would then be equivalent to visibility of those globals--equivalent to having linked with the library containing the PMC definition--and so PMC class versioning is thereby solved to the same extent that library versioning is solved by the dynamic linker. Also, if the PMC class global is visible to user code, then it's already registered and that code doesn't need to do anything special at all to load it up. I suppose this screws up in the single process/multiple interprete (SPMI?) scenario, since the dynamic PMC could need to appear in a different slot on each interpreter. But if the DLL was itself loaded only through the interpreter itself, and the interpreter communicated to the library's initialization routines? (Worst case means of communication: Giant spinlock around library loading, plus a current_parrot_interpreter global in the parrot library, which the DLL is of course linking against.) Then a sufficiently private mapping or per-interpreter initialization might be possible, depending on dynamic linker's capabilities. — Gordon Henriksen [EMAIL PROTECTED]
Re: [perl #23039] [PATCH] event handling-2
Leopold Toetsch wrote:
> OK here it is.
> Again the description for the record:
>
> 1) Initialization:
> - normal core: build op_func_table with all opcode #4 [1]
> - CG core: build ops_addr[] filled with this opcode
> - prederef cores: build a list of (backward) branch instructions
> and the opcode at that offset
I'm not sure, but I think you should also include "invoke", "call", and
"invokecc"s in that list.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Re: [imcc] objects speed, .include and file-scoped vars, and various stuff
Leopold Toetsch wrote: > Jerome Quelin <[EMAIL PROTECTED]> wrote: > > - will objects introduce a speed overhead? > For sure, but not a big one. You can AFAIK obtain an integer index > for an attribute or method so its basically an array lookup. Nice. So maybe I'll go for an object... > > - if I implement the Lahey space module as a regular module, how > > can I declare file-scoped vars that will be accessible by the > > subroutines of the file and only them? Since imcc parses > > compilation units first, I don't see how to do this... Maybe with > > the ".namespace" keyword? > Just put a ".local" or ".sym" declaration outside/in front of your > subs. This declares a file-scoped variable. It does not seem to be file-scoped: $ cat main.imc .sub __START__ call _main .end .include "lahey_space.imc" .sub _main call _lhs_init print "main.imc: " print width print "\n" end .end $ cat lahey_space.imc .local int width .sub _lhs_init width = 42 print "lahey_space.imc: " print width print "\n" ret .end $ imcc main.imc lahey_space.imc: 42 main.imc: 42 $ It looks like a global variable to me. > > - the global does not seem to be available: > > $ cat foo.imc > > sub _main > > .local int width > > width = 0 > > global "lhs_width" = width > The *global opcodes are PMC variables only. > > Will the feature be implemented soon? > As the global stash is a PerlHash, it could be done. OTOH all the > lexical opcodes are PMC-only too and these can only store PMCs in > their array slot. Okay. > > - when including a file with .include, the line numbering > > continues to increase without being zeroed, and it's quite > > difficult to track errors because of this behavior > This needs work - Or its a bug, if line numbers are messed up by > including a file. Not messed, but it would be nice to have the real file and line number of the error. Jerome -- [EMAIL PROTECTED]
Re: approaching python
Benjamin Goldberg wrote:
[snip]
> If someone's code emits something like:
>
>save $P1
>restore $P2
>
> Then IMCC should be able to optimize that to:
>
>$P = $P1
>$P2 = $P
Actually, that (sometimes) should be able to be changed to:
$P2 = $P1
noop
or:
noop
$P2 = $P1
or even removed entirely, rewriting everything after the "" to refer
to $P1 instead of $P2. Does imcc do anything like this?
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Re: approaching python
Joseph F. Ryan wrote:
> Benjamin Goldberg wrote:
>> Joseph Ryan wrote:
>>> Benjamin Goldberg wrote:
[snip]
Hmm... If imcc is smart enough, (or perhaps I should say, when the
flow control is simple/clear enough) it should be able to see when a
value is pushed onto the stack, and later popped off, when there are
enough registers free that we could have stored it in a spare
register instead of on the stack. That is, a sort of register
*un*spilling.
>>>
>>> Doesn't IMCC already do this?
>
> I think I misunderstood you. However, I still don't see this would be
> helpful.
If someone's code emits something like:
save $P1
restore $P2
Then IMCC should be able to optimize that to:
$P = $P1
$P2 = $P
True, a human writing code wouldn't do a save/restore like that, but a
naive compiler might (the 'save' being the last instruction of one of
's opcodes, and the 'restore' being the first instruction of
the next of one of 's opcodes). And I'd rather we make imcc
smart enough to make such code fast, than have to make my compiler
smarter.
> How would IMCC know which save/restore are associated with
> "the" stack, and which are "normal" save/restore? (i.e., associated
> with parameters/results from a subroutine) Unless I'm missing
> something, you'd have to between those two sets of use...
That's why I said, "when the control flow is simple/clear enough" ...
The following isn't the only way to do it, merely the first that comes
to mind, and I *could* be quite mistaken about whether or not it would
work.
We can analyze each basic block, and try and figure out how much it
changes the stack -- how many items from the stack it will pop, and how
many it will push. We can say "unknown" for these if we have to, if
it's beyond our ability to analyse. Also, code can make assertions,
saying that even though we're doing this weird sequence of pushes and
pops, (e.g., doing saves in one loop, followed by restores in another
loop), that it will always pop a total of X, and push a total of Y.
For each stretch of ops, repeatedly scan for a save op, then look for
the following restore op. If we *know* that the value that was just
saved wasn't popped off the stack by the ops and blocks in between (we
should know this due to the analysis we just did), then we can replace
that save...restore pair with $P = $P1...$P2 = $P.
Note that no differentiation needs to be made about whether a
save/restore is for a subroutine argument/return value, or a "normal"
save/restore. We only count *how many* saves/restores occur.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Re: subroutines and python status
On Fri, 1 Aug 2003, Dan Sugalski wrote: > At 11:04 PM +0200 7/31/03, Leopold Toetsch wrote: > >Luke Palmer <[EMAIL PROTECTED]> wrote: > >> You mind submitting a patch to put this in the languages/pirate > > >I'd appreciate that very much. Pie-thon, here we come ... > > As would I. If you're willing, Michal, we can check it in and get > you CVS repository access. Hey guys, I'd kind of like to keep it where it is - for now, anyway. But I'm *more* than happy to give people access to the repository. I just set up users for you three (I'll send your logins in a second), and if anyone else wants access, just drop me a note. Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: [perl #23186] [PATCH] adding "yield" semantics to IMCC
Kenneth A Graves <[EMAIL PROTECTED]> wrote: > Inside the iterator, there are three differences compared to a function: > 1) Every register in use needs to be saved to the user stack. (Anyone > have a clean way to do this?) Its the same thing as calling a subroutine in the first place. Imcc has to figure out, which registers are used (and which are persistent over the function call). With this info the register allocation as well as the necessary register save/restore opcodes can be optimized. When this is done, the same logic applies to the .pcc_*_yield block. > --kag leo
Re: subroutines and python status
At 11:04 PM +0200 7/31/03, Leopold Toetsch wrote: Luke Palmer <[EMAIL PROTECTED]> wrote: You mind submitting a patch to put this in the languages/pirate I'd appreciate that very much. Pie-thon, here we come ... As would I. If you're willing, Michal, we can check it in and get you CVS repository access. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Trapping find_lex failure; case for search_lex?
Jos Visser <[EMAIL PROTECTED]> wrote: > Hi, > 1)Is there an efficient way to trap the failure of a "find_lex"? Not yet. We have to clean up the internal_exception stuff first. C could e.g. return a NULL in case of failure, and we could then throw an exception in F at the opcode-level, so that the exception would be resumable. > 2)What about a "search_lex" op that follows the format of > "find_lex" but which stores null in the target PMC register > (Px). To make this really useful an "isnull" comparison operator > would come in handy too... defined I0, Px would do it. > ++Jos.es leo
Re: [perl #23186] [PATCH] adding "yield" semantics to IMCC
Kenneth A Graves <[EMAIL PROTECTED]> wrote: > The .pcc_* directives are working for me in terms of implementing > function calls. I want to do something similar for iterator calls. > I've decided to implement iterators using coroutines. I have applied it. The test program foo.pir is now a test in t/syn/pcc.t Thanks for the patch, leo
Re: Question about interpreter == NULL
Juergen Boemmels <[EMAIL PROTECTED]> wrote: > They should not fail more drastic than necessary. Only fail if its not > possible to report an error to the upper level. Yep. That's right. To panic() is not necessary nost of the time. > bye > boe leo
%_ - is it available for use?
We have been discussing how to pass data to Tk callbacks. In particular Entry widget validation routines. There are a number of items that they _might_ be interested in but a typical routine would only use a few. Currently it passes them all as positional parameters. One idea that occured to me/us is to have a "localized" hash for this purpose (which might be tied/magical). One choice of name for this is %_ - which fits neatly with @_ for positional args and $_ as current thing. Also *_ glob already exists to have its GvHV entry (ab-)used. What does p5p think of this use ? Basically @_ says "how" you been called $_ is "what" you are working on, and this idea gives %_ the meaning of "why". (Caller gives the "who" ;-) )
Re: Question about interpreter == NULL
Leopold Toetsch <[EMAIL PROTECTED]> writes: > Juergen Boemmels wrote: > > > Leopold Toetsch <[EMAIL PROTECTED]> writes: > > [...] > > > > > >>PIO_eprintf > >>PIO_printf > >> > >>for printing to stderr/stdout during 1st interpreter construction & > >>destruction if something goes wrong. In all other cases we have an > >>valid interpreter (or an parent interpreter if any). > >> > > This means all the Parrot_warn(NULL,...) in > > config/gen/platform/ansi.c > > > are invalid. Ok remove them > > Not exactly :-) > platform/ansi and probably miniparrot using such function should IMHO > and probably just PANIC() or throw an exception, which might then do > panic. Most of them don't need to panic, they do the right thing: Parrot_floatval_time: returns a float representing the time but only with seconds resolution. But the resolution is always platform dependend. Parrot_sleep: No need to panic here. Maybe busy waiting. Yes this is ugly but portable. Parrot_dlopen: It cant open a dynamic library so it fails -> returns NULL. The caller must already check this as there also might be a "File not found" Parrot_dlsym: Parrot_close: These two should never be called as there never will be a valid handle. These may PANIC() or just return error. > Its very likely a sever error, when unsupported platform functions are > called during parrot bootstrap, which is that what I presume > miniparrot/ansi.c will finally be doing. They should not fail more drastic than necessary. Only fail if its not possible to report an error to the upper level. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: subroutines and python status
- Original Message - From: "Leon Brocard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 01, 2003 1:30 AM Subject: Re: subroutines and python status > K Stol sent the following bits through the ether: > > > Actually, I named my little project "pirate" (s. > > http://members.home.nl/joeijoei/parrot for this) already, but it's a bit of > > a dead end already (although I learnt much of it), so I don't mind. > > Quick, we need more parrot jokes... :-) > > I don't like things becoming dead-ends. How much work do you think > it'd be to extend it some more and update it to latest Lua? Well, at some point while writing the code generator, I had 2 problems. 1: I needed some Parrot features that weren't working yet, like events (I need an op to post events or something) so some essential features of the language couldn't be implemented. 2: I misdesigned the code generator; that is, at the point where I couldn't start over, it was too late, the code generator was too big already (it was unmaintainable). But because I had a time schedule, I kept it this way (the product itself wasn't the most important thing, I was writing an undergraduate report for the last semester of my education (for the record: the project served me well, I finished this education)) > Would it > be worth checking this into parrot CVS? > Only if the thing would be working, otherwise it would only be a source of confusion and frustration. Now I'm just thinking very hard to decide if I've got enough spare time to rewrite the code generator Klaas-Jan
Re: subroutines and python status
K Stol sent the following bits through the ether: > Actually, I named my little project "pirate" (s. > http://members.home.nl/joeijoei/parrot for this) already, but it's a bit of > a dead end already (although I learnt much of it), so I don't mind. Quick, we need more parrot jokes... I don't like things becoming dead-ends. How much work do you think it'd be to extend it some more and update it to latest Lua? Would it be worth checking this into parrot CVS? Leon -- Leon Brocard.http://www.astray.com/ scribot.http://www.scribot.com/ ... Dang this hobby is expensive!
Re: [imcc] objects speed, .include and file-scoped vars, and various stuff
Jerome Quelin <[EMAIL PROTECTED]> wrote: > - will objects introduce a speed overhead? For sure, but not a big one. You can AFAIK obtain an integer index for an attribute or method so its basically an array lookup. > - if I implement the Lahey space module as a regular module, how can I > declare file-scoped vars that will be accessible by the subroutines of > the file and only them? Since imcc parses compilation units first, I > don't see how to do this... Maybe with the ".namespace" keyword? Just put a ".local" or ".sym" declaration outside/in front of your subs. This declares a file-scoped variable. > - the global does not seem to be available: > $ cat foo.imc > sub _main > .local int width > width = 0 > global "lhs_width" = width The *global opcodes are PMC variables only. > Will the feature be implemented soon? As the global stash is a PerlHash, it could be done. OTOH all the lexical opcodes are PMC-only too and these can only store PMCs in their array slot. > - when using the global keyword, can the string where one stores the > value be anything? For example, can I use "foo::bar" as a global name? Yes. > - when including a file with .include, the line numbering continues to > increase without being zeroed, and it's quite difficult to track errors > because of this behavior This needs work - Or its a bug, if line numbers are messed up by including a file. > - when including a file, if it isn't properly newline terminated, you > get an error even if the line is a comment... > $ imcc main.imc > (error) line 26: parse error, unexpected $undefined, expecting '\n' > Didn't create output asm. That's fine for me and the error message is stating the problem. > Thanx for your answers, > Jerome Welcome, leo
Re: Perl 6's for() signature
John Siracusa:
> Did this ever get resolved to anyone's satisfaction? While reading
> EX6, I found myself wonder exactly what for() would look like in Perl 6
> code...
Well, the easiest signature to do is probably:
sub for([EMAIL PROTECTED]) {
PRE { @list.end =~ Code }
...
}
And just pop the coderef off the list. Of course, that's not as nice as it
ought to be, so perhaps it's really:
class List {
method for(&code) { ... }
multi for(List $list: &code) { $list.for(&code) }
}
Or somesuch. But that should be slurpy, I suppose. Damn...
--Brent Dax <[EMAIL PROTECTED]>
Perl and Parrot hacker
Trapping find_lex failure; case for search_lex?
Hi, I am writing a parrot code generator back-end to an interpreter for a long-lost (some would say "dead", but I prefer "hibernating" :-) programming language: Comal (see http://www.josvisser.nl/opencomal). Anyway, in the course of my code generation I have run into the situation where I think I need to either: - Be able to trap a find_lex failure (efficiently), or - Be able to search the lexical pads for the occurrence of a lexical with potentially getting "not found" as a result (I dubbed this feature "search_lex"). The reason is that in this language I can create new variables at any place in the control flow, but referring to an unknown variable should throw an error. Also, once created and stored in the lexical environment, I want assignments to a variable to always refer to the same PMC (because of a language feature that allows call by reference). So, my questions are: 1) Is there an efficient way to trap the failure of a "find_lex"? 2) What about a "search_lex" op that follows the format of "find_lex" but which stores null in the target PMC register (Px). To make this really useful an "isnull" comparison operator would come in handy too... ++Jos.es -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon "Breyten Breytenbach"
Re: subroutines and python status
- Original Message - From: "Melvin Smith" <[EMAIL PROTECTED]> To: "Luke Palmer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, July 31, 2003 3:33 PM Subject: Re: subroutines and python status > At 01:51 PM 7/31/2003 -0600, Luke Palmer wrote: > >You mind submitting a patch to put this in the languages/pirate > >directory of the parrot distro? I'd like to stay up to date, and > >probably do some work (as, I imagine, would others). > > I'd like to officially complain that "pirate" is a cooler name than > my own "cola" and I haven't figured out what to do about it yet. :) > Actually, I named my little project "pirate" (s. http://members.home.nl/joeijoei/parrot for this) already, but it's a bit of a dead end already (although I learnt much of it), so I don't mind. Klaas-Jan > -Melvin > > >
JVM->PIR translator (was: Re: subroutines and python status)
Leopold Toetsch wrote: Luke Palmer <[EMAIL PROTECTED]> wrote: You mind submitting a patch to put this in the languages/pirate I'd appreciate that very much. Pie-thon, here we come ... Speaking of adding new projects to languages, I have a partially complete JVM->PIR translator done. It's complete, with the exception of: 1: The two threading ops arent translated 2: I need to translate the core libraries. I'm hoping GNU Classpath will be of some help here. 3: I'm missing some runtime exceptions, which I just havent gotten around to yet. Other than that, its pretty complete. However, the code it generates isn't quite runnable. Pasm seems to be missing a few instructions, specifically add_method and add_attribute instructions. So, I just made them up. As you can imagine, this causes a few errors :) That means that beyond trivial cases, the code is mostly untested. So, would anyone want this in the tree? Or should I wait until it is better tested and documented? You take a look at it at: http://jryan.perlmonk.org/images/jirate.tar.gz Let me know what you think. - Joe
