Arbitrary callbacks on the input tree

[robertodr]

Should we add the possibility to perform arbitrary operations on the input tree? At the moment we have callables for defaulting and predicate checking. The former can modify the input tree, but only to fill default values, the latter are only allowed to return booleans. @stigrj has a really good use case of modifying an entry in the dictionary to a value with an entirely different type (reading in the molecule from a multiline string to a dictionary of lists) We could add an actions field to keywords a hook to run arbitrary operations after predicate checking. This sort of throws out of the window the whole type checking thing, but gives a lot of flexibility to the users of the library. I can see the argument against: parselglossy parses and gives you an input tree, what you do afterwards is up to you and if you screw it up, it's on you.

[bast]

In this use case (converting molecule string to a dictionary of lists) - this is done to simplify parsing on the client side, right? Do we have other use cases?

I am a bit worried to make the library "too flexible" but I see the advantage of a finer-grained parsing of values through actions.

[bast]

An action could be a function which takes the value and returns a dictionary of keys and values which would be attached to the current dictionary node.

The action would not modify other nodes and would not depend on values or defaults "outside" since this would make dependency scanning difficult and the model brittle.

Discussing this with Stig and Roberto we have concluded to postpone this functionality until later to reduce the number of "moving parts". We may implement this after other issues have been addressed.

[robertodr]

And here is a picture from the discussion

[bast]

An action could be a function which takes the value and returns a dictionary of keys and values which would be attached to the current dictionary node.

The dictionary would replace the current leaf/node instead of attaching to it.

[robertodr]

We decided that it's out of scope for the library. Any further modifications of the validated input can be done in an external layer by the users.