question

[geraldstanje]

Hi,

did you also think about using: https://github.com/cznic/goyacc ?

Thanks,
-Gerald

[zellyn]

Nope: I didn't know about it. Looks like a willing-to-modify-yacc approach to http://people.via.ecp.fr/~stilgar/doc/compilo/parser/Generating%20LR%20Syntax%20Error%20Messages.pdf (as opposed to the approach taken by rsc (referencing the same paper) at http://research.swtch.com/yyerror.

Thanks for the pointer. I'll probably stick with the go tool yacc for this, since it's just a classroom compiler, and everyone is guaranteed to have it :-)

[geraldstanje]

can you generate good error messages if the syntax of the cool source is not correct?

[zellyn]

For a classroom compiler, yes :-)

In fact, the test data they give you to check against has fairly typical
yacc errors in it, so it's actually easier to validate that I'm getting it
right if I have the same kind of (relatively uninformative) errors. :-/

Zellyn

On Tue Nov 18 2014 at 12:42:32 AM geraldstanje [email protected]
wrote:

can you generate good error messages if the syntax of the source is not
correct?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[geraldstanje]

any updates on error handling?
how would you implement preprocessor commands like #ifdef or #include ?

[zellyn]

I got a lot of mileage out of reading https://code.google.com/p/rsc/source/browse/cc/ - it does #include at the lexer level. I'm not sure about #ifdef.

[geraldstanje]

where do you store variable declarations within functions/methods?

[zellyn]

Not quite sure I understand. Variables in Cool are either object attributes (

gocool/parser/ast.go

Line 46 in 4af5076

type Attr struct {

), function parameters (

gocool/parser/ast.go

Line 41 in 4af5076

Formals []*Formal

), or created with Let statements (

gocool/parser/ast.go

Line 96 in 4af5076

Let // Let expression

)

[geraldstanje]

Sorry for the unclear question. I was saying you need to implement a stack for local variable declarations within functions...
so you traverse the AST and push the variable on the stack if there is a new VariableDecl. The variable will be poped from the stack if you leave the scope...

[zellyn]

Yep. But I'm just now implementing the compiler, so I have't got there yet. For typechecking, I'm using this: https://github.com/zellyn/gocool/blob/master/symbols/symbols.go

[geraldstanje]

can you give me some feedback to my toy compiler? https://github.com/geraldstanje/toycompiler

i would also like to add function, if statements and variables ... im not sure how to implement scoping...any comments?

[zellyn]

Which areas in particular would you like feedback on?

I haven't got all the way through the implementation of scoping, but what's done is mostly in https://github.com/zellyn/gocool/blob/master/symbols/symbols.go

Basically, each time you encounter a variable in a new scope, you push it on the stack. Some implementations push a whole new scope on a stack of scopes. But Cool is so simple that I don't think I'm going to need those. You'll notice that queries of symbol tables run from the end backwards, so you always search the most nested scopes first.

I've been using the coursera compilers class as my reference: I think I've watched all the relevant videos at least twice now.

[geraldstanje]

about the design of the toy compiler...i still need to add proper testing and split into packages...

so i would best add the scoping into https://github.com/geraldstanje/toycompiler/blob/master/codegen.go and add FuncCallNode, IfNode, VarDeclNode into func (c *AsmCodeGenerator) compNode(node Node)?

i guess i also need the prev scope in case i do:
void foo(int a) {
print a;
}

int main() {
int a = 2;
foo(a);
}

[zellyn]

So, at least for Cool, a function has its own scope (well, plus the Object properties). So foo wouldn't care about the a in main(). That would be dynamic scope, like in elisp. :-)

[geraldstanje]

ok, i don't refer to cool :)

so for the variable a in foo I would need to lookup the varDecl in the prev scope?