On Friday, 23 December 2016 01:00:29 UTC+2, mhh...@gmail.com wrote: > > Not sure i quiet get your meaning about symbolic evaluation, >
It just reminded me how you can do expression simplification in Prolog and LISP. * http://stackoverflow.com/a/3516781/192220 * https://mitpress.mit.edu/sicp/ > or it s just what i did :x > > Anyways, for whoever else interested > https://github.com/mh-cbon/template-tree-simplifier > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmh-cbon%2Ftemplate-tree-simplifier&sa=D&sntz=1&usg=AFQjCNGgMxLhAmGhvyniAJuHOqW3Yop9LQ> > > I was wondering if you have any thoughts regarding the idea to > generate the go code not via string manipulation but > via the go ast capabilities. > > https://golang.org/pkg/go/ast/ > Working with text/template (or just printing) + go/format is much easier. Using go/ast might make sense when you are rewriting based on some rules, but not for generating code from scratch. > I saw there is a printer. I m not quiet sure yet how this going to turn, > but i felt i was needing a sort of structure to store types of the data > while generating go code, which was not available when i used text > processing. > > I don t want to abuse, but i was also wondering if ESI processing was > waking up any of your hears. > I'm not quite sure what you are referring to? > As i feel more & more confy with the template package i begin to think > about this. > > you or anyone else. > > thanks! > > On Thursday, December 22, 2016 at 7:55:10 AM UTC+1, Egon wrote: >> >> >> >> On Wednesday, 21 December 2016 23:34:54 UTC+2, mhh...@gmail.com wrote: >>> >>> Hi, >>> >>> back on my initial question about compiling template, i m looking for >>> some experienced ideas. >>> >>> I have now found out i needed to change the ast tree of template in >>> order to simplify it for later manipulation. >>> >> >> The easiest way I can think of is trying to do it in terms of >> symbolically evaluating of the tree and using the actions as the new tree. >> >> https://play.golang.org/p/i-QY-7wJYq >> >> Obviously doing the same on the actual structure is more annoying. >> >> >>> So for example i transform this >>> {{ ("what" | up) | lower }} >>> into >>> {{ $some := ("what" | up) }} >>> {{ $some | lower }} >>> >>> And so on, i d like to reach >>> {{ $some := up "what" }} >>> {{ lower $some }} >>> >>> Which will be as close as possible to regular go code. >>> >>> The thing is that the process to do those transformations seems pretty >>> fragile and tedious. >>> >>> I have tree like this >>> parse.Tree >>> parse.ActionNode >>> parse.PipeNode >>> parse.CommandNode >>> parse.IdentifierNode Ident="up" >>> parse.StringNode Quoted="\"some\"" Text="some" >>> parse.TextNode Text="\n" >>> parse.ActionNode >>> parse.PipeNode >>> parse.CommandNode >>> parse.StringNode Quoted="\"some\"" Text="some" >>> parse.CommandNode >>> parse.IdentifierNode Ident="split" >>> parse.PipeNode >>> parse.CommandNode >>> parse.PipeNode >>> parse.CommandNode >>> parse.StringNode Quoted="\"what\"" Text="what" >>> parse.CommandNode >>> parse.IdentifierNode Ident="lower" >>> parse.CommandNode >>> parse.IdentifierNode Ident="up" >>> parse.TextNode Text="\n" >>> >>> to simplify, one of the algorithm consist of browsing the structure >>> until it match a Pipe containing a Cmd with an Identifier after a Cmd >>> with a Pipe >>> that would match *("what" | lower) | up* >>> >>> And so on to simplify more and more the tree. >>> >>> I wonder if there are better ways to achieve this kind of transform. >>> >> -- 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.
