Lambda the Ultimate

The visitor pattern is interesting as the prime example of how-to-implement-FP-in-OO. FP and OO are kinda duals of one another: in OO you sprinkle functions amongst your data (objects); in FP you sprinkle data amongst your functions. The visitor pattern reverses the typical OO relationship to give you functional style in an OO program (but my gawd it is butt ugly!) That the authors concentrate on the visitor pattern raises some suspicions in my mind. There are well known language features that lead to a pretty visitor pattern (e.g. multiple dispatch). I suspect, but cannot prove as I can't read the paper, that the limited view of single-dispatch OO is clouding the authors' perspective. That said I think there is some value in AOP, but separating it out of the mess that is Java would give a better understanding of what those benefits are.

http://www.cs.iastate.edu/~cclifton/multijava/

One of the presentations referenced in the posting talks about how this compiler (the "mjc compiler") and how it is used to build a compiler in a modular fashion in the compiler class they teach.

> How applicable is AOP to functional programming?

I think cross-cutting features are a problem in imperative, functional, and object oriented language paradigms because programs in these paradigms are basically hierarchies of function calls. In unification based languages like Prolog or HPSG the flow of control can jump around between various seemingly distant feature structures at will, but this lack of locality has its drawbacks. There seems to be a tradeoff between locality and tangledness in code. (Just my opinion.)

For Aspects and Haskell see: http://lambda-the-ultimate.org/classic/messagx3091

Program slicing seems to be an imperative programming tool that makes up for the ill-defined semantics you find in functional languages. Can anyone recommend open sourced program slicing tools?

I presume you've made a typo in your last paragraph: " Program slicing seems to be an imperative programming tool that makes up for the ill-defined semantics you find in functional languages." I guess you mean "imperative languages".

Not sure if this is the kind of thing you're looking for, but Elide provides some slicing capabilities for Java, which from what I understand, are rather more powerful (and therefore dangerous) than what e.g. AspectJ offers. There's a paper here.

> I presume you've made a typo in your last paragraph: "

Yep, Sorry, I left several typos or half-formed thoughts that I only realized while running/exercising after I left the internet cafe. To complete one half formed thought:

Hypothesis: The things that give programmers a headache when they try to understand programs: cross-cutting concerns, aspects, and tangled code, are similar to the things that give linguists headaches when they try to understand natural language: "long distance dependencies" .

[1, 2]

The similarity:

localization of functionality in a text (localized concerns or not-tangled code, constituent phrases of sentence, e.g. a noun phrase) vs. physical separation and distribution of functionality throughout a text (cross-cutting concerns, tangled code, )

It seems to me like computational linguists have adopted unification of typed feature structures to deal with this physical separation of functionality.

Once a problem has been declaratively described with feature structures unification can bridge the long distances of dependencies or the cross-cuttings of concerns better than the functional decompositions used in imperative, functional and object oriented programming.

I found the idea of "equivalence classes of programs" in the presentations intrigueing, but I think equivalence classes of programs across paradigms and meaning preserving transformations (refactorings) across paradigms is more interesting than restricting to object oriented languages.

If anyone could come up with such a unified theory of programming bridging the gap between programming paradigms, they would truly deserve a Nobel prize.

Could you draw out this analogy further? Or do you know somewhere it is? Most descriptions of the visitor pattern I've read are very nuts-and-bolts-ish and never any analogies outside the specific object oriented programming language.

> I do wonder how much of aspect orientated
> programming is motivated by concerns
> particular to single-dispatch OO. It seems that
> CLOS before, after and around
> methods get one a lot of what aspects give you
> (no surprise given the same
> people are behind large chunks of both).

Seems like these ideas could be a good way to motivate a description of CLOS, namely the fact that methods aren't embedded in the scope of a class and can be dynamically associated with different classes, makes it easier to treat cross-cutting concerns. Most of the Lisp books I read did not motivate their descriptions with higher order ideas like this that cut across programming paradigms.

Bridging Functional and Object-Oriented Programming http://citeseer.nj.nec.com/383622.html

Synthesizing Object-Oriented and Functional Design to Promote Re-use http://citeseer.nj.nec.com/krishnamurthi98synthesizing.html

Pattern Transfer: bridging the gap between theory and practice http://citeseer.nj.nec.com/461895.html

The first paper shows how many patterns are directly coded when functional features are available. They show that Visitor, Virtual Proxy, Command, Observer, Adaptor and more are all easier to express when FP features can be used. They develop a C++ library to allow this.

The second paper shows very clearly how FP and OO in inverses in terms of program organisation. They show how both fail to solve certain program extension tasks and provide a new pattern (Extensible Visitor) to solve this problem. This paper is your best bet if you want to see how OO and FP mirror each other.

The final paper discusses the problem of technology transfer between academia and industry. It's interesting for its (brief) discussion of design patterns and their relation to functional languages.

These three papers should give you everything you want to know. I have much more to say, but unfortunately not the time to say it today!