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
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
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 ta
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 Ra
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 wo
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
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 op
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 ta
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
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
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 rea
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, yo
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 C. [See RT
>> #24251]
>> +Note that by using an opc
[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 C. [See RT #24251]
+Note that by using an opcode name as a local variable name, the variable will
+I the opcode name, effectively making th
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
==
15 matches
Mail list logo