Yeah, it's basically a toolkit for building jitted languages. Basically the easiest way to get a tracing jit these days. So it'll be a self-hosting jit similar to pypy or pixie.
Yeah, it was a difficult decision to remove types - I'd gotten myself into a corner trying to tack on dependent types, and it just wasn't happening. My bet is that unlike most of the un{i,}typed languages out there (most of which I'd categorize as lisps and smalltalks), tulip provides tagging and destructuring that allows the programmer to maintain some level of control over the polymorphism. Tulip will panic at runtime for non-total functions, but ideally you'll have the tools necessary to keep the panic as close to the problem as possible.
Exactly! This is what the @method / @impl system is for - it's about equivalent to clojure's defprotocol. Future plans include named protocols consisting of multiple methods, and protocol-based matching.
Yep, it's my opinion, and that's why I put it into the design. Lots of language design comes from opinions. I hope it's borne out. FWIW it's the same approach Rust has taken, where macros have to end with a ! to make them visually distinct.
Yep! It focuses more on dynamic type-checks than on static typing though, so I put it in the category of "untyped functional" - more like clojure and erlang than haskell or ml.
This is essentially where I'm going with ix. Vim with an awesome haskell-like language underneath whose syntax is optimized for doing powerful stuff in command mode.
I don't know if this can be solved without a syntax change. As long as there is variable binding and variable mutation are conflated in the syntax, there's really no good way for the compiler to distinguish between the two. It's an unfortunate design decision that we may be stuck with if we want back-compat.
LiveScript is interesting, but seems to have Too Many Features for my tastes.