Earlier quoted context omitted.
[flagged]
yes, that Eric Schmidt.
I Wrote a Compiler
61–70 of 78 posts
Re: I Wrote a Compiler
#62Re: I Wrote a Compiler
#63I 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?
The original term for "compiler" was not restricted to compiling down to machine code. From Grace Hopper's paper "The Education of a Computer" (1952)[1]: 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 progr…
Re: I Wrote a Compiler
#64> 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.
Much of the parser code, if you compare the code with the BNF grammar, is a 1:1 correspondence. Super easy to do.
Re: I Wrote a Compiler
#65> 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 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…
1. having to learn lex and yacc
2. running into limitations with lex and yacc
3. having a foreign program (i.e. lex and yacc) integrated into your build process
4. requiring a particular version of lex and yacc that may be awkward on multiple platforms
5. optimizing the code. (Once you start doing that, you cannot use lex/yacc to generate a new version.)
And so on.
At one point, we decided to write a D program that built the D compiler, instead of using make. Well, that turned out to be a greater time sink than just using make.
Re: I Wrote a Compiler
#66> 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.
In my lifetime parsers have gone from: written by hand with great effort, to: use a parser generator to be sure the grammar is correct and save effort, to: just write by hand because it's not that hard and error reporting, to: just use AI.
I suspect you might spend more time trying to specify what you want to the AI than just writing it.
Re: I Wrote a Compiler
#67> 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.
Yacc/lex tend to produce generic error messages and do very poorly with error recovery.
Re: I Wrote a Compiler
#68Earlier quoted context omitted.
The original term for "compiler" was not restricted to compiling down to machine code. From Grace Hopper's paper "The Education of a Computer" (1952)[1]: 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 progr…
Thank you for digging this up. I agree about "translator". They were called "compilers" because the first ones were little more than linkers.
Re: I Wrote a Compiler
#69Earlier quoted context omitted.
BASIC is an amazing language that computing novices (including humanities majors) could learn in an afternoon, that could be efficiently compiled or compactly interpreted, that was small enough to support dozens of interactive users on a mainframe or minicomputer, or to fit into a tiny 8-bit microcomputer – and yet was largely equivalent to FORTRAN in terms of its expressive power. I think the closest modern equivale…
Delphi for sure. And while you have to run it on Windows, it can create binaries for Windows, macOS, Linux, and mobile. https://www.embarcadero.com/products/delphi
Re: I Wrote a Compiler
#70Earlier quoted context omitted.
Strictly speaking it's a transpiler, but honestly the delta between the target language (Go) and the source language (BASIC) is very fluffy and wooly, from what I remember from my PL theory days the distinction was always fuzzy enough that people used whatever term felt right to them. An example off the top of my head — Chicken Scheme (call-cc.org) calls itself a compiler but it's target language is C
"Transpile" is a shortening of the older term "trans-compile". [0] It's a subset. All transpilers are compilers. Not all compilers are transpilers. [0] Amiga BASIC called itself a transcompiler, from memory.