Revamp parse function interface

[Krzmbrzl]

See individual commits.

TODO:

• Make options take syntax version param
• Provide explicitly namespaced/versioned access to parse/deparse
• Implement defaulted parse/deparse

[evaleev]

is this a good time to revisit the "incosistent" naming?

• deparse is similar to to_latex but names are very different ... how about to_sqtext or to_sqmath
• deparse is seemingly only a word used in R language (i.e. it's not an actual word)
• parse_expr and parse_result_expr are factories, make_expr and make_result_expr would be more in line with naming of factories in SQ and elsewhere ...

[Krzmbrzl]

If we do make changes, now would indeed be a good moment.

I kinda like the symmetry between the parse and deparse function names. We don't really have that with the alternate names you suggested...

Also, given that what we do is parsing, I would prefer to actually have parse in the name 👀

[evaleev]

I kinda like the symmetry between the parse and deparse function names. We don't really have that with the alternate names you suggested...

I like the symmetry too. I like design precision even more.

Can keep it, but not in the top-level namespace. The issue with these names (and the reason for this PR) is that these must be specific to a format that they refer to (and with parse_* function we must declare explicitly what we are constructing). So we must namespace them. So perhaps what we need is:

sequant::io::latex::parse...;
sequant::io::latex::deparse;  // does this exist? At some point deparse actually took pure latex as input ...
sequant::io::sqtext::v1::parse...;
sequant::io::sqtext::v1::deparse;
sequant::io::sqtext::v2::parse...;
sequant::io::sqtext::v2::deparse;

To avoid such long names we still need top-level sugar, such as to_latex. I propose to_text for sqtext::default::deparse and from_text<{Expr,ResultExpr}> as top-level sugar.

Also, given that what we do is parsing, I would prefer to actually have parse in the name 👀

Parsing is an implementation detail, name should reflect what users care about (to_text, from_text ... how these are implemented? They should not care).

[evaleev]

so perhaps this is what I have in mind:

sequant::io::latex::to;
sequant::io::latex::from...;
sequant::io::sqtext::v1::to;
sequant::io::sqtext::v1::from...;
sequant::io::sqtext::v2::to;
sequant::io::sqtext::v2::from...;
using namespace sequant::io::sqtext::default = sequant::io::sqtext::v1;
sequant::to_latex = sequant::io::latex::to;
sequant::to_text = sequant::io::sqtext::default::to;
etc.

[Krzmbrzl]

I like the idea of an io namespace that bundles all different input/output formats. I would probably use function names serialize and deserialize instead of to and from though. To me that makes the function calls appear a bit more natural… I guess with to and from I would kinda expect the format to be attached as to_latex and from_latex rather than latex::to and latex::from.

However, since not all of these formats are intended to be roundtrip-capable (e.g. LaTeX only works in the expression-to-string direction afaict) serialize is probably not quite correct (though I think we could use serialize instead of sqtext). So maybe using to_string and from_string instead is the way to go?

Something like

sequant::io::latex::to_string;
sequant::io::serialization::to_string; //Note: these are actual implementations that do the forwarding at runtime
sequant::io::serialization::from_string;
sequant::io::serialization::v1::to_string;
sequant::io::serialization::v1::from_string;
sequant::io::serialization::v2::to_string;
sequant::io::serialization::v2::from_string;

// Note sure if we really should define these (users can bring the functions in their namespace as desired)
sequant::to_latex = sequant::io::latex::to_string;
sequant::serialize_to_string = sequant::io::serialization::to_string;
sequant::deserialize_from_string = sequant::io::serialization::from_string;