How to make GAP understand that a homomorphism is a representation? In a previous question I asked how one constructs an explicit representation in GAP. As a concrete example, I want to consider the $5$-dimensional $\mathbb{F}_3$-representation $\rho$ of $C_8$ sending a generator $g$ to
$$ \rho(g) = \begin{pmatrix}
1 & 0 & 1 & 2 & 2 \\ 2 & 1 & 1 & 2 & 2 \\ 1 & 0 & 2 & 1 & 0 \\ 1 & 1 & 1 & 1 & 0 \\ 2 & 1 & 1 & 0 & 2 \end{pmatrix} $$
It was suggested that the best way to achieve this is to explicitly construct a homomorphism to the general linear group, leading to the following implementation:
G := CyclicGroup(8);
gen := GeneratorsOfGroup(G)[1];
GLn := GeneralLinearGroup(5, GF(3));
img := Z(3)^0 * [[1, 0, 1, 2, 2], 
        [2, 1, 1, 2, 2], 
        [1, 0, 2, 1, 0], 
        [1, 1, 1, 1, 0], 
        [2, 1, 1, 0, 2]];
rep := GroupHomomorphismByImages(G, GLn, [gen], [img]);

This works as a homomorphism, but I would like to now invoke some representation-theoretic functions, and I strongly suspect that these functions expect a different datatype as input. For instance, I'd like GAP to tell me the dimension of my representation:
MTX.Dimension(rep);

Error, illegal access to record component `obj.dimension' of the object <obj>. 
(Objects by default do not have record components. 
The error might be a relic from translated GAP3 code.) 
at /usr/lib/gap/lib/record.gi:160 called from
return module.dimension; 
at /usr/lib/gap/lib/meataxe.gi:223 called from
<function "unknown">( <arguments> )

Although the error tells you nothing, I strongly suspect that the MeatAxe algorithms simply require the input to be stored differently. So how do I tell GAP to view my homomorphism as an actual representation?
 A: The problem lies in conflating apples with oranges. There are a number of related concepts in representation theory: representation, module, character, etc. but formally they are different kinds of objects. Informally, it can be convenient to identify one with the other, but the computer in general will be picky.
There is a second difficulty, and that has to do with effective implementation. Formally, a vector space is an abelian group with action by a field. But when working in practice, with a finitely dimensional vector space, objects are row (or column) vectors. Similarly, a linear transformation formally is a map from one vector space to another, in practice it is a matrix (once bases have been chosen).
The MeatAxe lives on this more "technical" level -- while it describes a module, it is actually a collection of matrix images of algebra generators, describing the algebra action on the module. (Thus, it is not possible to, say, test membership in the module.)
To form a MeatAxe module from a group homomorphism rep, you could use
gap> GModuleByMats(List(GeneratorsOfGroup(Source(rep)),
> x->ImagesRepresentative(rep,x)),DefaultFieldOfMatrixGroup(Range(rep)));

Finally notice that the MeatAxe functionality is only implemented over finite fields, not in characteristic zero.
