Issue with named imports? about rock

[nddrylliog]

I'm totally guilty of laziness on this one. fredreichbier was implementing namespaced imports in j/ooc, and I did the same in rock, following his tests that he wrote progressively, and I just bailed out on the 'namespaced types' issue, I only did the 'namespaced variables / functions' thingy.

I can fix it pretty easily, but if someone else wanna do it, I suggest you read the 'rock/middle/NamespaceDecl.ooc' class, and how it's used in 'rock/middle/FunctionCall' / 'rock/middle/VariableAccess'

[wandernauta]

Has this been fixed yet?

[danopia]

Related to #97

[nddrylliog]

Yes, #97 was a duplicate and has been closed

[duckinator]

Please tell me this has been fixed. If we're missing features j/ooc had.... :(

[nddrylliog]

Not been fixed afaict

On Mon, Sep 5, 2011 at 4:48 AM, duckinator <
[email protected]>wrote:

Please tell me this has been fixed. If we're missing features j/ooc had....
:(

Reply to this email directly or view it on GitHub:
#46 (comment)

Amos Wenger
Crafting the future of Web Audio at ofmlabs.org
I'm @nddrylliog https://github.com/nddrylliog on GitHub

[duckinator]

NOOOOOOOOOOOOOOOOOOOOOOOOOOoooooooooooooooooooooooooooooooooooooooooooooooooo dies

[fredreichbier]

Sssshh. Nobody knows named imports exist anyway!

[nddrylliog]

yajl does!

On Tue, Sep 6, 2011 at 10:49 PM, Friedrich Weber <
[email protected]>wrote:

Sssshh. Nobody knows named imports exist anyway!

Reply to this email directly or view it on GitHub:
#46 (comment)

Amos Wenger
Crafting the future of Web Audio at ofmlabs.org
I'm @nddrylliog https://github.com/nddrylliog on GitHub

[alexnask]

I'll work on this, possibly this weekend, perhaps earlier if it is easy to do, I will use namespace imports in gooc-gen :P

[alexnask]

Ok I tried some stuff but it doesn't really work...
These are my changes at the moment:
Nagaqueen

TypeBase = FuncType |
          (< { tokenPos; core->typeBuffer[0]='\0'; type=NULL;} (CONST_KW -)?
            (
                ( "unsigned"                                  { strcat(core->typeBuffer, "unsigned "); } -
                | "signed"                                    { strcat(core->typeBuffer, "signed "); } -
                | "long" &(- ("long" | "double" | "int"))     { strcat(core->typeBuffer, "long "); } -
                | "struct"                                    { strcat(core->typeBuffer, "struct "); } -
                | "union"                                     { strcat(core->typeBuffer, "union "); } -
                )
            - )*
            rest:IDENT
            (type:IDENT)?
          > {
                if(!type) {
                    strcat(core->typeBuffer, rest);
                    $$=nq_onTypeNew(core->this, core->typeBuffer);
                } else {
                    strcat(core->typeBuffer, type);
                    $$=nq_onTypeNew(core->this, core->typeBuffer);
                    $$=nq_onTypeNamespace(core->this, $$, rest);
                }
            })

And in AstBuilder.ooc

    onTypeNamespace: unmangled(nq_onTypeNamespace) func (type: BaseType, ident: CString) -> Type {
        "yay for %s with %s" format(type toString(), ident) println()
        token() formatMessage("","","") println()
    }

However, there are a couple of issues. This is my test file:

import structs/ArrayList into AL

f: func -> AL ArrayList {
    null as AL ArrayList
}

And rock prints:

yay for ArrayList with ArrayList 

f: func -> AL ArrayList {
                         
yay for ArrayList with ArrayList

    null as AL ArrayList
            ~~~~~~~~~~~~
yay for toString with toString

    argc times(|i| result add(argv[i] as CString toString()))

The issues here are that for some reason, the first IDENT in the type rule is getting overwritten by the second IDENT and that there is ambiguity in statements like the last one. How are we supposed to know where the type stops and where the statement continues? I think making the use of parenthesis to access namespace types should be mandatory, as @fredreichbier had suggested in issue #97 a long time ago. This would make parsing easier and would clear out ambiguity as in the last statement.

[nddrylliog]

Okay, let's make parenthesis mandatory then.

(Otherwise, here's how it was done in j/ooc: I think it was parsed as a VariableAccess, and the access was resolved at tinkering time, and it was turned into a TypeAccess)

[alexnask]

Still, if we have for example the casting rule accept a variableaccess, in the last statement wouldn't CString toString() be parsed as a VariableAccess? Anyway, I'll work on the parenthesis for now and if I think of a clever way to make it work without them I will implement it.

[alexnask]

Closed by #380