my_basic is a BASIC interpreter you can paste into a C project as two files

The core is one C file and one header, and that is the design

MY-BASIC is a lightweight BASIC interpreter written in standard C in dual files, and the aims are stated as embeddable, extendable and portable. The core is written in a C source file and an associated header file, and the README says it is easy to either use it as a standalone interpreter or embed it with existing projects in C, C++, Java, Objective-C, Swift, C# and so on, and to customise it by adding your own scripting interface.

That is the whole proposition. The language is a vehicle for the embedding, and the two file structure is what makes the embedding possible. The feature list supports this: the API is easy for extending new BASIC functions, there is easy interaction with BASIC facilities at the native side and vice versa, and there is a debug API.

The size constraint is explicit too. The interpreter is described as lightweight, within less than a 128KB footprint, fast, and configurable, and it is written in standard C so the source is portable to a dozen of platforms.

The copyright line runs from 2011 to 2026 for Tony Wang, which tells you this is a long-running project rather than an experiment, and the licence is MIT.

The repository layout matches the description. There is a core/ directory, a shell/ directory holding the standalone interpreter, a makefile for Linux, my_basic.sln and my_basic.vcproj for Windows, my_basic_mac.xcodeproj/ for macOS, precompiled binaries in output/, sample/ programs, and a resource/ directory.

The language is retro BASIC plus prototypes plus lambdas

The language description is where my_basic stops being a BASIC dialect and becomes its own thing. It is a dynamic typed programming language that reserves structured syntax, supports a style of prototype-based programming for object oriented work, and also implements a functional paradigm by lambda abstraction.

The keyword list shows how much of both worlds is present. The retro constructs are there, with reserved GOTO and GOSUB/RETURN, but the structured forms are the ones the language prefers. There is DEF/ENDDEF for subroutines, IF/THEN/ELSEIF/ELSE/ENDIF, FOR/TO/STEP/NEXT, FOR/IN/NEXT, WHILE/WEND and DO/UNTIL. On top of that sits a set of modern features: prototype-based programming with reflection support, lambda abstraction for enhanced functional programming, customizable referenced and non-referenced user types, and collection construction and manipulation functions for LIST and DICT.

Two other details matter for an embedder. Tokenization is case-insensitive, and there is Unicode support, with a wiki page on using Unicode. Multiple source files can be imported with the IMPORT statement, and the wiki documents module or namespace behaviour.

Memory management is handled by the runtime rather than left to the embedder. The feature list says automatic releasing for referenced values, covering prototype, lambda, referenced user type, list and dictionary, benefited from reference counting and garbage collection, and there is a customizable memory pool so the host application can control allocation.

A Hello World convention in the language is not the usual shape, and it shows the design:

input "What is your name: ", n$

def greeting(a, b)
	return a + " " + b + " by " + n$ + "."
enddef

print greeting("Hello", "world");

There is a named subroutine with arguments, a string variable, and a call with a trailing semicolon. The Quick Reference PDF is what the README points to for the details of how to program in it.

Embedding is five function calls, and the interpreter API is small

The README gives a simple setup, and the shape of it is the important part:

#include "my_basic.h"

int main() {
	struct mb_interpreter_t* bas = NULL;

	mb_init();
	mb_open(&bas);
	mb_load_string(bas, "print 22 / 7;", true);
	mb_run(bas, true);
	mb_close(&bas);
	mb_dispose();

	return 0;
}

The lifecycle is explicit and symmetric. mb_init sets up the global state, mb_open allocates an interpreter instance, mb_load_string parses a source string, mb_run executes it, and then mb_close and mb_dispose tear it down in the matching order. The trailing boolean arguments to mb_load_string and mb_run are the kind of flag the documentation would define, and the README does not spell them out, so the header and the wiki are where to look.

The two file approach is what makes this drop-in. The instructions for combining with existing projects are to copy core/my_basic.c and core/my_basic.h into your project and add them to the build pipeline, and there is a separate wiki page on linking with MY-BASIC as a library for cases where a static link is not what you want.

For someone who wants a scriptable layer in an application they already ship, this is the whole integration surface: one include, five calls, and a documented way to add your own native functions that BASIC code can call.

Prebuilt binaries for three platforms, or build it yourself

For the standalone interpreter, the repository contains precompiled binaries for Windows, macOS and Linux, and the README says the easiest way is to download one to get a direct playground. There is also a web playground linked from the top of the README, which is the fastest way to try the language without touching a toolchain.

