Interpreters written in standard C or C++

7
votes

Are there any extensible interpreted programming languages written in standard, platform-independent C or C++?

I would like to be able to simply put all the sources in one directory, compile the sources with any standard compliant C or C++ compiler and produce an executable which reads and interprets script files in the designated scripting language.

It seems like many programming languages "written in C" often incorporate many features dependent on the platform they are in, and as a result, require some configuration program to run based on your target system (e.g. Autoconf) which complicates matters and limits cross-platform compatibility.

Reason for question:

I am interested in learning about programming language design. I have played with some toy programming languages after following tutorials involving yacc, lex, and llvm. However, recently I have become interested in studying a programming language written in portable C/C++, as that way, I can study the program and code on any machine that supports a standard C or C++ compiler (possibly even on my ipad) and still have a reasonably uniform experience.

As this is just for educational purposes, the scripting language doesn't need to support super low level features like C, nor does it have to feature GUI like Java (I don't think you can write any kind of GUI limited to standard C/C++ anyway) or any complicated io for that matter. However, I would like the language to be complete enough that it would be practical to write some useful programs in the language (e.g. It should be possible to extend the language using C/C++ so that you can use it like a shell on tty).

Thanks.

Edit:

@AndréCaron I would prefer it if at least the core of the language was 100% platform independent. It would be ok if the language included a large standard library that depended on other libraries to make it "more useful", however, I would like to be able to strip the standard library and use just the core of the language (possibly with custom hand written libraries) if I wanted to.

4
c++cinterpreter
This is really a better question for the programmers site. – the Tin Man
How is this off-topic? Seems to fit solidly in Programmers.SE excluded topics. – Ben Voigt
"Embed the library sources into my source tree" isn't really a common way to include libraries in your project outside of the iOS platform. If you intend to use C, you should consider add "using third-party libraries", and "dealing with autotools" to your educational goals. – millimoose
Is 100% platform indepence desired, or is something that compiles out of the box on all platforms fine with you? It's really difficult to write any sort of useful compiler/interpreter without using any language/library extensions. – André Caron
That said, you might want to take a look at Lua. "Easy embedding into other software" is one of their main goals, so they just might support your desired scenario. (As a bonus, it's a really tiny language and implementation, so it should be easy to both understand and possibly feasible to remove the OS-dependent code from.) – millimoose

4 Answers

9
votes

Maybe embedded Lua?

Actually core Lua itself is probably better. At first glance, I though eLua's claim of running on many different systems meant it was highly portable, but in fact it takes core Lua and adds a bunch of hardware drivers, which obviously aren't so portable.

Ocaml would be another excellent choice. It claims "The bytecoded system currently runs on any POSIX-compliant operating system with an ANSI-compliant C compiler" And Caml Light is especially suitable for learning. "The runtime system and bytecode interpreter is written in standard C, hence Caml Light is easy to port to almost any 32 or 64 bit platform."

7
votes

Lua is really your best bet. The core Lua interpreter is about as minimalistic as you can get. The distro includes a makefile, but it's about as bare-bones as it gets. There are even instructions that explains which files you need to build just the core language, which ones are the Lua standard library, and which ones are the command-line interpreter.

The core language itself doesn't touch any platform-specific APIs or headers. The standard library does, but only in the most minimal way. And you don't have to build the standard library if you don't feel like it.

There are some #defines you can use to configure the build, but that's mostly for things like DLL building and the like.

Note: The purpose of autotools and other platform-specific build configuration utilities is to allow libraries to effectively wrap platform-specific stuff within a platform-neutral interface. There's not really much you can do on most platforms with pure platform-neutral C or C++ standard libraries. You can't even access directory trees and search for files, let alone really useful things like bringing up a window. For simple stdin/stdout applications, that might be enough. But for the vast majority of cases, it isn't.

My suggesting is that you get used to having to configure a build for a specific platform. Unless your domain is scientific applications (and in some cases, not even then), you're not going to get much out of platform-agnostic programming. You're going to have to learn to work with these kinds of libraries.

Lua is an outlier when it comes to libraries. Most libraries are not lists of files you can just shove into a directory and compile willy-nilly. The sooner you figure out how to work with the tools that libraries use, the better off you'll be.

1
votes

Almost all recent script languages are written in C or C++: Perl, bash, csh, PHP, html, Javascript, make, vim, tcl, etc., etc.

The fact that building them requires configuration is not a feature of the interpreter so much as it is an adaptation for building on multiple platforms—usually considered a good thing.

They are all extensible in the sense that you can write functions which create new functionality.

0
votes

LUA and TCL are the two simplest interpreted languages so get a copy of the source code for both of those and examine it. However I think that your question is more related to static linking versus shared linking. A statically linked program has no system dependencies beyond the kernel interface, but a dynamically linked program requitres the correct set of shared libraries to be installed.

With a language like Python you need to worry about Python's own libraries (called modules) as well as any binary shared libraries that a module depends on. Python itself is usually built using shared libraries, but it can be built statically. In addition, I have built a Python binary that uses the Linux shared library RUNPATH feature so that all binary dependencies can be bundled with Python in its own folder hierarchy.

If your question is more about linking, have a look at how StaticPython is built compared to standard dynamic Python and the Pybuild build scripts using RUNPATH.