I did an initial sketch of this idea in this PR: #9
The premise is based purely on my own experience: I found quoting hard to understand until I encountered it explained as a 'code/data transformation'.
I think this idea could be used to add clarity to quoting in this new tidyeval documentation.
Take this first para introducing quoting functions:
On the other hand, a quoting function is not passed the value of an expression, it is passed the expression itself. We say the argument has been automatically quoted. The quoted expression might be evaluated a bit later or might not be evaluated at all. The simplest quoting function is quote(). It automatically quotes its argument and returns the quoted expression without any evaluation. Because only the expression passed as argument matters, none of these statements are equivalent:
It does not define quoting. It also says about quote:
It automatically quotes its argument and returns the quoted expression without any evaluation.
Which I found very confusing until I learned of the 'expert' definition of 'evaluate' it employs - which requires some appreciation of parser + evaluator model.
Using the code/data transform idea:
On the other hand, a quoting function is not passed the value of an expression, it is passed the expression itself as data. We call the process of converting an expression to data quoting. The quoted expression might be evaluated a bit later or might not be evaluated at all. The simplest quoting function is quote(). It automatically quotes its argument and returns the quoted expression as data. Because it not the value of the expression, but its representation as data that matters, none of these statements are equivalent:
It defines quoting explicitly 'the process of converting an expression to data'. It avoids saying 'unevaluated' and in turn avoiding the need for explanation of interpreter internals.
There are a couple of further ideas in the PR. Please accept this as a genuine suggestion based on a frame of explanation I found useful as a conceptual newcomer. A blog post I wrote exploring this idea was received well with many independent positive expressions of feedback. This gives me some confidence in its broader applicability and appeal.
I did an initial sketch of this idea in this PR: #9
The premise is based purely on my own experience: I found quoting hard to understand until I encountered it explained as a 'code/data transformation'.
I think this idea could be used to add clarity to quoting in this new tidyeval documentation.
Take this first para introducing quoting functions:
It does not define quoting. It also says about
quote:Which I found very confusing until I learned of the 'expert' definition of 'evaluate' it employs - which requires some appreciation of parser + evaluator model.
Using the code/data transform idea:
It defines quoting explicitly 'the process of converting an expression to data'. It avoids saying 'unevaluated' and in turn avoiding the need for explanation of interpreter internals.
There are a couple of further ideas in the PR. Please accept this as a genuine suggestion based on a frame of explanation I found useful as a conceptual newcomer. A blog post I wrote exploring this idea was received well with many independent positive expressions of feedback. This gives me some confidence in its broader applicability and appeal.