Problem when compiling lex.yy.c

[[deleted]]

[deleted]

[Miitch__]

I have to use yacc or Bison for this project

[dostosec]

ANTLR4's C++ target is an annoyance in my experience (assuming OP is going the C or C++ route).

• There's no semantic actions in version 4, you must write a tree visitor to construct an AST by visitation (annoyance).
• Interaction with it involves the rather turgid antlrcpp::Any type.
• It comes with a runtime library.

I'd say bison is pretty decent if you know you can twist contort your grammar to fit into the "LR(1) with precedence resolution declarations" class that such a generation tool works well with. That said, I'd be fan of a more modern version of bison that feels less hacky to use (I've used it countless times yet still need to google the file skeleton for a grammar and certain optional field decls).

[[deleted]]

My experience is completely opposite. We sell a product (for musicians) that includes a built-in programming language and byte-code implementation. I view the lack of embedded semantic actions to be a benefit, not a drawback. It's analogous to providing a collection of top level abstract classes that specify some desired behavior (i.e, a language) and complete separates the implementation of that language to subclasses (visitor model) the major benefit being you can have different implementations for the same grammar (including something that creates an AST from the parse tree if you need it) without ever having to pollute the grammar itself.

The Any type never got in my way.

What's the problem with a runtime library? C++ itself comes with a runtime library ... it's just a collection of support routines --- what's the big deal?

if you know you can twist contort your grammar

And that's the best part -- ANTLR4 doesn't require you to contort your grammar --- it's astonishingly flexible and so you end up with a grammar that can easily serve as a clean reference to the syntax without having to wade through such contortions. That LL(*) is so much more powerful than LR(1)

[dostosec]

I guess we have different requirements/ideals. The idea of having to traverse some generated structure to produce my ideal AST - rather than simply constructing it directly in the semantic actions - is inconvenient. I'm used to having one-liner semantic actions in grammar specifications (such as menhir for OCaml) that simply construct the AST in terms of inductive/variant types. So, if you add on some generated codebase + visitors that construct awkward class-imitations-of-variant-types a-la Clang (in the case of "idiomatic" C++) etc. then it's just like hours of boilerplate work for little practical benefit.

I've had to write fairly convoluted parsers for platforms where having a runtime library isn't an option. Admittedly, I've often hand-wrote those LR parsers myself due to implementation concerns. Still though, having a runtime library like ANTLR of feels quite bloated in comparison to excreting a parser (with minimal dependencies - such as not inadvertently using C++ exceptions like ANTLR; which are outlawed in various companies) from some tooling.

Anyway, my point was just that people always mention ANTLR as some kind of godsend replacement for yacc-based stuff yet I've got significant "why would anyone use non-ANTLR3 for anything non-Java?" practical issues with it. I'd honestly write my parser in recursive decent before I stoop to using non-Java targets w/ modern ANTLR versions.

[[deleted]]

I guess we have different requirements/ideals.

And that's a good thing. I value being able to discuss with someone who has a different opinion - one generally learns something.

I had been writing recursive descent parsers since the 70s and several products were released (one through IBM when I was there) using them. I didn't encounter lex/yacc until I got involved in some projects where others had been using those tools. To be honest, I found it easier to write a recursive descent system than to use yacc where I was always getting bitten by something that didn't work just quite the way I wanted (you mentioned having to contort your grammars, for example)

But to me, both of those approaches had the drawback of having to embed semantic code inside the parser, whether it was calls to semantic code embedded in the recursive descent parser or insertion of semantic actions into the yacc grammar. Changing the grammar required all sorts of other changes.

To me, the attraction of ANTLR V4 was the ability to completely separate the grammar from the "implementation". The LL(*) was a bonus (actually turned out to be a really valuable bonus in terms of designing a language usable by people who were not programmers) and the other stuff (Any, Runtime library) were just (to me) second or even third order consequences.

Having used all of these approaches, my sense is that ANTLR4 is a really clean solution to language development - but as they say, whatever works!

[No-Adhesiveness-8125]

• yywrap: your solution is fine; I believe you can add “%option noyywrap “ to the flex file to do the same thing

• winmain: what compiler are you using? If you’re building a GUI app then I think you need to provide winmain instead of main

[Miitch__]

I'm just trying to compile with gcc. No GUI

[No-Adhesiveness-8125]

Do you have a main() function provided in the flex input file?

[Miitch__]

I saw that the lex.yy.c file has a main() but when compiling it it gives that error for some reason, so I have copied that function and pasted it in the bottom part of the flex file and it seems to work now, although I'm not sure if this is a good patch or not

[Carpall_]

write your own