How to fix shift/reduce problem between tab and space - c

Question

I am trying to write a minipython compiler, and as we know, Python works with spaces to define a block. In my situation, I defined the block as exactly 4 spaces, but when I want to create a block with multiple lines it tells that there is a shift/reduce conflict. I guess I know where the problem is; it doesn't know to treat the second line as space or tab, but I am not sure, so here is my code:
lexical :
" " {column = column + strlen(yytext); return mc_tab;}
" " {column = column + strlen(yytext);}
syntaxic :
S : INSTRUCTION S
| {printf("\nWINNER WINNER CHICKEN DINNER\n");YYACCEPT;}
;
INSTRUCTION : DECL mc_jmp | LOOP | COND | mc_jmp
;
COND : IF ELSE
;
IF : mc_if mc_opnArc COMPARISION mc_clsArc mc_dblpnt mc_jmp BEGIN_BLOCK
;
ELSE : mc_else mc_dblpnt BEGIN_BLOCK |
BEGIN_BLOCK : mc_tab INSTRUCTION BEGIN_BLOCK |
;
Just to know, when I deleted the recursion in BEGIN_BLOCK, the conflict is gone.
EDIT :
and there is another problem, I guess if we solved it, then the first will be solved too.
when I write TAB in any line of code it will be treated exactly as that tab didn't exist, so the code treated the tab exactly as it treats the 4 spacements

Answer 1

As I wrote in comments, shift / reduce conflicts are parser issues. They are being reported by Bison in your case, and they are a function of your grammar (only). If you ask it to do so via either or both of -v or -r all, Bison will produce an output file that shows you (among other things) exactly where such conflicts occur.
The grammar presented in the question is incomplete, but I made it into an input file that Bison would accept by adding section delimiters and adding a %token declaration for each symbol that is not otherwise defined. I also added the semicolon that appears to have been intended after the definition of the ELSE symbol, before the definition of BEGIN_BLOCK. Bison reported four shift / reduce conflicts for the result:
when the token on top of the stack is an IF and the next token is an mc_else, it is ambiguous whether to reduce zero tokens to an ELSE or to shift the mc_else in anticipation of performing a later reduction to an ELSE. This arises in part because the grammar accommodates nested conditionals, so it is a manifestation of the common issue of matching elses with the appropriate ifs.
when the tokens on top of the stack are mc_else mc_dblpnt and the next token is an mc_tab, it is ambiguous whether to reduce zero tokens to a BEGIN_BLOCK or to shift the mc_tab in anticipation of an INSTRUCTION to follow.
when a token sequence that can be reduced to a BEGIN_BLOCK is required and the next token is an mc_tab, it is ambiguous whether to reduce zero tokens to a BEGIN_BLOCK or to shift the mc_tab in anticipation of reducing to a BEGIN_BLOCK via the other production for that.
when the tokens on top of the stack are mc_if mc_opnArc COMPARISION mc_clsArc mc_dblpnt mc_jmp and the next token is an mc_tab, it is ambiguous whether to reduce zero tokens to a BEGIN_BLOCK or to shift the mc_tab in anticipation of an INSTRUCTION to follow.
A common theme emerges: empty rules are biting you hard. Such rules are by no means the only way that a shift / reduce conflict can emerge, but I presume that you will recognize that allowing the parser to create a token out of nothing is something to be handled with considerable care.
The name and usage of BEGIN_BLOCK in particular suggest a design problem, especially in conjunction with the fact that there is no corresponding END_BLOCK. Python's own parsing approach relies on the lexical analyzer to track indentation levels, and to emit synthetic indent and corresponding dedent tokens, as appropriate, when the indentation level changes. Sometimes a sequence of multiple dedents must be emitted to maintain correct indent / dedent pairing. And again, indents and dedents correspond to indentation level changes, not individual characters.
Making the lexer track indents and corresponding dedents allows for grammatic rules along these lines:
if_stmt: IF conditional_expr COLON block optional_else ;
optional_else: /* empty */
| ELSE COLON block
;
block: INDENT stmts DEDENT ;
stmts: stmt
| stmts stmt /* note _left_ recursion */
;
stmt: ...
conditional_expr: ...
Note that the block structure is completely unambiguous -- a block begins with an indent and ends with a matching dedent. Although it may not be immediately obvious, that takes care not only of ambiguities such as arise from your empty BEGIN_BLOCK productions, but also ambiguities such as arise from your rules providing for optional else clauses. The latter are addressed because now the grammar allows at most one if with which any given else can pair.
You could do similar.