tag:blogger.com,1999:blog-10770855.post111792848406165906..comments2024-03-28T03:20:57.393-04:00Comments on The Little Calculist: AOP is...Dave Hermanhttp://www.blogger.com/profile/00405190527081772997noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-10770855.post-1119202208407795802005-06-19T13:30:00.000-04:002005-06-19T13:30:00.000-04:00If you turn AOP inside-out, and insist on types......<I>If you turn AOP inside-out, and insist on types...</I><BR/><BR/>I'm not insisting on types, just some kind of reasoning tool, of which types are only one example. (It's not too controversial a point, really. When people decry the loss of local reasoning, AOP apologists tend to promise tool support as the solution.) For example, Kathi Fisler's and Shriram Krishnamurthi's work on <A HREF="http://www.cs.brown.edu/~sk/Publications/Papers/#comp-sw-verif" REL="nofollow">verification techniques for AOP</A> looks like an interesting alternative to types. I have yet to look deeply at this, though.<BR/><BR/>Your paper looks interesting--I'll take a look. Thanks for the pointer!Dave Hermanhttps://www.blogger.com/profile/00405190527081772997noreply@blogger.comtag:blogger.com,1999:blog-10770855.post-1119192787666167502005-06-19T10:53:00.000-04:002005-06-19T10:53:00.000-04:00If you turn AOP inside-out, and insist on types, i...If you turn AOP inside-out, and <B>insist</B> on types, it is possible to deal with all this cross-cutting concerns mumbo-jumbo in nice ways. Oleg Kiselyov and I have been working on this in <A HREF="http://www.metaocaml.org/" REL="nofollow">MetaOCaml</A> with some <A HREF="http://www.cas.mcmaster.ca/~carette/metamonads" REL="nofollow">nice results</A>. We talked about Template Haskell, but because it is untyped (ha!), that did not seem very satisfying.<BR/><BR/>We ended up having to use a Monad, CPS, higher-order Functors, a bit of syntactic sugar, polymorphic variants as well as meta-programming, but that is all in the infrastructure, the final code isn't too bad. (This was accepted to <A HREF="http://www.gpce.org/05" REL="nofollow">GPCE 05</A>)<BR/><BR/>The real difference in our work (other than all the types!) is that we do not <I>modify</I> pre-existing code, which destroys all local reasoning, but rather <I>build</I> code from the ground up by weaving together all of its aspects. This restores the ability to do local reasoning!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-10770855.post-1118034036603370582005-06-06T01:00:00.000-04:002005-06-06T01:00:00.000-04:00I mostly agree; it's an important correlation, ins...I mostly agree; it's an important correlation, insofar as both AOP and monads are trying to address the idea of linguistic abstraction. Both are frameworks for extending the semantics of a base language in a way that increases its expressive power, though at the expense of local reasoning. But I don't think <I>either</I> deserves to be considered "the" answer to solving cross-cutting concerns.<BR/><BR/>You could put all of the following technologies under the same umbrella of "growing a language:" AOP, macros, monads, meta-object protocols.<BR/><BR/>I know that at some level of abstraction any set of things can look the same. But for me, the most useful aspect (*cough*) of drawing this correlation is that it makes it clearer why you keep seeing the same controversies appear over and over in each of the different areas, e.g.:<BR/><BR/>A: Ooh, look at my pretty new abstraction!<BR/>B: Where's my local reasoning?<BR/>A: The tools! The tools!Dave Hermanhttps://www.blogger.com/profile/00405190527081772997noreply@blogger.comtag:blogger.com,1999:blog-10770855.post-1117998969770678522005-06-05T15:16:00.000-04:002005-06-05T15:16:00.000-04:00After seeing several talks about AOP, I came to th...After seeing several talks about AOP, I came to the conclusion that the best way to think about them is as an object-oriented programmer's rediscovery of monads in the same sense that XML is an object-oriented programmer's rediscovery of s-expressions. When you cut through the thick layer of (from what I can tell) nonsensical hype and kind of crufty technology, what you've got is a way of overriding a program flows from one expression to the next in such a way that you've got an opportunity to do all kinds of sneaky stuff. I suppose if you want to call that "separating out cross-cutting concerns" you can reasonably to so, but it seems like the cross-cutting-concerns terminology is one of those businessy terms that sounds impressive but is hard to pin down to an actual meaning.<BR/><BR/>I think you've done a lot more studying of AOP than I have, so if you disagree with me you're likely to be right :), but the aspects-as-monads paradigm has served me well in understanding what aspects are all about.Jacob Matthewshttps://www.blogger.com/profile/01440842967865877789noreply@blogger.com