On Wed, Jul 15, 2020 at 11:27 AM Randall O'Reilly <rcoreil...@gmail.com> wrote:
> wouldn't gofmt remove the superfluous (z) in this case (and even with a > more complex expression inside the parens, as the > operator would have > appropriate precedence?), in existing code? And thus, would it not be > reasonable to have a convention in this case that if you have an expression > that fits the type parameter interpretation, that interpretation is used > instead of the alternative? And if you really wanted to write the > alternative, you would be forced to make it explicit with the parens as > noted: > > a, b = (w < x), (y > (z)) > > This seems like a very rare case, and a small price to pay for following > the established convention.. > > If the parser cannot disambiguate without type information, then neither can gofmt. In practice, this means you risk opening pandoras box in several ways: * gofmt is now part of the system, as you cannot safely parse without it. * gofmt needs to be more powerful than the parser. * gofmt must alter the semantics of the program, which goes directly against the idea of gofmt. The really hard part is that you have to nail all parsing problems in a parser. You can't attack problems on a case-by-case basis as it often yields inconsistency. Languages in the ML family solves problems like the above by having several steps in the chain: Lex -> Parse -> Elaborate -> Phase split -> Type Check -> ... -> Machine code Elaboration is the phase where type information is brought in to disambiguate what the parser found. Phase splitting is also interesting in that it splits work into compile-time and runtime phases (since MLs kind of blends those two things together in its syntax). However, this has implications in the complexity of the parser and language. Go seems to lean more toward a Niklaus Wirth'esque simplicity path; though not as stringent as Wirth would. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiU97KmzLM8SRZRgjXNN4Lf80Z8YdjVMSb6XQJQG3L-J5w%40mail.gmail.com.
