Closed hoshsadiq closed 4 years ago
One of the things I like most about this library is that the behaviour is very well-defined and intuitive, even for edge cases. Adding such an option would open room for interpretation and will yield results, even if an error was expected. It won't be clear which syntax errors would actually be propagated to the user, and which would be interpreted as strings and string-concatenations.
Unfortunately, adding such a feature as a configurable opt-in is currently not possible due to how the library functions. It would require a completely different set of yacc expressions that can't be easily integrated into the current ruleset. That's also the reason why I didn't make any progress on #3.
To add such a feature (or any kind of configuration that influences the syntax / yacc ruleset), the library would probably need to take a different approach. Instead of evaluating the expressions during parsing, it would need to build an intermediate AST instead. Afterwards, this AST can be evaluated by go-code, which is then able to react differently, based on the given configuration.
I've no experience in goyacc so not sure how I would be able to implement this, but it would be nice if it we can have a setting where it would automatically default unresolved things as a string, and concat it. E.g.
Hello World
Hello World
Hello "World"
Hello World
Hello " World"
Hello World
(that is two spaces betweenHello
andWorld
)Hello strlen(World) World
Hello 5 World
World=Hosh
Hello World
Hello Hosh
This obviously would be an optional setting rather than the default.