To build from source there are three supported routes, one per platform: the Visual Studio solution my_basic.sln for Windows, the Xcode workspace my_basic_mac.xcodeproj for macOS, and the makefile for Linux.

For a platform that is not one of those, the manual instructions are four steps. Retrieve everything under the core and shell folders for a minimum setup, set up your toolchain for compiling and linking, compile core/my_basic.c and shell/main.c while both include core/my_basic.h, then link up an executable.

The standalone binary has three running modes, and they are worth knowing because the third is a pleasant detail. Run it with no arguments and you get the interactive mode, where typing HELP and pressing Enter shows the usages. Pass a file and it loads and runs that BASIC source. Or pass the argument -e followed by an expression, and it evaluates and prints it instantly as a simple calculator, for example -e "22 / 7".

The interactive mode and the calculator mode are what make this usable as a scratchpad, and the fact that the calculator is a documented mode rather than an accident says the author thought about the shell experience.

The project ships a game as a demonstration, and a wiki for the rest

The README points at BASIC8, the Fantasy Computer powered by MY-BASIC, which is on Steam and aimed at game and other program development in an integrated environment, and there is a collection of user creations linked as well.

That is a real usage case for an embeddable interpreter, and it is worth reading as a design constraint. A game scripting language has to be safe to expose to players, small enough to ship inside a binary, and quick enough to run a frame's worth of logic. The 128KB footprint figure and the C core follow from exactly those constraints.

The wiki is where the design detail lives, and the README is honest that the manual does not cover everything. The principles section covers passes, the interpreter workflow diagram and how lambda works. The coding section covers using Unicode, importing another file, modules or namespaces, and subroutines.

The manual is the Quick Reference PDF in the repository root, which the README links for the details of how to program in the language. Between the PDF and the wiki, the actual language specification is documented, and the README itself is the overview.

The main features list ends with more features under development, which is the honest framing for a language at this stage.

One more piece of the picture is the community dimension. The project has a Discord link and a donation page, and the repository carries a HISTORY file, a clean.cmd script and a .github/ directory with a build workflow.

Where a different dialect, or no interpreter at all, is the better answer

The first limitation is dialect ambiguity. my_basic supports both retro and modern BASIC syntax, with the retro GOTO and GOSUB reserved but the structured forms taking precedence. That is a deliberate choice, and it is convenient if you are writing a game scripting layer for people who learned one BASIC or the other. It is a problem if you need a specific standard dialect with a specification other implementations follow, because this is one person's design of what retro and modern should mean, and the two overlap in places a script author has to learn.

The second is the toolchain. The project supports three platforms with committed build files and offers manual instructions for others, but the manual route assumes you can compile two C files and link them, which is fine for a C or C++ host and more work for the other languages the README lists. The embedding examples for Java, Objective-C, Swift and C# are not in the repository listing, so the C core plus the documented API is what you have to work from.

The third is the one that decides it for many teams. A BASIC interpreter in a hosted product is a sandbox, and a sandbox needs a security review, a resource limit policy and a plan for what happens when a user writes an infinite loop. The feature list mentions a debug API and a customizable memory pool, which are the ingredients for control, but the README does not describe a sandboxing or timeout story.

The alternative to weigh is not another BASIC. It is a purpose-built scripting language with a documented security model, or a configuration language evaluated in a restricted environment, or simply exposing an RPC or plugin interface instead of an interpreter. Those give you less language surface to learn and more control over what a script can do, at the cost of the retro familiarity that is my_basic's main appeal.

The honest case for adopting it is narrow and specific: you have an existing C or C++ application, you want to let your users script it, and your users grew up with BASIC. In that case the two file core is a very good fit, and the licensing makes that easy. Outside that case, the language design decisions are an imposition rather than a convenience.

Editorial conclusion

Adopt my_basic if you need to give users of an existing application a scriptable layer, because the two file core and the native to BASIC and BASIC to native calling in both directions are the whole point of the design. Do not adopt it as a general purpose BASIC if you want a mature standard dialect, since it mixes retro and modern syntax deliberately and the language surface is one person's design. Verify first that the target toolchain can compile the two core files, since the project ships separate Visual Studio, Xcode and makefile builds, and read the Quick Reference PDF, because the README points at it as the place where the language details actually live.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. paladin-t/my_basic on GitHub
4. Project website
5. README