[Rd] removeSource() vs. function literals

[Ivan Krylov]

Thanks for the comments and sorry I didn't reply sooner!

On Thu, 30 Mar 2023 12:38:24 -0400
Duncan Murdoch <murdoch.duncan using gmail.com> wrote:

> You'd need to recurse through all expressions in the object.  Some of
> those expressions might be environments, so your changes could leak
> out of the function you're working on.

In my efforts to get arbitrary objects to hash consistently, I already
walk them recursively, but I do stop at environments. (In theory, it
could be possible to create mock environments with the same
relationships between each other and then "fix up" and hash their
contents, but it's hard to do right. Imagine environments e1 and e2
where e1$other <- e2 and e2$other <- e1.)

I think that removeSource() already walks language objects recursively,
it just doesn't remove source references from unevaluated function
expressions.

> Things are simpler if you know the expression is the unmodified
> result of parsing source code, but if you know that, wouldn't you
> usually be able to control things by setting keep.source = FALSE?

I receive the expression object from substitute(). The idea is to hash
the expression, locate and hash its dependencies and then see if
there's already a file named like the resulting hash. In theory, the
user could be constructing elaborate scary-looking expressions and then
calling my function on them, but I think I can be reasonably certain I
get the calls straight from the parser. Unfortunately, this doesn't put
me in a position to be controlling options(keep.source=...).

> Maybe a workable solution is something like parse(deparse(expr,
> control = "exact"), keep.source = FALSE).

Thanks for this idea! At some point I was considering hashing text
representations of objects, but then I got serialize()-hashing working
and forgot about it.

-- 
Best regards,
Ivan