On Tue, Jul 26, 2011 at 10:23 PM, Jose Vergara <[email protected]>wrote:
> John, > > Thank you for the pointers on AOP, to explore the links between pattern > calculus and AOP is high in my list. > If you are interested, the functional style as supported in pattern > calculus is discussed in [1]; some of the relational style is explored in > [2]. > I am currently exploring compiler construction for a minimum subset of > bondi that supports language growth, > and have plans to use LLVM as backend. > > [1] Pattern Calculus: Computing with Functions and > Structures<http://www.springer.com/978-3-540-89184-0> > [2] Programming with Heterogeneous Structures: Manipulating XML data > Using bond <http://crpit.com/confpapers/CRPITV48Huang.pdf> > > Cheers > Jose > Jose, To push back, why is AOP high on your list? Through history, there were many approaches to software composition: * Generators * Co-routines * Meta Object Protocols (MOP) * Aspect-oriented programming (AOP, repackaging MOPs) * Subject-oriented programming * Hyperspace programming (Multi-dimensional separation of concerns) * Feature-oriented programming * View-based programming * Frame-oriented programming [1] * Software architecture description languages * Mix-ins * Traits * Parametric modules by types, as in ML * Parametric modules by logic equations, as in languages such as Maude [2] The intent behind Uwe Assmann's work was to create a generic framework for implementing any of the above! The idea is to define the basic composition primitives required for each software composition paradigm, and then use these composition primitives to implement compound composition operators until all the operators of the paradigm are implemented. His book, Invasive Software Composition [3], is actually very similar to Barry's monograph on the Pattern Calculus [4]. One of his book's main goals is to show that every language construct can be generic. He also developed a vocabulary for talking about language extensions: composers, declared hooks, implicit hooks. In some way, the richer vocabulary is nicer. On the other hand, it is a distraction, since the achievement of the Pattern Calculus can be seen as simplifying what Assmann writes about. As far as I can tell, ISC ended up being a very applied effort, focusing on Eclipse and the Semantic Web. I think Assmann did develop a calculus to show the soundness guarantees of various composition techniques within his framework (e.g., sound view merging, sound aspect weaving), but I can't recall the name of the calculus. The other neat thing about Assmann's book is Chapter 3, which breaks down some existing approaches and their trade-offs: Laurent Dami's Lambda N Calculus and Lumpe's piL Calculus. That said, there are some obvious limitations to using Assmann's toolset. Since it is built in Java, it is procedural, imperative and verbose. Also, it does not unify language definition and language extension trivially, and so it does not seamlessly cross the bridge to "domain workbench" tools like ASF+SDF for prototyping language environments. Another way to demonstrate this weakness is by comparing it to Maude's very powerful module system, where the semantics of a module can be re-written so that whole modules are defined only in terms of the differences between itself and other modules, e.g. erasing associative property annotations on operators. Maude's ability to integrate logic programming and user-definable syntax has made it a good tool for demonstrating formal approaches to describing software architectures, such as the work on applying Hyperedge Replacement Grammars to software architecture definition. [5] See other work by Roberto Bruni for more information on applying graph grammars to formally describing architectural styles. This is really, really awesome stuff. (The casual software developer reading this should read Bruni's "Ten Virtues of Structured Graphs" [6] for a cursory overview.) I have way more suggestions on where to take these things, but it takes time writing them down. Since I see so many cool applications, I would recommend not spending too much time with the LLVM backend - just get it working correctly. There are way too many user-oriented features that can be added as "libraries" and build up a user base for bondi. Smart users will drive innovation in the LLVM backend. Finally, since Filman and Friedman wrote "Aspect-Oriented Programming Is Quantification and Obliviousness", it should be shown in the Pattern Calculus how to achieve those distinguishing properties of the AOP paradigm. [1] http://www.amazon.com/All-About-Maude-High-Performance-Programming/dp/3540719407 [2] http://www.softmetaware.com/oopsla2002/sauerf.pdf [3] http://www.springer.com/computer/swe/book/978-3-540-44385-8 [4] http://www.springer.com/computer/theoretical+computer+science/book/978-3-540-89184-0 [5] http://soa.fbk.eu/download/2008/11/BBGHL_08.pdf [6] http://journal.ub.tu-berlin.de/eceasst/article/view/261/246
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
