[m-rev.] for post-commit review: goal ids

[Zoltan Somogyi]

On 04-Jan-2011, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> > Whatever the type, it still identifies a program point, and in the future,
> > it SHOULD be a goal_id.
> 
> I agree with pp_id if it should be a goal_id in the future.

Yes, it should be. I actually started to make it a goal_id now, but then 
realised that much of the code using that type is

- code that I don't understand well enough to change over, as well as
- code that should be replaced with completely different algorithms,
  so there is no POINT in changing them over.

> > If you did, you would need to break the abstraction barrier all the time,
> > so I don't think you would gain anything, and the cost in clarity would
> > be significant.
> 
> This is true without functions such as remove first and cons for goal paths.
> But I belive that the list syntax is easier to read than these functions.

Exactly. Abstraction is good because it usually makes things easier to
understand. In this case, it made things HARDER to understand, and it did not
buy anything meaningful, because to ensure acceptable efficiency, you STILL
had to know what those auxiliary functions were doing under the hood.

> > We do. rev_goal_path_to_string takes a reverse list, but the string it returns
> > is in forward order. The string forms of goal paths should ALWAYS be in forward
> > order. If you find any that aren't, that is a bug.
> 
> Good :-)  I like this behaviour.

That's why I designed it like that.

> This is because the reading glasses offer me a
> wider field of view.

Exactly why I wear the glasses I do.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------