I've read rather a lot of formal documentation where the authors were not so careful with their language, particularly with distinctions between words like "undefined" and "invalid".
I think it a reasonable expectation that an object of type X returned by one function of a library be acceptable to other parts of that library that accept an object of type X. Did I miss a section of the go/printer documentation that says that any Pos values in the input must be well defined? I had no expectation that the printer would care about original source location. I do expect that the expression of source locations in error messages would depend on well formed Pos information, but I wasn't complaining about being misdirected by error messages. Anyway, I filed a ticket. I looked at the source and believe it would not be easy to fix without making the entire parser be accepting of nil for File and FileSet values. I have a workaround which is available to whoever else experiences this problem. I hope no one else wastes a week trying to deal with the same problem. On Tuesday, August 14, 2018 at 1:36:42 PM UTC-4, Marvin Renich wrote: > > * na...@mit.edu <javascript:> <na...@mit.edu <javascript:>> [180814 > 11:43]: > > The documentation can be interpreted as you say. > > I do not see how you can interpret it otherwise. > > > If the resulting AST is subsequently inserted into a larger AST and then > > serialized, the source that is output can be syntactically invalid. > > > > It is unexpected (and I believe unreasonable) that serializing an AST > can > > produce code that can't be parsed. > > If you insert an ast.Expr that was given to you with documented > deficiencies, I do not see why you would expect otherwise. > > This sounds like a difference between what you want and what the package > is documented to do. I.e. a feature request. > > > There is no API for invalidating the Pos information of an AST. In > order > > to make my application work, I needed to implement a function which > copied > > an entire AST except for its Pos information > > ( > https://raw.githubusercontent.com/MarkNahabedian/Goshua/master/rete/rule_compiler/nopos.go). > > > > > > > > Issue filed: > > https://github.com/golang/go/issues/26986 > > This seems like the correct approach to me, though I still think your > wording implies something wrong with the documentation and/or > implementation, as opposed to requesting an improvement to the design (I > do believe what you are asking for would be an improvement). > > ...Marvin > > -- 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. For more options, visit https://groups.google.com/d/optout.
