Modules and Patching
Following Wouter’s fp lunch chat about patches and bit of a kickaround with Lucas Dixon, I’ve started wondering whether there’s a sensible notion of patch which should accompany the editing of a module–if I edit module A, eg by renaming something, can we generate a patch not for A, but for every module importing it, propagating the change? If we timestamped every module import on compilation, we could figure out which patches to apply on recompilation. Is revision control (darcs?) another ingredient of a good Epigram system? Somehow, it’s already a part of what we do ‘in the small’.
June 29th, 2005 at 3:57 pm
Some Java IDEs have functionality similar to what you mention (under the rubric of refactoring). They don’t apply changes at recompilation but propagate when explicitly being used.
Common refactoring actions r.e. Java are rename entity (class|interface|method|field), move entity up or down an inheritance hierarchy, extract interface from class etc. There some interesting work in test driven programming where you specify code by writing the test unit first. The classes and methods implicitly mentioned in the test unit are then created. You then fill out the generated classes until the test passes.
Normally to implement refactoring you have to maintain a database of references, which requires a workspace (collection of projects/packages in the case of Java, I’d suspect a set of modules in Epigram). This is where traditional source control systems fall down, they don’t extract or maintain inter-dependence data, so large merges can still be conflict free and fail to compile. It may be possible to avoid the workspace maintenance overhead and apply changes at recompile as you mention (it’d be less work I’d imagine).
I wrote an asset management system (when I was working in games) that tracked references. It was for artists and designers so it didn’t manage code, just 3D-models, bitmaps and proprietary map and game entity data formats. Having the inter-dependence information allowed large commits to be refined into referentially disjoint ‘commitlets’ so it didn’t fall foul of the above mentioned pain r.e. source control systems. Updating a single file would also update any files it depended on, stopping another bane of CVS, darcs, Subversion et al when they’re used in anger.
Anyway, there’s lots of nice stuff you can do with inter-reference data but it can be a pain to implement (and would also mean changes to the theory of patches). Anyone who writes a large program in Epigram that needs overhauling just once would thank you for it though.