Re: [abc-users] Tracematch matching semantics

Note: Again, this was left undelivered for almost a day. Sorry about the
delay, I need to fix my mail system setup.

--------------------

As it happens, that is a feature I implemented very recently. You can
use it with the abc.ja.tm extension (it is not implemented in abc.tm).
You also need to compile abc from svn HEAD.

The way it works is that in each tracematch, you can specify several
'distinctness constraints', of the form "distinct x1, x2, ..., xn;" for
tracematch variables x1...xn. The effect will be that no valuations
which map some xi, xj \in x1...xn to the same value will be considered.

Thus, in your example, you would put the following after the symbol
declarations:

    distinct a0, a1;

This is still a relatively new feature, so I'm keen on hearing about
your experiences -- problematic or not -- with it.

- P

Jon Oldevik wrote:
> Hi,
> Thanks everyone for prompt and informative answers.
>
> I have another question concerning the tracematch semantics:
>
> In the OOPSLA'05 paper it is specified that trace matches are
> sensitive to instances if the same variable is bound several times in
> the same tracematch, its value (object equality) must be identical in
> order to make a match.
>
> Is it also possible to create a tracematch that is capable of
> distinguishing two different objects in a trace, lets say to capture a
> trace where a sequence of messages is sent to object a0:A followed by
> a sequence of messages sent to a1:A, where a0 != a1?
>
> Regards,
> Jon Oldevik
>
>
> On Thu, 11 Sep 2008 03:18:02 -0700, Pavel Avgustinov
> <pavel_at_comlab.ox.ac.uk> wrote:
>
>> Note: Somehow this message remained in my unbox unsent, and I see
>> there have been some replies in the meantime.. sorry for the delay,
>> and any repeated information.
>>
>> ---------------------
>>
>> Hi Jon,
>>
>> Yes, this is indeed working as designed. The tracematch pattern is
>> matched against *all suffixes* of the program trace. Thus, after the
>> second 'save' event, the last two save events trigger a match, and
>> after the third 'save' event, the second and the third events trigger
>> a match.
>>
>> The formal semantics of the matching behaviour is laid out in our
>> OOPSLA'05 paper
>> (http://abc.comlab.ox.ac.uk/documents/re21-allan.pdf). Note that
>> there is an example there that is superficially similar to yours: We
>> define an "autosave tracematch" that automatically saves a document
>> every 5 actions after the last save. There, the pattern is indeed
>> just "action [5]" (where yours is "save [2]), however, it would not
>> trigger after every single action after the 5th. The reason is in the
>> body of the tracematch: That calls "Application.autosave()", which
>> matches one of the declared tracematch symbols which isn't referenced
>> in the pattern. This event effectively resets the matching state,
>> since no suffix will match the pattern until another five action
>> events occur.
>>
>> Hope this helps, do let me know if I can clarify further.
>>
>> - P
>>
>> Jon Oldevik wrote:
>>> Hi,
>>> I have a question about the matching semantics that tracematch
>>> supports.
>>>
>>> given a really a tracematch, e.g. the simple one given below, which
>>> is matching two subsequent calls to save: When two 'save' are
>>> detected, the tracematch gives a match. However, when a third 'save'
>>> is detected, a new match is given (rather than waiting for a fourth).
>>>
>>> Is this the intended semantics of tracematches?
>>>
>>> public aspect MatchTwoSaves {
>>> pointcut save(Editor e): target(e) && call (* Editor.save(..))
>>>
>>> tracematch (Editor e) {
>>> sym save after returning: save(e);
>>> save save {
>>> // we got a save+save match, now do something with it
>>> }
>>> }
>>> }
>>>
>>> Best regards,
>>> Jon Oldevik
>>>
>>
>>
>>
>
>
>
Received on Sat Sep 13 2008 - 13:23:28 BST