Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
jerry gay wrote: the sugar for what can be on the left side of an equals sign needs to be changed. simply having a first parameter with OUT isn't enough. the same thing happens for $P0 = push $S1 which is legal pir syntax, but obscure at best. ops must have some means of specifying (perhaps an attribute like C:returns or C:rvalue?) that allows them to be on the right side of the equals. only this class of ops allows the syntax described above. Yes, agreed. Allison
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: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Fri, Sep 5, 2008 at 2:36 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: 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 the sugar for what can be on the left side of an equals sign needs to be changed. simply having a first parameter with OUT isn't enough. the same thing happens for $P0 = push $S1 which is legal pir syntax, but obscure at best. ops must have some means of specifying (perhaps an attribute like C:returns or C:rvalue?) that allows them to be on the right side of the equals. only this class of ops allows the syntax described above. in the case of .local pmc getstdin ... $P0 = getstdin this can be resolved because the (now) compiler knows (either during parsing or semantic analysis) that the Cgetstdin op is not allowed to be an rvalue and lookup Cgetstdin in the list of C.locals as a fallback. ~jerry
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
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: [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: [svn:parrot-pdd] r30569 - trunk/docs/pdds
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
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
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'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.
Allison
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: [svn:parrot-pdd] r30569 - trunk/docs/pdds
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
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: [svn:parrot-pdd] r30569 - trunk/docs/pdds
[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
[svn:parrot-pdd] r30569 - trunk/docs/pdds
Author: kjs Date: Tue Aug 26 04:27:55 2008 New Revision: 30569 Modified: trunk/docs/pdds/pdd19_pir.pod Log: [pdd19] be a bit more precise in opcode names vs local var names vs sub names. Modified: trunk/docs/pdds/pdd19_pir.pod == --- trunk/docs/pdds/pdd19_pir.pod (original) +++ trunk/docs/pdds/pdd19_pir.pod Tue Aug 26 04:27:55 2008 @@ -62,8 +62,11 @@ 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.
