Hi Adrian, > Le 18 juil. 2020 à 10:26, Adrian Vogelsgesang <avogelsges...@tableau.com> a > écrit : > > Hi Akim, hi Christian, > > Really interesting thread and discussion! > I almost feel guilty for only picking up one particular point ;) > > Akim's comment >> No, it's also about the targeted model. Most other GLR parser generators >> address a somewhat simpler issue: their parsers generate the final AST. >> They are DOM-parsers. Bison is more like SAX-parsers: we run user actions. >> Memory management is really a problem here. > touches an interesting point to me. > > It made me realize: We in Hyper are actually using bison only to generate a > DOM tree. We built our own abstraction on top of bison, a "bison > preprocessor" which translates a kind of ad-hoc "DOM-description language" > used in the parser actions into actual C++ code for our actions which can > then be fed into bison > > Would it be valuable to have something similar in bison? > I.e. teach bison some kind of short-hand syntax which can be used in actions > and to create a DOM tree? > Would others also be interested in such a DOM-building capability?
It very much depends upon what you are thinking about. I'm not willing to follow ANTLR and provide the whole stack, including generating the AST, the visitors, etc. However, I think it's appropriate for Bison, and there's interest from users, to not have to call user actions, but to rely on conventions to build the tree by calling a set of user provided functions. Adrian, is there a place where we can see your tool?
