Merged.

Yes, please!

I'm fine with that. Should I also close the branch and re-merge in the repository?

Once we're closer to the end of the M&S refactoring, we should perhaps reread
all of the code in context and then we'll hopefully see if there are more names
that can be improved, but I don't think we need to keep this issue open for
this. So I think we can close this -- if you think this is premature, feel free
to reopen it.

Ok, merged, but not closed yet.

Feel free to merge without me looking at it, but perhaps closer to the end of
the complete refactoring, we can have another look and see if there are other
places where the names can be improved. (Maybe it's not worth fretting too much
about getting it 100% perfect now when many things will change anyway.)

I thought the same about abstract states being fine.

Okay, so we may consider making it a class, but not in this issue. Do you
need/want to look at the renamings in the code or can I merge?

I think the name is good. Calling the states of a transition system "abstract
states" is something we often do.

Regarding whether it's useful, it's not an easy question. I like the idea of
seeing at a glance what is and isn't an abstract state. There are 49 lines that
use the word "AbstractStateRef", which is quite a lot, so this seems to be a
useful concept.

On the other hand, a typedef doesn't offer any type safety, so calling something
an AbstractStateRef rather than an int is more a comment than anything else.
Considering the large number of uses, I wonder if it couldn't be useful for code
clarity to replace AbstractStateRef by an actual class (which would just
encapsulate an int).

For me, the main drawback with getting rid of it is that function signatures and
member declarations are much easier to understand if you know that something
refers to an abstract state and not just an arbitrary int. Examples:

abstraction.cc:    vector<vector<AbstractStateRef> > forward_graph(num_states);
abstraction.cc:    deque<AbstractStateRef> queue;
abstraction.h:    std::vector<std::vector<AbstractStateRef> > lookup_table;
shrink_bucket_based.h:    typedef std::vector<AbstractStateRef> Bucket;
shrink_strategy.h:    typedef __gnu_cxx::slist<AbstractStateRef> EquivalenceClass;

I think these are much clear than if they all said "int" instead.

I renamed Abstraction to TransitionSystem and now I wonder whether I should
change AbstractStateRef (typedef int) to something else (or get rid of this
typedef). What do you think?

This is part of the meta issue432.

We want to have a look at the m&s code and rename classes and variables to fit
paper names, e.g. Abstraction -> TransitionSystem.