recursive descent parser
Go fmt

First off, always go fmt your source code. The best thing about Go is that it always looks the same. 

Godoc

Follow the godoc standard for comments. When commenting a function, start with the function name, capitalized, and end with a dot. Use proper grammar (like capital letter after punctuation). This makes automatically generated documentation look great, and further normalizes how Go code looks. TokenStack represents the input stack. is a good first sentance to start with. 

(Actually, maybe TokenStack should be named InputStack, if that's what it really is?)

Const

Using iota to assign a single value like you are doing looks wierd. It's not that clear what you are doing. 

const T_NUM = 1


or

const T_NUM = iota+1


or actually use the first value; make the nil value useful:

const (
    T_UNKNOWN = iota
    T_NUM
)


Usually, there is more than one constant. Since you're only using one, I'm wondering if it would be better to remove it as well. Every valid token is T_NUM, after all, so why have a constant for it in the first place? 

Type

If you are going to use T_NUM as an enum, give it a type. Right now, T_NUM is just a constant integer. That means we can do weird things like T_NUM + T_NUM * 5. If we define a new type, such as type TokenType int and then make T_NUM a constant TokenType instead, we get a compililation error, since multiplying a TokenType by a number doesn't make sense. In many C-like languages, like C and C++, defining a new type like this wouldn't help, but in Go, types are real types, not type aliases.

Package main

You're starting the file with package main but there's no func main() in the source code. It looks like this is a library package, and in that case, the package name should be changed. The Go Blog has a great post about naming packages and things in packages. 

NoMatch

It feels like NoMatch should be an error (for example `var NoMatch = errors.New("could not match TokenStack to known rules"). Right now it looks like C-code. 

Exporting everything

Everything in your package is exported. You probably want some of the functions or types to be package-local. I'd aim for only exporting a single function: Parse. That way, it's super simple for someone to get started with the package. V and T should definitely not be exported as they stand, but if they have to be exported, they should probably be renamed. 

Package testing only gets away with exporting T because that's almost the only thing it's exporting, and everytime you use it, you write testing.T. The name of the package helps explain what T is.

In-bound errors

Some of your functions return NoMatch on error, which is just -1. This is a common way of doing things in C or C++, but not in Go. It's usually better to return multiple values, the last one being an error, so that the caller can know how to check for errors without having to read the documentation first. Maybe all negative return values are errors, or just -1. What happens if the library updates and adds another possible return value; do we get subtile bugs? Is 0 an error? atoi is a good example. In C, there's no way of knowing if it encountered an error (or if it just parsed the string "0"). In Go, it returns (int, error).

if else if else if else if

The Go switch statement is very powerful and can be used instead of long if/elseif/elseif/else statements. If you omit the argument to switch it looks at the cases one by one until it finds one that is true, just like a long if/elseif/elseif statement does. In this case, however, since you need semicolons in your if-statements, switch does not work. Just a pointer for future code.