~oconnor0/zinc

the zinc systems programming language

6d58fce chess: dragon, flower, owl, etc.

15 hours ago

0d6e7d4 chess: dragon, flower, etc.

15 hours ago

#Zinc, a systems programming language prototype

Zinc is my attempt at a low-level systems programming language prototype. I found this parser, called Owl mirrored here, that generates parsers for visibly pushdown languages. Visibly pushdown languages are those where recursion to other grammar productions must be guarded by tokens which can only be used for that purpose. While somewhat limiting, this ends up meaning that all grammar productions that can "contain" other productions are wrapped in certain tokens and so the language is visually easier to parse. And it runs in linear time.

mut i = 0
def n = 10
while 0 <= i < n {
    def x = call rndi()
    if i = 0 {
        ; verify that the fixed seed rng is working as expected
        assert "rndi() = 13109595": x = 13109595
    }
    call puti(x)
    call putc(10)
    set i = i + 1
}
return i

#Features!

  1. All statements start with a keyword, except for blocks with start and end with curly braces.
  2. Range conditionals like you used in math: 0 <= i < 100
  3. Builtin assert syntax - that's included in all compliation modes. Make sure things are what you expect them to be.
  4. Add new functions by defining them in the lib/prelude.h.
  5. if and while statements don't need parentheses around their conditional.
  6. Mutable variables and immutable bindings.
  7. Semicolons used to comment out the rest of the line.
  8. The language splits side-effects from non-side-effecting code. Or rather would once functions and subroutines are implemented. Subroutines can have side-effects, functions cannot. Expressions can only apply functions, not call subroutines. It's like Haskell but better.
  9. No package manager to distract you.
  10. Simple type system. Currently, a unityped language - everything is an int - except for the optional assert message.
  11. No need to write functions. Top-level code in a .zn is executed when the file is included.
  12. No package/file/module imports yet. I had some idea about compiling each file to a struct, but whether there was one of them or multiple of them was undecided. And there's always the issue of what to do about side-effects on module load.
  13. No nil. No pointers or references either. I wondered how far I could get with this model, maybe using arrays or structs or arenas or static allocations or something.

#Status

While I dreamed of integrating it with some 2D graphics or tile engine and playing around with old-school game dev, I ran into a few limitations with its design. Like how cool would it be to write a clone of Raptor: Call of the Shadows in a language I wrote?

I intended to write it as a single-pass compiler directly from the syntax tree and targeting C via TCC to enable it to run quickly and on any platform. Unfortunately I also designed a language with top-level execution and nested functions - neither of which I could come up with a good compilation model for if I wanted to preserve the single-pass, no AST, no IR design of the compiler. It's certainly possible there is a model, but my musings couldn't figure it out.

The reality is too that I've been a programmer in GC languages my entire career (if you ignore the 5 years I did C++ and Verilog) and that's where my mind resides so writing a low-level limited language was, well, limiting.

#Older Notes

#Goals

  • Cross-platform - don't have to install Unix to get compiles on Windows to work. Don't depend on platform-specific tools.
    • Cross-compiling - compile to other targets - OS and architecture - easily.
  • Single executable (optionally) with compiler, assembler, linker.
  • Can run without an OS.
  • Standard library is optional, but large-ish.
  • Core library is dynamic allocation free.
  • Low-level and easier, for me, to program in than C.
  • No magic - implicit casts, lots of optimizations for zero cost abstractions.
  • Prioritize simplicity - compiler or developer though?
  • To be a language I want to write in.
  • To be the implementation language for an application and a scripting programming language to come later.
  • Reasonable C interop, and probably, initial compilation to C.
  • Package system, should one develop, doesn't support transitive dependencies.
  • To eventually support a simple, cross-platform graphics.h or MODE 13h style graphics library.
  • To include a console.h/TUI style library.
  • Inline assembler.
  • Small and clean and sane language.
  • Some kind of module system.
  • Arbitrary, or principled, restrictions.
  • Builtin SIMD?

#Non-goals

  • Garbage collection.
  • To be useful to anyone.
  • Complete memory safety, I think.
  • Advanced optimizations.

#Open questions

  • How do modules and types interact?
  • How are runtime and compile time separated? How do they interact?
  • Where does polymorphism fit in? Parametric? Monomorphization?
  • What is the relationship between statements and expressions?

#Inspiration

What you are I once was. What I am you will become.