Hi Shriram and Kathy:

I noticed that in your FSE-12 paper you have atoms/elements/designators.
I did not quite understand why this complexity is needed.

When we originally designed pointcut languages 10 years ago we had
a simpler structure shown below. The message below uses class/link terminology.
In the context of your paper this should be translated as follows:
class graph -> static call graph.

-- Karl

============================================
From lieber Thu Aug 31 13:51:57 1995
From: Karl Lieberherr <lieber>
To: lamping@parc.xerox.com, lieber@ccs.neu.edu
Subject: Re: Boolean and Regular
Cc: Gregor@parc.xerox.com, boaz@ccs.neu.edu, crista@ccs.neu.edu,
        huersch@ccs.neu.edu, ivbaev@ccs.neu.edu, palsberg@theory.lcs.mit.edu,
        salil@ccs.neu.edu, seiter@ccs.neu.edu, yangl@ccs.neu.edu

Hi John:

yes, we agree. The operators of what I called Boolean algebra operators
are just as well counted as regular expression operators.

I like your integration; have to think more about how expressive it is.

-- Karl
============================
>From lamping@parc.xerox.com Thu Aug 31 13:33:57 1995
Subject: Re: Boolean and Regular

We seem to be converging, but I still think that enhanced regular
expressions can express all of the operators.  Here is the enhanced regular
expression language from a while back:

Atomic expressions:

   A    The empty traversal at class A
   lnk  a link of type lnk ("any" is a special case of any link type)

For combining expressions, the usual regular expression crowd:
   .     concatenation
   \cap  intersection
   \cup  union
   *     repetition
   not   negation

Note that A is like an empty string; the traversal that just sits at class
A.  As with all empty strings, A.A = A


Here are the operators from the Karl's last message, with a translation
into enhanced regular expressions:

[A,B]			A.any*.B
through edges           any*.lnk.any*
bypassing edges         not(any*.lnk.any*)
through vertices        any*.A.any*
bypassing vertices      not(any*.A.any*)
d1 join d2              [d1].[d2]
d1 merge d2             [d1]\cup[d2]
d1 intersect d2         [d1]\cap[d2]
not d1                  not([d1])

where [x] is the translation of x into regular expressions.

Of course, \cap is not strictly necessary, as it can be expressed in terms
of \cup and not.  Furthermore, with distribution, not can be pushed down to
leaves.

The enhanced regular expressions can also express some things that I can't
see how to express with the operators, such as paths from A to B that
don't visit an A or B node except at the start and end:

  A.(any*).B \cap not(A.any.(any*).(A \cup B).(any*).any.B)

Since the enhanced regular expressions are equivalent to DFAs (enhanced
with the ability to sense node types), it would be an interesting exercise
to find a set of operators that could capture any regular expression.