Deparsing API

[lionel-]

Meta-issue about the deparsing API:

Naming

• I'm not sure why we duplicated the API with expr_ and quo_ functions. Isn't it simpler to just treat quosures as any other language type and deal with them in expr_ functions as well?

• Perhaps relevant for naming: These functions are about pretty printing, while expr_deparse() is about transferring R objects as text. Though the latter also has pretty printing features such as omitting the last n elements of vectors.

• The naming of expr_text(), expr_name() etc generally suggests they are accessors. In reality they are actions (deparse variants).

• Are expr_name() and quo_name() misnomers? It seems it should only be used to provide default names for quoted arguments that might be complex expressions. I often see it used for transforming symbols to strings, which should better be done with as_string() or as.character() (the former works better on Windows with foreign characters).

  Perhaps expr_pretty_name() would be more suggestive that it's about default names?

Features

• Do we need a _line() variant? We are using _name() for backtraces, it seems we are really after line. It should try to deparse as much of an expression as possible while keeping it on a same line and within peek_option("width"). It should take a column position as argument to be substracted from width.

[hadley]

Maybe _abbr, _line, _full

And maybe deparse_, or label_?

[lionel-]

Squash quosures with the label variant but represent them with ^ with the other variants?

[krlmlr]

I was searching for quo_text() but didn't find this issue. Good it's linked from the docs ;-)

Is it safe to use quo_text() for now?

[lionel-]

If you need a multi-line deparser yes. It'll go through a long lifecycle of deprecation.

[lionel-]

Discussion continues in #1173.