Introducing Lever Programming Language

The website is already up for the Lever programming language and it is hosted on the same server as this blog. There is still little work left before the features on the front site hold: I haven't made up a good way to customize the grammar and the eventloop is still missing. Going to get those through before I announce the 0.5.0. I do that because it is good enough for trying out things already, and I want to have a track of which version of lever each library is using to maintain translations into newer versions.

Why name it "Lever"?

Common style of room light switches are levers. I want every program written in Lever to have some convenience of a light switch. Specifically I'd like software installs and updates be easy for end-user. It's that one thing that should be provided without greater pain. I want the name to carry that ideal.

At the same thing "Lever" stands for the idea that this language leverages heavily on Python, which is a very well established language. Foremost Python is a great scripting language, but the main reason why I use Python here is the RPython that originated from the PyPy -project. With RPython, I can afford to develop & design & maintain Lever alone. That is. It allows Lever to succeed even if there were only one person using it. Also many updates to RPython will eventually end up to Lever, so maintaining PyPy project maintains Lever.

Overall the name also stands for the philosophy that we want choose the solutions that produce high leverage versus effort put into it. We are tired of coding stuff that does basically nothing. Lever's foreign function interface has been already designed in this way:

FFI

Common way to extend what python is able to do is to wrap a C library into python objects. Many python C wrappings try to "pythonize" such interfaces, so they tend to do lot of idiotic things to achieve it. Lever does it smarter, such that:

Lever FFI API has been carefully thought out to allow direct use of C APIs in a dynamic language. Since relatively simple wrapping is sufficient, I can compile wrappings directly from the C headers with a tiny filtering & renaming script. The wrappings are stored in a declarative format into a format that isn't meant to be modified by human.

Grammar & Syntax

There's a quote that I think Lever fullfills:

"A language that doesn't affect the way you think about programming, is not worth knowing." - Alan Perlis

Lever is the first language that exposes it clearly that the grammar and syntax of the programming language are merely an user interface of the language. Compiling facility in Lever is generic:

This is made possible by the fact that I have a powerful enough Marpa-style parser along the compiler. Btw. The compiler can be written in any language, and it has been written in python because I have avoided bringing up "self-hosting" code for Lever. I want to figure out how "Vanilla" Lever looks before I get onto that. Right now it looks a bit like python, except that some things are bit different. Here's how a hello world will be written:

main = ():
    print("hello")

The default behavior for Lever program is to run the main() -function in the module. This is intended to improve readability of the programs, by letting you orient the code into an order where it would make sense to read.

Runtime differences to Python

The main difference Lever and Python has is in the way operator overloading is done: Python relies on having __add__ and __sub__ -methods inside objects. I've found this a little ugly and felt it makes the operators way too much special functions. It is difficult to introduce new operator-style functions into Python without doing anything that is frowned upon.

Lever does operator overloading with multimethods. Multimethod is just a function that looks up a function from a table depending on what type of objects it gets. To make it fast, multimethods ignores inheritance in types, and inheritance ignores multimethods for types. The user is expected to fare well when he does the same, because together these two concepts can be used to produce very intractable code.

Almost needless to say: The above approach makes it lot more easier to track & explain how the types are implemented in Lever. Otherwise lever strives to have just as customizable and introspectable types as Python has, if not even more so.

Other important details:

A secondary minor difference to Python is that Lever has register based bytecode. JIT causes it to mostly not matter but it provides some difference to compiling and translating code, so we are slightly different there.

Game development

Lever is a generic purpose programming language, but despite the improvements it represents over Python, I think Python will remain being a neat generic programming language. I want to concentrate on domain that Python hasn't traditionally catered much: Game development and audio programming.

I've got tutorials and examples for game development coming. The first sample programs and instructions will come along the first release. Narrowing of the goal hopefully makes it possible for community to form around the language.

Contributions welcome

Despite I can maintain Lever myself, it doesn't mean I must. If you think you'd like to code with Lever, you may also like that it is actually quite easy to make it do new tricks. The learning curve from user of Lever into developer of Lever runtime will never be steep.

I already got to thank the people on the #pypy channel for helping me out. They've been whole bunch of nice folks!

Similar posts