4 posts tagged “programming language”

Yet Another Systems Programming Language

Nov 12, 2009
Post a comment

I haven't posted much here lately because I've been consumed with a programming hobby project that has taken up almost all of my discretionary time. (I haven't been writing any fiction, mostly because I don't have any ideas I like as much as I liked Arts Of The Wize, which hasn't gotten any more publishable since I stopped fussing with it. I don't write here about personal and family matters. I've got other places to do that. And the programming project isn't in a place yet where it makes much sense to talk about it.)

As some of you know, I'm interested in the basic problem of designing a better systems programming language, and if you've been following the computer science news lately (as everyone does, naturally), then you know about the latest in a long series of high-profile efforts to displace the venerable C language from its position at the top of the popularity charts for systems programming languages, i.e. Google's new Go language. Mark Chu-Carroll wrote up what I think looks like a pretty fair review here.

There are thousands of computer programming languages, but there's a very long, thin tail there. There are plenty of good systems programming languages kicking around that don't get much attention from the overwhelming majority of working practitioners. Some of the ones that come to mind as candidates for replacing C (and its close cousins, C++ and Objective-C) include D, ooc, Vala, and Cyclone (my favorite from this list).

New languages typically don't achieve noteworthy popularity without major institutional backing, and it remains to be seen how much energy Google will devote to promoting Go as an alternative to C for systems programming. Go has some interesting features and some well-regarded practitioners driving its design and implementation. At first glance, however, it looks like they made some strategic decisions to sacrifice some semantic flexibility in exchange for syntactical elegance, e.g. no parametric polymorphism, no isorecursive algebraic data types, etc.

This strikes me as the typical result of language designers who are primarily motivated by syntactical considerations. What separates my [unnamed and undisclosed] hobby project from the efforts mentioned above (with the exception of Cyclone) is that my principle concerns are with the other two branches of semiotics: semantics and pragmatics.

First and foremost, I think any attempt to displace C from its position as the language mindshare leader among systems programmers has to start by considering how to improve the semantic flexibility of the programming language without sacrificing the pragmatic utility that makes C the premier language in which to write an interrupt handler. That's a really tough problem, as the arguably negative example of C++ shows, and I think that with a workable solution to that problem in hand, the task of designing an appropriate syntax for the language is comparatively trivial.

So, that's what I'm working on in my copious spare time. I'm hard at work building the intermediate language for a front end to LLVM that I hope will make a better systems programming language than C or C++. Yes, I'm attacking the same problem that a lot of others, who have much more impressive CV's than me, have tried or are trying to solve. I think I have an idea that will distinguish itself when I'm done messing with it.

My biggest competitor is not Go or D or any of those other languages I mentioned above. If I have any worries about another language mooting my work before too long, it's Glasgow Haskell.

I Hate The C Language Family

Jul 8, 2008
2 comments

This is the fifth time today my build has failed because I forgot that stupid semicolon these languages require for statement terminators.

More Things I've Learned About Compiler Design

Jun 28, 2008
Post a comment

When your language allows the programmer to specify the precedence of operators, you're going to have a hard time parsing it with a grammar accepted by Yacc. That's because Yacc produces LALR(1) parsers, and that isn't going to work for you. Fortunately, for my current project, I have a really nice module of parsing combinators in my OCaml NAE Core Foundation that can produce LL(x) parsers. What's so nice about it? I can still use a static lexer with it, and I've got a nice lexical analyzer already. (It supports layout boxes like the ones planned for Haskell', which is the first reasonable model for whitespace sensitive syntax I've ever seen.)

So— what do you know? It turns out all that fiddling around wasn't necessarily a complete waste of time.

Things I've Learned About Compiler Design...

Jun 6, 2008
2 comments

..trying to implement my own crazy programming language. (See my previous post. For the language geeks who might be reading, I'm envisioning a strict functional language with strong types and a concurrency regime like Occam-π, Pict or JoCaml. I have a crazy scheme in mind for limiting side-effects that I'm interested to find whether it works.)

The obvious place to start turned out to be the wrong place. I started by writing a parser for the basic syntax and producing an abstract syntax tree. That was the easy part. I now understand how travesties come to pass like the one that made Squirrelfish necessary. If you start by writing the parser for your AST, and you don't lay the groundwork first for a type system and the compiler, then you end up finding the shortest path to a functioning language is to write a cheap, stupid interpreter for the AST.

That's how Javascript happened, I'm pretty certain now. The horror.

I put my parser and AST aside. Now, I'm looking at designing the type checker. That, I'm pretty sure is the hard part of implementing a new language design. Fortunately, my type system is very similar to the ones you find in Haskell and ML, so it's not like I'm inventing a whole new theory. I just want to mix a couple of existing theories into a new form. That's all.

More when I know it...