Is Groovy Science Dead?

In short: Is Groovy Science dead? Yes and no. Yes, its author (me) is somewhat distracted with other things and has left the project to atrophy. On the other hand, no, its author (me) still has strong opinions about what it is and where it can go, and will probably pick it up again eventually if no one else does.

Well, I went back to school, and I left Groovy Science in a pretty unuseful state. I only got about halfway through the tutorials I was planning, I never set up a way to build a .jar file, and I didn’t even end up choosing a license.  To trump that, I think I was going about it the wrong way from the start.

The premise was to make a common, easy-to-transform format for symbolic expressions, which could be used to help glue and wrap (groovify?) existing Java libraries. What I failed to notice was that Groovy already has a standard format for symbolic expressions: Objects.

Groovy Science isn’t what has my attention nowadays, but I’ve still been doing some thinking about it in my spare time, and I’d like to see it redefine itself in a few directions:

Forget the science pretense.

What I’ve made, and what I’ve hoped to make, isn’t really invested in “science.” It doesn’t do any numerical calculations, and it’s completely oblivious to statistics. It doesn’t handle databases or data visualization. It doesn’t do simulations. It does symbolic manipulation. Symbolic manipulation is something that rests comfortably in the realm of things programmers do all the time.

I think the project would be better off called Gimble. For now, I’ll keep calling it Groovy Science, simply because that’s what I’ve been calling it so far.

Extract the iterator functionality into its own module.

Pattern matching is a process that can potentially have more than one result. I kept that in mind while making Groovy Science, so there  are a few tools I put there for internal use in manipulating Iterables and Iterators.

If it were up to me, Groovy would have language support for Iterables with a “yield” statement. Of course, then I’d ask for coroutines, and then I’d ask for continuations, and Groovy would be a mess. In the absence of generators, I’ve ended up making a particularly satisfying class I call SuperIterable. I can build simple Iterables using Groovy closures, and I can build those into complex Iterables combinatorially, using methods like collecting and findingAll and concatenating with +. Incidentally, I think it’s even easier to build these things combinatorially than it would have been writing those “yield” statements.

I think this would be a great thing to put in the actual API for Groovy Science. I sure like it, and I think it would particularly help out those people who want to implement some wacky, unforeseen form of pattern matching.

Provide a complete implementation of unification.

The pattern matching stuff is extremely close to unification as it is, but it doesn’t go all the way. The difference is that full unification would allow pattern expressions to match with each other and share bindings.

This is still a bit of a daunting task, for two reasons.

One, it raises the question of whether recursive expression structures should be supported (since sometimes that’s what you get when you unify certain pattern expressions). I’m pretty sure that would be a bad idea. People can keep their code from breaking in recursive structures if they keep a trail of breadcrumbs (read: a set of “I’m already exploring this section, so don’t start exploring it again” references), but that’s a big hassle in the otherwise simple iteration code I’d like to promote.

Two, I think unification might not fit very well with the PatternTermOperator model. Unification is typically defined with the assumption that the pattern expressions have constants, predicates, and expression variables, and not much else. This works for expressions like A * B + A * C, but PatternTermOperators are more flexible than just automatically matching and binding the matched expression to a name. A PatternTermOperator can do things like matching only under certain criteria or performing a deep search of its branch of the subject expression and making multiple bindings.

Still, I think a symbolic manipulation library should provide at least some implementation of unification… eventually.

Give things like Maps, Lists, and JavaBeans the same treatment as SymbolicExpressions.

There’s nothing particularly wrong with keeping SymbolicExpressions around. All of their Groovy overloadable operators are overloaded, so they can be used to great effect in making readable algebraic expressions. But, as I’ve said, symbolic manipulation is already done in Groovy (and Java) using objects.

I would be perfectly okay with writing a symbolic expression as [ op: IntegrateOp, expression: x, d: x ]. I’d probably still end up defining a simple closure so I could say integrate( x, x ) instead, but I have to do that with Groovy Science as it is anyway. And if I can say [ op: UnionOp, args: [ R, S, T ] ] and have pattern-matching stuff available to use with that, it’ll be fantastic.

As it is, a match pattern is just a way to turn a subject SymbolicExpression into an Iterable of results, which themselves are Maps describing the bindings made. A replacement pattern is a way to turn one of those Maps back into a SymbolicExpression. This process isn’t inherently specific to SymbolicExpressions. (For instance, people already do it with regexes and strings all the time. In fact, regexes were sort of an inspiration for me here.)

I’m especially intrigued with what could happen if the intermediate Map format itself could be transformed before it was reconstituted. At that point, we might as well stop calling it an intermediate format, and then we can leave off the “matching” and “reconstituting” steps and just focus on the transformations… which is what it’s all about, right?

Unleash it on program code.

Where I think this approach would really excel is in code manipulation, and especially Groovy AST transformations. Now that @Immutable and @Bindable have made their debut in Groovy 1.6, it’s the perfect time to take their example and make a relatively easy-to-use system for making one’s own AST transformation annotation.

I’d do it, but I have other things distracting me right now. …


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s