Morning! This weekend I tried to download & compile the project but didn't work... I cloned your repo in github and then ran "git submodule update --init", which basically only downloaded autoconf (I was expecting more tools, like automake). I tried running ./bootstrap but it said that there were no "autoconf" nor "automake" tools available. I decided to directly install them with brew and then I ran again bootstrap, which complained again saying there was not "wget". After installing wget, bootstrap asked again about a tool called "autopoint", which is not available in brew and for which I didn't find a reliable repository online.
In sum, this project has a lot of dependencies... I will try again today when I go back home. Perhaps I will virtualize a popular Linux distro, they usually have more tools than Macs. Thanks Victor -----Original Message----- From: Akim Demaille <a...@lrde.epita.fr> Sent: Thursday, October 17, 2019 2:33 PM To: Morales Cayuela, Victor (NSB - CN/Hangzhou) <victor.morales_cayu...@nokia-sbell.com> Cc: Paul Eggert <egg...@cs.ucla.edu>; Bison Bugs <bug-bison@gnu.org> Subject: Re: Getting involved in Bison Hi Victor, > Le 17 oct. 2019 à 07:38, Morales Cayuela, Victor (NSB - CN/Hangzhou) > <victor.morales_cayu...@nokia-sbell.com> a écrit : > > Hello! > > No, I don't know D... It's incredible how many languages still keep emerging. Well, D has been here for a while (2001). Way before Rust (2010) or Go (2009) for instance. As a reaction to C++: D is C++ "fixed". > One thing that I have always encountered funny in Bison is the way to > describe lists. For example, if you expect comma-separated list called > my_list, you would write: > my_list: element | my_list ',' element; I believe there could be > some more elegant syntax to avoid that kind of loops. I don't know how much > we can make up, but creating a simplified expression like this would help: > my_list: %list ',' element; > The directive %list would expand that expression into the previous one. It's far from being that simple, as Bison is taking user actions. This kind of feature is quite easy for parsers that yield ASTs, not so clear for Bison (until the day we equip it with a means to generate ASTs, but that's long into the future, there are many things to do first). If you want to see what a nice modern LR parser generator looks like, have a look at Menhir. Be aware that they cheat: they work with a functional language, Caml, which simplifies quite a few things :) (Heck, we don't even have lists in C...). You'll see that they support the feature you'd like, with an even way more powerful abstracts: user defined "meta rules" (users can define there own abbreviations much like your %list). To summarize: don't even think about this now, it is much more delicate than it first seems. > I've also had problems generating the grammar in C++. Right now I only use C > version of the code because of compilation/interaction problems with the > lexer (I used flex). I don't know in which side is the problem, but every > time I had to mix up C++ code from the project and C code from the > parser/grammar resulted in a mess... Especially when I wanted to wrap > different parsers in different classes and objects. Solving this would be a > big improvement for me. Very much agreed. But first see our examples/ in C++, which show how to have Bison and Flex together for C++. It's not nice though, I fully agree. But it works. I've done that several times in my C++ projects. Second... Well, Joel E. Denny (a former Bison maintainer) and I already have big plans to solve that issue. It will be long and require a lot of testing on real case grammars, but eventually, it will be there. Which is also why I let in only features that aren't subsumed by this work. > I can use github if it's more convenient. I can adapt to anything right now. > > I will take a look again at the pending tasks. First thing then is to have Bison compile on your machine from the repo :)
