The site is pretty far out of date—it describes an older version of the language/compiler, so it’s better to check out the GitHub repo. I figure I’ll send a pre-release announcement to all the stargazers, when the time is right.
One of my new year’s resolutions is to work on Kitten every week this year, and release it before the end of the year. I’m also working on a short ebook (“Programming with Kitten”) to serve as the standard tutorial.
I could really use help with all this—building and marketing a language is no small task. If you’re interested in contributing, even if you’re not familiar with Haskell or compilers, I’d be glad to help you get involved. :)
You might also give Gforth a try. https://www.gnu.org/software/gforth/
That sounds like a gross exaggeration: https://hookrace.net/blog/nim-binary-size/
The sizes in the link you submitted are very small and rational (what I was expecting to see). I can't remember what it does on Windows without GCC. It might have used Cygwin, but it should have still not been orders of magnitude bigger. This turned me off immediately.
I remember reading somewhere that Haskell is particularly suited for building compilers. I use Elm at work which is another wonderful language written in Haskell. Has that been your experience ? curious what makes is so great. Any recommendations on resources to learn compiler building in haskell ?
I don’t have any particular recommendations. Mostly I’ve just been figuring things out as I go along, reading papers and asking for help. I’d written compilers & interpreters before, but got into using Haskell for it with Write Yourself a Scheme. I’ve also heard good things about Implementing a JIT Compiled Language with Haskell and LLVM.
I'm curious about how it compares to Joy, is it also homoiconic?
I'm also curious about how you implement the ffi to C.
I might try to contribute :)
In the old compiler, there was no FFI. In the new compiler, codegen isn’t done yet, but the Kitten ABI on x86-64 is similar enough to the System V ABI that you can just save some registers and do a regular call. As for the front-end, it’s been a long-standing goal to allow a programmer to just import C headers, rather than write or generate a bunch of tedious FFI declarations; I have a prototype implementation of this.
If you’re interested, shoot me an email (username@gmail) and we can find something for you to work on. There are many different things to do: adding features, improving error messages, polishing the interactive environment, writing tests and documentation, integrating with editors, you name it.
If not, and you're emitting x64 object code, will you support the stack frame pointer (needed for DTrace and similar tools)? Will the ABI be similar enough that I could use a debugger on a core file (I'm assuming the absence of DWARF)?
And what are your plans with hardware threads?
It will support frame pointers, but they might be a bit less useful than when debugging C, because Kitten guarantees tail-call optimisation. The ABI is fairly similar (not fully worked out yet), just a couple of register differences to separate the data stack from the call stack.
I’m still working out Kitten’s story for concurrency and parallelism. You’ll be able to easily spin up an OS thread if you want one, but I expect most code to use other approaches, like a green-thread library.
In any case, I'm happy to hear Kitten will be usable with DTrace and gdb/lldb, even with some caveats! Too few languages nowadays support dynamic analysis or post-mortem, which dramatically reduce their usefulness for industry. :)
I agree that binary debugging support is a must. I’m trying generally to make the language a “good citizen” when it comes to interop—we’ll see how it turns out. :P
Completely tangential: how do you send a message to all stargazers?
please don't, IMHO that is too spammy.
(But it is a good point, why does Github have no "get notified of releases" level of watching?)