That turns this:

  prod[2][1] = a[2][1]*b[1][1]+a[2][2]*b[2][1];

For something more interesting on the English side of things, let's look at our variable declarations (trimming away much detail).

declaration :
    declaration_specifiers init_declarator_list(?) ';'

init_declarator_list :  
{
    my @init_decl_list = @{$item[1]}; 
# Once again, we dereference to get the array the  
# construct gives us. There could be 1, 2, or more
# declarators. Each one we have to handle differently. 
    my $last = ''; 

    if ($#init_decl_list > 1) {
# To avoid calling up the ghost of E.B. White, 
# in the plural case we have to separate the declarators
# by commas (funny how English and C share this requirement), and
# add the word "and" before the last one:
        $last = pop @init_decl_list; 
        $return = 'the variables ' . join(', ', @init_decl_list) . ', and ' . $last;
    } elsif ( $#init_decl_list == 1 ) { 
# In the dual case, we don't have to use commas:
        $return = 'the variables ' .  $init_decl_list[0] . ' and ' .$init_decl_list[1];
    } else { 
# And in the singular case things are easy:
        $return = 'the variable ' . $init_decl_list[0]; 
    }
}

{
	$return = "Specifying the type $item{declaration_specifiers}, allocate "; 
	$return .= join('',@{$item{init_declaration_list}}) . ".\n"; 
}

        unsigned int lfsr1_lo,lfsr1_hi,lfsr0,combined;
        byte o_lfsr0, o_lfsr1;

There are a few more tricks we need to use for this task. For example, we could parse an assignment expression succesfully as a complete statement or as part of one. This is where the %arg hash rescues us. We write the rule for an assignment operator this way:

assignment_operator : 
    '=' 
{
    if ($arg{context} eq 'statement') { 
        $return = ['Assign to', ' the value' ] ; 
    } else { 
        $return = ', which is assigned to be '; 
    }
}

assignment_expression : 
    unary_expression[context => $arg{context}] 
    assignment_operator[context => $arg{context}] 
    assignment_expression[context =>  'assignment_expression'] 

    if ($arg{context} eq 'statement' ) { 
        $return .= "${$item{assignment_operator}}[0] $item{unary_expression}${$item{assignment_operator}}
[1] \"$item{assignment_expression}\".\n";
    } else {
        $return = "$item{unary_expression}, $item{assignment_operator} $item{assignment_expression}"; 
    } 

Another issue that comes up is when we need to know what comes after a rule we've parsed. For example, when we use '-' as a unary operator (e.g. "foo = -bar; baz = -1;"), we need to know what comes afterwards because standard usage in seventh grade is "minus b" but "negative one". One way to solve this is to do this in the rule for a unary operator:

unary_operator : [ other things] 
	| '-' ...constant {$return  = 'negative ';}
	| '-' {$return = 'minus ';}

Having figured out that the correct way to verbalize mathematical expressions is to spell them out in the drone of a math teacher, and that this lets us make our script work faster since we can cut down the number of rules in that series from ten to two, we've taken care of the hardest issues. Compared to that, it's easy to verbalize the flow control statements in C, and the function definitions. The simpler expressions, are, well, simpler. It's easy to translate "foo(bar);" to "Perform the function 'foo' as applied to the argument 'bar'." In fact, to do so requires no more tricks than what we've done in the examples above. But there is another issue we have to cover, which the is parsing of parentheses in an expression.

In mathematics, parentheses allow us to bypass the rules of operator precedence. Unfortunately, parems don't translate well to human discourse, because what they conceptually do is set up a context stack. Our minds do implement a stack, which lets our attention change contexts as we deal with various aspects of our lives. But that stack is limited to 6 frames of context (for more elaboration on this, there is the wonderful "Godel, Escher, Bach, an Eternal Golden Braid", by Douglas Hofstader), and in conversation, a person will avoid hogging more than one of his listener's context frames. To do so is bad form in speaking and in writing, and this limitation plays a role in how our standards of writing and oration are shaped.

Painful as it may be to some, let's go back to that day in math class. You're taking your teacher's dictation on the blackboard, and there's a pair of parentheses. Your teacher might have just said "open parem, blah blah blah, close parem...", but for our purposes that's cheating. My 9th grade teacher would say "the quantity x plus y, now over z...", letting "the quantity" and "now" indicate motion on the stack. When we have to use our listener's stack in conversation, we might indicate such motion with hand gestures.

So, now, what do we do with parenthetical expressions in C code? We could replace each opening parem with "the quantity" and closing parem with "now", but what about nested parentheses? Repetitions of "the quantity" or of "now" are simply unacceptable for our purposes because we would never use them in writings or in speech. In class, we would raraely open or close consecutive parems, and rarely nest umpteen pairs of them. So here we have to spell out when we open several layers of them. Here's how:

primary_expression :  
    '('
    expression
    ')' 
{
    my $expression = $item{expression} ; 
    my $repeats = 1 ; 
    my $ending = 1 ; 
# We use these variables to keep track of layer numbers.
# If we have an expression that is already nested in the front,
# we remove the nesting.
    if ($expression =~  /^the (\\d+)-layered parenthetical expression/) { 
        $repeats= $1 +1 ; 
        $expression =~ s/^the \\d+-layered parenthetical expression //;
# If we have to start the nesting, we do this:
    } elsif ($expression =~  /^the parenthetical expression/) { 
        $repeats =2 ; 
        $expression =~ s/^the \\d+-layered parenthetical expression //;
    } 
# So for now the internal parems are gone.
# Now, to the rear of our expression:
    if ($expression =~ / now$/) { 
        $ending ++; 
        $expression =~ s/ now$//; 
        $expression .= " (now drop $ending layers of context)" ; 
    } elsif ($expression =~ /now drop (\\d+) layers of context\)$/ ) { 
        $ending =~ $1 +1; 
        $expression =~ s/\\d+ layers of context\)$/$ending layers of context \)/
; 
    } else { $expression .= ' now'; } 
# Finally, we wrap the expression in our pair of parems:
    if ($repeats > 1) { 
        $return =
            "the $repeats-layered parenthetical expression $expression"; 
    } else { 
        $return =
            "the parenthetical expression $expression"; 
    }
# And one more detail: if we're closing the parentheses at the very
# end of the C statement, we don't need to bother with the word "now."
    if ($text =~ /^;/) {
        $return =~ s/ now$//;
    } 
}

So now, when we start a set of nested parems, we say "the 22-layered parenthetical expression" (I'll take a poll on whether "the 22-layered quantity" makes for better style), and if we close multiple sets, we say so: "(now drop 22 layers of context)". Since such a statement does interrupt the flow of expression, it's good form to put it in, yes, parentheses.

So, the c2eng whole script (1400 lines) is available http://www.mit.edu/~ocschwar/c2eng

There are still many extant issues. When the C compiler sets about to do its work, it first strips out the comments and runs the C preprocessor. We don't. This means comments and preprocessor directives could interrupt the C code anywhere and in any context. The script is limited in its ability to handle that, at the moment, (it can handle CPP directives and comments only between statements) but I am working on it. A run against a certain piece of controversial C code has succeeded. Finally, there's the issue of translating C back to English for the purpose of the demonstration. Since the script spells things out very explicitly, the eng2c reverse script should be easier to write than the c2eng, but writing it may have to wait until c2eng reaches the 1.0 stage.

{
      $return = "This program makes use of the system file $item{filename}.\n" ;  
}

inclusion : 
    'This' 'program' 'makes' 'use' 'of' 'the' 'system' 'file'
    filename '.'
{
    $return =
        "\n#include <$item{filename}>\n"; 
}