Constraint languages are a complete subfamily of very useful programming languages: Instead of specifying what to do, step by step, you specify the relationships you wish to have maintained, and the code gets cranked out for you.
The make program might be the most familiar example
to Linux programmers: Just specify the dependencies between
programs in a Makefile and it takes care of the messy
details of updating files in correct order for you.
Dynamic persistent systems like Muq are great platforms for implementing and applying such languages, since they are both full of complex datastructures with important relationships we would like maintained, and also make it easy to dynamically compile and execute appropriate code on the fly. (I'm thinking in particular of Alan Borning's Smalltalk-based ThingLab.)
For example, as soon as we have dynamic 3D worlds in Muq, we'll have lots of demand for a system which automatically generates code to update their positions properly, starting from an abstract description of the forces and constraints acting upon them.
Another fun little project which very likely will never rise to the top of my programming project list!
A compiler for the usual knobs-and-tubes grapical programming notation used by systems like the previously-mentioned AVS would be fun and not too difficult. The paradigm is a graphical instantiation of dataflow computing where one has data sources (microphones, cameras, user-controlled widgets...), data sinks (3D rendering windows, bargraph widgets &tc &tc) and a variety of transformation operators on datastreams (think of all the GIMP operators, say): The user programs "Without programming!!" by dragging and dropping appropriate icons on a canvas and then wiring them together with the mouse. Changes at any source are them automatically reflected at the appropriate sinks: Unidirectional contraint programming. Given completion of some of the other projects listed in this section as support, this could be a quite enjoyable and easy project. I never wind up being the one to do the fun projects, so I presume someone else will get to do this one...
A more pressing, project is implementing rpm-style package
management for Muq dbfiles: To maintain db sanity, we sooner rather than
later need to have dbfiles specify what other dbfiles they need for
correct operation, what dbfiles they conflict with, and so forth. This
isn't very complex stuff, and both RedHat's rpm and Debian's
dpkg are available as tested examples, so implementing something
workable shouldn't be hard. This is a critical need, so unless someone
else beats me to it pretty quickly, I'll probably wind up doing this.
Go to the first, previous, next, last section, table of contents.