Re: [perl #45857] [IMCC][RFC] #line vs .line
On Mon, Nov 24, 2008 at 2:00 AM, Patrick R. Michaud [EMAIL PROTECTED]wrote: On Mon, Nov 24, 2008 at 02:31:58AM +0100, Jonathan Worthington wrote: Oh, argh, so .line now carries the file *and* the line number?.I wanted it to just carry the line number (the clue's in the name... ;-)) and have .file carry the filename. Then the source you compiled from one file has one .file 'foo.pir' directive, and then you just have .line 42 style things for lines. Either way works for me -- PCT can generate either without much difficulty. It probably makes more sense to have separate .file and .line directives. In particular, I wouldn't want to be repeating the .file annotation information throughout the bytecode! :-) well, I guess that's two +1's for the proposal in RT#59830 :-) kjs
Re: [perl #45857] [IMCC][RFC] #line vs .line
On Sun, Nov 23, 2008 at 10:08 PM, Jonathan Worthington [EMAIL PROTECTED]wrote: Klaas-Jan Stol via RT wrote: On Thu Dec 13 04:35:13 2007, pmichaud wrote: On Sat Sep 29 08:57:28 2007, kjs wrote: A few months ago, the #line directive was implemented. I'm wondering what the reason was why it looks like a comment (as # will start a comment). Is there any reason to not replace this by .line? A directive typically tells the assembler/compiler something, and in this case it updates the line number. As this gets addressed we should also address the handling of the 'setline' opcode (RT #43269). Pm .line directive is implemented per r33084. #line still works. I'm not sure what Pm meant by addressing the handling of 'setline' opcode, so leaving this ticket open. I'm planning to work on bytecode annotations Real Soon Now...my thoughts on these issues are: * I think .line and .file will remain for setting the PIR-level line and file (#line and #file maybe too, or we could deprecate those) Minor detail: .file does not actually exist, except in PIRC. I do not have a strong preference for adding it. Pro: it's a bit clearer than .line, as .line indicates, ehm, the line :-) Specifying a filename by .line is a bit weird. Con: generating 2 directives instead of 1 each time you want to update the location makes the generated code string a bit longer/more verbose, which might not be desirable. Anyway, I'm open to anything :-) (possibly renaming even to .location (or .loc, but that's another well-known abbreviation) * .annotate key value / .annotate key value will be added for setting annotations, which will form high level language debug info (.line and .file may be converted to also store data using the new annotations segment rather than keeping a separate PIR debug segment in the future; not sure how soon that will happen, will leave the current debug seg intact for now though) * setline and setfile opcodes can probably go away; I can't think of a use case where we'd want to set these dynamically, since we know the line number/file number/column/whatever else we wish to store at compile time. Doing an op dispatch rather than making an annotation we can look up only when we need it seems odd to me. I agree. Thoughts? Jonathan
Re: [perl #60592] [TODO] change :lexid into :subid.
I'm not entirely sure whether it was *just* a rename... ISTR there was also something to do with a look-up of names. Pm knows more about it :-) (admittedly, the topic is not well-defined then.) kjs On Thu, Nov 20, 2008 at 4:21 PM, Will Coleda via RT [EMAIL PROTECTED] wrote: On Sun Nov 16 11:04:32 2008, kjs wrote: On the PDS2008, it has been decided that :lexid is renamed into :subid. kjs Completed in revision 32941. Includes updates to core docs, tests, PIR syntax, and the internal C struct that held the id. compilers/pirc needs to be updated to track this change. -- Will Coke Coleda ___ http://lists.parrot.org/mailman/listinfo/parrot-dev
Re: [svn:parrot] r32368 - trunk/compilers/pirc/new
On Sat, Nov 8, 2008 at 9:22 PM, chromatic [EMAIL PROTECTED] wrote:
On Wednesday 05 November 2008 14:31:21 [EMAIL PROTECTED] wrote:
Modified:
trunk/compilers/pirc/new/pir.l
trunk/compilers/pirc/new/pirlexer.c
trunk/compilers/pirc/new/pirlexer.h
Log:
[pirc] add support for braced arguments in macro expansion.
Modified: trunk/compilers/pirc/new/pir.l
===
=== --- trunk/compilers/pirc/new/pir.l (original)
+++ trunk/compilers/pirc/new/pir.lWed Nov 5 14:31:19 2008
@@ -610,6 +610,12 @@
yy_switch_to_buffer(lexer-buffer,
yyscanner); }
+MACROEXPAND{[^}]*} { /* a braced argument; match ANYTHING up
to
the closing brace. */
+ yylval-sval =
dupstrn(yyget_extra(yyscanner), +
We have strdup, str_dup, and dupstrn; any thoughts on standardizing on one
or
two? (I like the idea of using an _n variant wherever possible.)
-- c
1) strdup is a C library function, but not C89.
2) str_dup is the IMCC version that does the same (and I'm trying to get rid
of that)
3) dupstrn is pirc's solution; it has dupstr and dupstrn, taking a 3rd
argument, n.
You're right, it's better to use *some* standard, but I shouldn't use 1) as
it's not C89 (AFAIK), 2) is IMCC-specific, so I chose 3), as it was the best
solution at the time I needed it (pirc didn't link to libparrot yet, and
moreover, it's a imcc-specific function, and I don't want to introduce
dependencies on something that I'm trying to replace).
Maybe there should be a configure test: if the platform has a strdup, use
that, otherwise use some built-in or so (possibly a macro, as strdup is
really really easy)
_n variant: do you mean dupstr_n?
kjs
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
I'd say kill it, and if we ever want to introduce new pragmas into PIR, we reintroduce. This way, .pragma keyword is not recognized without a reason. (recently I've become a great fan of being able to override commandline options with directives in the file processed; .pragma directive would be good to do this in PIR. You'll see my PROPOSALS whenever the time is ripe for that :-) I was thinking: .pragma output out.pbc # pbc output is written to out.pbc .pragma noregallocation # no register optimization .pragma nostrengthreduction # no strength reduction (add $I0,1 - inc $I0) .pragma warningson and so on. kjs On Tue, Nov 4, 2008 at 9:05 PM, Will Coleda via RT [EMAIL PROTECTED] wrote: On Wed Jul 30 13:06:06 2008, coke wrote: From PDD19: =item .pragma n_operators [deprecated] This appears to be the only .pragma; should we leave a placeholder or just remove .pragma entirely when we remove this particular one? -- Will Coke Coleda
[perl #60182] pirc/new codetest failures
fixed in r32209.
[perl #39760] [CAGE] make warnings (r13197 - x86-msvc-7.1)
The warning of inconsistent dll linkage no longer occurs on microsoft visual studio, which resolves this issue. kjs
[perl #39760] [CAGE] make warnings (r13197 - x86-msvc-7.1)
I think the issue of inconsistent dll linkage has been resolved recently by adding the YYMALLOC and YYFREE #defines to imcc source. Can other windows people confirm this? Then this ticket can be closed. Thank you very much, kjs
Re: [perl #60000] [BUG][IMCC] an :immediate sub cannot load_bytecode
On Mon, Oct 20, 2008 at 6:18 PM, chromatic [EMAIL PROTECTED] wrote: On Sunday 19 October 2008 14:02:58 Klaas-Jan Stol wrote: when running code as this: .sub main :immediate load_bytecode foo.pir .end (assuming you have a file 'foo.pir'), IMCC can't handle this. This is because in pbc.c, a global structure called 'globals' is used to allow the different functions to share access to some data (in particular, the code segment stuff). As documented by a warning in imcc's sources, a load_bytecode will trigger a (nested) compilation phase, which will overwrite this data. Parrot won't output anything (windows) , possibly segfaulting. The fix would be to store this 'globals' structure in the imcc_info structure (I think). That analysis sounds right to me as well. Is it affecting any language at the moment? As much as I hate modifying IMCC before a release, I wonder if it's a valuable fix. -- c Let's wait with it. It has been like this for ages, but I only recently actually tested it. The comments indicating it's dangerous have been there for a while. For now, Just Don't Do It (writing :immediate subs that load_bytecode). kjs
[perl #58374] [TODO][PDD19] Decide on maximum identifier length and implement this.
PDD19 already states that there's no limit, and the note that in the future such a limit might be introduced is also there. So, issue is resolved. kjs
[perl #45859] [RFC][IMCC] clean up method syntax: bare word and quoted method names
I think this ticket has been resolved by the decision that method names must be quoted (as stated in pdd19). I propose to close ticket. kjs On Thu Oct 04 16:39:31 2007, coke wrote: On Sep 29, 2007, at 12:07 PM, Klaas-Jan Stol (via RT) wrote: # New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #45859] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45859 Hi, This proposal is about resolving method names: bare words or quoted it might be that i'm not well informed on this issue, so please correct me where I go wrong. IMCC currently allows for method call syntax like this: foo.bar() foo.bar() One thing to think about is that allowing double quoted strings wrapping this allows us to have method names with spaces, unicode, newlines... (and having single quoted strings allows us to easily have escaped versions of same.) Both invoke the method named bar on the object foo, UNLESS there is a local variable named bar, in which case the first statement will invoke the method whose name is stored in that local variable. This is confusing, and makes reading code not easy (imagine having a subroutine of 50+ instructions, and debugging it) PCCMETHODs (a method on a pmc written in C) is, IIRC, invoked using a bare word methodname like so: foo.bar() So, what is called here? Is bar a method, a PCCMETHOD (but I guess that does not matter), or a local variable containing the name of a method? In order to prevent confusing, I propose that methodnames are always written between quotes. This should also be true for PCCMETHODs. Only then is it always clear when calling a method whose name is stored in a local variable, or if it's actually the name of the method that was written. I think the method new on a class is a PCCMETHOD, right? This would mean that you would create a new object instance like so: .local pmc b b = Foo.new() Having to write b = Foo.'new'() might seem inconvenient, but I think it's a matter of getting used to, and it is more consistent. Consistency is good. The assembly language (if you can call PIR that) should not have too many rules and exceptions. -- Will Coke Coleda [EMAIL PROTECTED]
[perl #59898] [TODO][IMCC] add some #define's to fix the inconsistent dll linkage on windows
fixed in r31956
Re: [perl #59830] [PROPOSAL][PDD19] Split .line directive into separate .line and .file directives.
On Mon, Oct 13, 2008 at 2:10 AM, Andrew Whitworth [EMAIL PROTECTED]wrote: On Sun, Oct 12, 2008 at 9:27 AM, via RT Klaas-Jan Stol [EMAIL PROTECTED] wrote: currently, the .line directive takes both an integer (for line number) and a string (for filename) argument. I propose to split these into a separate .line and .file directives, both only taking 1 argument. (much line #line and #file in the C preprocessor). What if the .line directive was changed to accept an integer line number, a string filename, or both, optionally? That is, is there a benefit to having two different directives instead of a single directive with dynamic behavior? --Andrew I don't consider the following very clear: .line my_included_file.pir as opposed to: .file my_included_file.pir Of course, the line number can be compulsory, as in: .line 1, my_file.pir but sometimes you just want to change the line, and sometimes you just want to change the file name. (although, admittedly, up till now I've only been using them in combination). kjs
Re: [perl #59576] [PATCH] 'property' scope for PAST::Var
On Fri, Oct 3, 2008 at 2:23 PM, I Sop [EMAIL PROTECTED] wrote:
From: Patrick R. Michaud via RT [EMAIL PROTECTED]
Subject: Re: [perl #59576] [PATCH] 'property' scope for PAST::Var
To: [EMAIL PROTECTED]
Date: Friday, October 3, 2008, 12:31 PM
On Thu, Oct 02, 2008 at 02:16:01PM -0700, I Sop wrote:
I just copied the 'attribute' method, renamed
everything, and changed the parameter order for the
'getprop' op.
Why should this be a PAST::Var node as opposed to simply
using a
PAST::Op node with :pirop('getprop') and/or
:pirop('setprop') ?
Pm
Why is this different than attribute access?
Maybe, because an attribute access can be more complex, or 'nested', if you
like. For instance, consider this pseudo code:
foo.bar.baz = 1
From the top of my head, I would implement this as a PAST::Var, of type
'attribute', where the attribute is itself represented by a PAST::Var node,
again of type 'attribute'.
so:
PAST::Var (foo, PAST::Var(bar, baz))
(not sure if that notation makes any sense, but the first operand is the
object to be indexed, the second is the key).
A property on the other hand is simpler; it's just a 'tag' on the object.
(or maybe it can be accessed in a similar way as attributes, the example
above, ?)
Just a thought.
kjs
Re: request for help (only a little :-): build pirc on linux
sorry, documentation and source should be reorganized at some point. For now, please check out compilers/pirc/README.pod. sorry for the confusion, kjs On Tue, Sep 9, 2008 at 5:31 PM, NotFound [EMAIL PROTECTED] wrote: I put the commands that I'm using in the README file (but that's for MSVC on windows), but I don't have any knowledge on how to do this on linux. There is no README file in compilers/pirc/new -- Salu2
Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19
On Sat, Aug 30, 2008 at 10:40 AM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
On Sat, Aug 30, 2008 at 11:04 AM, Allison Randal [EMAIL PROTECTED]
wrote:
Yes, it will be deprecated, or at least renamed. The C.return
directive
without parentheses is an old convention for passing a single return
result,
and must always be sandwiched between C.begin_return and
C.end_return.
Do you mean this one? (see next)
.begin_return
.return hi
.return 42
.return 3.14
.end_return
(which is the same as: .return (hi, 42, 3.14) )
Is the purpose of renaming this to make a clear distinction between the
'.return' directive in this long style of returning and the short one
('.return ()' ) ?
Yes. That whole set of directives would benefit from clearer naming.
Perhaps:
.set_return hi # return value passed, between .begin_return
# and .end_return
.set_arg foo # argument passed, between .begin_call and .end_call
.get_result # result retrieved, between .call and .end_call
And, there's another C.return without parentheses that performs a
tail-call, invoking a sub or method reusing the same return continuation.
This should also be renamed.
Is the purpose to be more explicit on being a tailcall? (in that case, it
could be renamed as .tailcall or whatever -- but that's obvious)
Obvious is good.
The only directive that should be named C.return is the one that returns
a value or values (i.e. it's syntactic sugar for a whole collection of
low-level directives/opcodes).
and this would be: .return (hi, 42, 3.14)
right?
Yes.
Allison
Allison:
I made the following changes in pirc/new:
.arg - .set_arg
.result - .get_result
.return - .tailcall (in context of .return foo() , which thus is now:
.tailcall foo() )
.return - .set_return (in long-style returning : .begin/end_return
.yield - .set_yield ( in long-style yielding : .begin/end_yield)
From your answers in your previous reply I deduce you support such changes.
Can you reconfirm, then I'll make the appropriate changes in PDD19.
thanks,
kjs
Re: [perl #45357] [TODO] Which exception should be thrown with register overflow?
It seems that the error condition refers to the case where too many arguments are passed (#args #params).It's not really overflow in that sense, IMHO, just too many arguments passed. I think an exception is already thrown when that happens, not sure. kjs On Tue, Sep 9, 2008 at 12:02 AM, chromatic [EMAIL PROTECTED] wrote: On Monday 08 September 2008 12:57:00 Christoph Otto via RT wrote: On Tue Sep 11 03:32:51 2007, pcoch wrote: Having a look through PDD03 I noticed the TODO item left by Chip: =head3 Overflow If too many values are provided to fit into the given target registers, Parrot will throw an exception. Note that if the final target is a P register with FLAT set, then this exception can never occur. XXX - FIXME - which exception? We really could use an exception subsystem. Oh, wait, that's my job. Never mind. --Chip What should we do here? Do we already have an exception subsystem? Has this been designed/implemented? Given the way Parrot currently regards registers, is this ticket still relevant? It looks like it. How about EXCEPTION_ERR_OVERFLOW? It's already an exception type. -- c
request for help (only a little :-): build pirc on linux
hi, recently I had a good look at Parrot's Makefile to figure out what link flags I need to link PIRC against libparrot. This worked out quite well, and I'm now able to link in libparrot so PIRC can now call all Parrot functions. (the only major thing that needs to be done to get rid of IMCC is generate PBC from the PASM assembly instructions that are being generated) However, I'm on windows, and don't have a linux box. My request, then, is as follows: could anybody on linux check out whether s/he can build PIRC (in compilers/pirc/new) and link against libparrot? I'd like to know that it can work on Linux as well. I put the commands that I'm using in the README file (but that's for MSVC on windows), but I don't have any knowledge on how to do this on linux. thanks in advance, kjs
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Tue, Sep 2, 2008 at 12:43 PM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: This must make the following syntax rule illegal: target = null because if null is declared as a .local, you can't know whether you want to nullify target, or want to set target's value to that of the .local variable null. I take it this is no problem; just stick to null target if you actually want to set target to 0/null. Yes, that's reasonable. The syntactic sugar was confusing in that case anyway. (Seemed like you were assigning a null value to the destination register, rather than nullifying the PMC in the destination register.) This belongs in a general category of opcodes where the standard transformation of call the opcode with the first argument stuck before an '=' sign doesn't really make sense. Allison the problem seems to be a bit bigger than I had foreseen. The issue is that ops with the first operand marked as 'OUT' may be rewritten as: target = op [operand [, operand]*]? However, consider the following: .local pmc getstdin $P0 = getstdin How should this be resolved? is the opcode 'getstdin' meant here, or is it the value of the .local getstdin. This problem occurrs with all ops, not only with single-operand ops. kjs
Re: [perl #39313] [TODO] or [BUG] improve PMC compiler
On Fri, Sep 5, 2008 at 1:28 PM, Will Coleda [EMAIL PROTECTED] wrote:
On Fri, Sep 5, 2008 at 3:45 AM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
On Fri Jun 27 13:14:53 2008, coke wrote:
While I think this particular example is now valid with the new calling
conventions, you can get a similar effect with:
METHOD BORK BORK parent() {
/* nothing to see here*/
}
This ticket doesn't seem to be closeable as is.Would it be good enough
if pmc2c.pl spit out an error on the above definition, or is this even
something that pmc2c.pl should be concerned about?
The goal of the ticket should be for pmc2c.pl to entirely parse the
input PMC files. Either passing through uncooked C, or doing
transformations. Silently dropping code on the floor is not
acceptable.
wouldn't a PGE-based compiler be helpful?
just a thought.
kjs
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
I checked in some major changes that allow all keywords (types and if, null, etc.) as identifiers. Cleanup and maybe a refactor will follow later. kjs On Wed, Sep 3, 2008 at 10:35 AM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: On Tue, Sep 2, 2008 at 2:28 PM, Allison Randal [EMAIL PROTECTED] wrote: I'm not clear on why we need to reserve 'if', 'unless' and 'null' either, since they never appear in locations that could be confused with variables. there's not a strict reason, no. In fact, it would be possible to allow them, although the implementation of that will require a number of special cases in the grammar (but doable, as far as my experiments showed me). We're marking them as a special case now to treat them as reserved words. The only concern would be (as Andrew indicated as well), that you could write: if null null goto goto if you had declared null and goto as .locals. That's more of a stylistic custom than something to enforce in the parser. But, like I said, this definitely isn't an urgent modification, just a general matter of clarity and consistency in PIR. Allison
Re: Name spaces of PIR identifiers
On Tue, Sep 2, 2008 at 8:08 AM, François Perrad [EMAIL PROTECTED]wrote:
It seems that PIR uses only one name space of identifiers.
$ cat const.pir
.const int cst = 42
.sub 'cst'
print cst
.end
$ parrot const.pir
error:imcc:undefined identifier 'cst'
in file 'const.pir' line 5
$ cat label.pir
.const int L1 = 42
.sub 'main'
print L1
goto L1
L1:
.end
$ parrot label.pir
error:imcc:syntax error, unexpected VAR, expecting IDENTIFIER or PARROT_OP
('L1')
in file 'label.pir' line 5
The expected behavior is not defined in ppd19.
François.
I agree, there should be more clarity on namespaces; do all identifiers
share the same namespace, or does each type of object (not Parrot type, but
whether it's a subroutine, .local, .const, etc.) have its own namespace?
Consider the following example:
.sub add
.local int add
add = 1
print add
add()
.end
Should the above be possible? That would imply that each type of object has
its own namespace, so that from the context the type of object can be
deduced (so:, invoking add means that add is expected to be a sub; however,
what if 'add' was declared as a pmc? it could hold a sub to be invoked, so
what sub should be called? ) It seems that .locals should take precedence
here: when invoking something that was declared as a .local, that .local
should be of type pmc and hold a subroutine (so the above example will then
emit an error message saying you can't invoke an integer). If add was not
declared a .local, a recursive call would be made.
Some clarity must be created around this.
kjs
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Tue, Sep 2, 2008 at 12:43 PM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
This must make the following syntax rule illegal:
target = null
because if null is declared as a .local, you can't know whether you want
to nullify target, or want to set target's value to that of the .local
variable null.
I take it this is no problem; just stick to
null target
if you actually want to set target to 0/null.
Yes, that's reasonable. The syntactic sugar was confusing in that case
anyway. (Seemed like you were assigning a null value to the destination
register, rather than nullifying the PMC in the destination register.)
This belongs in a general category of opcodes where the standard
transformation of call the opcode with the first argument stuck before an
'=' sign doesn't really make sense.
Allison
So, preferably, the special words in PIR will be allowed as identifiers
('if','unless', 'null') and PIR will DWIM. What about the type identifiers:
int, num, pmc, string; should these be allowed as identifiers? The currently
special PIR words such as if, unless, null are ops, and as opnames are
allowed as identifiers, allowing 'if', 'unless' and 'null' makes sense. The
type names on the other hand, are not related to PASM code, so I'd vote to
have them as 'reserved' words; but I'd just like to check now. (maybe the
general feeling is that there must be no reserved words in PIR...)
kjs
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Tue, Sep 2, 2008 at 2:28 PM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
So, preferably, the special words in PIR will be allowed as identifiers
('if','unless', 'null') and PIR will DWIM. What about the type
identifiers:
int, num, pmc, string; should these be allowed as identifiers? The
currently
special PIR words such as if, unless, null are ops, and as opnames are
allowed as identifiers, allowing 'if', 'unless' and 'null' makes sense.
The
type names on the other hand, are not related to PASM code, so I'd vote to
have them as 'reserved' words; but I'd just like to check now.
AFAIK, you can never use a variable in any position where you can use a
type name. So, you can't declare a variable named 'foo' and then use it as a
type:
.local string foo
* .local foo thingy # (* not valid syntax)
And also, you can't use a type name as a variable, if you haven't actually
declared a variable of that name:
* pmc = hello # (* not valid syntax)
So, there's no reason this couldn't be valid syntax, because there's no
ambiguity:
.local pmc pmc
pmc = new String
pmc = hello
(maybe the
general feeling is that there must be no reserved words in PIR...)
Not no reserved words just the smallest set of reserved words possible,
which means not reserving words we don't need to reserve.
I see.
I'm not clear on why we need to reserve 'if', 'unless' and 'null' either,
since they never appear in locations that could be confused with variables.
there's not a strict reason, no. In fact, it would be possible to allow
them, although the implementation of that will require a number of special
cases in the grammar (but doable, as far as my experiments showed me). The
only concern would be (as Andrew indicated as well), that you could write:
if null null goto goto
if you had declared null and goto as .locals.
Allison
kjs
Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19
On Sat, Aug 30, 2008 at 11:04 AM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol (via RT) wrote:
The parentheses surrounding the arguments are mandatory. Besides making
sequence break more conspicuous, this is necessary to distinguish this
syntax from other uses of the C.return directive that will be probably
deprecated.
The open issue of the 'probably deprecation' should be decided on; what
return directive is meant here that supposedly would be deprecated?
Will it? (any need?)
Yes, it will be deprecated, or at least renamed. The C.return directive
without parentheses is an old convention for passing a single return result,
and must always be sandwiched between C.begin_return and C.end_return.
Do you mean this one? (see next)
.begin_return
.return hi
.return 42
.return 3.14
.end_return
(which is the same as: .return (hi, 42, 3.14) )
Is the purpose of renaming this to make a clear distinction between the
'.return' directive in this long style of returning and the short one
('.return ()' ) ?
And, there's another C.return without parentheses that performs a
tail-call, invoking a sub or method reusing the same return continuation.
This should also be renamed.
Is the purpose to be more explicit on being a tailcall? (in that case, it
could be renamed as .tailcall or whatever -- but that's obvious)
The only directive that should be named C.return is the one that returns
a value or values (i.e. it's syntactic sugar for a whole collection of
low-level directives/opcodes).
and this would be: .return (hi, 42, 3.14)
right?
Allison
kjs
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Sat, Aug 30, 2008 at 12:27 PM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: This is another one of those muddy cases in PIR where words conflict when they shouldn't. I can't think of any way that it's actually useful to have a variable named 'add' prevent you from using the opcode 'add'. .. but of course, I don't want to exclude it. If it is really felt that these 'muddy' cases should be resolved, it shouldn't be too hard to implement (I tried some 30 min. hacking in pirc, and results seemed promising). Desirable, but not urgent. Allison ok. This must make the following syntax rule illegal: target = null because if null is declared as a .local, you can't know whether you want to nullify target, or want to set target's value to that of the .local variable null. I take it this is no problem; just stick to null target if you actually want to set target to 0/null. kjs
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Thu, Aug 28, 2008 at 10:07 PM, Allison Randal [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Opcode names are not reserved words in PIR, and may be used as variable names. For example, you can define a local variable named Cprint. [See RT #24251] +Note that by using an opcode name as a local variable name, the variable will +Ihide the opcode name, effectively making the opcode unusable. Opcode names +used as subroutine identifiers, on the other hand, will Ihide that opcode. -PIR keywords, on the other hand, Iare reserved, and cannot be used as +In contrast to opcode names, PIR keywords Iare reserved, and cannot be used as identifiers. Some opcode names (Cif, Cunless) are, in fact, PIR keywords, which therefore cannot be used as identifiers. This is another one of those muddy cases in PIR where words conflict when they shouldn't. I can't think of any way that it's actually useful to have a variable named 'add' prevent you from using the opcode 'add'. Call it a bug, or at least a misfeature caused by limited parsing. Allison I see what you mean, but being able to do what you would like, would be very complex to implement and IMHO not worth the effort (probably something like setting flags like and lexer code such as: 'if (strcmp(yytext, add) expect_math_op) return TK_ADD;'. No fun. Having a rule that says that any local variable declared, hides any other object by the same name in the current scope, is not too hard to understand. In any case, having a local id called 'add' would be a bad practice any way, IMHO. kjs
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Fri, Aug 29, 2008 at 11:06 AM, Klaas-Jan Stol [EMAIL PROTECTED]wrote: On Thu, Aug 28, 2008 at 10:07 PM, Allison Randal [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Opcode names are not reserved words in PIR, and may be used as variable names. For example, you can define a local variable named Cprint. [See RT #24251] +Note that by using an opcode name as a local variable name, the variable will +Ihide the opcode name, effectively making the opcode unusable. Opcode names +used as subroutine identifiers, on the other hand, will Ihide that opcode. -PIR keywords, on the other hand, Iare reserved, and cannot be used as +In contrast to opcode names, PIR keywords Iare reserved, and cannot be used as identifiers. Some opcode names (Cif, Cunless) are, in fact, PIR keywords, which therefore cannot be used as identifiers. This is another one of those muddy cases in PIR where words conflict when they shouldn't. I can't think of any way that it's actually useful to have a variable named 'add' prevent you from using the opcode 'add'. Call it a bug, or at least a misfeature caused by limited parsing. Allison I see what you mean, but being able to do what you would like, would be very complex to implement and IMHO not worth the effort (probably something like setting flags like and lexer code such as: 'if (strcmp(yytext, add) expect_math_op) return TK_ADD;'. No fun. Having a rule that says that any local variable declared, hides any other object by the same name in the current scope, is not too hard to understand. In any case, having a local id called 'add' would be a bad practice any way, IMHO. kjs ... but of course, I don't want to exclude it. If it is really felt that these 'muddy' cases should be resolved, it shouldn't be too hard to implement (I tried some 30 min. hacking in pirc, and results seemed promising). kjs
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
docs/imcc/macros.pod was integrated into pdd19 some time ago. That's all information available on macros, currently kjs On Mon, Aug 25, 2008 at 10:08 AM, Reini Urban [EMAIL PROTECTED] wrote: pdd19_pir.pod references the not-existing docs/imcc/macros.pod. It would be nice if this documents shows up somewhere, as I found nothing more about macros, besides the section in pdd19_pir.pod -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: Fwd: [perl #57656] [PROPOSAL][PIR] change PIR sugar for concat into .. (or something else)
On Mon, Aug 18, 2008 at 10:31 PM, Allison Randal [EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
On Sat, Aug 16, 2008 at 9:41 AM, Allison Randal [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] wrote:
Klaas-Jan Stol wrote:
On Wed Aug 06 05:53:07 2008, kjs wrote:
My proposal would be to change the concatenate dot into
.., which looks
like it, but is more explicit, and will prevent such mistakes.
I agree that there should be some change. I've run into this
problem
myself in the past, and it's very frustrating. I don't like
having to
take into account whitespace to resolve syntactic ambiguities,
especially not in something which is basically an assembly
language.
The example in the original ticket is an IMCC parsing problem. The
code:
foo . bar()
should absolutely never be parsed as a CONCAT operation. The dot
should only be parsed as CONCAT when it's accompanied by an '=':
$S0 = hi . there
having a '=' around is not enough. This is valid PIR:
$S0 = foo.bar()
Yes.
$S0 = foo. bar()
$S0 = foo .bar()
No, these are both syntax errors and always have been.
I'm sorry, but this is not the case. It is in fact valid:
running:
==
.sub main
newclass $P0, foo
$P1 = new foo
$P1 .hi() # note the space before the dot
$P1. hi() # note the space after the dot
.end
.namespace [foo]
.sub hi :method
print hi\n
.end
==
prints hi\n twice on my system and always has since I've worked on pir..
(this is because, in imcc's lexer a '.' is always returned as DOT (for
object/method separation) and a '.' is only returned as a concatenation
operator iff it is surrounded by whitespace on both sides; the actual
reg.expr for this in imcc.l is {WS}'.'{WS} )
but this is not:
$S0 = foo . bar()
Pardon, I wasn't clear enough. I was explaining why the following is never
a valid statement
foo . bar()
(there is no syntactic sugar for concatenation without a destination for
the result of the operation)
The only '.' statements that are valid syntax are:
Concatenation:
$XN = hi . there
$XN .= there
or Method Call:
$XN = foo.bar()
They all include an '=' sign, but I didn't mean to imply that all possible
variations on statements that include a '.' and '=' are valid syntax.
Is this statement:
Space is never allowed around the method-call dot.
the general rule, or is this merely the current situation? I mean, it's
how IMCC now implements the difference between the methodcall dot and the
concatenation dot. So, if not allowing space around a method-call is the way
to distinguish, well then there's no problem.
Except for the reason I sent this proposal in the first place: it can
confuse newcomers, because it's a special case where whitespace is
significant.
It's the spec. Whitespace is often significant in PIR. Newlines terminate
statements. Spaces are currently allowed around hash/array keys, but really
shouldn't be. In fact, you can currently do:
$P0=new'ResizablePMCArray'
$P0[1]=foo
$S1=$P0[1]
print $S1
print\n
The only place you can't remove the space is between 'print' and the
register variable. Blech. We should make spaces obligatory in a few more
places.
I see where you're coming from, and makes your previous argument more valid.
However, IMHO, in this aspect, PIR is just parsed as any HLL language; for
instance in C, you can write something like:
int x=1; return x;
No space needed when it's clear what tokens are meant; but in order to be
able to parse 'int' or 'return', both must be followed by a space.
to be clear: my proposal was not to use '+', and I disagree on that '+' is
the only thing that makes sense: Perl 6 uses '~'. (Or maybe I misunderstand
the phrase 'From common HLLs .. '.)
I know you weren't proposing '+'. By common HLLs I meant I can name 10
languages off the top of my head that use '+' and that's not an exhaustive
list. But, they're all HLLs with a large number of more advanced features
than PIR has.
Perl 6 is the only language that uses '~'. Any other alternate
concatenation operators ('', '||', '$+') are equally rare. Even '.' is only
Perl 5 and PHP, so it's soon-to-be rare.
Inventing new syntax for concatenation isn't particularly helpful for
newcomers, and neither is using rare concatenation operators that newcomers
will have likely never seen before.
I see. I think the confusion is not with the concatenation, the confusion
can come with invoking methods.
If you really don't like '.' we can remove the syntactic sugar for
concatenation entirely and only use 'concat'. :)
I wouldn't go as far as that, but then again, it's not my call :-)
Allison
In all, I don't want to make too big an issue out of this, just trying to
clean up the peculiarities and have them documented :-)
kjs
Re: Fwd: [perl #57656] [PROPOSAL][PIR] change PIR sugar for concat into .. (or something else)
On Sat, Aug 16, 2008 at 9:41 AM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: On Wed Aug 06 05:53:07 2008, kjs wrote: My proposal would be to change the concatenate dot into .., which looks like it, but is more explicit, and will prevent such mistakes. I agree that there should be some change. I've run into this problem myself in the past, and it's very frustrating. I don't like having to take into account whitespace to resolve syntactic ambiguities, especially not in something which is basically an assembly language. The example in the original ticket is an IMCC parsing problem. The code: foo . bar() should absolutely never be parsed as a CONCAT operation. The dot should only be parsed as CONCAT when it's accompanied by an '=': $S0 = hi . there having a '=' around is not enough. This is valid PIR: $S0 = foo.bar() $S0 = foo. bar() $S0 = foo .bar() but this is not: $S0 = foo . bar() or $S1 .= there because it is simple syntactic sugar for the 'concat' opcode, which always either takes a destination argument, or a self-modifying first source argument. Is this statement: Space is never allowed around the method-call dot. the general rule, or is this merely the current situation? I mean, it's how IMCC now implements the difference between the methodcall dot and the concatenation dot. So, if not allowing space around a method-call is the way to distinguish, well then there's no problem. Except for the reason I sent this proposal in the first place: it can confuse newcomers, because it's a special case where whitespace is significant. I like .. and ~. I also like +, if we can get IMCC to reliably understand that when used on strings it performs concatenation instead of some crazy addition. I definitely don't like . since our best practices involves quoting method names such as foo.'bar' which raises all sorts of ambiguity. From common HLLs, '+' is the only one that makes any sense. And, it's impossible in a low-level language like PIR, because PIR would have no way of knowing whether to dispatch the following to 'concat' or 'add': $P0 = $P1 + $P2 to be clear: my proposal was not to use '+', and I disagree on that '+' is the only thing that makes sense: Perl 6 uses '~'. (Or maybe I misunderstand the phrase 'From common HLLs .. '.) So, proposal rejected. In any case where the dot is unclear, you can always use: $S0 = concat hi, there or concat $S0, hi, there PIR really is just an assembly language with a tiny bit of syntactic sugar. It's not an HLL. Allison I see. I think the confusion is not with the concatenation, the confusion can come with invoking methods. kjs
[perl #57942] [BUG] Smolder failure [linelength, compilers/pirc]
fixed in r30252.
Re: [perl #57634] [RFC] Remove .globalconst from PIR
What's the general feeling about this proposal? Any thoughts of the architect? kjs On Tue, Aug 5, 2008 at 6:47 PM, via RT Klaas-Jan Stol [EMAIL PROTECTED] wrote: # New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #57634] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57634 hi, in PIR you can use the .globalconst directive in a sub to define a constant that is globally accessible. Likewise, you can use the .const directive in a sub that is local to that sub. .sub foo .globalconst int answer = 42 .const num PI = 3.14 .end answer in this case is globally accessible (in any other sub, that is parsed AFTER the foo subroutine, I should note) PI in this case is only accessible in this subroutine foo. However, I question the need for .globalconst, as the .const directive can also be used /outside/ of a subroutine, like so: .const int answer = 42 Therefore, the .globalconst directive seems to be superfluous; why have 2 directives that do the same thing; if a .globalconst is accessible globally anyway, there's no need to define it WITHIN a sub. Therefore, my proposal is to remove the .globalconst directive; whenever you need to have a global const, use .const outside of a subroutine. whenever you need to have a local const (in a sub), use .const inside a subroutine. comments welcome, kjs
Re: [perl #57656] [PROPOSAL][PIR] change PIR sugar for concat into .. (or something else)
What's the general feeling about this proposal? Any thoughts of the architect? thanks, kjs On Thu, Aug 7, 2008 at 5:17 PM, Bob Rogers [EMAIL PROTECTED]wrote: From: Andrew Whitworth [EMAIL PROTECTED] Date: Thu, 7 Aug 2008 11:36:16 -0400 On Thu, Aug 7, 2008 at 11:18 AM, Bob Rogers [EMAIL PROTECTED] wrote: But there's a concat_p_p_p op, so + is ambiguous. In general, it seems best to use distinct tokens for distinct operations, rather than depending on register types, so that extending the set of register types for a given op doesn't introduce ambiguities by the back door. I forgot about that opcode, so + is out. We don't have another use for .., do we have another one for ~? bxor (binary XOR). .. seems unproblematic. -- Bob
Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Fri, Aug 8, 2008 at 12:57 PM, Patrick R. Michaud [EMAIL PROTECTED]wrote: On Thu, Aug 07, 2008 at 10:15:24AM -0400, Will Coleda wrote: Now, if the problem is that the register allocator is broken, then let's fix the register allocator. If :unique_reg is just a workaround because fixing it is hard, let's document it as deprecated with the expectation that it will be removed when the allocator is no longer broken. Here's my slightly different interpretation: Before we had variable register frames, the register allocator was something of a necessary evil, because we needed something that could fit a large number of symbolic registers into a fixed number of absolute registers. However, now that we have variable register frames, the register allocator is really more of an optimizer than anything else -- i.e., it allows our code to run using fewer registers. And as with any other optimization, we ought to provide the compiler writers with an option to turn the optimization off. This is effectively what :unique_reg does on a per-symbol basis. Of course, :unique_reg on individual symbols might not be the best way to achieve this, but it does at least have historical precedent. If we eliminate :unique_reg, I'd still like to have a way to generate PIR code where I know that the register allocator isn't re-using registers or doing other fancy allocation. Pm Well, at least I've seen some good reasons to keep :unique_reg around; viewing the pir compiler as an assembler (which it is, in the end, albeit a fancy one), :unique_reg is just a directive. Once the whole register allocation stuff is revisited (and I'm sure imcc's should be tested for bugs), this can be reconsidered. For now, this thread provided enough information to update pdd19. I will do this sometime soon. Thanks for all the feedback. kjs
[perl #57794] [doc] POD error in compilers/pirc/new/pircompunit.c
fixed in r30169. apologies for messing up.
Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Wed, Aug 6, 2008 at 8:30 PM, Jonathan Worthington [EMAIL PROTECTED]wrote: Will Coleda wrote: Can you describe a situation where this occurs that isn't a bug in the register allocator? Yes. IIRC, it was added when I was working on the .Net bytecode translator, and it needed to take references to registers in callers. If you're doing that, you need to know that the register won't get re-used once the reference has been taken, or you'll end up with a reference to the wrong register. Named registers holding things that references were being taken to, were marked with :unique_reg, to make sure this didn't happen. It also, as Pm mentioned, works as a hint to the register allocator not to bother trying to allocate something that will have life over the entire compilation unit anyway. Jonathan That sounds like a good reason. Correct me if I'm wrong, (just to get this clear in my head) but this sounds a bit like the register keyword in C, except that C's register is more like a hint, so that the compiler is not obliged to do anything with it. kjs
Fwd: [perl #57656] [PROPOSAL][PIR] change PIR sugar for concat into .. (or something else)
[this message was not sent to list, which it seems it should have; hence the forward.] -- Forwarded message -- From: Andrew Whitworth via RT [EMAIL PROTECTED] Date: Thu, Aug 7, 2008 at 12:11 AM Subject: [perl #57656] [PROPOSAL][PIR] change PIR sugar for concat into .. (or something else) To: [EMAIL PROTECTED] On Wed Aug 06 05:53:07 2008, kjs wrote: My proposal would be to change the concatenate dot into .., which looks like it, but is more explicit, and will prevent such mistakes. I agree that there should be some change. I've run into this problem myself in the past, and it's very frustrating. I don't like having to take into account whitespace to resolve syntactic ambiguities, especially not in something which is basically an assembly language. I like .. and ~. I also like +, if we can get IMCC to reliably understand that when used on strings it performs concatenation instead of some crazy addition. I definitely don't like . since our best practices involves quoting method names such as foo.'bar' which raises all sorts of ambiguity. --Andrew Whitworth
Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Thu, Aug 7, 2008 at 12:45 PM, Will Coleda [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 3:30 PM, Jonathan Worthington [EMAIL PROTECTED] wrote: Will Coleda wrote: Can you describe a situation where this occurs that isn't a bug in the register allocator? Yes. IIRC, it was added when I was working on the .Net bytecode translator, and it needed to take references to registers in callers. Being allowed to poke inside your caller's register set seems... evil? if the HLL compiler can make such an analysis (of liveliness), then it can emit such hints to the register allocator. So it's not that evil imho. then again, one might argue that the register allocator itself should be smart enough to see that a certain object is being retrieved into a register several times in the same block, and decide to optimize that by assigning a register to it for the whole block. kjs Can you provide a working PIR example that shows this functionality? If you're doing that, you need to know that the register won't get re-used once the reference has been taken, or you'll end up with a reference to the wrong register. Named registers holding things that references were being taken to, were marked with :unique_reg, to make sure this didn't happen. It also, as Pm mentioned, works as a hint to the register allocator not to bother trying to allocate something that will have life over the entire compilation unit anyway. Jonathan -- Will Coke Coleda
Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Thu, Aug 7, 2008 at 1:33 PM, Jonathan Worthington [EMAIL PROTECTED]wrote: Will Coleda wrote: So, again, do we in parrot want to support the ability to dig into our callers register set and pull out a particular register since we have no way to say which register that is when we're using PIR? Even unique_reg just says 'the register doesn't change', not it's PMC register 3 When you take a reference to the register you specify (just by naming it - with it's $P0 or it's .local name) which register it is that you want to reference. (What I forgot before is there's a dynop at work here too...). So nothing here needs to know, in the PIR itself, what actual register number is being used. Jonathan I think basically the question remans; is there any way we could do without the :unique_reg? kjs
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
As far as I could see, it seems that the whole n_operators thing is no longer mentioned in pdd19. if it's what Pm thinks, just a change from .pragma n_operators to .n_operators, then that should be added. kjs On Sat, Aug 2, 2008 at 6:56 PM, Patrick R. Michaud [EMAIL PROTECTED]wrote: On Thu, Jul 31, 2008 at 10:07:49AM +0100, Klaas-Jan Stol wrote: On Wed, Jul 30, 2008 at 9:06 PM, via RT Will Coleda wrote From PDD19: =item .pragma n_operators [deprecated] does this mean that by default all ops will have the n_ prefix by default? That would imply some variants of these ops are removed (namely, the non-n_-prefixed ones). I guess what my question is, what's the reason for removing this? I think all this means is that the pragma itself is deprecated. I would presume that the n_operators remain, and that programs can continue to generate both n_ and non-n_ opcodes as needed. Pm
Re: [perl #57410] [TODO] syntactic sugar for named arguments: key = value - Add to PDD19 or deprecate
On Wed, Jul 30, 2008 at 8:22 PM, Will Coleda via RT [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2008 at 9:13 AM, via RT Klaas-Jan Stol [EMAIL PROTECTED] wrote: # New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #57410] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57410 hi, afaics, pdd19 does not specify the syntactic sugar for named arguments. So, the following is not specified: foo( answer = 42 ) This syntax is implemented in IMCC. On a side note, the named parameter specification: .param int key = answer was deprecated (but it is implemented IIRC). This TODO is then as follows: Either specify the above argument syntax (e.g. answer=42) in pdd19 or remove it from the implementationi. kjs I just tried to test (.param int key = answer) and got an error, so I removed it from the PDD (r29880) -- Will Coke Coleda Try this: .sub main foo(answer = 42) .end .sub foo .param int answer = a print a .end Also, see imcc.y, lines 947-956, this implements this. I don't think it's ever used, so we could cheat a bit with the deprecation cycle. kjs
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
On Wed, Jul 30, 2008 at 9:06 PM, via RT Will Coleda [EMAIL PROTECTED] wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #57438] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57438 From PDD19: =item .pragma n_operators [deprecated] does this mean that by default all ops will have the n_ prefix by default? That would imply some variants of these ops are removed (namely, the non-n_-prefixed ones). I guess what my question is, what's the reason for removing this? kjs -- Will Coke Coleda
Re: [perl #57430] [TODO] [PDD19] implement .HLL_map 'Foo' = 'Bar'
Implemented in r29908. kjs On Wed, Jul 30, 2008 at 7:51 PM, via RT Will Coleda [EMAIL PROTECTED] wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #57430] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57430 =item .HLL_map core_type = user_type This is identical to the current implementation that uses a , for its syntax. This syntax needs to be added, and then the comma version can go through a deprecation cycle before removal. -- Will Coke Coleda
Re: [perl #57428] [DEPRECATED] [PDD19] .HLL 'name', 'lib'
Attached is a patch that does this, but I'm not quite sure about the last 2
statements.
Hence, this is submitted as a patch instead of me applying it myself.
kjs
On Wed, Jul 30, 2008 at 7:47 PM, via RT Will Coleda
[EMAIL PROTECTED] wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #57428]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57428
While deprecated, there's currently no other way to achieve this
functionality. See RT #57426 for its replacement.
=item .HLL hll_name, hll_lib [deprecated]
An old form of the .HLL directive that also loaded a shared lib for the
HLL. Use C.loadlib instead.
--
Will Coke Coleda
Index: compilers/imcc/imcc.y
===
--- compilers/imcc/imcc.y (revision 29908)
+++ compilers/imcc/imcc.y (working copy)
@@ -768,6 +768,17 @@
IMCC_INFO(interp)-cur_namespace = NULL;
$$ = 0;
}
+ /* .HLL language variant (without the library name) */
+ | HLL STRINGC
+ {
+STRING * const hll_name = string_unescape_cstring(interp, $2 + 1, '', NULL);
+CONTEXT(interp)-current_HLL =
+Parrot_register_HLL(interp, hll_name);
+
+IMCC_INFO(interp)-cur_namespace = NULL;
+$$ = 0;
+ }
+
| HLL_MAP STRINGC comma_will_be_equals STRINGC
{
Parrot_Context *ctx = CONTEXT(interp);
next generation parrot compiler tools
a Brainf*** interpreter in lolcode: http://forum.lolcode.com/viewtopic.php?id=51 I wonder whether it runs on parrot :-) kjs
[PATCH] json reimplemented with pct
without any internet connection at home you get really bored. that means, time for some fun :-) Included is a patch that implements JSON with the PCT. As JSON is just a data description (sub) language, I was not sure what the TOP rule should contain; I decided for now that it would be just value* Running the pct-based JSON language, just input some string on the command line, like [1, 2, 3], and the output is dumped to stdout. kjs json_pct.patch Description: Binary data
Re: design problem with :outer
maybe I overlooked something, but wouldn't specifying the full outer subname
(including its namespace) help?
like so:
.namespace ['B']
.sub 'inner' :outer(['A';'outer'])
...
.end
instead of the proposed :lexid property.
just a thought. maybe there's something i'm overlooking or missing, but to
me this seems like the most obvious solution.
kjs
On Tue, Jun 24, 2008 at 12:27 AM, Patrick R. Michaud [EMAIL PROTECTED]
wrote:
There appears to be a fundamental design problem in Parrot's
current implementation of :outer. The short summary is that
:outer(sub_name) doesn't provide sufficient specificity
to accurately resolve an outer sub.
In particular, given:
.namespace ['A']
.sub 'outer'
...
.end
.namespace ['B']
.sub 'outer'
...
.lex '$a', x
'inner'()
...
.end
.sub 'inner' :outer('outer')
$P0 = find_lex '$a'
.end
Parrot incorrectly uses A::outer as the :outer sub of B::inner.
In fact, the :outer flag seems to always use the first sub
that it finds having a matching name. At the bottom of this
message I've added a fuller description and demonstration of
the problem.
Jonathan and I discussed this briefly on #parrot.
Constraining :outer to subs only in the same namespace
isn't a sufficient solution for at least two reasons:
1. Some languages (incl Perl 6) allow inner classes and inner
namespaces that can access items in (outer) lexical scopes.
2. Some subs can be :multi -- i.e., multiple subs (each of which
may be an independent outer scope) may be referenced by the
same global symbol name.
The best solution I've come up with thus far is to allow every sub to
have a :lexid(...) attribute that uniquely identifies the sub.
The :outer() flag would then refer to this lexid instead of the
sub's name. A sub that doesn't supply a :lexid(...) attribute
would use its normal name as its lexid (thus existing simple cases
of :outer continue to work).
An alternate approach would be go the other way -- have every sub
use a unique name, and use an :export(xyz) flag to cause the
sub to be placed in the namespace under its common name. The
:anon flag would continue to mean don't make an entry in the
namespace, and omitting :export() would continue to use the sub's
name as the exported name. (I choose :export here to parallel the
proposal in RT#53302 regarding listing methods in namespaces,
but any flag name would work for me.)
Yet another approach would be to keep things as they are now,
but have :outer only refer to the closest (most recent) version
of a sub with that name. We still may have to be careful about
dealing with :multi subs, though, and it might be possible to craft
some HLL code where it's not possible to make this approach work.
(A fourth approach, which I have a strong dislike for, is to have
PCT always generate a unique name for every sub and then use a
:load :init sub to bind them as their common names in the namespace.)
Lexical symbol handling in Parrot is rapidly becoming a huge blocker
for progress on Rakudo -- there are a number of cases in the test
suite that have nested blocks and subs that can't really be implemented
in Rakudo due to problems with Parrot's lexicals.
Pm
-fuller description-
Here's a longish test program that demonstrates the problem.
The key thing to note is that we have two subs named 'bar',
albeit in different namespaces. The Foo::inner sub wants
Foo::bar to be its :outer lexical scope.
$ cat x.pir
.sub 'main' :main
'bar'()
$P0 = get_hll_global ['Foo'], 'bar'
$P0('hello world')
.end
.sub 'printf'
.param string fmt
.param pmc args :slurpy
$S0 = sprintf fmt, args
print $S0
.return ()
.end
.sub 'bar'
$P0 = get_global 'bar'
$I0 = get_addr $P0
'printf'(in global 'bar' (0x%x)\n, $I0)
.end
.namespace ['Foo']
.sub 'bar'
.param pmc x
.lex '$a', x
$P0 = get_global 'bar'
$I0 = get_addr $P0
'printf'(in Foo::bar (0x%x)\n, $I0)
'inner'()
'printf'(back in Foo::bar (0x%x)\n, $I0)
.end
.sub 'inner' :outer('bar')
$P0 = get_global 'inner'
$I0 = get_addr $P0
'printf'(in Foo::inner (0x%x)\n, $I0)
$P0 = getinterp
$P1 = $P0['outer']
$I1 = get_addr $P1
'printf'(Foo::inner's :outer is 0x%x\n, $I1)
$P0 = find_lex '$a'
say $P0
.return ()
.end
When the above is run, we can see that Foo::inner incorrectly
receives the global 'bar' sub as its outer scope. As a result,
it's unable to find the lexical '$a' that was set by Foo::bar .
$ ./parrot x.pir
in global 'bar' (0x82484b8)
in Foo::bar (0x8248508)
in Foo::inner (0x82485b4)
Foo::inner's :outer is 0x82484b8
Lexical '$a' not found
current instr.: 'parrot;Foo;inner' pc 136 (x.pir:48)
called from Sub 'parrot;Foo;bar' pc 83 (x.pir:33)
called from Sub 'main' pc 18 (x.pir:5)
[PROPOSAL] rename languages/abc to languages/bc
hi, as far as I know, languages/abc is an implementation of the 'basic calculator', commonly found on unix platforms, known as 'bc'. For some reasons, this name changed to 'abc' some time ago. However, there is also a programming language called 'abc' (a precursor of Python, Guido van Rossum worked on it IIRC). (I just heard about this language this week) Therefore, it might be a good idea to rename abc to bc, so as to have the option to implement the Real 'abc' language on Parrot (which would be a nice project for anybody wanting to learn PCT). kjs
Re: [perl #55670] [BUG] cannot build perl6
On Thu, Jun 12, 2008 at 3:18 PM, Francois PERRAD via RT [EMAIL PROTECTED] wrote: Klaas-Jan Stol (via RT) a écrit : # New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #55670] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55670 hi, I'm having trouble when building perl6: I'm on windows xp (win32), using strawberry perl and msvc express edition. output is shown below. Which SVN revision ? This morning, r28255 on Windows 2000, using ActiveState Perl 5.8.8 and MinGW gcc, build fine. Recent chromatic's commits require a 'make realclean'. D'Oh! that did it. sorry for the trouble. (this ticket can be rejected) kjs
call for papers for conference on VMs
I came accross this: http://www.cs.iastate.edu/~design/vmil/cfp.shtml I didn't read the whole page, but this caught my eye: I had to think about modularization with the whole compiler architecture on Parrot (PCT). quote Research and experience papers: These submissions should describe work that advances the current state of the art in support of advanced separation of concerns techniques in virtual machines and intermediate languages. Experience papers that are of broader interest and describe insights gained from practical applications. The page limit for these submissions is 10 pages. /quote As parrot is a new VM, this may be interesting. Of course I'm aware that there's not many researchers working on parrot (if any), but it might be an idea. It'd be nice to have Parrot in the spotlight in an academical setting. kjs
Re: [perl #55332] [BUG] can't build parrot on win32 + strawberry perl
somehow a fresh checkout has resolved the problem (but my other sandbox was still up to date according to svn status...) anyhow, this ticket can be rejected. kjs On Thu, Jun 5, 2008 at 10:38 AM, via RT Klaas-Jan Stol [EMAIL PROTECTED] wrote: # New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #55332] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55332 Parrot is built fine, but there seems to be something wrong in PGE. I'm using visual studio express edition and strawberry perl. this is the output: [...] mingw32-make: Leaving directory `C:/Documents and Settings/klaas-jan.stol/My Documents/parrot3/src/dynoplibs' mingw32-make -C compilers\pct mingw32-make: Entering directory `C:/Documents and Settings/klaas-jan.stol/My Documents/parrot3/compilers/pct' ..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT.pbc --output-pbc PCT.pir ..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\PAST.pbc --output-pbc src\PAST.pir ..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\Grammar.pbc --output-pbc src\PCT\Grammar.pir ..\..\parrot.exe -o ..\..\runtime\parrot\library\PCT\HLLCompiler.pbc --output-pbc src\PCT\HLLCompiler.pir mingw32-make: Leaving directory `C:/Documents and Settings/klaas-jan.stol/My Documents/parrot3/compilers/pct' mingw32-make -C compilers\pge mingw32-make: Entering directory `C:/Documents and Settings/klaas-jan.stol/My Documents/parrot3/compilers/pge' C:\strawberry\perl\bin\perl.exe -MExtUtils::Command -e rm_f PGE.pbc ..\..\runtime\parrot\library\PGE.pbc C:\strawberry\perl\bin\perl.exe -e PGE\builtins_gen.pir ..\..\parrot.exe -o PGE.pbc --output-pbc PGE.pir ..\..\parrot.exe ..\..\runtime\parrot\library\PGE\Perl6Grammar.pir --output=PGE\builtins_gen.pir PGE\builtins.pg Null PMC access in invoke() current instr.: 'parrot;PGE::Perl6Grammar::Compiler;compile' pc 200 (..\..\runtime\parrot\library\PGE\Perl6Grammar.pir:157) called from Sub 'parrot;PCT::HLLCompiler;eval' pc 753 (src\PCT\HLLCompiler.pir:450) called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1065 (src\PCT\HLLCompiler.pir:587) called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1257 (src\PCT\HLLCompiler.pir:679) called from Sub 'parrot;PGE::Perl6Grammar::Compiler;main' pc 16 (..\..\runtime\parrot\library\PGE\Perl6Grammar.pir:66) mingw32-make: *** [PGE.pbc] Error 1 mingw32-make: Leaving directory `C:/Documents and Settings/klaas-jan.stol/My Documents/parrot3/compilers/pge' NMAKE : fatal error U1077: 'mingw32-make' : return code '0x2' Stop. === myconfig === Summary of my parrot 0.6.2 (r28084) configuration: configdate='Thu Jun 5 09:24:55 2008 GMT' Platform: osname=MSWin32, archname=MSWin32-x86-multi-thread jitcapable=1, jitarchname=i386-MSWin32, jitosname=MSWIN32, jitcpuarch=i386 execcapable=1 perl=C:\strawberry\perl\bin\perl.exe Compiler: cc='gcc', ccflags='-DWIN32 -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -maccumulate-outgoing-args -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wno-missing-format-attribute -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull', Linker and Libraries: ld='g++', ldflags='', cc_ldflags='', libs='-lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lgmp' Dynamic Linking: share_ext='.dll', ld_share_flags='-shared ', load_ext='.dll', ld_load_flags='-shared ' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8
Re: Comments on parrotblog
On 5/28/08, Will Coleda [EMAIL PROTECTED] wrote: Would it be helpful to have comments that are posted on articles on parrotblog sent to this mailing list? Very helpful IMO. kjs
question tutorial/license
Hi, I'm converting the tutorial on the PCT to POD files, so they can be added to languages/squaak/doc. I do have a question on the license; not sure if this is an issue. I put the tutorial in the public domain, by adding a section 'license' below each episode, like so: The source code in this tutorial has been released by the author into the public domain. Where this is not possible by law, the author grants license to use this file for any reason without any rights reserved, and with no warranty express or implied or fitness for a particular purpose. However, will this be a problem when storing this in the parrot repos.? All advice is welcome! (maybe I could change the license by editing the posts? ) thanks in advance, kjs
Re: [perl #46499] [RFE] Allow comment lines in PIR .param list
On Fri, May 23, 2008 at 4:05 AM, Will Coleda via RT [EMAIL PROTECTED] wrote: On Wed Oct 17 12:09:54 2007, bernhard wrote: Currently following PIR is failing because of the '#' in the '.param' list. .sub main :main ( $S1 ) = my_sub( 'hello', 'world' ) say $S1 .end .sub my_sub .param string str1 # .param string str3 .local string hello hello = concat str1, str3 .return( hello ) .end This surprised me, as I expected that '#' lines would be ignored. So I propose to tweak the PIR grammar such that comment lines are allowed Regards, Bernhard Supporting blank lines between .param would also be a reasonable extension. I've updated the tests in t/compilers/imcc/syn/regressions.t to test for those conditions too. The parser already allows comments and whitespace before the first .param, just not in between them. IIRC, the blank line stuff in .param lines has to do with the helper_state non-terminal; this is a kludge to make things work currently, as there's a shift/reduce (or reduce/reduce, can't remember) conflict otherwise on the statement (instructions) non-terminal. Parsing of '\n' would ideally be done by both the lexer and parser, to introduce the concept of 'logical newline', representing one or more newlines. I did this in pirc/new, but this is not straightforward, as IMCC's macro parser might get in trouble then. kjs
Re: [perl #46499] [RFE] Allow comment lines in PIR .param list
On Fri, May 23, 2008 at 2:42 PM, Andrew Whitworth [EMAIL PROTECTED] wrote: On Fri, May 23, 2008 at 6:55 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: IIRC, the blank line stuff in .param lines has to do with the helper_state non-terminal; this is a kludge to make things work currently, as there's a shift/reduce (or reduce/reduce, can't remember) conflict otherwise on the statement (instructions) non-terminal. Parsing of '\n' would ideally be done by both the lexer and parser, to introduce the concept of 'logical newline', representing one or more newlines. I did this in pirc/new, but this is not straightforward, as IMCC's macro parser might get in trouble then. I can't find a non-terminal called helper_state in either the lexer or the parser, there is a helper_clear_state that forces a precedence onto the clear_state action. yes that's the one I meant. Sorry, I was being lazy; I wrote that reply from the top of my head, didn't check the source. It seems to me that the most straight-forward way to hack this in would be to add a bare newline in as an alternative to the sub_param non-terminal. This would cause the sub_param to also eat all newlines between the parameters block and the rest of the subroutine body, but that shouldn't cause any problems. I'll try to throw together a patch for this, see how it works. --Andrew Whitworth great, if it works that'd be good. but personally, IMHO this should be fixed in a major rewrite of the pir grammar eventually (so that all other kludges can be got rid of too); it's more complex than necessary, and not good for maintainenance. kjs
question on tutorial/license
Hi, I'm converting the tutorial on the PCT to POD files, so they can be added to languages/squaak/doc. I do have a question on the license; not sure if this is an issue. I put the tutorial in the public domain, by adding a section 'license' below each episode, like so: The source code in this tutorial has been released by the author into the public domain. Where this is not possible by law, the author grants license to use this file for any reason without any rights reserved, and with no warranty express or implied or fitness for a particular purpose. However, will this be a problem when storing this in the parrot repos.? All advice is welcome! (maybe I could change the license by editing the posts? ) thanks in advance, kjs
[perl #36283] [TODO] pasm/pir: forbid assignment syntax for inout params
On Thu Dec 13 05:54:17 2007, kjs wrote: On Tue Jun 14 02:30:00 2005, chip wrote: It makes sense to allow e.g. C$P0 = add $P1, $P2 as alternative syntax for Cadd $P0, $P1, $P2. However, when the first parameter is inout rather than out, assignment syntax is *not* appropriate. For example, Csubstr $P0, 1, 2, x actually modifies $P0 rather than just assigning to it, so C$P0 = substr 1, 2, x is just wrong, and should be a compile-time error. In order to make this work, a check should be done for each op in the pir compiler. Besides the question whether an identifier is an op (is_op() ), its meta-data must be retrieved. While I'm sure this is possible, by having the .ops pre-processor store the mode of the op parameters somewhere, it does involve extra checks, making the pir compiler slower. Also, for ops in dyn.op.libs written by third parties, which are only distributed in binary form (as the .so or .dll file), which does not include any source, this check cannot be done, EXCEPT this check is ALSO done during runtime. In short, this issue is a pain to solve; is it worth fixing? (probably that's why this ticket is stalled.) on second thought, I had another idea. currently the PIR compiler (IMCC) will select the appropriate operation based on the types of the arguments. So: print hi will become: print_sc hi # print s(tring) c(onstant). Currently, you can also write: $S0 = hi $S0 = print Maybe it's an idea that inout arguments are marked using the same strategy; so for instance: $S0 = print will be translated to: print_sco # print s(tring) c(onstant) o(utput) or whatever letter/mark is chosen to mark that a parameter is an output parameter; surely, Parrot won't have a print_sco instruction, only a print_sc (or, if you want to make it explicit: print_sci). This way, there's no additional overhead of checking any meta data, but we can easily emit an error message when writing stuff like $S0 = print. just some thoughts. kjs
[perl #48188] [TODO] [amber] Correct overflow for -maxint in abs()
amber sources are no longer stored in the parrot repository. ticket rejected.
[perl #48192] [TODO] [amber] Correct overflow issue in integer()
amber sources are no longer stored in the parrot repository. ticket rejected.
[perl #48184] [TODO] [amber] Use has(index) to check indices in set_item()
amber sources are no longer stored in the parrot repository. ticket rejected.
[perl #48186] [TODO] [amber] Consider using unicode in character()
amber sources are no longer stored in the parrot repository. ticket rejected.
[perl #48190] [TODO] [amber] Can null variable check be reinstated by generating n_neg instead of neg?
amber sources are no longer stored in the parrot repository. ticket rejected.
[perl #48182] [TODO] [amber] Reject out of range values in item()
amber sources are no longer stored in the parrot repository. ticket rejected.
string documentation: PDD and docs/strings.pod
hi, it seems that there is overlap in the strings pdd (28) and the strings implementation document in docs/strings.pod. I'm not sure if this is a good idea; I think these should be merged. If so, I'll open a ticket to do so (but wanted to check first) kjs
Re: Concurrency implementation tasks
On Mon, Apr 28, 2008 at 1:53 PM, Allison Randal [EMAIL PROTECTED] wrote: Bob Rogers wrote: From: Klaas-Jan Stol [EMAIL PROTECTED] about the removal of internal_exception: the specified ticket (in the list on the wiki) does not have a conclusion: no final decision seems to be have made on that issue. What's more, a quick check on a few calls to internal_exception revealed that there's no interpreter argument available . . . Yes; that's what the ticket is really about, whether it's worth modifying callers in the few cases where it's needed, so the ticket is really misnamed. internal_exception itself is still needed for sanity checking in cases where exceptions cannot work. A good example of this is for instance in tsq.c::queue_destroy. (line 381) This exception indicates something's wrong with the thread-safe queue, which I assume is really really fatal, and should result in parrot exiting? kjs Yes. These cases should be few (stack corruption, severe GC problems), but they cannot be reduced to zero without removing useful sanity checks. In some cases, it may be a choice between an internal_exception and a (possibly exploitable) jump into random memory. In any case, convertible calls to internal_exception should already have been handled in RT#40392 (though it is possible that other inappropriate internal_exception calls may have crept in since then). There's certainly a need for a way to die cleanly and print out an error message and possibly a backtrace under extreme circumstances. But that's not what internal_exception does (even though we're using it that way now). internal_exception is an early and very poor attempt at an implementation of exceptions, and carries a load of baggage of nasty code. I'll put in a new task: - Provide a simple function for completely fatal errors where throwing an exception isn't possible, and replace last dregs of 'internal_exception' with it. Allison so this function should exit then? Maybe it should be called 'exit_fatal', or something at least that marks that parrot will bail out. kjs
Please check out ticket RT#39845
Hi, Could anybody check out ticket #39845? I replied on it multiple times, but somehow the reply button is not visible anymore when I log in. I think the ticket can be closed. thanks heaps, kjs
Re: Concurrency implementation tasks
On Sun, Apr 27, 2008 at 2:00 PM, Allison Randal [EMAIL PROTECTED] wrote: By popular demand, I've put my ongoing list of tasks for the concurrency implementation branch on the wiki. Mark a task you start to work on with your initials, so we know you're working on it: http://www.perlfoundation.org/parrot/index.cgi?concurrency_tasks Allison about the removal of internal_exception: the specified ticket (in the list on the wiki) does not have a conclusion: no final decision seems to be have made on that issue. What's more, a quick check on a few calls to internal_exception revealed that there's no interpreter argument available. Does this imply that the function in which this call to internal_exception occurs should be updated? Or could we pass NULL for the interpreter argument to real_exception? A good example of this is for instance in tsq.c::queue_destroy. (line 381) This exception indicates something's wrong with the thread-safe queue, which I assume is really really fatal, and should result in parrot exiting? kjs
Re: Please check out ticket RT#39845
On Sun, Apr 27, 2008 at 7:38 PM, Mark Glines [EMAIL PROTECTED] wrote: On Sun, 27 Apr 2008 19:25:55 +0100 Klaas-Jan Stol [EMAIL PROTECTED] wrote: Hi, Could anybody check out ticket #39845? I replied on it multiple times, but somehow the reply button is not visible anymore when I log in. http://rt.perl.org/rt3/Ticket/Display.html?id=39845 has Reply buttons. http://rt.perl.org/rt3/Public/Bug/Display.html?id=39845 doesn't. sorry about that; didn't know. Fun, huh. I think the ticket can be closed. Looks like it... I'll close it. Thanks! Mark thanks! kjs
amber tickets
hi, there are some RT tickets for languages/amber, but this language does not seem to be in the repository anymore. I'd say the tickets can be rejected. Am I right? 48180 48182 48184 48186 48188 48192 kjs
Re: [perl #53356] Misc. build warnings
On Sat, Apr 26, 2008 at 7:39 PM, chromatic [EMAIL PROTECTED] wrote: On Friday 25 April 2008 10:50:24 Will Coleda wrote: Miscellaneous build warnings that need to be cleaned up. src/key.c:306: warning: switch missing default case Fixed in 27195. compilers/imcc/imclexer.c:4288: warning: switch missing default case compilers/imcc/imclexer.c:4447: warning: comparison between signed and unsigned compilers/imcc/imclexer.c:4615: warning: switch missing default case These are all in generated code. I suspect we're not going to clear these up without patching lex/flex or writing a filter for post-generation. You can quote me on this: yuck. -- c In my experience, compiling a flex-generated lexer with -Wall flag on msvc should not emit these warnings in a normal situation; in other words, I'm fairly sure (but not absolutely sure) that this can be fixed without a filter. kjs
Re: Squaak README
Good idea! I'll add the file (if nobody beats me to it). BTW, I think it'd be good to keep Squaak up to date, meaning that once return statements are supported in PAST, that these are added as well. This way it can be used as a complete showcase, demonstrating all of PAST. As soon as PAST is feature-complete and I have enough time to play, I'll improve Squaak kjs On Fri, Apr 25, 2008 at 4:49 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: Someone looking for basic information about Squaak may have difficulty finding it. Below is some text I adapted from the parrotblog tutorial that might be suitable as a starting point for a README in languages/squaak. Feel free to add or modify it as appropriate. Pm [Adapted from the parrotblog.org page -- feel free to update --Pm] Squaak: A Simple Language Squaak is a case-study language described in the Parrot Compiler Tools tutorial at http://www.parrotblog.org/2008/03/targeting-parrot-vm.html . Squaak demonstrates some common language constructs, but at the same time is lacking some other, seemingly simple features. For instance, Squaak does not have return, break or continue statements (or equivalents in your favorite syntax). Squaak has the following features: * global and local variables * basic types: integer, floating-point and strings * aggregate types: arrays and hash tables * operators: +, -, /, *, %, , =, , =, ==, !=, .., and, or, not * subroutines and parameters * assignments and various control statements, such as if and while A number of common (more advanced) features are missing. Most notable are: * classes and objects * exceptional control statements such as break and return * advanced control statements such as switch * closures (nested subroutines and accessing local variables in an outer scope)
Re: Notes on removing stack.ops, further steps
On Tue, Apr 22, 2008 at 7:52 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: Tonight I resolved RT#52838 and RT#52840, eliminating the saveall/restoreall opcodes, the register stack, and fixing up tests and other items to avoid save/restore/etc. opcodes. I've also created a userstack branch where I've got the details for removing the rest of stack.ops . I've already implemented and tested it (it's pretty straightforward), but since DEPRECATED.pod says that these opcodes are to be removed post 0.7.0 it's too early to commit these changes to trunk. One of the interesting features of removing stack.ops is that we no longer need the STACK_ENTRY_INT, STACK_ENTRY_FLOAT, or STACK_ENTRY_STRING types in src/stacks.c, as those were being used only by the save/restore opcodes. Should we see about removing these entry types from the code, or should we leave them there in case we come up with a need for them in the future? in case you're leaving them in, I'd suggest to make a comment on their (former) usage, or maybe an RT ticket, so later code archeologists won't have to figure out what they are. You probably thought of this yourself, but just in case :-) kjs
[PROPOSAL] Add tutorial language Squaak to examples in repository
hi, Currently, the pct tutorial language is out there, mostly on the parrotblog entries, and I uploaded a .zip onto the wiki. However, updating it is now a pain, because I have to recreate a .zip and replace it on the wiki. What do people think about adding it in the examples directory? At first I was somewhat hesitant to do so, as I rather not see grow the parrot repository too big... (it's already big), but... it would be quite helpful to store squaak somewhere, so it doesn't get lost. comments welcome, kjs PS: On a sidenote, besides a job, I have limited internet access, which doesn't allow me to connect to irc in the evening :-(
Re: Another Optimization Target: bsr and stacks
On Mon, Apr 21, 2008 at 8:25 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 10:19:08AM -0700, chromatic wrote: I'm still exploring the Rakudo build progress as a profiling target for likely optimizations. After this weekend's work, I have src/gen_actions.pir generation down to 27,788,055,796 instructions (with an optimized Parrot). A big chunk of that time goes to support bsr_ic: 7,784,136,854 core.ops:Parrot_bsr_ic 7,775,231,886 stacks.c:stack_push 7,763,569,145 stack_common.c:stack_prepare_push 7,754,735,042 stack_common.c:cst_new_stack_chunk Why is it expensive? *Every* call to cst_new_stack_chunk() requests a free bufferlike object from the GC. 98% of the inclusive cost of these four functions is in running the GC. Someone who's familiar with the stack code (or wants to be) might be able to find a big optimization here. To me, the scary part of src/stacks.c is at the beginning: The stack is stored as a linked list of chunks (CStack_Chunk), where each chunk has room for one entry. Eek! For something like bsr_ic, which is really just pushing a return address (i.e., opcode_t *) onto a stack, we're allocating a new GC-able object for every bsr invocation, and freeing it on ret. Since PGE uses bsr/ret for its backtracking, that's a lot of allocations. In fact, this seems to be the case for everything using the generic stack, which AFAICT is the interp-dynamic_env structure. So, everything that gets pushed onto this stack (exceptions, continuations, coroutines, bsr/ret calls) ends up with a separate gc-able structure (Stack_Chunk) to hold the stack entry. So, switching PGE from bsr/ret to another control structure doesn't give us a win here. I think we'd get a BIG win if we changed the dynamic_env stack to have an approach similar to ResizableIntegerArray, where we allocate arrays of Stack_Chunk entries and manage them that way, instead of a separate allocation per element in the stack. what about actually using a ResizableIntegerArray for this purpose? (or PMC, if Integer is not suitable for storing addresses) Or is this a really dumb idea? kjs
Re: [PROPOSAL] Add tutorial language Squaak to examples in repository
On Mon, Apr 21, 2008 at 8:41 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Mon, Apr 21, 2008 at 08:34:49PM +0100, Klaas-Jan Stol wrote: hi, Currently, the pct tutorial language is out there, mostly on the parrotblog entries, and I uploaded a .zip onto the wiki. However, updating it is now a pain, because I have to recreate a .zip and replace it on the wiki. What do people think about adding it in the examples directory? At first I was somewhat hesitant to do so, as I rather not see grow the parrot repository too big... (it's already big), but... it would be quite helpful to store squaak somewhere, so it doesn't get lost. I think it could go either in examples/ or in languages/ . Either way, having it in the repo somewhere is probably the best place for it at the moment. it's added in languages/ ../../parrot squaak.pbc examples/life.sq, and enjoy :-) kjs
Re: PCT tutorial update suggestions
On Fri, Apr 11, 2008 at 5:32 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote:
With some recent PCT-related changes I think we may want to
update the tutorials a bit.
1. Remove the custom List class.
ResizablePMCArray now has built-in shift/unshift/push/pop
methods, so we can use it directly from NQP and don't need
to create a custom List class to be able to invoke these
operations.
2. Remove :scope attribute from PAST::Var nodes.
My intent has been that most PAST::Var nodes for simple variables
would not require individual scope attributes; with the changes
I checked into Parrot tonight this should be easier. In Squaak's
case this means that the Cidentifier action method should now
read:
method identifier($/) {
make PAST::Var.new( :name($name),
:viviself('Undef'),
:node($/) );
}
In particular, note that there's no longer a need to
explicitly search outer blocks for the scope -- PCT
will handle this automatically.
To indicate that all undeclared variables should default
to 'package' scope, we use the Csymbol_defaults method on
the top-level block. For Squaak, we add the following to its
TOP action method:
$?BLOCK.symbol_defaults(:scope('package'));
This says that 'package' scope is to be used for any PAST::Var
node that doesn't have its own :scope and that doesn't have a
scope provided by an outer block's symbol hash.
3. (Bonus problem) Eliminate @?BLOCK
Since PAST::Var nodes no longer need to search outer blocks
(PCT will handle that), we no longer need to maintain a @?BLOCK
array. So, for bonus points, eliminate @?BLOCK from the Squaak
methods.
I don't really see immediately that @?BLOCK can be removed...
blocks open and close, but $?BLOCk should always point to the current
block, right?
So, in order to restore $?BLOCK, we need to store the old one
somewhere, and this must be done in a LIFO order (to allow for
multiple nested blocks).
Maybe I'm missing something. Could you explain this a bit?
thanks!
kjs
If I can help explain or demonstrate any of the above, let me know.
Thanks!
Pm
Re: [perl #52854] [bug] Build failure with G++
On Mon, Apr 14, 2008 at 8:10 AM, Senaka Fernando [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 6:33 AM, chromatic [EMAIL PROTECTED] wrote: On Sunday 13 April 2008 08:14:11 Senaka Fernando wrote: The build of Parrot fails with g++, which is a possible indication that it fails on other C++ compilers too. I have attached herewith patches to some issues. Thanks, applied as r26965, except for the patch to compilers/imcc/imclexer.c, which is a generated file. The source is compilers/imcc/imcc.l. Well if it is a generated file, why should it be under version control? Shouldn't that be removed? Not all platforms have lex/yacc (or flex/bison) available, like windows (there are ports, but your average windows user doesn't have them). (and I'm not sure, but I think the ports available are not really up to date) kjs Regards, Senaka -- c
Re: [perl #52858] $ vars in PASM don't work, but aren't disallowed either
On Mon, Apr 14, 2008 at 12:26 AM, via RT Bob Rogers [EMAIL PROTECTED] wrote: # New Ticket Created by Bob Rogers # Please include the string: [perl #52858] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52858 If you run the following PASM code: new P0, 'Integer' set P0, 77 set $N1, 1 set $N2, 2 set $N3, 3 print $N1 print ' ' print $N2 print ' ' print $N3 print \n print P0 print \n end you will see something like the following output: [EMAIL PROTECTED] ./parrot dollar-vars.pasm 3.00 3.00 3.00 Segmentation fault [EMAIL PROTECTED] The reason for this odd behavior is that all of the $N registers are getting mapped to N-1 (that's the register *before* N0); disassembly shows the bogus register numbers clearly. This happens to overwrite P0, hence the segfault. So either the $ syntax for registers must be disabled in PASM, or it must be implemented properly. (I don't particularly care, and haven't the IMCC-fu to do anything about it myself.) -- Bob Rogers http://rgrjr.dyndns.org/ IMCC's lexer has a number of states, one of which is emit. I'm not clear on how all these states are interacting,and to what cases these states correspond, but I think emit is pasm mode (I might be wrong here! I never really figured out what all states in IMCC are). The lexer recognizes virtual registers (with the $) in this emit state too. Ideally, the lexer could be tweaked that when reading $P0 in pasm mode, it emits an error message saying you can't use virtual registers in pasm mode. Rewriting the lexer rules (and states) might be tricky, but a simple solution would to check whether the lexer is in pasm mode in the action body of the rule for registers. (I think there's a flag in IMCC_INFO). I don't have time currently to work on this, unfortunately kjs
Re: macro PIR needs
IMCC's macro processor doesn't currently allow for uniquely generated variable names. It's in the pdd (19), but not yet implemented. You're right in that it only works for labels. kjs On Mon, Apr 14, 2008 at 1:32 PM, François Perrad [EMAIL PROTECTED] wrote: In Lua libraries, I wrote many time the same piece of code. The purpose of this code is to register each function. So, I try to write the following PIR macro : .macro register(tname, fname) .const .Sub $fname = .fname $fname.'setfenv'(_lua__GLOBAL) set $P1, .fname .tname[$P1] = $fname .endm Currently, I obtain the following error : error:imcc:'$fname' is not a valid register name in macro '.register' line 30 included from 'src\lib\base64.pir' line 1 make: *** [src\lib\base64.pbc] Error 2 The notation $fname seems limited to local label (.label) and local variable (.macro_label). Are there any other notation? Or is this a new requirement? The attached patch is a full example for languages/lua/lib/base64.pir François Perrad.
Re: PCT tutorial update suggestions
Hi,
these are good improvements! It will also improve performance a bit I think.
currently I don't really have much time to work on it, but I will in
maybe a week or so (or 2 weeks, possibly)
If people are looking for additional Exercises I suggest these are nice :-)
kjs
On Fri, Apr 11, 2008 at 5:32 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote:
With some recent PCT-related changes I think we may want to
update the tutorials a bit.
1. Remove the custom List class.
ResizablePMCArray now has built-in shift/unshift/push/pop
methods, so we can use it directly from NQP and don't need
to create a custom List class to be able to invoke these
operations.
2. Remove :scope attribute from PAST::Var nodes.
My intent has been that most PAST::Var nodes for simple variables
would not require individual scope attributes; with the changes
I checked into Parrot tonight this should be easier. In Squaak's
case this means that the Cidentifier action method should now
read:
method identifier($/) {
make PAST::Var.new( :name($name),
:viviself('Undef'),
:node($/) );
}
In particular, note that there's no longer a need to
explicitly search outer blocks for the scope -- PCT
will handle this automatically.
To indicate that all undeclared variables should default
to 'package' scope, we use the Csymbol_defaults method on
the top-level block. For Squaak, we add the following to its
TOP action method:
$?BLOCK.symbol_defaults(:scope('package'));
This says that 'package' scope is to be used for any PAST::Var
node that doesn't have its own :scope and that doesn't have a
scope provided by an outer block's symbol hash.
3. (Bonus problem) Eliminate @?BLOCK
Since PAST::Var nodes no longer need to search outer blocks
(PCT will handle that), we no longer need to maintain a @?BLOCK
array. So, for bonus points, eliminate @?BLOCK from the Squaak
methods.
If I can help explain or demonstrate any of the above, let me know.
Thanks!
Pm
Re: [svn:parrot-pdd] r26707 - trunk/docs/pdds/draft
Hi Geoffrey,
thanks for your reply and your thoughts. Please keep in mind it was
not a proposal to remove this long-invocation syntax, it just came to
mind when I realized that it's not used that much.
On Thu, Apr 3, 2008 at 5:17 PM, Geoffrey Broadwell [EMAIL PROTECTED] wrote:
On Wed, 2008-04-02 at 14:16 -0700, [EMAIL PROTECTED] wrote:
=head3 Directives used for Parrot calling conventions.
+{{ A bit of a radical idea, but now would be the time to decide on this:
+ Remove the whole long-style invocation syntax altogether.
+ Only allow the short version.
+ As PIR is typically being generated, and hopefully by PCT-based
+ compilers, there seems to be no real use for too much syntactic
+ sugar. Just a thought.
+}}
Not sure I understand this, since it seems self-contradictory. Or maybe
I'm just reading it wrong. To my eyes, you're saying you want to get
rid of the syntax that involves a pile of directives, setting up various
parameters, return slots, etc., and then doing .call, in favor of
keeping var._method([args]). But then you go on to say that you don't
want too much syntactic sugar, while the short form is definitely more
highly sugared. I'm confused.
Yes, my choice of words was poor there. What I meant was, is it
desirable to have More Than One Way To Do IT? After all, PIR is not
Perl, it's an assembly language (although a bit higher level than your
average ASM), so once there are complete HLLs, the need to write PIR
manually will decrease, and I doubt the need to have such a rich
assembly language.
I can see advantages in both keeping it and removing this sugaring, I
don't really have a personal preference. It's just a thought.
Apart from that confusion, I'd still argue against removing the short
form. One rule of assembly languages is that even if the normal case is
that compilers write the assembly code, there are always times when a
human has to do it by hand (bootstrapping, microoptimization, whatever).
Having to write a fair amount of it myself right now, I'm VERY thankful
for every bit of sugar I can get.
I don't argue to remove the short form; I think the short form should
be kept definitely.
I'd also be against getting rid of the *functionality* present in the
long form, because there are things the short form apparently can't do
yet, such as hoisting repeated return continuation creation out of a
loop. (I haven't had to do that myself yet, but I would expect that an
optimizing compiler would, and a hand-optimizing PIR programmer
definitely would.)
I can't say anything about this, because I don't really understand this :-)
But if what you say is true, it is a very valid reason to keep all
syntax (or fix the short-version).
Mind you, there's nothing magical about the *syntax* used for the long
form. If someone has better syntax, or wants to fold the special
features of the long form into adverbial flags on the short form, or
what have you, so much the better.
-'f
Summarizing, I noticed that the long-invocation form is not used that
much; even the PCT generate the short version.
If there's PIR syntax that's never used, it may as well be removed.
Note that I do not propose to do so, I just want to give this a bit of
attention, so it's at least well-considered.
If there's any reason whatsoever to keep the long-invocation syntax
(or any syntax for that matter), then I'm all in favor of keeping it.
kjs
[PDD19] some remarks/proposals
hi,
i have some remarks/proposals on the current PDD 19 (PIR).
It already is full with proposals and issues that must be resolved
before it can be pushed out of draft status, but I figured now is the
time (as it will soon be worked on, I heard)
shall i provide this as a patch, or can i go ahead and commit my {{
PROPOSAL }} stuff?
kjs
Q on lexicals
I'm a bit confused on how lexicals are supposed to work. Below is a simple example, which looks more or less on code generated by PCT for a try/catch statement. in the exception handler, a new Undef is created in $P0. When leaving this line, this code won't work. When commenting out this line, it will print hi, as expected. I don't get that, because, 3 lines later, a new object is stored by name lex; I had expected to overwrite the current object by that name. Where do I go wrong? kjs == .sub main push_eh exc foo() pop_eh .return () exc: $P0 = new 'Undef' .lex ex, $P0 .get_results($P1, $S0) store_lex ex, $P1 find_lex $P2, ex print $P1 .end .sub foo $P0 = new 'String' $P0 = hi throw $P0 .end
Re: Q on lexicals
On Tue, Apr 1, 2008 at 2:37 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Tue, Apr 01, 2008 at 01:23:38PM +0200, Klaas-Jan Stol wrote: in the exception handler, a new Undef is created in $P0. When leaving this line, this code won't work. When commenting out this line, it will print hi, as expected. I don't get that, because, 3 lines later, a new object is stored by name lex; I had expected to overwrite the current object by that name. [...] .sub main push_eh exc foo() pop_eh .return () exc: $P0 = new 'Undef' .lex ex, $P0 .get_results($P1, $S0) store_lex ex, $P1 find_lex $P2, ex print $P1 .end .sub foo $P0 = new 'String' $P0 = hi throw $P0 .end I think that .get_results() has to be the _first_ instruction executed as part of an exception handler. When I change the exception handler to the following seems to work just fine: exc: .get_results($P1, $S0) $P0 = new 'Undef' .lex ex, $P0 store_lex ex, $P1 find_lex $P2, ex print $P1 Pm yes, I think you're right. thanks for this info. declaring a .lex before this .get_results instruction is allowed, though. This is a bit confusing: some directives (such as .get_results) are mapped to instructions, while .lex is just a directive. If they're just directives, they're allowed. kjs
Re: [perl #52280] [PATCH] HLLCompiler: fix overriding default prompt using $commandline_prompt
Hi, Although the patch is appreciated, I think it's better to keep it empty; if you don't set a prompt, there shouldn't be one. I do not know a language that has an empty prompt, but I'm sure there is. Anyway, I think an empty prompt is a better default. my 2c, kjs On Mon, Mar 31, 2008 at 12:09 AM, via RT mmcleric2 [EMAIL PROTECTED] wrote: # New Ticket Created by mmcleric2 # Please include the string: [perl #52280] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52280 HLLCompiler allows to set commandline_parser to any value, but prints default ' ' prompt always. This patch fixes that behavior. -- Vyacheslav Matjukhin
Re: wishlist for NQP
On Fri, Mar 28, 2008 at 2:20 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Thu, Mar 27, 2008 at 10:33:54PM +0100, Klaas-Jan Stol wrote: On Wed, Mar 26, 2008 at 6:30 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wrote: * list ops ( I think this is meant by list ops? ) All languages that have some kind of scope mechanism now have to define a class List, which has an unshift and shift method, which are just wrappers for the equally named parrot ops. I don't quite understand what is meant by have to define a class 'List'. Can you give an example? Yes, sorry, I didn't explain the context. In order to write @?BLOCK.shift() (and unshift() ) (for implementation of the scope stack in pretty much all languages), @?BLOCK must be an object that has these methods. As ResizablePMCArray doesn't have such methods, the trick here is to subclass ResizablePMCArray (calling it List) and wrapping the shift and unshift instructions in the equally-named methods. Actually, it can be done without subclassing via the following .namespace [ 'ResizablePMCArray' ] .sub 'unshift' :method .param pmc list .param pmc value unshift list, value .end .sub 'shift' :method .param pmc list .param pmc value shift list, value .end I've already commented that perhaps these should be a built-in part of the ResizablePMCArray in Parrot. However, if that's not likely to happen, then perhaps either PCT or NQP should go ahead and provide them, so that they're available whenever PCT is loaded. But part of me feels that adding methods to ResizablePMCArray is a little out of NQP's scope. So, our choices become: 1. Have NQP automatically recognize shift/unshift/push/pop as special functions (keywords) and map them directly to Parrot's shift/unshift opcodes. 2. Add shift/unshift/push/pop methods to ResizablePMCArray (or one of its superclasses) in Parrot 3. Have PCT and/or NQP supply the shift/unshift/push/pop methods. 4. Have PCT and/or NQP define their own List subclass that provide shift/unshift/push/pop (this could conflict with List classes in other languages). 5. Advise compiler writers to use some other existing class for things like @?BLOCK (any of Capture_PIR, Match, or PAST::Node would work, but could be confusing). Opinions from the gallery would be greatly welcomed here. The other items in your message all make good sense and I think I'm likely to adopt them as soon as we can get implementations for them. :-) Attached is a patch implementing: * ++ and -- postfix operators, implemented as n_sub and n_add (taking 1 as the 3rd operand), this is because each instruction must have an output register as far as I can tell (so inc/dec won't work). I wasn't sure how to implement +=; how to spell that? (as there's only a := operator right now). I figured that ++ and -- are probably more used anyway, and if you want to += 2, then you can always use the normal assignment syntax. * , =, and = operators kjs Thanks! Pm nqp_proposals.patch Description: Binary data
Re: wishlist for NQP
On Fri, Mar 28, 2008 at 1:41 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 10:51:16AM +0100, Klaas-Jan Stol wrote: Attached is a patch implementing: * ++ and -- postfix operators, implemented as n_sub and n_add (taking 1 as the 3rd operand), this is because each instruction must have an output register as far as I can tell (so inc/dec won't work). It really needs to be inc/dec. And not only that, but the output value of postfix ++ and -- needs to be the value _before_ the inc/dec operation. So the PIR code for postfix:++ should be something like: %r = clone %0 inc %0 Yes, that's right. I was too quick. Also, they need to have the is lvalue(1) trait so that PAST knows that the operand is to be treated as an lvalue. is this really necessary? It seems to work without. This is also a problem when writing 1++; not sure if this is allowed, but the grammar allows it. PAST::Val doesn't have an lvalue method. I wasn't sure how to implement +=; how to spell that? (as there's only a := operator right now). I figured that ++ and -- are probably more used anyway, and if you want to += 2, then you can always use the normal assignment syntax. Ideally += should be implemented as the two-argument 'add' opcode in PIR... something like add %0, %1 But the PAST compiler doesn't yet have a great way for distinguishing a 2-argument add from a 3-argument add. We can get close with add_p_p %0, %1 but of course that means that an expression like += 2 would end up creating a PMC for the 2 constant. And PAST needs a way to know that the result is in the %0 argument as opposed to a new unique register (this is planned but not yet implemented). maybe the PCT can include optimizations to remove the creation of PMCs for constants? * , =, and = operators The relational ops in the patch appear to be using iseq and isne; I think it would make more sense for them to use islt, isle, isgt, isge. is there any reason that == and != have to use cmp_num, and not use iseq and isne directly on the operands? reasons I used iseq and isne, is that cmp_num returns -1, 0 or 1, so I checked for these return values. I think, if the new rel.ops can use islt and friends, then == and != can use iseq and isne directly too without cmp_num, right? Also, we should have tests for all of the above. Thanks! Pm kjs
Re: wishlist for NQP
On Wed, Mar 26, 2008 at 6:30 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 02:25:06PM +0100, Klaas-Jan Stol wrote: having used NQP a bit, I feel like I'm missing a few things. I'm not entirely sure what the fate of NQP is; will it always be a bootstrap stage for Perl 6,or is it a tool for now and will it be discarded later on. Neither! It's important to be wary of viewing NQP solely in the context of Rakudo and Perl 6 -- NQP is designed to be a tool that many Parrot HLLs can use to build tools, not just Rakudo and/or Perl 6. So, it's entirely possible that Rakudo will stop using NQP as part of its build process at some point, but NQP will still be around for other translators to use (as many of them are). As noted in README.pod: The key feature of NQP is that it's designed to be a very small compiler (as compared with, say, perl6) and is focused on being a high-level way to create transformers for Parrot (especially hll compilers). In addition, unlike perl6, NQP attempts to restrict itself to generating code that can run in Parrot without the existence of any NQP-specific runtime libraries. Ok, that's clear; I didn't mean to mention Rakudo specifically. [...] I understand that NQP is designed to be small, but these features won't clutter the implementation that much, and are pretty easy to implement, I think. * other relational operators, such as , =, and =. I keep writing these, but NPQ only has == and !=. * postincrement/decrement ops, or at least +=. Often you need syntax like $index := $index + 1; Writing += 1 is so much nicer. One of the overarching principles behind NQP is to add features and operators only as they are actually needed, as opposed to would be nice to have. And since I haven't really needed the relational ops, I haven't put them into NQP. But if you really need them we can certainly add them. Well, I don't really need them that much, but I think they're interesting for 2 reasons: they're so 'basic', in the sense that many a programmer will expect them to be present, and 2) they're self-documenting: writing while $i != $max doesn't tell me whether $i is going up or down; of course I can check out the code in the while block, but still... Also, it feels somewhat safer: writing while $i $max will make sure $i is never greater than $max; $i != $max doesn't express this assertion. * the ternary operator ?: This allows for shorter/easier notation when both the Then and Else part of an ifstatement are 1 line. Adding the ternary operator is no problem, except remember that it's ??!! and not ?: . The tricky part for the ternary op is getting it into the grammar. We can either use PGE's built-in ternary: category, or we can try to follow STD.pm's approach. Ok, i just guessed the syntax as it's written ? : in the NQP pseudo code (Actions.pir of NQP implementation). But that's a spelling issue. More importantly: is it worth adding, and how to implement it. Both adding it and leaving it out has its advantages, so I will leave it to the Powers that Be ;-) I just proposed this, and based on the first comment in this thread, at least one other person agreed. * list ops ( I think this is meant by list ops? ) All languages that have some kind of scope mechanism now have to define a class List, which has an unshift and shift method, which are just wrappers for the equally named parrot ops. I don't quite understand what is meant by have to define a class 'List'. Can you give an example? Yes, sorry, I didn't explain the context. In order to write @?BLOCK.shift() (and unshift() ) (for implementation of the scope stack in pretty much all languages), @?BLOCK must be an object that has these methods. As ResizablePMCArray doesn't have such methods, the trick here is to subclass ResizablePMCArray (calling it List) and wrapping the shift and unshift instructions in the equally-named methods. Being able to write unshift @?BLOCK, $?BLOCK; would be useful, as it prevents the need for creating the List class over and over again. I feel that these ops are so basic, it would be well worth it to have them around. Thus far NQP has avoided most forms of listop parsing (i.e., functions w/o parens), so the above really ought to be written as unshift(@?BLOCK, $?BLOCK); This would work for me too. My point is, all languages I have worked on that have scope, I had to write (well, copy/paste, but still) this List class I mentioned above so that the @?BLOCK object (which is a List object) can shift and unshift PAST::Blocks. I'd rather leave out this wrapping class for ResizablePMCArray. What exact syntax is not that important, but using the method invocation syntax requires @?BLOCK to have methods. Now that listop parsing is available in Rakudo, we could see about backporting it into NQP and using that. But even
Re: Tutorial Question: catch blocks
On Thu, Mar 27, 2008 at 6:48 PM, Ovid
[EMAIL PROTECTED] wrote:
Hi all,
Trying to work through the tutorial
(http://www.parrotblog.org/search/label/tutorial) and am trying to
finish Episode 4 with catch blocks. The grammar in Episode 3 has this:
try-statement ::= 'try' block 'catch' identifier
block
'end'
I've translated it to this:
rule try_statement {
'try' block
'catch' identifier $catch_block=block
'end'
{*}
}
I did this myself the first time, but I got into problems, couldn't
get this working. Not sure why.
In any case, in my own implementation, the catch block is written (in
the grammar) as statement*, not block.
I posted my implementation a few days ago to the list; you could check
that for yourself.
In searching through code, I've come up with this method for that:
method try_statement($/) {
my $try:= $( $block );
my $identifier := $( $identifier );
my $catch := $( $catch_block );
my $past := PAST::Op.new(
:pasttype('try'),
:node($/)
);
$past.push($try);
# Create the catch
my $catchpir := .get_results (%r, $S0)\nstore_lex ' ~
$identifier.name() ~ ', %r;
$catch.unshift( PAST::Op.new( :inline( $catchpir ) ) );
$past.push($catch);
make $past;
}
However, when I try it with this: try x=4 catch e y=2 end, my pir
doesn't appear to have any logic to catch an exception (or I just know
pir very well).
See marker [1] below. The PIR that does the catching of the
exception is .get_results... (this is the string in $catchpir,
above)
The action method looks pretty good to me, except that it won't run (I
think). the store_lex 'e' ... will fail (in my experience) because
e wasn't declared as a .lex. Again, see the reference
implementation that was sent to the mailing list.
So, what I did myself was, also adding a PAST::Var to the catch block,
that specifies a lexical (scope) that has the name of the exception
object (don't reuse the PAST node for the exception identifier), and
set the isdecl flag on it.
Also, how do I know that the exception object is in
$S0? My pir is below. Is this actually correct and all will become
clear later?
So, catching an exception in Parrot is done like this:
.get_results($P0, $S0)
where the actual exception object (printing the output of the typeof
instr will print Exception) is stored in $P0, and the exception
message is stored in $S0. So, Parrot always (currently!) provides 2
things: the exceptino object and the exception message. The message
can actually be retrieved from the exception object, so it seems
superfluous. I don't know why it is implemented like this (but my
personal preference would be to remove the need for $S0). In any case,
$S0 is just a dummy, we don't use the message, just using the
exception object (which will be stored in $P0) is fine.
hope this helps, let me know if you're still having trouble.
kjs
Cheers,
Ovid
.namespace
.sub _block10
push_eh catch_11
get_global $P15, _block12
newclosure $P15, $P15
$P14 = $P15()
pop_eh
goto catch_11_end
catch_11:
get_global $P19, _block16
newclosure $P19, $P19
$P19()
catch_11_end:
.return ($P14)
.end
.namespace
.sub _block16 :outer(_block10)
[1]:
.get_results ($P17, $S0)
store_lex 'e', $P17
new $P18, Integer
assign $P18, 2
set_global y, $P18
.return ($P18)
.end
.namespace
.sub _block12 :outer(_block10)
new $P13, Integer
assign $P13, 4
set_global x, $P13
.return ($P13)
.end
--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/
wishlist for NQP
hi,
having used NQP a bit, I feel like I'm missing a few things. I'm not
entirely sure what the fate of NQP is; will it always be a bootstrap
stage for Perl 6,or is it a tool for now and will it be discarded
later on.
Anyway, if NQP is to stay, the following features would come in handy,
IMHO. I understand that NQP is designed to be small, but these
features won't clutter the implementation that much, and are pretty
easy to implement, I think.
* other relational operators, such as , =, and =. I keep writing
these, but NPQ only has == and !=.
* postincrement/decrement ops, or at least +=. Often you need syntax
like $index := $index + 1; Writing += 1 is so much nicer.
* the ternary operator ?: This allows for shorter/easier notation when
both the Then and Else part of an ifstatement are 1 line. Typical for
this in the PCT is writing:
if $?BLOCK.symbol($name) {
$scope := 'lexical';
}
else {
$scope := 'package';
}
which could be nicely written as
$scope := $?BLOCK.symbol($name) ? 'lexical' : 'package';
* list ops ( I think this is meant by list ops? )
All languages that have some kind of scope mechanism now have to
define a class List, which has an unshift and shift method, which
are just wrappers for the equally named parrot ops. Being able to
write
unshift @?BLOCK, $?BLOCK;
would be useful, as it prevents the need for creating the List class
over and over again.
I feel that these ops are so basic, it would be well worth it to have
them around.
* MAIN support: this feature is a nice-to-have, but not that important.
I don't think it's there already: when writing an NQP script, I'd like
to have access to the command line options. To be precise, I'd like to
write the compiler driver in NQP instead of in PIR. So, creating a new
HLLCompiler, setting the grammar stuff and invoking the command_line
method on it with the commandline args. How do I get access to these
args from NQP?
Comments most welcome.
kjs
Re: [tutorial] pct tutorial language: Squaak implementation
after reading this tutorial you shouldn't have too much trouble
implementing SmallTalk (SmallSquawk?) :-)
the only issue is to find a proper grammar to stick with; effectively
all statements are PAST::Op( :pasttype('call') ) or
:pasttype('callmethod') (depending on your implementation, I think the
latter is better).
I understand the confusion, and my intention was to spell it as the
proper English word... but something went wrong apparently. Maybe
Squawk is a nice enough name to save for a real language, rather than
this toy language.
kjs
On Tue, Mar 25, 2008 at 3:17 PM, Eric Hanchrow [EMAIL PROTECTED] wrote:
Mark == Mark J Reed [EMAIL PROTECTED] writes:
Mark ... confusion with Squeak, which is how I read this subject
Mark at first. (Smalltalk on Parrot?! Whoa!). But maybe
Mark that's just me. :)
I read it that way too (and had the same reaction :-)
--
[T]he main reason Viaweb ended up being server-based was
that we didn't want to have to write Windows apps.
-- Paul Graham
Re: [ANN] Lua on Parrot 0.6.0
Hi François, lua on parrot seems to have improved a lot, indeed. It's looking really good. Some remarks: * is it possible to show the generated PIR? I can't get life.lua (included with lua distr.), and I'd like to see what's going on under the hood. * running (n)make fails for me on windows,as I don't have yapp installed. Running (n)make test won't work either (because of that) * if you need help with converting to PCT, let me know. kjs On Wed, Mar 19, 2008 at 4:44 PM, François Perrad [EMAIL PROTECTED] wrote: Parrot is a VM (virtual machine) designed specifically for running dynamic languages in general, and Perl 6 in particular (see http://www.parrotcode.org/). Parrot is still in development, the latest monthly version is 0.6.0. A complete prototype of Lua 5.1 (aligned on 5.1.3) is available : - an Lua interpreter written in PIR (Parrot Intermediate Representation) that generates PIR - a large subset of the Lua Standard Librairies (written in PIR) - a test suite (more than 980 tests) For the first time, with Parrot 0.6.0, all garbage collection problems seem to be fixed. Documentation starts in http://svn.perl.org/viewcvs/parrot/trunk/languages/lua/doc/running.pod?view=markup and http://svn.perl.org/viewcvs/parrot/trunk/languages/lua/doc/status.pod?view=markup. Any comments, suggestions, bug report, test, improvement are welcome on Parrot mailing list (perl6-internals@perl.org). François Perrad.
Re: [perl #37542] [TODO] core - document behavior of multiple :load subpragmas in same compilation unit
On Tue, Mar 18, 2008 at 2:41 AM, James Keenan via RT [EMAIL PROTECTED] wrote: On Tue Feb 20 00:31:58 2007, kjs wrote: Fortunately, in this case it looks to me as though t/pmc/sub.t does have tests that check for proper execution of multiple :load subs. So I think this ticket can be safely closed. Jonathan, Patrick, kjs: Can the ticket be closed? Thank you very much. kid51 I think so, yes. kjs
Re: [perl #39711] [TODO] Make PIR-PBC reentrant
On Tue, Mar 18, 2008 at 3:03 AM, James Keenan via RT [EMAIL PROTECTED] wrote: On Wed Jul 05 00:24:34 2006, [EMAIL PROTECTED] wrote: Done, and I also added Vishal as a requestor on the relevant tickets. The discussion appears to have been wrapped up, but the ticket was never resolved. Can we do so now? Thank you very much. kid51 it seems to me that the original subject of this ticket, making the PIR to PBC conversion reentrant, has not been solved. From that view, I think it can't be closed. kjs
Re: [perl #47978] [C99] [IMCC] double free
On Sun, Mar 16, 2008 at 11:04 PM, chromatic [EMAIL PROTECTED] wrote: On Saturday 23 February 2008 14:23:19 Klaas-Jan Stol wrote: On Sat, Feb 23, 2008 at 5:00 PM, Ron Blaschke [EMAIL PROTECTED] wrote: The issue seems to be caused by languages/c99/src/preamble, where: .local $iter_loop: Consider this test program. $cat m.pir .macro test .local $iter_loop: .endm $ parrot -o m.pbc --output-pbc m.pir compilers/imcc/imcc.l:992: failed assertion 'valp-s' (Remove the colon and it parses again.) that makes sense, now i see this: .local is not valid anymore to declare labels, you should use .label. Can we somehow make this an error in IMCC? I poked at the LOCAL and LABEL rules slightly, but didn't figure it out. -- c I think that macro definitions are slurped, not parsed. In other words, it gets tricky to check for that (Only macro expansions are parsed.) (FYI, the 3-phase PIR compiler pirc/new + pirc/macro separates the macro stuff from pure PIR; the macro processor is really a parser there, which would be able to do this in a nicer way. The future of pirc is unclear, though; currently it's a lot of work to do a replacement for imcc) kjs
Re: [perl #51662] [TODO] Remove 'classname' rule in imcc.y
On Wed, Mar 12, 2008 at 9:28 PM, via RT Bernhard Schmalhofer [EMAIL PROTECTED] wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #51662] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=51662 In RT#41237 it was decided: P0 = new 'Integer' # correct $P0 = new .Integer # deprecated the dot notation is still used heavily in the .const rule: .const .Sub foo = foo It was mentioned before, and someone (don't remember who) suggested to change this into: .const Sub foo = foo this seems like a good solution to me. This, or an alternative solution must be implemented before the dot notation can be removed altogether. $P0 = new Integer # deprecated this means that 'classname' can be removed from imcc.y. TODO: - Make sure that parror and languages tests pass. - Adapt to new error messages from the parser kjs
Re: Assistance requested for Parrot testing
On Mon, Mar 10, 2008 at 12:11 PM, James E Keenan [EMAIL PROTECTED] wrote: A developer who recently attended Perl Seminar NY asked me this question, to which I didn't have the answer. Hi James, Is Parrot embeddable into C programs, like Perl is ? Can anyone advise? Thanks. unless I misunderstand your question, yes. See http://www.parrotcode.org/docs/embed.html kjs
a PCT tutorial case study
hi, I'm working on a tutorial for using the PCT (will be published on parrotblog.org). For that purpose I built a case study language, which is simple enough to understand and implement in a straightforward way, yet it has enough features to demonstrate the power of the PCT. An important issue in the design of this language was that I want to provide a *complete* language, not one with missing features due to lack of PAST/PCT support (there is of course still the issue of disappearing local variables in interactive mode, but that will be made clear in the tutorial) IMO, it's more or less finished now. (I wanted to implement the Game of Life as a nice demo, but it might take a while before I get that working) Features are: * variables: globals, locals * subroutines and parameters * if/while/try/throw/for statements * assignments and subcalls * basic types: integer, float, string * aggregate types: array, hash * operators: +, -, /, *, %, not, and, or, .. (string concat), and relational ops (, == etc) notable missing features (by choice) are: * return, break, continue and friends * classes and objects * closures (nested subroutines, subroutines as first class citizens) For the interested reader, I added a .tar.gz file containing the source. Comments and especially suggestions are most welcome. kjs squaak.tar.gz Description: GNU Zip compressed data
Re: pdd17pmc branch review
Hi, I'm on win32 xp pro, msvc express Punie, Pynie, ecmascript are passing tests. (c99 does not, but that's not different from trunk.) kjs On Wed, Mar 5, 2008 at 1:48 AM, Will Coleda [EMAIL PROTECTED] wrote: I wanted to call attention to part of today's Parrot Sketch: allison - Otherwise, the PMC branch is ready for language testing, will plan to merge it back into trunk next weekend. So, language developers (and others); please grab a copy of https://svn.perl.org/parrot/branches/pdd17pmc and check out the languages to see how they fare compared to their counterparts in trunk. Thanks! -- Will Coke Coleda
