Ace: a syntax-driven C preprocessor (1989) [pdf] | Hacker News Reader

Ace: a syntax-driven C preprocessor (1989) [pdf]

swtch.com

45 pointskazinator13 comments

Xoc[0] is a newer extensible C compiler. The project ended in 2008 but the papers are worth reading.

[0] https://pdos.csail.mit.edu/archive/xoc/

A distant cousin of Golang? One of the major example extensions Cox provides in his paper is Alef-style channels, which naturally (considering the lineage) feels similar to what Go has.

Unusual preprocessors in longstanding classical languages such as C and Fortran should be a well-considered decision. I know a particular example of a mature Fortran code which must be preprocessed with a weird perl script which enriches the Fortran notation with some semantic meaning of the array indices. We can do something similar now in a C++ code which uses templates but can be compiled without any tricks.

My personal bottom line: Better stick to the language canon and switch the complete infrastructure then only parts of it, except it is a small developer group or exceptional documentation.

> We can do something similar now in a C++ code which uses templates but can be compiled without any tricks.

That's nice, but you cannot do that in Fortran without that perl script, so apples and oranges.

That perl script cannot possibly be a worse dependency containing more technical debt than C++.

"here is a routine for drawing vectors using Bresenham’s algorithm."

https://en.wikipedia.org/wiki/Bresenham's_line_algorithm

> It is possible to use this technique to calculate the U,V co-ordinates during raster scan of texture mapped polygons {citation-needed}

Way back as an undergrad student, I suspected this, after successfuly implementing the rendering of hyperbolic (y = A/x) curves with Bresenham. It hit me; that /x could be the perspective divide by z; that vertical coordinate could be marching through texture space. Never tried it, though.

Neat. This looks a lot like GHC’s rewrite rules (used to define loop fusion optimizations, among other things) except that Haskell doesn’t have to worry about side effects quite as much and the whole system is simpler as a result.

Has anyone here tried to use m4 as a CPP replacement?

Good christ no, m4 is one of the worst macro preprocessors.

If you're going to preprocess C code then you should use something which is aware of the syntax of C (analogous to camlp4 for OCaml). There are a bunch of "LISP macro for C" projects out there.

The reason I even considered m4 is its ubiquity; since it's mandated by POSIX, it wouldn't be another external build dependency if I wanted more powerful (but more painful) preprocessing.

If you're after POSIX compliance I'd use sed(1) and dc(1) before I touched m4(1)

I just signed up to respond to this. So... ...First Post! (of mine anyway). OK, 20 years ago I went to a talk by Stroustrup in Cambridge, UK. He critiqued C and said there were better macro processors available than CPP. After the talk I went up and asked him what he was referring to, and he said M4. So I learnt it and haven't regretted it. I've used it in non-C projects quite extensively. tl;dr I've reasonable experience using M4 and from that I strongly disagree with you objection. Stroustrup moreso. Yes, it's weird, but very capable. It lacks named parameters but I can live with that for what it does give me, which is arbitrary blocks of code without '\' at the end of every line, and recursion which is the biggie. But diversions, which allow you to 'put aside' some code until later, which are pretty good and there's loads more stuff. May I suggest you give it another try before dismissing it.

Did it ever escape the Sun?

Reply on news.ycombinator.com