Guys, I'm apologize to David publicly here. When I wrote him it was to give him a heads up that I would be asking him for advice, but I didn't present a plan at that time (a few months ago). So I ask now. If any of you has any help to give PLEASE jump in and help me on this. I am going to re-write the parser using a recursive descent approach instead of the yacc grammar. I believe this is the best way to go because, as David pointed out and as I already knew, both GCC and LLVM/Clang have moved to this approach.
On Wed, Oct 22, 2014 at 2:01 PM, Gregory Casamento <[email protected]> wrote: > All, > > As usual people come back with useless comments such as this rather than > actual advice. > > David, I did ask your advice on which parser generator to use in the > beginning. I call your attention to the private email I sent you months > ago. It would have been nice to hear from you then. If you had an > objection to my using bison it should really have been registered then > instead of now. > > Far too often I find that individuals on this project do not give advice and > then criticize when it's convenient. > > There is nothing in your comment which is remotely constructive. If you have > a suggestion regarding which parser to use then please offer up a suggestion > as to which you believe is most appropriate rather than simple saying which > ones you believe are not. > > Criticism is easy. Offering advice is not. I asked you for your advice > before and I'm asking for it now again. Which parser generator do you > believe I should switch to? The grammar was built by using a scraper > derived from the swift2js project which produced the grammar. It wouldn't > be hard to change it to generate a grammar for another parser generator. > > I realize that designing a modern compiler is not a trivial task but it is > not one in going to shy away from. I am ready to "jump into it" as you say. > > GC > > > On Wednesday, October 22, 2014, David Chisnall <[email protected]> wrote: >> >> On 22 Oct 2014, at 18:14, Dr. H. Nikolaus Schaller <[email protected]> >> wrote: >> >> >> John Siracusa's review of Yosemite is extensive; for this thread, the >> >> embedded extensive overview of Swift is more interesting. I would highly >> >> recommend reading pages 21, 22, 23 as an overview of what makes Swift >> >> interesting. It sounds like the added step of compiling code into SIL >> >> before >> >> compiling and optimizing SIL into LLVM IR makes some interesting >> >> optimizations possible. >> >> http://arstechnica.com/apple/2014/10/os-x-10-10/21/ >> >> >> >> I'd be particularly interested in hearing from Gregory what is the >> >> intended pipeline in Phoenix and how it compares to what Swift compiler is >> >> doing. >> > >> > Yes, that would be interesting to learn how the architecture is intended >> > to look like. If it is a pre-compiler (using some other for real binary >> > code >> > generation) or it it is intended to generate bytecode or whatever. >> >> I would also be interested in this. Looking at the existing code, it >> looks like a compiler that is based on the state of the art circa 1970 that >> would need a complete redesign to be comparable to anything vaguely modern. >> I appreciate that there's a strong desire for people to leap into this kind >> of project, but designing a compiler for a modern language is not a trivial >> task. >> >> David >> >> -- Send from my Jacquard Loom >> >> >> _______________________________________________ >> Discuss-gnustep mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep > > > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com -- Gregory Casamento Open Logic Corporation, Principal Consultant (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
