From murdoch.duncan at gmail.com  Thu May 12 20:37:42 2011
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Thu, 12 May 2011 14:37:42 -0400
Subject: [Rd] Recursively parsing srcrefs
In-Reply-To: <BANLkTikpgh27=EJGnmfrmuQ7QBh1vV-Qkw@mail.gmail.com>
References: <BANLkTikpgh27=EJGnmfrmuQ7QBh1vV-Qkw@mail.gmail.com>
Message-ID: <4DCC28F6.2090502@gmail.com>

On 12/05/2011 1:02 PM, Hadley Wickham wrote:
> Hi all,
>
> Is it possible to "recursively" parse srcrefs to match the recursive
> structure of the underlying code?  I'm interested in this because it's

I don't understand what you mean by that.  It is certainly possible to 
walk through nested srcrefs, to zoom in on a particular location; that's 
what findLineNum() does.
> the final step in allowing functions to modify other functions while
> preserving the original source. I've tried to make a bit of demo of
> what I want to do below, and I think I may uncovered a bug in parse.
>
> f<- function(x = T) {
>    # This is a comment
>    if (x)                  return(4)
>    if (emergency_status()) return(T)
> }
>
> parsed_src<- parse(text = attr(f, "source"))
> src_ref<- attr(parsed_src, "srcref")[[1]]
>
> f_one<- parse(text = "{
>    # This is a comment
>    if (x)                  return(4)
>    if (emergency_status()) return(T)
> }")
> attr(f_one, "srcref")[[1]]
>
> f_inside<- parse(text = "
>    # This is a comment
>    if (x)                  return(4)
>    if (emergency_status()) return(T)
> ")
> f_inside # Displays incorrectly?
> attr(f_inside, "srcref")[[1]]
> # Should be:
> #  # This is a comment
> #  if (x)                  return(4)


That last display looks like a bug indeed.  I'll take a look.

Duncan Murdoch



[Rd] Recursively parsing srcrefs
Duncan Murdoch