4 ms·

I wouldn’t call it homoiconic, but I’m working on a macro system which will let you manipulate terms as regular data structures at compile time. That was an ear

I wouldn’t call it homoiconic, but I’m working on a macro system which will let you manipulate terms as regular data structures at compile time. That was an early insight about Kitten—things are much easier to statically type if you differentiate data from code, and you can recover a lot of the flexibility with other approaches to metaprogramming. 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.

dmpk2k 10y ago
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?
- evincarofautumn 10y ago
  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.
  - dmpk2k 10y ago
    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. :)
    - evincarofautumn 10y ago
      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

dmpk2k 10y ago

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?

evincarofautumn 10y ago
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.
- dmpk2k 10y ago
  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. :)
  - evincarofautumn 10y ago
    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