Empty parentheses failure exit code?

Challenges
1

I’m stuck on Stage #XE6

I’m a tad confused… I know the parentheses are empty, but why would that result in an error? And if so, what do I need to adjust in my code to account for that? I’ve followed the crafting interpreters book pretty closely while trying to translate the code into Go.

Here are my logs:

remote: [tester::#XE6] [test-3] Writing contents to ./test.lox:
remote: [tester::#XE6] [test-3] [test.lox] ()
remote: [tester::#XE6] [test-3] $ ./your_program.sh parse test.lox
remote: [your_program] 
remote: [your_program] Logs from your program will appear here!
remote: [tester::#XE6] [test-3] expected exit code 65, got 0
remote: [tester::#XE6] [test-3] Test failed

And here’s a snippet of my code:

if p.match(LEFT_PAREN) {
		expr := p.expression()

		p.consume(RIGHT_PAREN, "Expect ')' after expression.")
		return &Expr{
			exprType: GROUPING,
			left:     expr,
		}
	}

func (p *Parser) consume(token TokenType, message string) Token {
	if p.check(token) {
		return p.advance()
	}
	panic(p.error(p.peek(), message))
}
2

Hmm, I think here the expression rule should raise an error, saying that an expression was expected. I don’t think lox treats () as nil/null. The grammar expects an expression to be present.

I’ll see if we can make this more clear in the instructions. @apmsabee let me know if you think this doesn’t agree with the official lox grammar, can dig further. For context, we do run our tests against the author’s jlox implementation to ensure the tests themselves aren’t faulty.

3

I’m not certain if it does or doesn’t agree with the lox grammar - I just followed the implementation of his code from the book, and I didn’t have any checks to see if an expression was present or not. If you reread his implementations of each of those expression types in 6.2, I don’t see any errors being thrown. Maybe in section 6.3 he starts throwing syntax errors, but if that’s the case then this test should be incorporated in that portion of the challenge and is testing functionality we haven’t been asked to create yet.

4

Is there a way to allow further tests to run after one fails? I’m trying to print debug this case, but can’t get to it because the print debugging is causing the tests to fail

5

The more I look at this test case, the less it makes sense. We don’t change the exit code at all in the parse portion of this code. That’s not mentioned once in any of the challenge stages. I don’t understand why this would/should result in an exit code that we only ever had to assign to the scanner.

6

Yep, agree. We’re fixing this! We should be checking for an error for unbalanced parentheses in this stage (like the book does), but we shouldn’t be checking for empty expressions yet.

7

@apmsabee anything printed to stderr will be ignored (unless it contains [line <digit>], which is used on error assertions), so you should be be able to print to stderr for debugging.

8

@apmsabee okay, this should be fixed now!

1 Like
9

Went one step ahead here and also removed the error check for unbalanced parentheses. Although this is implemented in the book when Robert implements the primary() function, the exact semantics of error recovery aren’t discussed yet.

10

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.