On 7/19/07, Nuno Carvalho via RT <[EMAIL PROTECTED]> 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
Hi, I sent a reply earlier, but from another non-subscribed address. Anyway, it may pop up later. The reply went more or less as follows: as the concept of what a parrot op is is dynamic, because you can load new ops during runtime, it 'd be strange to forbid having built-in ops as var. names and allow dyn. ops (as these must be "new" names). This would be inconsistent. (although I do think it's bad practice). However, it just occurred to me that IMCC calls is_op() for each identifier, and based on the current set of ops known returns true (PARROT_OP token) or false, in which case the id is really an ID. I think this would work for dyn. ops as well, as is_op() should return true for the newly loaded ops as well. That's the whole point of is_op(), instead of defining the ops statically in the lexer. In other words, I would plea for forbidding using opnames as identifiers. 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
