5 ms·

Indeed. It's beyond my understanding how one could even consider not providing a public API to the parser, when one develops an interpreter or a compiler. Given

by DasIch 11y ago

Indeed. It's beyond my understanding how one could even consider not providing a public API to the parser, when one develops an interpreter or a compiler. Given all the complexity of such programs, this is trivial. The standard library of a language should provide access to the parser, so that developers can easily create tools for the language they're using.

NhanH 11y ago
You just sang the song of Lisp programmers all over the worlds.
- DasIch 11y ago
  In Lisp basically everyone starts to develop their own languages. Given that most people can barely get a reasonable API together that's just a bad idea.
  - NhanH 11y ago
    No disagreement here. I was just pointing out that what the GP wanted already exists in the form of Lisp (with different flavors of macro being different "API" to the parser, so to speak).
  - sklogic 11y ago
    It is far, far easier to design a good DSL than to design a usable API.
mafribe 11y ago
Most modern compilers do provide hooks into the compiler. But this does limit flexibility to evolve the compiler. You can turn the argument around. As writing a parser is near trivial with parser generator tools, parser APIs are not what is problematic with writing tools.
chubot 11y ago
Two things: 1) It's not "trivial" -- it's actually a substantial amount of work, especially as the language evolves. How many parsers have you written? Do they have public APIs? Which public APIs to parsers have you used before? 2) It can actually constrain the evolution of the language. IIRC Python has had some non-trivial upgrades that "reinterpret" text with a different parse. If you have to provide parse tree compatibility in addition to text compatibility, that makes changing things harder. I've noticed that people who have taken a compiler class (often not in C) but haven't worked on "real world" parsers (nearly all written in C/C++) have a very idealized notion of how they behave. Parsers written in C are more often than not tightly coupled to both the lexer and compiler.
sklogic 11y ago
Some (most notably, gcc) are deliberately not providing any external access to the compiler entrails, out of some deranged ideological motives.

by DasIch 11y ago

NhanH 11y ago

You just sang the song of Lisp programmers all over the worlds.

DasIch 11y ago
In Lisp basically everyone starts to develop their own languages. Given that most people can barely get a reasonable API together that's just a bad idea.
- NhanH 11y ago
  No disagreement here. I was just pointing out that what the GP wanted already exists in the form of Lisp (with different flavors of macro being different "API" to the parser, so to speak).
- sklogic 11y ago
  It is far, far easier to design a good DSL than to design a usable API.

mafribe 11y ago

Most modern compilers do provide hooks into the compiler. But this does limit flexibility to evolve the compiler. You can turn the argument around. As writing a parser is near trivial with parser generator tools, parser APIs are not what is problematic with writing tools.

chubot 11y ago

Two things: 1) It's not "trivial" -- it's actually a substantial amount of work, especially as the language evolves. How many parsers have you written? Do they have public APIs? Which public APIs to parsers have you used before? 2) It can actually constrain the evolution of the language. IIRC Python has had some non-trivial upgrades that "reinterpret" text with a different parse. If you have to provide parse tree compatibility in addition to text compatibility, that makes changing things harder. I've noticed that people who have taken a compiler class (often not in C) but haven't worked on "real world" parsers (nearly all written in C/C++) have a very idealized notion of how they behave. Parsers written in C are more often than not tightly coupled to both the lexer and compiler.

sklogic 11y ago

Some (most notably, gcc) are deliberately not providing any external access to the compiler entrails, out of some deranged ideological motives.