Talk:Parsing/RPN to infix conversion: Difference between revisions

:::::: Formally, <code>1+2+3</code> is the infix version of <code>1 2 + 3 +</code>, as addition is ''left''-associative in this exercise (the “normal” model for programming languages). Knowing that <code>1 2 3 + +</code> is also a way of writing that requires knowing that addition is ''fully'' associative, and I suspect that most people aren't going to model that. I know I don't intend to. (To confirm what I say, use the inverse of this task to parse the string; the type of structure it produces — or equivalently the RPN form it generates — is precisely determined by the defined associativity and precedence rules, with not mattering in this case.) I suppose we could implement all the code to allow your intuition to not be wrong, but then it wouldn't be a parsing/formatting task, but rather a general symbolic mathematics task. We ''must not'' conflate (A•B)•C with A•(B•C) when parsing! I believe that any task that generates A•B•C from both of those is necessarily wrong; after all, we've not described the differences between “+” and “-” to the computer, and the difference matters critically there. (What's more fun, with some type systems even “*” and “+” are not truly associative; [[C]] has such a type system, as do the plethora of languages derived from it, and it can be the source of many subtle bugs.) –[[User:Dkf|Donal Fellows]] 02:42, 19 December 2011 (UTC)

::::::: My intuition really didn't come into it. Each RPN should have to generate only one infix in a parsing task. And as I said before, I didn't write the task. I just noticed that it was broken with respect to "^" and that the output from different inputs into other tasks could not be recreated. To me it was obvious because several of the code examples defined but did not use the associativity information. That was my only complaint. --[[User:Dgamey|Dgamey]] 04:48, 19 December 2011 (UTC)

: Tcl version is now fixed (it would have helped if the original example had been sensitive to such things, but there you go). –[[User:Dkf|Donal Fellows]] 18:59, 17 December 2011 (UTC)