The C Interpreter: A Tutorial for Cin (1988) | Hacker News Reader

The C Interpreter: A Tutorial for Cin (1988)

tuhs.org

I occasionally use tcc (https://bellard.org/tcc/) like an interpreter (`tcc -run`), it's convenient for certain odd tasks.

Not so much for interactive stuff, but if I'm building little PoCs for an idea that will get dropped into a C project, or fiddling with structs work out how something should/is being stored, or in situations where I'm making stuff that interacts with or examples based on C code and I want to use the same parts as in the real code, etc.

c interpreter, I remember trying to get a good one of those was the holy grail back in the 80s. Then (IIRC), PERL came out and the interpreter talk disappeared.

There's some interest in interpreted C++ in the scientific community (e.g. ROOT), but C and C++ are just about the worst possible languages to run interpreted. Ugly as it may be, the "interpreted shell, compiled core" approach is the winning one.

C and C++ are about the worst possible languages to use for scripting—let alone interactive interfaces, which even the current crop of conventionally “scripting” languages is kind of bad at[1].

Having an interpreter to poke at in-development code, though, would IMO still be useful. (I wouldn’t use Haskell or SML/OCaml for scripting either, and yet I swear by their interpreters.) Even GDB has something like one—the expression fragment the “print” command understands includes casts, which means it can parse type names, and for unoptimized C that’s honestly half the battle.

Or take it from (younger) Russ Cox[2]:

> All current C environments suffer from a much larger problem, namely a lack of interactivity. You can’t sit at a prompt, enter C fragments, and see what happens.

[1] http://yosefk.com/blog/i-cant-believe-im-praising-tcl.html

[2] https://swtch.com/~rsc/systems-2002.pdf

Depends on the workflow, "C++ for scripting" helped to discover the higgs boson

Python has an excellent interactive shell but I’m not sure this is such a blessing. It seems that nearly every package out there required you to use that shell to understand something mundane, like the type of a function result or properties of some object. I’d rather have good documentation instead.

As-in "The advantage of using a normally compiled language is that code can be compiled once the prototype is debugged and refined. CINT is a C++ interpreter, making it a tool for rapid prototyping and scripting in C++."

https://root.cern.ch/root/html534/guides/users-guide/CINT.ht...

Other C interpreter threads here[1,2] refer to a number of historical implementations (which you can often find on abandonware sites if that’s your thing), but this particular one from 10th Edition Unix seems to mostly go unmentioned on the ’net (this roff source for the paper and a spartan man page[3] are all I could find).

[1] https://news.ycombinator.com/item?id=11748147

[2] https://news.ycombinator.com/item?id=20950865

[3] https://man.cat-v.org/unix_10th/1/cin

i used c, and latterly c++, throught the 1980s - i don't remember any particular interest in interpreters for either.

Perl having all the typical bindings for sockets, ioctl, localtime, and most of the stdlib stuff probably scratched the itch well enough. And the overall syntax isn't terribly different from C, if you want. So that makes sense to me.

I'm sure I remember Pike starting off as a literal C interpreter, but somewhere along the line decided to become it's own 'C-like' language.

https://pike.lysator.liu.se

Wikipedia seems to imply that it was separated out from LPmud's built-in 'C interpreter' which sounds about right.

Reply on news.ycombinator.com