Progress is slow so far as I haven’t found a reliable way to fit regular work on Braid into my schedule. Building the apps that make the money is taking priority for now.
This weekend I finished parsing support for Algebraic Data Types (ADTs), both for definitions and for creating new literal instances. Record types map directly to Go’s structs, which is nice and easy, but sum types will require a more complicated combination of structs and interfaces to implement. At the moment these cannot be compiled properly unless they only use concrete types. The typical Option/Maybe type is not yet supported, as the Braid compiler lacks the means to determine which concrete versions it needs to generate based on where the type is used.
My goal for Braid’s syntax has been to try and build something practical, so if not familiar at first glance, then easy to pick up. Part of this, inspired by the same impending changes in Reason’s syntax, is to think about changing function application to use parentheses — you know, the way every C-style language works. So instead of:
List.add  2 3
List.add(, 2, 3)
This is more familiar to programmers with a background in imperative languages, and easier (at least for those folks) to parse. The downside is that it’s now less obvious how currying would work, if it all. Given I haven’t actually decided if I’ll support currying, maybe that’s okay.
The other point this brings up is that I’m building a language that borrows a lot of ML concepts like ADTs and pattern matching, using familiar C-style syntax, and probably not supporting currying… That sounds quite similar to a certain other Rust-y language. Am I just building Rust-lite? I’ve given this a bit of thought, and although I don’t want to build something that’s going to be seen solely as an inferior derivative, I think the answer is, “maybe, but that’s okay”.