search

mna / pigeon

Command pigeon generates parsers in Go from a PEG grammar.
BSD 3-Clause "New" or "Revised" License
821 stars 66 forks source link

Add type safety #62

Open felipellrocha opened 6 years ago

felipellrocha commented 6 years ago

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 commented 6 years ago

@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 commented 2 years ago

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

breml commented 2 years ago

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 commented 1 month ago

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#?