3 ms·
But the hard part isn't dealing with invalid parses and error recovery. The hard part is dealing with completely valid bits of code that aren't yet finished:
by ibdknox 13y ago
But the hard part isn't dealing with invalid parses and error recovery. The hard part is dealing with completely valid bits of code that aren't yet finished:
(doseq [x (range|cursor|)]
)
You can wait until the end of time, but that won't finish ;) Whereas I probably wanted to get out (range 10) before it went off and looped forever.
Text also doesn't provide you with stable IDs. If I previously had function "foo" in a file and now that's gone, but there's a function "bar" in the same place with roughly the same code, does that mean it was renamed? Or did foo get deleted and we need to surface that anything using foo is an error? How would you know? The only thing you have to go on is position and position can change for all sorts of other reasons. I ran into this problem with trying to do functions in single editors: when the file can change in any way, reconciling that file with your previous view of the world is tremendously difficult.
- seanmcdirmid 13y agoI don't have a problem with this. If you accidentally encode an infinite loop, you just break it on the next code change. You can memoize your token stream in an incremental lexer to use tokens as stable IDs: you use the same symbol for bar as you did for foo because the token/tree start position never changed; only the contents of the existing token happened to changed! This is what I do in YinYang, and it works well. Of course, to get here, you have to be incremental 100% and not use existing batch tools (or adapt them first to be incremental). I'd be happy to share these techniques sometime.
- bronxbomber92 13y agoI'd enjoy reading.
- seanmcdirmid 13y agoOk, I'll make an effort to really write this up sometime, maybe as an SLE paper.
- lomnakkus 13y agoPlease do even if only as an informal blog post or something. :)
- DanielRibeiro 13y agoI agree that the problem is not error recovery, but is more generaly described by Peter Naur's "Programming as Theory Building"[1]. With that, programming is hard because creating a theory, collectively, and teaching other people about it, is hard. Making it easier is therefore solving the problem Douglas Engelbart envisioned solving: Augmenting the Human Intellect [1] http://catenary.wordpress.com/2011/04/19/naurs-programming-as-theory-building/ http://catenary.wordpress.com/2011/04/19/naurs-programming-a...
- lomnakkus 13y agoI apologize for the fanboy post in advance, but Peter Naur was such a badass.