[m-dev.] add goal path at external ports

[Mark Anthony BROWN]

Hi,

Erwan Jahier writes:
> 
> Hello there.
> 
> I have a question. Currently the following goal: 
> p:- ((a,b);c) -> d ; e.
> generates this kind of trace :
> 
> call p 
> disj p   "?:d1"
>   call a
>     ...
>   fail a
> dicj p   "?;d2"
>   call c
>     ...
>   exit c
> then p    "e"
>   call d
>     ...
>   exit d
> exit p
> 
> I think it would be helpfull to have a little bit of context information here. 
> For example, we could have the goalpath from which the call is made. Something 
> like :
> 
> call p 
> disj p   "?:d1"
>   call a "?:d1"
>     ...
>   fail a "?:d1"
> dicj p   "?;d2"
>   call c "?;d2"
>     ...
>   exit c "?;d2"
> then p   "e"
>   call d "e"
>     ...
>   exit d "e"
> exit p

In each case the goal path for an external port at depth N is the same as
the most recent goal path for an internal port at depth N - 1.  So if
you remember the most recent goal path for each depth less (shallower)
than the current depth, you can reconstruct that context information.

> 
> How hard do you think it is to add this information to the current trace ?
> Is this information still available when generating external events ? 

You could reserve a stack slot, store the information there for
every internal port, then look it up at every external port.  I
wouldn't recommend this though, since for large conjunctions you
may wind up sending the same goal path through the socket many
times.  You would pay for the extra stack slot and socket traffic
whether you wanted the extra information or not.

> 
> Maybe once we've got that, we don't need internal ports anymore... (?)
> 

Maybe, but with internal ports we don't need the extra goal paths (!)

>            ----------------
> ps :
> The reason I am asking that is that I try to work out some kind of path
> coverage rate of a test suite. Most of the time, this is done by source code
> instrumentation. But here, I think we can take advantage of the information
> contained in the trace and particulary the goalpath attribute. 

That is a good idea.  But I think there is already enough information
in the trace for what you want.


> 
> The current goal paths information is not sufficient : if you consider my
> exemple, all the possible goalpaths that can be generated are
> {"?;d1","?;d2","e","t"}. Now suppose you have other input values to p such that
> c fails. Then in that case the else branch is entered, and all the possible
> goal paths have generated. Nervertheless, the goal b has never been entered ! I

Your proposed change doesn't add to that set of possible goal paths, so
you would still have this problem.


> think what I really need is the information about the context I was just
> requesting about (I could elaborate on that but I think it is enough for this
> time...).
> 

I think I understand the difficulty.  Here is another problematic
example:

p(X, Y) :-
	( c(X), c(Y) ->
		d
	;
		e
	).

If the condition fails, how do we know which call to c/1 failed?  We
could always inspect the arguments of p and c, but this is asking
a fair bit from the user...

Cheers,
Mark
-- 
Mark Brown  (dougl at cs.mu.oz.au)       )O+   |  For Microsoft to win,
MEngSc student,                             |  the customer must lose
Dept of Computer Science, Melbourne Uni     |          -- Eric S. Raymond