On Jul 19, 10:37 pm, [EMAIL PROTECTED] (Nuno Carvalho via RT) wrote: > Greetings, > > On Mon Sep 13 21:31:17 2004, coke wrote: > > > > > The compile error has changed: > > > error:imcc:Sub isn't a PMC > > in file 'bar.imc' line 5 > > > But, IMO, this should still barf on the declaration of "index" instead. > > > > [coke - Sun Oct 19 18:01:33 2003]: > > > > Is there a way to get this to barf on .local rather than the call to > > > index? > > > > (Was a bit confusing, since I had a working program, then moved the > > > .local up to the beginning of the sub. At that point, parrot started > > > complaining about my call to index.) > > > > bash-2.05a$ cat bar.imc > > > .sub _main > > > > .local int index > > > > index $I0, "whee", "w" > > > > end > > > .end > > > bash-2.05a$ ../../parrot bar.imc > > > error:imcc:parse error, unexpected IREG, expecting '=' > > > > in file 'bar.imc' line 5 > > As far as i can tell there's no decision on using parrot ops as variable > names (please do correct me if i'm wrong). So, are these valid PIR > instructions or not: > > .local int set # or > .local int print # or > .local int new
Although I think it's not a good idea to name your variables after parrot ops, the concept of what a parrot op is, is flexible, because you can load your own using dynamic op libraries. So, from that perspective, it would be more consistent to allow *all* ops to be var. names, both built-in and dyn. loaded ones. my 2c. kjs > > There is one test for this (leo++ for poiting it) in > t/compilers/imcc/syn/clash.t: > > pir_output_is( <<'CODE', <<'OUT', "parrot op as identifier" ); > (..) > > Luckly (or not) that test uses: > > .local int set # which works ok > .local int new # would have failed the test for example > > Divine intervention needed, thank you. > > Best regards, > ./smash
