A programming language for parallel computing

I’ve started poking around at connecting Radian to LLVM. The current backend translates the flowgraph to a linear intermediate code, then translates the LIC instructions to C source code, then passes that through gcc to get machine code. I’m not sure whether to leave the LIC pass in place, then convert to LLVM instead of C source code, or to emit LLVM IR from Radian’s data flow graph. The significant semantic difference is that LLVM IR includes type information, which is implicit in LIC.

While I think about this, I’m playing around with using Church encoding for booleans. Instead of including a “boolean” data type with two predefined values which represent true and false, then implementing a “branch” operation which chooses between two values based on a boolean value, true and false themselves become the implementation of the branching operation. It’s as though they were defined like this:

If you have a reference to one of these functions, you can use the function itself to perform the branch: you just call the boolean value, passing in the option you want to use for “true” and the option you want to use for “false”, and it returns the one that matches the boolean’s value.

This wouldn’t be appropriate in every language, but in a functional language like Radian the only thing you can do with a boolean value is to select which of two expressions you want to use. It makes sense to do away with the custom “branch” instruction and just use function invocation.

I have a simple Hello World running now, and that means it is probably time to abandon my temporary C-source-code backend and start using LLVM. I’ve finished as much of the front-end language support as I’ll need for now, and it’s probably time to shift my focus toward the runtime environment. I need to build an IO interface, a garbage collector, and the core function library; using C as an intermediate step is just a hindrance here.

It is also possible to create a patch file with git which you can send via email. I am thinking about setting up an auto-build-verify system that checks a dedicated email inbox, downloads patch files, builds them on a temporary branch, runs a validation suite, and either pushes the changes up to another repository or sends back an email describing the errors that occurred.

We were working toward a system like that just before I left Real Software, using Buildbot. It was a big improvement over the ad-hoc practices we’d always used before, but it was still a reactive notifier rather than an active filter. You checked in code first, then the buildbot would run its tests to see whether you broke anything. It was much better than hearing about it from one’s irritated colleagues a day or two later, but still too fragile.

It was much harder to break the build at Microsoft, where no change could be committed until it included a new test suite and had been shown to pass every existing test. This was unfortunately a completely manual process and thus extremely time-consuming, but it did create an unusual degree of confidence in the checkins, when they finally did happen.

Grunt work is a waste of human time: that’s what robots are for. I want to send my code off to the build system whenever I think it’s ready, let it do the repetitive validation, and then either pass the code on to the development trunk or let me know what went wrong. If I screw up, I’ll have a chance to fix it before I waste anyone else’s time dealing with the problem, and I’ll know that code I pull from the trunk will always work as far as the test suite is concerned.

I’ve built a simple object system, with member dispatch, inheritance, instance variables, and parameterized constructors. There are no mutator methods yet (all methods are “const”, in C++ terms), but it should be enough to build a primitive console-IO module. I expect I will have a working “Hello world” by the end of the month.