7

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.

vainolo
  • 6,907
  • 4
  • 24
  • 47
math4tots
  • 8,540
  • 14
  • 58
  • 95
  • This is really a better question for the [programmers](http://programmers.stackexchange.com) site. – the Tin Man Jan 27 '12 at 23:30
  • 2
    How is this off-topic? Seems to fit solidly in [Programmers.SE excluded topics](http://programmers.stackexchange.com/faq). – Ben Voigt Jan 27 '12 at 23:30
  • "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 Jan 27 '12 at 23:32
  • 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 Jan 27 '12 at 23:32
  • 2
    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 Jan 27 '12 at 23:34
  • There are plenty of interesting reading here: [Learning to Write a Compiler](http://stackoverflow.com/questions/1669/learning-to-write-a-compiler) – Stephen Quan Jan 27 '12 at 23:41

4 Answers4

9

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."

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Sadly, no. From http://www.eluaproject.net/doc/master/en_building.html: "**eLua** has a very flexible build system [...]. To use it, you need to edit a single configuration file (*platform_conf.h*) located in the platform specific directory (*src/platform//platform_conf.h*)." – ruakh Jan 27 '12 at 23:39
  • 4
    Well, it's not perfect - but I don't think there's such a thing as a cross-platform platform-independent anything. If there were, then all platforms would be consistent and there would be no cross-platform issues at all, right? Everything would just be platform independent. The value of Lua is that the changes necessary are small and in only one file, they've already done the work to make the _code_ platform independent. My understanding is that you're just tweaking the build, not the interpreter. – Matt Jan 27 '12 at 23:52
  • @Matt: I think the point is that the C (and C++) runtime libraries are supposed to abstract (almost) all the platform differences. But the C standard APIs still require the app to use platform-specific data like filenames. – Ben Voigt Jan 27 '12 at 23:55
  • @Matt Actually you can take what BenVoigt said a little further and require alot of platform-specific data to be passed by argument, or saved to another file. Though, I would imagine this is what build-tools do to begin with. – math4tots Jan 28 '12 at 00:10
7

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.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
1

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.

wallyk
  • 56,922
  • 16
  • 83
  • 148
0

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.

Michael Dillon
  • 31,973
  • 6
  • 70
  • 106