Question

It's common for a programming language to come with a standard library implemented at least partly in the language itself.

In the case of an interpreted language, the obvious implementation is to read the library source files when the interpreter starts up, but this runs into the messy but persistent problem of making sure the interpreter knows where to find those files even when both are moved around. It would be cleaner if they could be embedded in the interpreter itself, so there is just a single executable.

I can see a simple way to do this by just translating the library source files to C literal strings, but I'm curious as to whether there are any pitfalls I'm overlooking or refinements to the method.

So my question is, what existing interpreted languages attach library source files in the language itself, to the interpreter?

Was it helpful?

Solution

Bytecode virtual machines often provide an answer to this: store the bytecode in files (*.pyc, *.rbc) and load the bytecoded versions of the libraries using a simpler mechanism.

Smalltalks do this by dumping the standard heap into a separate file called an "image".

As for single-file distribution, append the library file(s) to the end of the executable file, and include special logic for the interpreter to read from its binary and find a structure of those interpretable program data, or alternatively build the interpreter with a static inclusion of the program data.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top