Hacker News Reader

Comment by evincarofautumn | Hacker News Reader

Author of Kitten here, happy to answer any questions.

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[1]. 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. :)

[1]: https://github.com/evincarofautumn/kitten

View on HN

Thanks for jumping on this (I submitted it after reading it on Reddit awhile back). I like the concept of Forth, but getting started is daunting and JonesForth just isn't enough. Kitten does seem pretty neat for sure and it probably wouldn't be too hard to get into like Haskell and Forth are. I'd love to use a lightweight stack/functional/imperative language if it compiles to native code and is fairly fast. Would it be possible to build someone an .exe or binary and have them run it without any runtime?

Thanks! Codegen isn’t done in the new compiler, but yes, the goal is to compile to native, statically linked executables, much like Go does. Ideally we wouldn’t even incur a libc dependency, but malloc is just so damn convenient.

You might also give Gforth a try. https://www.gnu.org/software/gforth/

Good to know. I think a small dependency is fine. There are precious few languages that allow a static binary. I wonder what the size would be though. HelloWorld in Nim is ~10 MB, although there may be an optimization setting I skipped. GForth can't make standalone executables though and doesn't have good beginner information either. I'm also under the impression that Forth shines best as a special purpose implementation for that particular project (how Chuck Moore does it). Not sure if Kitten works better as a general purpose language or not yet, but i like the concepts so far.

> HelloWorld in Nim is ~10 MB

That sounds like a gross exaggeration: https://hookrace.net/blog/nim-binary-size/

I downloaded Nim last year, wrote the line: echo "Hello World" , and then used the Aporia IDE's feature to compile to executable I believe. That or the command-line method. This was on Windows and the resulting exeutable was indeed sized around 10 MB. I did state that there could have been more optimizations like a release mode flag.

Edit:

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.

The reason you saw that is because the default compilation includes lots of debug info.

9.95 MB worth? Dang that is a lot of info. Glad to see they can be made to be really small.

You could do what the Spitbol compiler (for the SNOBOL language) does, which is to statically link against musl libc.

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

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 ?

Yeah, I’ve found Haskell a pleasure to work with for writing compilers. There’s no single thing, just a combination of language features and libraries. The bulk of a compiler is transforming trees of stuff, which Haskell makes very easy, and it nudges you pretty strongly in the direction of making code testable and refactorable.

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[1]. I’ve also heard good things about Implementing a JIT Compiled Language with Haskell and LLVM[2].

[1]: https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...

[2]: http://www.stephendiehl.com/llvm/

Y'all might find it interesting that the first attempt at a Perl6 implementation was done in Haskell and was considered vitally important.

Pugs was, by my count, the third or fourth attempt. I can think of at least two in the Parrot repository long before Pugs was a thing, and I believe one of those had a fork/rewrite before 2005.

Lol thanks Chromatic. Always good to get corrected by someone who was there and actually knows. Thanks for your work!

Great project! I've been thinking a lot about concatenive languages lately. I haven't had the time to run it or look at the compiler code, I'll do it tomorrow.

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

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.

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

> I figure I’ll send a pre-release announcement to all the stargazers, when the time is right.

Completely tangential: how do you send a message to all stargazers?

Using the GitHub API, you can get the list of stargazers for a repo, then get the public email (if any) from each of their profiles.

If the number of stargazers was relatively low, you could @mention everyone in an issue.

> I’ll send a pre-release announcement to all the 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?)

I know it’s not ideal, but I can’t think of a better way to directly reach people that have expressed interest. Nim did the same thing, and I’m happy to get the occasional direct update from them. Obviously I’d have to include an “unsubscribe” link or whatever.

Reply on news.ycombinator.com