Add simple pretty-printer extension mechanism

[smowton]

Despite its name, expr2c is the de facto global default pretty-printer.
This allows an extension module to register a handler for expr types
that expr2c cannot do by itself.

[tautschnig]

What about the slightly different design of making convert_norep virtual (plus possibly renaming it), permitting solving this via inheritance instead of events/listeners?

[peterschrammel]

We should forbid using expr2c directly, but use languaget::from_expr() instead. So, all the pretty printing of expressions is done regardless of the language. If you need a specialised version of an expression pretty printer it should be configured through the language interface.

[smowton]

I was initially going to do either / both of these. I did it this way instead because:

1. We need to catch not just direct from_expr(some_special_expr), but also e.g. from_expr(member_exprt(some_special_expr, ...)), which will be processed via expr2ct::convert not via another call to from_expr. I therefore need to at least override convert, rather than get in at from_expr which only gets a chance to intervene at top level.
2. If I want from_expr to use my extended version of expr2ct then I'll need to become the default language (supplanting ansi_c_languaget at the head of the registered-languages vector) which doesn't sound great-- I don't want to be the default language, I just want to augment the pretty-printer that is the de facto fallback.

[smowton]

Looking further at this, @tautschnig's solution doesn't really work because we have the existing situation:

expr2javat <: expr2ct

So if I wrote some new subclass of expr2ct that added support for printing some particular expression, it would have to be included in the hierarchy in both cases-- ideally I want to go underneath expr2ct since the thing I'm printing is language-independent. This recommends a pointer-to-parent rather than inherits-from-parent pattern.

Therefore, possibilities:

1. Create two variants of my custom printer that inherit from expr2ct and expr2javat; override from_expr to return those instead of the base types.

2. Make a bigger change and rewrite the whole thing in explicit adapter style:

custom_pretty_printert --has-pointer--> expr2javat --has-pointer--> expr2ct

This would require each to hold a pointer to the top level and use it to execute recursive convert calls.

3. Add an explicit delegation model to expr2ct, which is this PR's current approach.

[marek-trtik]

If I may, I'd propose this solution for the consideration:

• Extension of "expr2c.h":

typedef std::function<std::string(const irept &, const namespacet &)> pretty_printert;
typedef std::map<irep_idt,pretty_printert> custom_pretty_printerst;

std::string expr2c(const exprt &expr, const namespacet &ns, const custom_pretty_printerst &cpps);
std::string type2c(const typet &type, const namespacet &ns, const custom_pretty_printerst &cpps);

(optional:)

bool register_custom_pretty_printer(const irep_idt &token, const pretty_printert &pp);
void unregister_custom_pretty_printer(const irep_idt &token);

• Extension of "expr2c_class.h" and "expr2c.cpp" :

Parameter list of each method "class expr2ct::convert_*" will be extended by
one parameter "const custom_pretty_printerst &cpps".

In all the methods there will be first added the code:

if(cpps.count(some_irep.id())!=0UL)
return cpps.at(some_irep.id())(some_irep,ns);

before the original processing of some_irep.

(optional:)

custom_pretty_printerst &get_registered_custom_pretty_printers()
{
static custom_pretty_printerst cpps;
return cpps;
}

bool register_custom_pretty_printer(const irep_idt &token, const pretty_printert &pp)
{
return get_registered_custom_pretty_printers().insert({token,cpp}).second;
}

void unregister_custom_pretty_printer(const irep_idt &token)
{
get_registered_custom_pretty_printers().erase(token);
}

std::string expr2c(const exprt &expr, const namespacet &ns)
{
return expr2c(expr,ns,get_registered_custom_pretty_printers())
}

std::string type2c(const typet &type, const namespacet &ns)
{
return type2c(expr,ns,get_registered_custom_pretty_printers())
}

[smowton]

Apologies Marek, crossed over with your proposed solution, but see what you think of the current solution. @peterschrammel @tautschnig here's how it works now:

• Language frontends can return a pretty-printer instance
• Anyone can register a plugin pretty-printer, which will go beneath the language frontend to handle expressions it can't
• The convert-norep printer is always last in the chain.
• All printers, including the language frontend printer, have a next_pretty_printer pointer for deferral and a top_pretty_printer pointer for subexpressions.

However:

• The actual frontend printers still use direct recursion to format subexpressions, as there are a lot of cases to check. This works so long as they are always the head of the chain (so this == top_pretty_printer)
• Java, Jsil, C++ still derive from expr2ct rather than explicitly calling into it-- this works fine, as they live in the same repository. Again it would be quite a bit of work to rework them for no gain.

Since I can't really afford to spend a week fixing these last two for no gain, I suggest we do that later if ever, and simply make it a rule that the parser returned from languaget::get_pretty_printer always gets to be the head of the printer chain.

[peterschrammel]

@smowton, as far as I see the necessity for your proposed mechanism arises from the desire to pretty-print language-independent expressions that are not part of the master branch.

Your proposal has the advantage that additional expressions can be handled on the language-independent level whereas subclassing would allow language-dependent implementations only (to handle additional expressions by overriding the "else" case).

Question: The way you can print these expressions in a language-dependent fashion is by registering a language-specific version of a pretty-printer that can handle these additional expressions. Is this what you had in mind?

[smowton]

I didn't plan to do anything language-dependent here, but yes we could extend this by allowing language-specific extensions that are only placed in the stack when a particular language is at the top. The current extensions are put in the stack between the language pretty-printer and the fallback print-as-lisp routine, regardless of the language in question.

I suggest that I shouldn't implement that particular hook here, as to implement a hook that I don't have a user for invites the hook to decay as it is unused, and it seems likely whenever the first user comes along their exact needs won't quite align with my guess now. Instead I suggest if this approach is basically suitable I will add commentary to make clear this approach's limitations, and the possible extensions that might be useful to future users with somewhat-different needs.

[smowton]

Revised this to fix inconsistent override usage, and ensure pretty-printers are always instantiated with a fallback printer instance. Also documented. Waiting for CI...