Where Is James?
I've been distracted lately while other things have been happening, and I haven't had much time to comment on them. Here's a bit of catching up...
Apparently, my Future Without IPv6 rant got picked up at Reddit.com, and it prompted some unexpected discussion around the web (you can find it yourself). Much it is the predictable combination of denial and magickal thinking that goes with the territory, but some of it is thought provoking. One of the more interesting responses came in the email from the author of RFC 1669. My reply: "Yep, you sure called it." I wish I had time to offer a more cogent reply to the contributors who had interesting things to say at Reddit, but like I said: distracted. Maybe next weekend.
This weekend, I'm up to my eyeballs in non-techie things. The bottles for the next batch of Tumultuous Uproar Imperial Stout are currently sanitizing in the oven. There's a batch of Six Dæmon that needs to be racked as soon as the stout comes out of its carboy. Also, it's finally time to pitch the blackberries into the lambic I started over two years ago. (Yes, folks: that bump in the pellicle is not a scary fungal growth on the top of my beer; it's the hygrometer I left in the wort, and which is now completely unreadable.)
After that, I hope I'll be able to finish the penultimate chapter in the second draft of my dumb fantasy novel. I put it aside a few weeks ago, and I'm starting to get antsy about not having done anything with it.
On the techie side of things, I recently got a bug report that my OCaml Network Application Environment code that ships in Debian is failing their build. It doesn't compile on the latest version of OCaml. The code in CVS does, but I haven't packaged up a release yet. Gotta do that soon.
The other big technology thing that has me distracted right now is LLVM. It turns out there are pretty good OCaml bindings for language front-ends that target LLVM, so I'm now excited by the possibility that lowly imbeciles like me could be authors of useful programming languages that compile down to fast, tight machine code for a wide variety of processor architectures. The LLVM people have done all the really scary heavy lifting by taking the difficulty of writing a back-end out of the process of writing a new language. With OCaml for a development tool, even a blithering moron like me can write a front-end for a new language, so that's what I'm playing with these days.
Why does James want a new language? I can hear you asking.
After learning OCaml, Haskell, Scheme, Objective-C, C++, Perl5, Python (not in that order), it really fricking pains me that I still have to use C89 as a programming language. I write embedded software for a living. Stuff that runs inside the kernel is high-level code for me. In the kernel, you've got all kinds of operating system services available: threads, dynamic storage, etc. You can sorta get away with arguments to the effect that "a tasteful subset of C++" is appropriate for code that runs in the kernel, but they start breaking down in embedded development environments where you're really constrained on code size. Most embedded software developers just laugh out loud when you tell them that you're serious: they should have written that in Python.
I want a language with the following properties (listed in order of descending importance):
- Suitable for embedded systems development. "Can I write a microkernel with it?"
- Accurate garbage collection of the dynamic store is available, but optional.
- Safe pointers, à la Cyclone.
- A Hindley-Milner type inference engine.
- Language front-end knows all the semantics, so error messages are sensible, i.e. no text preprocessor.
- Some additional hackery to make interfaces with build systems not have to suck so much. (More on that later.)
- Built-ins for concurrency, à la JoCaml or Concurrent Haskell. (Cyclone fails here.)
- Syntax that doesn't make me want to claw my eyes out while I'm reading my own code. (Cyclone fails badly here.)
I've got a tiny little bit of the language implemented at this point, i.e. basically just some of the constant expression evaluations and a portion of the abstract syntax tree construction for the primitive types. I'm a long way off from even opening the LLVM modules.
One of the things I'm doing that doesn't seem like the usual approach used by more experienced language designers (I'm curious to know why) is that I'm focusing early on making the error messages and warning produced by my compiler as useful and descriptive as possible. (I'm taking a cue from the Clang developers here.)
For example, here's a little snippet of test code in my crazy language that I'm currently using:
(#--- This is a test ---#)
static w a := 64 / a
static g := 32packet v a b := a array[w b]
packet b := word 8
packet p z i := b sign -zvma z array[i] sign -o
packet r := v [form [k :: word g, n :: b array[w 128]]] 2##| STATIC EXPRESSION TYPE ERROR
static k := w ()##|-- End of file
This code is supposed to assign the static variable 'k' the result of applying the void literal to the static function 'w' (defined near the top of the program). Don't get too excited about the syntax here— that's highly subject to change this early in the game.
Here's the error message my compiler produces for the source code above:
test.pi0:2:15-20: error: static binary operator '/' types mismatch...
static w a := 64 / a
^^^^^^
test.pi0:11:13-16: ...evaluated here:
static k := w ()
^^^^
Already, this is better than most of the supposedly mature tools I'm using in my professional work today. Why don't language designers focus on getting the diagnostic messages right in the first go around? I don't understand.
Anyway, yes I know this syntax makes you want to claw your eyes out. That's your problem. It makes sense to me. In fact, the way I would characterize the nature of this project I'm playing with is that I'm trying to define the intermediate language that currently only exists in my head, from which all the code I have to write professionally these days has to be translated into C89 before it will run.
One of the amusing things about this project, of course, is that LLVM has a C-language back end. In practical terms, this means that I can write my code in my own language, have the compiler spit out LLVM bitcode, pipe that into the LLVM compiler with the -arch=c flag, and get shiny C-language source code that does what I want. Maybe not the most readable C language source code... but, then, have you seen my hand-coded C lately?
My Groups
-
Amnesty International Updated: 3 hours ago
-
Writers Hub Updated: 3 days ago
Neighborhood
Explore friends, family, friends & family, or entire neighborhood.
