Dewy Programming Language
Unknown
About
Dewy is a programming language I have been developing off and on since 2016. It is a general purpose language, designed with engineering applications in mind. Think the functionality and ease of use of matlab or python combined with the speed of a compiled language like C or Rust, but with its own unique flare.
Some key planned features include:
- Functional and Imperative - Dewy is an imperative language with strong support for functional programming. This allows for a very flexible programming style, where you can use the best tool for the job.
- Expression based syntax - Dewy uses an expression based syntax, meaning that everything is an expression. This allows for a very simple yet powerful syntax, where common language features often are just a free consequence of the syntax
- Garbage-collector-free memory management - Dewy uses a unique memory management system, allowing for fast and efficient memory management without the need for a garbage collector.
- Strong type system - Dewy has a powerful static type system with inference, reminiscent of those in Typescript and Julia.
- Built in unit system - Dewy has a built in unit system, allowing you to easily work with units and convert between them. This is especially useful for engineering applications.
- Strong math support - Dewy has strong support many math features, including complex numbers, quaternions, vectors, matrices, and more. This is especially useful for engineering applications.
An example of the common FizzBuzz program implemented in Dewy might look like this:
Or a more functional style implementation might look like this:
For clarity, the variables at each step look like so:
Current Status
Currently I'm working through a simple interpreter for the language (powering the demo above). I've got a tokenizer, a basic interpreter backend, and handling of a few basic types of syntaxes via the parser. But much of the syntax is still unimplemented, hence the long list of "Broken Examples". Thus the current focus is finishing parser support for the rest of the syntax features.
Previously I had been doing a lot of development on bleeding edge parser generators, but that ended up being too big of a time sink for not much visible progress. Instead, for the time being, I ended up just hand rolling a parser in python, which has led to actually runnable code! I'll definitely revisit parser generators in the future when the language is further along.
After the parser is complete, the next steps will be working on compiling to different backends. Initially I was planning to target LLVM as the primary backend, however I recently discovered QBE, which is a much lighter alternative that supposedly gets 70% of the performance of LLVM for only 10% of the code. Longer term I'm interested in supporting a wider range of backend targets, like C, a universal polyglot targeting many scripting languages simultaneously (sh, bash, windows cmd, powershell, javascript, python, etc.), and eventually LLVM too. At some point I'll start building out the standard library, and bootstrapping the compiler to be able to compile itself—at which point we might be ready for a version 0 release!
About the Demo
The demo above was actually pretty complex to put together. The current interpreter is written in python, and this website is statically hosted, which meant the demo required some way to statically run python code without a server. For this, I used Pyodide, which is basically CPython compiled to WebAssembly via Emscripten.
Pyodide itself isn't too difficult to use, except for the fact that it doesn't have good support for asynchronous standard input—it really wants to halt the entire UI while you type input into a stock browser popup prompt. To get around this, I found a handy library where you run pyodide in a web worker, and then any time it wants to read input, the worker makes a synchronous XHR request to a service worker, blocking the pyodide web worker until the service worker receives a response from the main thread with the input, which the service worker can then pass back to the pyodide worker. Suffice it to say, I don't think I ever want to deal with service workers again.
Now that python is handled, the next aspect is getting the Dewy interpreter itself to run. For this, I fetch (at website build time) the source code directly from github. I then abuse the python import lib to allow loading "modules" directly from strings, and then pass all of the dewy source in as string modules. Then I have a little wrapper function for the entry point which receives a dewy source code string, and runs the program. The entry point can then be called from the browser via a javascript wrapper function.
The final piece of the puzzle is the text entry, and terminal emulator. For text input, I'm using the Code Mirror Library with a custom syntax highlighter. For the terminal, I use the xterm.js library. I then hooked up stdin and stdout from pyodide to interact with the terminal, and voila! A Dewy interpreter running in the browser.
There are definitely some rough edges, and the parser only supports a small handful of features, but it runs! It's probably the easiest way to try out the language, and I'm looking forward to getting all of the broken example programs working!
