41–50 of 78 posts
I wrote a very small but complete compiler and VM for a very simple language: boolean expressions. I use it as a "what to expect" type of introduction during the first session of my compiler course.
The whole code is here, it is less than 150 lines of OCaml code (plus a few lines of C for the VM) and uses standard parsing tools: https://gist.github.com/p4bl0-/9f4e950e6c06fbba7e168097d89b0...
Earlier quoted context omitted.
> I write mine all by hand. It's the easiest part of a compiler to write, by far. It's also the least troublesome. It's also the most annoying if you're writing a new language. You want to iterate on its ideas, but can't do so until you have a parser done. I've been designing a few language concepts over the past year, and it feels 80% of this time has been writing and debugging parsers; by the time I get to the meat…
> You want to iterate on its ideas, but can't do so until you have a parser done. Embed your language into host language. It is simple to do even in C++. Iterate on ideas till your heart content, then add syntax.
Where is the special tooling to help spot errors?
But the same could be said about books, nothing is stopping you from writing a book except good ideas, story, and structure.
How does one debug a grammar? This has always eluded me. Where is the special tooling to help spot errors?
[2] https://mingodad.github.io/parsertl-playground/playground/ not sure.
How does one debug a grammar? This has always eluded me. Where is the special tooling to help spot errors?
I am probably misunderstanding your requirements but if you are looking for something like regex101 then https://omrelli.ug/nearley-playground/ and https://bnfparser.firebaseapp.com/ although not sure how much 'practical' are they. Googling gives [2], [3], [4]. [2] https://mingodad.github.io/parsertl-playground/playground/ not sure. [3] https://chrishixon.github.io/chpeg/playground/ [4] https://mdkrajnak.github.io/eb…
I thought a compiler, with no adjective or caveat, should turn a HLL into machine language. Isn't what this describes—turning BASIC into Go—more accurately described as a "pseudocompiler" or "Go compiler" or somesuch? I know Emacs is always said to have a "bytecode compiler" that processes Elisp code, not a "compiler" per se. Am I mistaken?
Specifications for computer information, a catalogue, compiling routines, and subroutines will be given after adding another level to the block diagram. As Fig. 5 stands the mathematician must still perform all mathematical operations, relegating to the UNIVAC programming and computational operations. However, the computer information delivered by the mathematician no longer deals with numerical quantities as such. It treats of variables and constants in symbolic form together with operations upon them. The insertion of a fourth level of operation is now possible, Fig. 6. Suppose, for example, the mathematician wishes to evaluate a function and its first n derivatives. He sends the information defining the function itself to the UNIVAC. Under control of a "compiling routine of type B", in this case a differentiator, using task routines, the UNIVAC delivers the information necessary to program the computation of the function and its derivatives. From the formula for the function, the UNIVAC derives the formulas of the successive derivatives. This information processed under a compiling routine of Type A yields a program to direct the computation.
IMO, a better term for a compiler would have been a "translator."
> It’s possible to write the lexer and parser entirely by hand I write mine all by hand. It's the easiest part of a compiler to write, by far. It's also the least troublesome. One advantage of doing them by hand is better, more targeted error messages are easier to fold in.
> It’s possible to write the lexer and parser entirely by hand I write mine all by hand. It's the easiest part of a compiler to write, by far. It's also the least troublesome. One advantage of doing them by hand is better, more targeted error messages are easier to fold in.
I suspect that this is the more common opinion, especially when the desired outcome is real world use. Recursive descent is surprisingly ergonomic and clean if one gets the heuristics right. Personally I find it way easier than writing BNF and its derivatives as you quickly get into tricky edge cases, slow performance and opaque errors.
Same with parser combinators. Not until a bunch of trial and error do you build up the intuitions you need to use them in production, I think.
Despite two decades of using those, I've found it much simpler to write my own scanning or RD parser.