After a long ride of changing syntax and complete rewrites, a beginning version of the Snowflake programming language is finally going to reach the surface!
snowflake
a fast, low-level, and expressive programming language designed for minimal usage of hierarchy
a brief history
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).
the language itself
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
an explaination of tagging
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 event system
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.
a roadmap
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
(there isn't much else that isn't likely to change)
Closing
While the prototype we have here is quite rough and incomplete, I hope you can see the value in the unique ideas Snowflake represents, and that with some more time, this language could grow into something remarkably different from anything seen before.
More about the language itself can be read in the readme, and while repl.it can't build a binary because it doesn't have enough memory, there is a linux binary provided in the release/ directory.
You can find the repl here and the github repository here.
It seems like Snowflake is easily one of the most unique languages that have come out of this jam, well... I guess the ideas didn't originate during the jam, but whatever.
After a long ride of changing syntax and complete rewrites, a beginning version of the Snowflake programming language is finally going to reach the surface!
snowflake
a fast, low-level, and expressive programming language designed for minimal usage of hierarchy
a brief history
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).
the language itself
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):
more performance out of equivalent code in other languages without needing to rely on the
implementation)
an explaination of tagging
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:
in the second
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 event system
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
those chains die)
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.
a roadmap
performance
see some references/examples of what we're looking at)
without a language feature using algebraic effects
rust impl
literature
compiler backends
dependent typing
examples
hello world
(there isn't much else that isn't likely to change)
Closing
While the prototype we have here is quite rough and incomplete, I hope you can see the value in the unique ideas Snowflake represents, and that with some more time, this language could grow into something remarkably different from anything seen before.
More about the language itself can be read in the readme, and while repl.it can't build a binary because it doesn't have enough memory, there is a linux binary provided in the
release/
directory.You can find the repl here and the github repository here.
Some other links are:
Thank you for reading! Have a great evening!
It seems like Snowflake is easily one of the most unique languages that have come out of this jam, well... I guess the ideas didn't originate during the jam, but whatever.