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

Reply via email to