over-eager syntax error reporting for break and continue

[jpolitz]

Just pushed two tests in 95dad02d1cc4255dbfda3f8e7008cfc794062084 that show we're over-zealously checking for break and continue in the wrong places.

Can we just use Python's compile() in parse-python.py, catch errors from the parse in Racket, and produce the thrown syntax error there? It seems like we're reproducing a lot of effort that Python has already put in for us, and getting it wrong.

[mpmilano]

We absolutely could. Sorry for the wasted effort; I managed to remain oblivious to the compile() function. Hooking it in now.

On Tue, Mar 26, 2013 at 1:43 PM, Joe Politz notifications@github.comwrote:

Just pushed two tests in 95dad02https://github.com/brownplt/lambda-py/commit/95dad02d1cc4255dbfda3f8e7008cfc794062084that show we're over-zealously checking for break and continue in the wrong places.

Can we just use Python's compile() in parse-python.py, catch errors from the parse in Racket, and produce the thrown syntax error there? It seems like we're reproducing a lot of effort that Python has already put in for us, and getting it wrong.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/56 .

[mpmilano]

The compile() function is now how we determine SyntaxErrors; the process-syntax-errors pass is now a noop.

Additionally, the default target in the makefile now will warn you if you have files with non-ascii characters in them. I managed to lose two hours due to one of these; hopefully the warning will help us avoid them in the future. It only checks base/, not the tests.

~matthew

On Tue, Mar 26, 2013 at 3:33 PM, Matthew Milano matthew@cs.brown.eduwrote:

We absolutely could. Sorry for the wasted effort; I managed to remain oblivious to the compile() function. Hooking it in now.

On Tue, Mar 26, 2013 at 1:43 PM, Joe Politz notifications@github.comwrote:

Just pushed two tests in 95dad02https://github.com/brownplt/lambda-py/commit/95dad02d1cc4255dbfda3f8e7008cfc794062084that show we're over-zealously checking for break and continue in the wrong places.

Can we just use Python's compile() in parse-python.py, catch errors from the parse in Racket, and produce the thrown syntax error there? It seems like we're reproducing a lot of effort that Python has already put in for us, and getting it wrong.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/56 .

[jpolitz]

Shoot! I saw that and forgot to push the fix. object's with a non-ascii unicode apostrophe again.

On Tue, Mar 26, 2013 at 5:34 PM, Matthew Milano notifications@github.comwrote:

The compile() function is now how we determine SyntaxErrors; the process-syntax-errors pass is now a noop.

Additionally, the default target in the makefile now will warn you if you have files with non-ascii characters in them. I managed to lose two hours due to one of these; hopefully the warning will help us avoid them in the future. It only checks base/, not the tests.

~matthew

On Tue, Mar 26, 2013 at 3:33 PM, Matthew Milano matthew@cs.brown.eduwrote:

We absolutely could. Sorry for the wasted effort; I managed to remain oblivious to the compile() function. Hooking it in now.

On Tue, Mar 26, 2013 at 1:43 PM, Joe Politz notifications@github.comwrote:

Just pushed two tests in 95dad02< https://github.com/brownplt/lambda-py/commit/95dad02d1cc4255dbfda3f8e7008cfc794062084>that show we're over-zealously checking for break and continue in the wrong places.

Can we just use Python's compile() in parse-python.py, catch errors from the parse in Racket, and produce the thrown syntax error there? It seems like we're reproducing a lot of effort that Python has already put in for us, and getting it wrong.

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/56> .

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/56#issuecomment-15490108 .

[mpmilano]

fixed in 709ab5742ea45d850542ba94857ca7827b6c7626