a fast, low-level, and expressive programming language designed for minimal usage of hierarchy
snowflake, the language, originally started as a collection of ideas to improve programming that somewhat resembled a mashup of go and rust (more heavily influenced by go at the time, but with the lower-level-ness of rust and some additional features superwhiskers, the author, thought would be nice to have in go).
further on in conceptualization, it gradually shifted to be more and more rust-like, until the point where it became rust but with a few tweaks such as the removal of ownership to allow for fully manual memory management by default, and other extensions (that in hindsight wouldn't make sense to create what was essentially a fork to implement).
eventually, it shifted to become more like lisp (retaining strong typing and manually managed memory) and had some things, such as most types and other unnecessary (in superwhiskers' opinion) language items/features stripped out to make a really portable language. in addition, macros were buffed to add in an all-powerful file-wide macro kind that could be used to implement alternative syntaxes on top of a lispy syntax to allow people to use the language the way they wanted
later on, methods were removed (as seen above) and tagging was created/discovered/applied to the language. this discovery heavily influenced the language later on, as even though superwhiskers was hesitant to apply it everywhere at first, it gradually made its way in, creating the language you see today
more recently, the lispy syntax was outright removed to simplify the parser and make it easier to implement, but alternative syntaxes are not completely gone, as they are now intended to be done using plugins. however, technically speaking, the current ml-like syntax you see now has existed since the lispy one, as it was intended to be the "default syntax", used in most cases as it would be drastically easier to work with (typed lisps are a pain).
snowflake is a language designed from the start to be low level. ideally, it should take very little to port snowflake to a new platform than c (due to very little types existing in the language itself and because it assumes very little about the underlying platform). aside from that, other goals/features include (but are not limited to):
- non-hierarchical programming (in both module system and type system)
- speed (due to the expressiveness of macros and such + optimizations + low-level-ness, one can get more performance out of equivalent code in other languages without needing to rely on the implementation)
- a primarily functional programming style (without sacrificing speed)
- clean, easy to read syntax that should be familiar to users of other functional languages
tagging is essentially applied set theory; it is based entirely upon single-layer collections of objects that can have operations applied to them in order to construct new tags. these operations can be listed as such:
- intersection, which returns a tag containing all of the common items between the operands
- union, which returns a tag containing all of the items in both sets regardless of presence
- difference, which returns a tag containing the items in the first set minus the ones that exist in the second
- symmetric difference/xor, which returns all of the items not in both sets
aside from that, snowflake tweaks the set theory model to create two kinds of tags: primary and secondary tags. primary tags are just mathematical sets, and secondary tags are mathematical sets without a uniqueness restriction. there is also one more change, the sets exclusively contain name-value bindings (like a map/key-value store/whatever) and primary tags only need to be unique on the name
if you don't understand this, you can visualize it like how set theory is taught really early on in grade school: as a venn diagram, where intersections are the overlapping parts of components, unions are two components combined, etc...
the snowflake event system is a portion of the standard library that is designed to cleanly abstract over additional concurrency systems as well as provide a model for how to implement concurrency in a potential "snowflake os"
it loosely works like this
- program has a central definition of event datatypes and the event handlers that take them
- program starts with a "genesis" event
- event handlers respond to this
- event handlers then emit new events (yes, they can emit multiple) (they can also emit nothing and those chains die)
- new event handlers respond to those
- the cycle continues
the idea behind it is that events are decoupled from their handlers and this would provide a more modular means of concurrency. it also avoids "coloring" functions because all handlers can be called like normal functions and can have their outputs chained to successive handlers in that chain of events.
- implement a parser from scratch to improve error messages and make it less hacky
- redo the interpreter to actually typecheck, then make it compile to bytecode for better performance
- add in tag typing (tagging applied to compound types)
- add in macros
- consider implementing dependent typing around this time (go down to literature to see some references/examples of what we're looking at)
- consider implementing algebraic effects
- look at adding in a distinction between purity / impurity & safe / unsafe, potentially done without a language feature using algebraic effects
- implement a compiler backend using qbe (see literature)
- polish more of the core language, smoothing out rough edges and taking feedback
- add a minimal standard library + core library and polish things
- implement the event system
- selfhost and implement llvm post-selfhosting as well as port existing things depending on the rust impl
- attempt to implement a jit
- write a package manager
def main =>
*println "hello, world"
(there isn't much else that isn't likely to change)