Yacc for different data types

I am trying to write a grammar lets the user use the operation symbol they are used to for multiple calculations. For example, A+B, where A and B are matrices, or numbers.
Here is the relevant part of the grammar:

q_term: fraction	
| q_term '+' fraction	{$$ = q_add($1,$3);}
| q_term '-' fraction	{$$ = q_sub($1,$3);}
| q_term '*' fraction	{$$ = q_mul($1,$3);}
| q_term '/' fraction	{$$ = q_div($1,$3);}
;

qm_term: q_matrix	
| qm_term '+' q_matrix	{$$ = qm_add($1,$3);}
| qm_term '-' q_matrix	{$$ = qm_sub($1,$3);}
| qm_term '*' q_matrix	{$$ = qm_mul($1,$3);}
;

It gives me a bunch of shift/reduce errors. I think that is because it sees the operation characters in more than one place.

How do I resolve the shift reduce errors?

Edit:

Here is how the parser tells the difference between a matrix and a scalar

q_term: fraction	
| q_term '+' fraction	{$$ = q_add($1,$3);}
| q_term '-' fraction	{$$ = q_sub($1,$3);}
| q_term '*' fraction	{$$ = q_mul($1,$3);}
| q_term '/' fraction	{$$ = q_div($1,$3);}
;

q_matrix: '[' q_term	{qm_temp = qm_create();  qm_append(qm_temp,$2,'c');}/* new q_matrix */
| q_matrix ',' q_term {qm_append(qm_temp,$3,'c');}	/* add a number to the current q_matrix row */
| q_matrix ';' q_term {qm_append(qm_temp,$3,'r');}	/* add a new row */
| q_matrix ']'	{qm_finish(qm_temp); $$ = qm_copy_matrix(qm_temp);} /* close the list */
;

fraction: INTEGER {$$ = q_new($1,1);} /* this converts a lone integer into a fraction */
| INTEGER '|' INTEGER {$$ = q_new($1,$3);}

In a language without variables (a simple calculator, for example), it can be possible to distinguish expressions of different types during the parse, provided that it is not possible to automatically coerce (cast) one type to another.

But realistically, it's going to be a nuisance to repeatedly type matrices out in full every time. You and your other users will very quickly demand some way to save a matrix constant as a named object. If named objects can also be scalars, then you will either have to insist that the name of an object somehow represent the type (for example, a matrix might have to be written with a capital letter or some such), or more likely you're going to end up not knowing during the parse whether a name is a scalar expression or a matrix expression. And at that point, any complicated grammar you might have built to try to distinguish the two types of expressions during the parse will suddenly become pointless.

So my advice is to save yourself the aggravation. The initial parse should just build an AST of some form, and you can then walk the tree to perform whatever semantic analysis you require, including resolving polymorphic operators and inserting automatic coercions, if any.

Ignorable Appendix

Although there is nothing wrong with your grammar for q_matrix, it strikes me as a little awkward because it doesn't really represent the syntactic structure of matrix constants. I would have written it slightly differently (also using the semantic values to store intermediate results instead of a global variable):

q_matrix: '[' q_row_list ']' { $$ = $2; }
q_rows  : q_row              { $$ = qm_create();
                               qm_append_row($$, $1); }
        | q_rows ';' q_row   { /* $$ = $1; */
                               /* ensure $1.cols() == $3.cols */
                               qm_append_row($$, $3); }
q_row   : q_term             { $$ = qr_create();
                               qr_append_val($$, $1); }
        | q_row ',' q_term   { /* $$ = $1; */
                               qr_append_val($$, $3); }

In the above, I commented out both instances of $$ = $1;, since in the case of C language bison-generated parsers, that copy has already been done just before executing any action. If you change to another language, such as C++, you might need to include the explicit copy.

The code assumes that you have both matrix and row (or vector) objects. (Of course, a vector object could be a matrix object with one row, if you didn't want to go to the trouble of implementing two distinct types.) In the code above, a row is completed before being appended to the matrix; at this point, it is easy to check to make sure that the row being appended has the same number of columns as the accumulated matrix. I indicated this test with a comment, rather than try to suggest what action should be taken if the test fails.