#2003: piraha_everywhere Zelmani stress test ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: sbrandt Type: defect | Status: assigned Priority: major | Milestone: Component: Cactus | Version: development version Resolution: | Keywords: piraha ---------------------+------------------------------------------------------
Comment (by knarf):
Most of the time you will find me arguing for backwards compatibility, for reasons Roland already mentioned. But there is a limit. Line-continuation within a token might have been allowed by the documentation, and might be working in the old parser. But I find it hard to imagine that someone actually _wants_ to use it. It shouldn't be used. So, my opinion is that we should start disallowing that.
Another issue is how we do this. Usually, we say we announce this in the release notes for the release after that one. The intention here is to give people time to adapt. In this specific case, however, it would mean either keeping the piraha changes out until then (and then still waiting for the double-parsing to be removed later I guess), or to change it to make two passes, just for that quite questionable case. If we were to do this, there should also be a parse-time warning about this, but frankly most likely this would be useless because nobody will be able to read it the few milliseconds it will be on the screen before it scrolls away. It would follow standard procedure, but it would be useless.
This, this time, I suggest to make that change (disallow line continuation within tokens), and make it already for the next release.
The one exception I see is a string (like a description). Here I could see someone wanting to break up a long string without introducing an actual newline in the string. But in this specific case, as Steve assured me, this would not be hard to handle, and wouldn't require two passes.