Add type safety

[felipellrocha]

Dealing with interfaces can be quite burdensome. Why not add type safety to the project?

The data matched by a single character matcher type byte, and if you are matching multiple items it's always an [] of whatever type underlies it. And instead of using simple { } go blocks, have it with a bit more detail, but details that define types. Something like this: [int, error] { } that defines we'll be returning an int, and an error

[breml]

@felipellrocha we are aware of the fact, that dealing with the interface{} everywhere is not funny and therefore, having static typing is on the wishlist. Feel free to move forward with this and write an initial PR.

That being said, I am not yet sure, what the best way to implement this would be.

[delaneyj]

Does the generics now in 1.18beta1 help makes this more tractable?

[breml]

Hi @delaneyj
Interesting question. I doubt, that generics alone do improve the situation. I assume, that an extension of the PEG grammar would be needed as well. But I have to admit, that I did not think about this at length.

[fy0]

It seems ok, but i'm not clear about the influence on performance.
Because any is used everywhere in pigeon, a label grammar example:
Add <- A:expr op:"+" B:expr
While Add parsing, a map[string]any was created and use to set A, op, B.
Actually it's not very difficult to get real type of A and B if we add a type hint.
But we must set a value with "TypeX" to map[string]any, then get it by m["A"].(TypeX), is it cost more cpu time due to type assertion? Is it like box and unbox in java/c#?