6 ms·

lex and yacc are part of POSIX, while flex and bison aren't.

by EuAndreh 5y ago

klodolph 5y ago
Sure, and C++ isn't part of POSIX. So if you must stick to strictly POSIX utilities, you cannot use C++.
- ncmncm 5y ago
  C++ and Posix are both ISO Standards.
  - klodolph 5y ago
    Are you constrained to only use software which is standardized by ISO? I'm just trying to figure out what you're saying here.
    - ncmncm 5y ago
      I am not so constrained, but some are. But in general, for anybody deploying software widely, any time you can avoid a necessary build dependency on another tool, you come out ahead.
      - klodolph 5y ago
        Could you tell me more about who is constrained this way? I'm curious about what kind of organization has these kinds of constraints. I have some friends who work in aerospace or at defense contractors and these constraints sound a little extreme even by their standards.
        ncmncm 5y ago
        They would know better than I do.
      - kazinator 5y ago
        You can avoid a build dependency on Bison or Flex by shipping their output. Their output is intended to be portable and standard-conforming. https://www.gnu.org/software/bison/manual/bison.html#Versioning https://www.gnu.org/software/bison/manual/bison.html#Version... Even if you have standard-conforming lex and yacc source code that, theoretically, work with any yacc or lex implementation, it's still wise to pick a good implementation and generate code with it, and ship that code. You don't want some random tool from the user's installation writing C code into your project. And POSIX does not guarantee the presence of a yacc command in an installation; it just describes what it does if it is present. There are Unix-like systems with no dev tools on them; requiring lex plus yacc plus a compiler is a bigger dependency than just requiring a compiler.
        ncmncm 5y ago
        There is no merit in adding a dependency on something that is demonstrated to be unnecessary. People writing C++ code no longer have any need for a thing like yacc, and that is a net good.
        kazinator 5y ago
        More precisely, people writing C++ code who fork a copy of cpgg into their project, and maintain their fork forever, never peeking at the upstream again, have no external dependency. Those who maintain some relationship with the cpgg upstream repo have some sort of dependency. (C++ itself is a heavy dependency. People who don't use C++ demonstrate that C++ is not necessary.) Dependencies are not all the same; they have different weights. Three light dependencies could be equal to one heavy one.) cpgg is currently not comparable to something like Bison. Bison has documentation, and an active mailing list where you can get quality help from knowledgeable people. It has multiple contributors. It supports multiple languages, so your parser-writing skill transfers to different stacks: e.g. from C to Java, for instance. In many cases you should be able to port the grammar directly; just the semantic actions need a rewrite. It has some novel diagnostic features, like the recently added feature of being able to generate counterexamples to explain conflicts. It has the old diagnostic features, like the y.output file so you can pore over the LALR(1) state graph, and a debug mode. It supports something called "push parsing": inverting the control flow, so that the parser becomes a state machine to which you can feed tokens one at a time. That makes it possible to do things like, oh, multiplex multiple parse jobs in parallel into a single event loop.
  - kazinator 5y ago
    If you use only ISO standard tools, how do you read e-mail? Or access the web? What bug database are you using: I don't know of any ISO-standard bug database. Git is not an ISO-standard; do you pass around pax archives for version control? Not using SSH, I hope; that's not ISO standard. Not even XWindow is an ISO standard, so nothing but ANSI terminals for you.

lex and yacc are part of POSIX, while flex and bison aren't.

klodolph 5y ago

Sure, and C++ isn't part of POSIX. So if you must stick to strictly POSIX utilities, you cannot use C++.

ncmncm 5y ago
C++ and Posix are both ISO Standards.
- klodolph 5y ago
  Are you constrained to only use software which is standardized by ISO? I'm just trying to figure out what you're saying here.
  - ncmncm 5y ago
    I am not so constrained, but some are. But in general, for anybody deploying software widely, any time you can avoid a necessary build dependency on another tool, you come out ahead.
    - klodolph 5y ago
      Could you tell me more about who is constrained this way? I'm curious about what kind of organization has these kinds of constraints. I have some friends who work in aerospace or at defense contractors and these constraints sound a little extreme even by their standards.
      - ncmncm 5y ago
        They would know better than I do.
    - kazinator 5y ago
      You can avoid a build dependency on Bison or Flex by shipping their output. Their output is intended to be portable and standard-conforming. https://www.gnu.org/software/bison/manual/bison.html#Versioning https://www.gnu.org/software/bison/manual/bison.html#Version... Even if you have standard-conforming lex and yacc source code that, theoretically, work with any yacc or lex implementation, it's still wise to pick a good implementation and generate code with it, and ship that code. You don't want some random tool from the user's installation writing C code into your project. And POSIX does not guarantee the presence of a yacc command in an installation; it just describes what it does if it is present. There are Unix-like systems with no dev tools on them; requiring lex plus yacc plus a compiler is a bigger dependency than just requiring a compiler.
      - ncmncm 5y ago
        There is no merit in adding a dependency on something that is demonstrated to be unnecessary. People writing C++ code no longer have any need for a thing like yacc, and that is a net good.
        kazinator 5y ago
        More precisely, people writing C++ code who fork a copy of cpgg into their project, and maintain their fork forever, never peeking at the upstream again, have no external dependency. Those who maintain some relationship with the cpgg upstream repo have some sort of dependency. (C++ itself is a heavy dependency. People who don't use C++ demonstrate that C++ is not necessary.) Dependencies are not all the same; they have different weights. Three light dependencies could be equal to one heavy one.) cpgg is currently not comparable to something like Bison. Bison has documentation, and an active mailing list where you can get quality help from knowledgeable people. It has multiple contributors. It supports multiple languages, so your parser-writing skill transfers to different stacks: e.g. from C to Java, for instance. In many cases you should be able to port the grammar directly; just the semantic actions need a rewrite. It has some novel diagnostic features, like the recently added feature of being able to generate counterexamples to explain conflicts. It has the old diagnostic features, like the y.output file so you can pore over the LALR(1) state graph, and a debug mode. It supports something called "push parsing": inverting the control flow, so that the parser becomes a state machine to which you can feed tokens one at a time. That makes it possible to do things like, oh, multiplex multiple parse jobs in parallel into a single event loop.
- kazinator 5y ago
  If you use only ISO standard tools, how do you read e-mail? Or access the web? What bug database are you using: I don't know of any ISO-standard bug database. Git is not an ISO-standard; do you pass around pax archives for version control? Not using SSH, I hope; that's not ISO standard. Not even XWindow is an ISO standard, so nothing but ANSI terminals for you.