Hacker News new | comments | show | ask | jobs | submit login

For the new compiler, are you sticking with using C as an intermediate language? It seems like not, but if you're planning to support importing C headers...

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?

I’m probably not writing another C backend. There is a convenient C parsing library for Haskell (language-c) that should let the compiler get all the information it needs from headers.

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.

Heh. Will you eventually ditch Haskell and go self-hosting?

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. :)

Yes, in fact I’ve tried to write the compiler in a style that should make it easier to port from Haskell to Kitten someday. But in my opinion it doesn’t make sense to bootstrap pre-1.0.

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

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact