Note: This is an old file, and old repository. To see the new repository, go to http://github.com/cheery/lever
This is left intact here for the reason that it is often not very nice to remove an URL from the internet.
Sometimes I tend to search better ways to write and design computer programs. I like to do that kind of things when I reach the next software-induced frustration of the week. I tend to be frustrated a lot over software. Pyllisp is the manifestation of that search.
I've realised it has reached a point that it presents some worthwhile ideas into language design. I wrote this README to funnel people into discovering these ideas.
Pyllisp resembles python or javascript by its overall structure. It does couple things different, of course:
- Leverages of RPython toolchain for rapid programming language development. Design choices can be tried in a functioning system with lower cost, allowing broader search in design space.
- Foreign Function Interface which automatically fetches header definitions from a json -formatted file. The files can be autogenerated from C headers with short scripts. The interface is convenient enough with a purpose to reduce the needs for implementing wrappers around C libraries.
- Bytecode format inspired by SPIR-V. The format is entirely table-driven to allow large changes into the bytecode and make it easier to optimize and translate the bytecode.
- Coroutines provided by RPython toolchain. Considered mandatory in the base interpreter for annihilating callback pyramids of doom.
- Multimethods with fixed arity. Incompatible with inheritance for the purpose to allow efficient implementation. When dispatch is not found in a table, it is driven into a default dispatch method, which may do the resolution with a coercion multimethod. Allows operators to be defined as functions. Avoids gang of four pattern because it makes the methods too special.
- Customizable grammars that can be shared between compiler modules. Made possible by a parsing kernel that copies concepts from the marpa parsing engine. Makes it trivial to design auxiliary notation for legibility.
Download the repository contents here, run the ./setup.py -script while you're still online. It verifies that you've got all the packages to make it worth to try running or compiling the program. If you're a hobbyist, you probably have an old machine to spare for ubuntu, or debian, or some other linux distribution. On ubuntu and debian, the ./setup.py will automatically prompt for downloading the missing packages from the apt repository.
If you like to compile the JIT binary, ./setup.py compile will compile the binary immediately after verifying that it can do that without errors. The error checking of setup.py covers only the obvious missing of packages. It doesn't check for package versions or architecture mismatch.
Once you've run the ./setup.py, you can run the ./run.py sample to test it out. If it works it runs the commands in the sample -file. If you do changes into the runtime, you may try out the changes without compiling by supplying -i -flag to the ./run.py.
If you got excited about something you tried out with pyllisp, you may be interested in forking the project. When you do it via github it will inform me of the forks. I may merge in contributions that increase the quality of the project.
I'm changing things here, and I occassionally change them a lot.
I remember being frustrated at something when picking the license. My choice of license, when frustrated, is GPLv3. But I don't think it matters that much because if you buy an interpreter you should get its source anyway.
I'm slightly unsure about the choice of license. It's because of the benefits RPython gives in interpreter design. RPython has been MIT licensed. I might follow that license for just the appreciation of effort put into RPython toolchain.