Re: [Rd] substitute

[Martin Maechler]

> Duncan Murdoch 
> on Mon, 15 Nov 2021 13:06:23 -0500 writes:

> I'd recommend responding now with a pointer to that bug
> report: whoever at CRAN is dealing with your package
> doesn't necessarily know about the bug report.  You might
> or might not need to make a change in the end, but if you
> do, it could be hard to meet the two week deadline.

> Duncan Murdoch

With thanks to Duncan and Adrian:

Just in case, Adrian  hasn't been following R's bugzilla PR#18232
i.e.  https://bugs.r-project.org/show_bug.cgi?id=18232

There have been extra patches to fix more cases of deparsing
while being more back compatible than what's been in R-devel for
a couple of days.

Notably the changes do revert to previous behavior for the
example you give;  and indeed QCA  passes its own checks again,
after applying the patches.

The changes are under review currently, but the plan is to
commit the changes within a few days.
(read on)

> On 15/11/2021 12:58 p.m., Adrian Dușa wrote:
>> Thank you, I was given a deadline of two weeks to
>> respond, hopefully this will be settled by then.  Best
>> wishes, Adrian
>> 
>> On Mon, 15 Nov 2021 at 19:28, Duncan Murdoch
>> > > wrote:
>> 
>> This looks as though it is related to the recent patch in
>> 
>> https://bugs.r-project.org/show_bug.cgi?id=18232
>> 
>> 
>> I think you should probably wait until that settles down
>> before worrying about it.
>> 
>> Duncan Murdoch
>> 
>> On 15/11/2021 12:18 p.m., Adrian Dușa wrote: > Dear R
>> wizards,
>> >
>> > I have recently been informed about some build errors
>> of my package QCA, > which I was able to trace down to
>> the base function substitute(), with the > following
>> replication example:

foo <- function(x) return(substitute(x))

## In the stable R version 4.0.5, I get the expected result:

foo(A + ~B + C~D)
## A + ~B + C ~ D

BTW: no need for foo()  {and even less for a return(.) in a 1-liner !}

Be assured that we agree that

quote(A + ~B + C~D)

should not "gain" any parentheses, indeed, and what you've been
seeing can well be considered an intermediate step in iterations
to get to improved deparsing in subtle situations.


Thank you for the report, and best regards,
Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute

[Duncan Murdoch]

I'd recommend responding now with a pointer to that bug report: whoever 
at CRAN is dealing with your package doesn't necessarily know about the 
bug report.  You might or might not need to make a change in the end, 
but if you do, it could be hard to meet the two week deadline.


Duncan Murdoch

On 15/11/2021 12:58 p.m., Adrian Dușa wrote:
Thank you, I was given a deadline of two weeks to respond, hopefully 
this will be settled by then.

Best wishes,
Adrian

On Mon, 15 Nov 2021 at 19:28, Duncan Murdoch > wrote:


This looks as though it is related to the recent patch in

https://bugs.r-project.org/show_bug.cgi?id=18232


I think you should probably wait until that settles down before
worrying
about it.

Duncan Murdoch

On 15/11/2021 12:18 p.m., Adrian Dușa wrote:
 > Dear R wizards,
 >
 > I have recently been informed about some build errors of my
package QCA,
 > which I was able to trace down to the base function substitute(),
with the
 > following replication example:
 >
 > foo <- function(x) return(substitute(x))
 >
 > In the stable R version 4.0.5, I get the expected result:
 >> foo(A + ~B + C~D)
 > A + ~B + C ~ D
 >
 > A different result (the culprit for the build error) occurs under
Fedora
 > with R devel:
 >
 >> foo(A + ~B + C~D)
 > A + (~B + C) ~ D
 >
 > The Fedora machine is the rhub docker image from:
 > https://hub.docker.com/r/rhub/fedora-gcc-devel

 >
 > probably very similar to the one signalling the CRAN build error:
 > https://cran.r-project.org/web/checks/check_results_QCA.html

 >
 > The first (expected) command is from the stable R version
installed on the
 > same Fedora machine, and I get an identical result on Windows and
MacOS.
 >
 > For some reason, substitute() gives a different result on Debian
using gcc,
 > and on both Fedora systems. I would be grateful for any hint, I
am not
 > entirely certain what I should do about this.
 >
 > Thank you very much in advance,
 > Adrian
 >

__
R-devel@r-project.org  mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel




--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu 


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute

[Adrian Dușa]

Thank you, I was given a deadline of two weeks to respond, hopefully this
will be settled by then.
Best wishes,
Adrian

On Mon, 15 Nov 2021 at 19:28, Duncan Murdoch 
wrote:

> This looks as though it is related to the recent patch in
>
>https://bugs.r-project.org/show_bug.cgi?id=18232
>
> I think you should probably wait until that settles down before worrying
> about it.
>
> Duncan Murdoch
>
> On 15/11/2021 12:18 p.m., Adrian Dușa wrote:
> > Dear R wizards,
> >
> > I have recently been informed about some build errors of my package QCA,
> > which I was able to trace down to the base function substitute(), with
> the
> > following replication example:
> >
> > foo <- function(x) return(substitute(x))
> >
> > In the stable R version 4.0.5, I get the expected result:
> >> foo(A + ~B + C~D)
> > A + ~B + C ~ D
> >
> > A different result (the culprit for the build error) occurs under Fedora
> > with R devel:
> >
> >> foo(A + ~B + C~D)
> > A + (~B + C) ~ D
> >
> > The Fedora machine is the rhub docker image from:
> > https://hub.docker.com/r/rhub/fedora-gcc-devel
> >
> > probably very similar to the one signalling the CRAN build error:
> > https://cran.r-project.org/web/checks/check_results_QCA.html
> >
> > The first (expected) command is from the stable R version installed on
> the
> > same Fedora machine, and I get an identical result on Windows and MacOS.
> >
> > For some reason, substitute() gives a different result on Debian using
> gcc,
> > and on both Fedora systems. I would be grateful for any hint, I am not
> > entirely certain what I should do about this.
> >
> > Thank you very much in advance,
> > Adrian
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute

[Duncan Murdoch]

This looks as though it is related to the recent patch in

  https://bugs.r-project.org/show_bug.cgi?id=18232

I think you should probably wait until that settles down before worrying 
about it.


Duncan Murdoch

On 15/11/2021 12:18 p.m., Adrian Dușa wrote:

Dear R wizards,

I have recently been informed about some build errors of my package QCA,
which I was able to trace down to the base function substitute(), with the
following replication example:

foo <- function(x) return(substitute(x))

In the stable R version 4.0.5, I get the expected result:

foo(A + ~B + C~D)

A + ~B + C ~ D

A different result (the culprit for the build error) occurs under Fedora
with R devel:


foo(A + ~B + C~D)

A + (~B + C) ~ D

The Fedora machine is the rhub docker image from:
https://hub.docker.com/r/rhub/fedora-gcc-devel

probably very similar to the one signalling the CRAN build error:
https://cran.r-project.org/web/checks/check_results_QCA.html

The first (expected) command is from the stable R version installed on the
same Fedora machine, and I get an identical result on Windows and MacOS.

For some reason, substitute() gives a different result on Debian using gcc,
and on both Fedora systems. I would be grateful for any hint, I am not
entirely certain what I should do about this.

Thank you very much in advance,
Adrian



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute

[Adrian Dușa]

Dear R wizards,

I have recently been informed about some build errors of my package QCA,
which I was able to trace down to the base function substitute(), with the
following replication example:

foo <- function(x) return(substitute(x))

In the stable R version 4.0.5, I get the expected result:
> foo(A + ~B + C~D)
A + ~B + C ~ D

A different result (the culprit for the build error) occurs under Fedora
with R devel:

> foo(A + ~B + C~D)
A + (~B + C) ~ D

The Fedora machine is the rhub docker image from:
https://hub.docker.com/r/rhub/fedora-gcc-devel

probably very similar to the one signalling the CRAN build error:
https://cran.r-project.org/web/checks/check_results_QCA.html

The first (expected) command is from the stable R version installed on the
same Fedora machine, and I get an identical result on Windows and MacOS.

For some reason, substitute() gives a different result on Debian using gcc,
and on both Fedora systems. I would be grateful for any hint, I am not
entirely certain what I should do about this.

Thank you very much in advance,
Adrian

-- 
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
https://adriandusa.eu

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute inconsistent output

[Duncan Murdoch]

On 18/03/2020 1:36 a.m., Jan Gorecki wrote:

Dear R-devel,

Is there anything that we can do to make output of those call more
consistent? So the first one will return `c(1L, 2L)` rather than
`1:2`. Note that it is not related to compact integer sequence
introduced by altrep, it is reproducible on R 3.1.0 as well.

substitute(v+x, list(x=c(1L,2L)))
#v + 1:2
substitute(v+x, list(x=c(0L,2L)))
#v + c(0L, 2L)



That's purely the deparser (the returned value from substitute doesn't 
contain a call to ":"), but it's not optional.


So the output is consistent, it's the printing that is inconsistent.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute inconsistent output

[Jan Gorecki]

Dear R-devel,

Is there anything that we can do to make output of those call more
consistent? So the first one will return `c(1L, 2L)` rather than
`1:2`. Note that it is not related to compact integer sequence
introduced by altrep, it is reproducible on R 3.1.0 as well.

substitute(v+x, list(x=c(1L,2L)))
#v + 1:2
substitute(v+x, list(x=c(0L,2L)))
#v + c(0L, 2L)

Thank you,
Jan Gorecki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute() on arguments in ellipsis ("dot dot dot")?

[Jim Hester]

Assuming you are fine with a pairlist instead of a list avoiding the
`as.list()` call for dots2 saves a reasonable amount of time and makes it
clearly the fastest.

library(rlang)

dots1 <- function(...) as.list(substitute(list(...)))[-1L]
dots2 <- function(...) as.list(substitute(...()))
dots2.5 <- function(...) substitute(...())
dots3 <- function(...) match.call(expand.dots = FALSE)[["..."]]
dots4 <- function(...) exprs(...)

bench::mark(
  dots1(1+2, "a", rnorm(3), stop("bang!")),
  dots2(1+2, "a", rnorm(3), stop("bang!")),
  dots2.5(1+2, "a", rnorm(3), stop("bang!")),
  dots3(1+2, "a", rnorm(3), stop("bang!")),
  dots4(1+2, "a", rnorm(3), stop("bang!")),
  check = FALSE
)[1:4]
#> # A tibble: 5 x 4
#>   expression min mean
 median
#> 

#> 1 "dots1(1 + 2, \"a\", rnorm(3), stop(\"bang!\…   2.38µs   5.63µs
 2.89µs
#> 2 "dots2(1 + 2, \"a\", rnorm(3), stop(\"bang!\…   2.07µs3.1µs
2.6µs
#> 3 "dots2.5(1 + 2, \"a\", rnorm(3), stop(\"bang…471ns  789.5ns
638ns
#> 4 "dots3(1 + 2, \"a\", rnorm(3), stop(\"bang!\…   3.17µs   4.83µs
 4.22µs
#> 5 "dots4(1 + 2, \"a\", rnorm(3), stop(\"bang!\…   3.16µs   4.43µs
 3.87µs


On Mon, Aug 13, 2018 at 7:59 PM Hadley Wickham  wrote:

> Since you're already using bang-bang ;)
>
> library(rlang)
>
> dots1 <- function(...) as.list(substitute(list(...)))[-1L]
> dots2 <- function(...) as.list(substitute(...()))
> dots3 <- function(...) match.call(expand.dots = FALSE)[["..."]]
> dots4 <- function(...) exprs(...)
>
> bench::mark(
>   dots1(1+2, "a", rnorm(3), stop("bang!")),
>   dots2(1+2, "a", rnorm(3), stop("bang!")),
>   dots3(1+2, "a", rnorm(3), stop("bang!")),
>   dots4(1+2, "a", rnorm(3), stop("bang!")),
>   check = FALSE
> )[1:4]
> #> # A tibble: 4 x 4
> #>   expression  min mean
> median
> #>  
> 
> #> 1 "dots1(1 + 2, \"a\", rnorm(3), stop(\"bang!\"…   3.23µs   4.15µs
> 3.81µs
> #> 2 "dots2(1 + 2, \"a\", rnorm(3), stop(\"bang!\"…   2.72µs   4.48µs
> 3.37µs
> #> 3 "dots3(1 + 2, \"a\", rnorm(3), stop(\"bang!\"…   4.06µs   4.94µs
> 4.69µs
> #> 4 "dots4(1 + 2, \"a\", rnorm(3), stop(\"bang!\"…   3.92µs4.9µs
> 4.46µs
>
>
> On Mon, Aug 13, 2018 at 4:19 AM Henrik Bengtsson
>  wrote:
> >
> > Thanks all, this was very helpful.  Peter's finding - dots2() below -
> > is indeed interesting - I'd be curious to learn what goes on there.
> >
> > The different alternatives perform approximately the same;
> >
> > dots1 <- function(...) as.list(substitute(list(...)))[-1L]
> > dots2 <- function(...) as.list(substitute(...()))
> > dots3 <- function(...) match.call(expand.dots = FALSE)[["..."]]
> >
> > stats <- microbenchmark::microbenchmark(
> >   dots1(1+2, "a", rnorm(3), stop("bang!")),
> >   dots2(1+2, "a", rnorm(3), stop("bang!")),
> >   dots3(1+2, "a", rnorm(3), stop("bang!")),
> >   times = 10e3
> > )
> > print(stats)
> > # Unit: microseconds
> > #expr  min   lq mean median
> > uq  max neval
> > #  dots1(1 + 2, "a", rnorm(3), stop("bang!")) 2.14 2.45 3.04   2.58
> > 2.73 1110 1
> > #  dots2(1 + 2, "a", rnorm(3), stop("bang!")) 1.81 2.10 2.47   2.21
> > 2.34 1626 1
> > #  dots3(1 + 2, "a", rnorm(3), stop("bang!")) 2.59 2.98 3.36   3.15
> > 3.31 1037 1
> >
> > /Henrik
> >
> > On Mon, Aug 13, 2018 at 7:10 AM Peter Meilstrup
> >  wrote:
> > >
> > > Interestingly,
> > >
> > >as.list(substitute(...()))
> > >
> > > also works.
> > >
> > > On Sun, Aug 12, 2018 at 1:16 PM, Duncan Murdoch
> > >  wrote:
> > > > On 12/08/2018 4:00 PM, Henrik Bengtsson wrote:
> > > >>
> > > >> Hi. For any number of *known* arguments, we can do:
> > > >>
> > > >> one <- function(a) list(a = substitute(a))
> > > >> two <- function(a, b) list(a = substitute(a), b = substitute(b))
> > > >>
> > > >> and so on. But how do I achieve the same when I have:
> > > >>
> > > >> dots <- function(...) list(???)
> > > >>
> > > >> I want to implement this such that I can do:
> > > >>
> > > >>> exprs <- dots(1+2)
> > > >>> str(exprs)
> > > >>
> > > >> List of 1
> > > >>   $ : language 1 + 2
> > > >>
> > > >> as well as:
> > > >>
> > > >>> exprs <- dots(1+2, "a", rnorm(3))
> > > >>> str(exprs)
> > > >>
> > > >> List of 3
> > > >>   $ : language 1 + 2
> > > >>   $ : chr "a"
> > > >>   $ : language rnorm(3)
> > > >>
> > > >> Is this possible to achieve using plain R code?
> > > >
> > > >
> > > > I think so.  substitute(list(...)) gives you a single expression
> containing
> > > > a call to list() with the unevaluated arguments; you can convert
> that to
> > > > what you want using something like
> > > >
> > > > dots <- function (...) {
> > > >   exprs <- substitute(list(...))
> > > >   as.list(exprs[-1])
> > > > }
> > > >
> > > > Duncan Murdoch
> > > >
> > > >
> > > > __
> > > > R-devel@r-project.org mailing list
> > > > https://stat.ethz.ch/mailman/listinfo/r

Re: [Rd] substitute() on arguments in ellipsis ("dot dot dot")?

[lmo via R-devel]

A potential solution, at least in terms of producing the desired output, is the 
base R function alist:
> alist(1+2, "a", rnorm(3))
[[1]]
1 + 2

[[2]]
[1] "a"

[[3]]
rnorm(3)

> str(alist(1+2, "a", rnorm(3)))
List of 3
 $ : language 1 + 2
 $ : chr "a"
 $ : language rnorm(3)


luke

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute() on arguments in ellipsis ("dot dot dot")?

[Hadley Wickham]

Since you're already using bang-bang ;)

library(rlang)

dots1 <- function(...) as.list(substitute(list(...)))[-1L]
dots2 <- function(...) as.list(substitute(...()))
dots3 <- function(...) match.call(expand.dots = FALSE)[["..."]]
dots4 <- function(...) exprs(...)

bench::mark(
  dots1(1+2, "a", rnorm(3), stop("bang!")),
  dots2(1+2, "a", rnorm(3), stop("bang!")),
  dots3(1+2, "a", rnorm(3), stop("bang!")),
  dots4(1+2, "a", rnorm(3), stop("bang!")),
  check = FALSE
)[1:4]
#> # A tibble: 4 x 4
#>   expression  min mean  median
#>   
#> 1 "dots1(1 + 2, \"a\", rnorm(3), stop(\"bang!\"…   3.23µs   4.15µs  3.81µs
#> 2 "dots2(1 + 2, \"a\", rnorm(3), stop(\"bang!\"…   2.72µs   4.48µs  3.37µs
#> 3 "dots3(1 + 2, \"a\", rnorm(3), stop(\"bang!\"…   4.06µs   4.94µs  4.69µs
#> 4 "dots4(1 + 2, \"a\", rnorm(3), stop(\"bang!\"…   3.92µs4.9µs  4.46µs


On Mon, Aug 13, 2018 at 4:19 AM Henrik Bengtsson
 wrote:
>
> Thanks all, this was very helpful.  Peter's finding - dots2() below -
> is indeed interesting - I'd be curious to learn what goes on there.
>
> The different alternatives perform approximately the same;
>
> dots1 <- function(...) as.list(substitute(list(...)))[-1L]
> dots2 <- function(...) as.list(substitute(...()))
> dots3 <- function(...) match.call(expand.dots = FALSE)[["..."]]
>
> stats <- microbenchmark::microbenchmark(
>   dots1(1+2, "a", rnorm(3), stop("bang!")),
>   dots2(1+2, "a", rnorm(3), stop("bang!")),
>   dots3(1+2, "a", rnorm(3), stop("bang!")),
>   times = 10e3
> )
> print(stats)
> # Unit: microseconds
> #expr  min   lq mean median
> uq  max neval
> #  dots1(1 + 2, "a", rnorm(3), stop("bang!")) 2.14 2.45 3.04   2.58
> 2.73 1110 1
> #  dots2(1 + 2, "a", rnorm(3), stop("bang!")) 1.81 2.10 2.47   2.21
> 2.34 1626 1
> #  dots3(1 + 2, "a", rnorm(3), stop("bang!")) 2.59 2.98 3.36   3.15
> 3.31 1037 1
>
> /Henrik
>
> On Mon, Aug 13, 2018 at 7:10 AM Peter Meilstrup
>  wrote:
> >
> > Interestingly,
> >
> >as.list(substitute(...()))
> >
> > also works.
> >
> > On Sun, Aug 12, 2018 at 1:16 PM, Duncan Murdoch
> >  wrote:
> > > On 12/08/2018 4:00 PM, Henrik Bengtsson wrote:
> > >>
> > >> Hi. For any number of *known* arguments, we can do:
> > >>
> > >> one <- function(a) list(a = substitute(a))
> > >> two <- function(a, b) list(a = substitute(a), b = substitute(b))
> > >>
> > >> and so on. But how do I achieve the same when I have:
> > >>
> > >> dots <- function(...) list(???)
> > >>
> > >> I want to implement this such that I can do:
> > >>
> > >>> exprs <- dots(1+2)
> > >>> str(exprs)
> > >>
> > >> List of 1
> > >>   $ : language 1 + 2
> > >>
> > >> as well as:
> > >>
> > >>> exprs <- dots(1+2, "a", rnorm(3))
> > >>> str(exprs)
> > >>
> > >> List of 3
> > >>   $ : language 1 + 2
> > >>   $ : chr "a"
> > >>   $ : language rnorm(3)
> > >>
> > >> Is this possible to achieve using plain R code?
> > >
> > >
> > > I think so.  substitute(list(...)) gives you a single expression 
> > > containing
> > > a call to list() with the unevaluated arguments; you can convert that to
> > > what you want using something like
> > >
> > > dots <- function (...) {
> > >   exprs <- substitute(list(...))
> > >   as.list(exprs[-1])
> > > }
> > >
> > > Duncan Murdoch
> > >
> > >
> > > __
> > > R-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
http://hadley.nz

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute() on arguments in ellipsis ("dot dot dot")?

[Henrik Bengtsson]

Thanks all, this was very helpful.  Peter's finding - dots2() below -
is indeed interesting - I'd be curious to learn what goes on there.

The different alternatives perform approximately the same;

dots1 <- function(...) as.list(substitute(list(...)))[-1L]
dots2 <- function(...) as.list(substitute(...()))
dots3 <- function(...) match.call(expand.dots = FALSE)[["..."]]

stats <- microbenchmark::microbenchmark(
  dots1(1+2, "a", rnorm(3), stop("bang!")),
  dots2(1+2, "a", rnorm(3), stop("bang!")),
  dots3(1+2, "a", rnorm(3), stop("bang!")),
  times = 10e3
)
print(stats)
# Unit: microseconds
#expr  min   lq mean median
uq  max neval
#  dots1(1 + 2, "a", rnorm(3), stop("bang!")) 2.14 2.45 3.04   2.58
2.73 1110 1
#  dots2(1 + 2, "a", rnorm(3), stop("bang!")) 1.81 2.10 2.47   2.21
2.34 1626 1
#  dots3(1 + 2, "a", rnorm(3), stop("bang!")) 2.59 2.98 3.36   3.15
3.31 1037 1

/Henrik

On Mon, Aug 13, 2018 at 7:10 AM Peter Meilstrup
 wrote:
>
> Interestingly,
>
>as.list(substitute(...()))
>
> also works.
>
> On Sun, Aug 12, 2018 at 1:16 PM, Duncan Murdoch
>  wrote:
> > On 12/08/2018 4:00 PM, Henrik Bengtsson wrote:
> >>
> >> Hi. For any number of *known* arguments, we can do:
> >>
> >> one <- function(a) list(a = substitute(a))
> >> two <- function(a, b) list(a = substitute(a), b = substitute(b))
> >>
> >> and so on. But how do I achieve the same when I have:
> >>
> >> dots <- function(...) list(???)
> >>
> >> I want to implement this such that I can do:
> >>
> >>> exprs <- dots(1+2)
> >>> str(exprs)
> >>
> >> List of 1
> >>   $ : language 1 + 2
> >>
> >> as well as:
> >>
> >>> exprs <- dots(1+2, "a", rnorm(3))
> >>> str(exprs)
> >>
> >> List of 3
> >>   $ : language 1 + 2
> >>   $ : chr "a"
> >>   $ : language rnorm(3)
> >>
> >> Is this possible to achieve using plain R code?
> >
> >
> > I think so.  substitute(list(...)) gives you a single expression containing
> > a call to list() with the unevaluated arguments; you can convert that to
> > what you want using something like
> >
> > dots <- function (...) {
> >   exprs <- substitute(list(...))
> >   as.list(exprs[-1])
> > }
> >
> > Duncan Murdoch
> >
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute() on arguments in ellipsis ("dot dot dot")?

[Peter Meilstrup]

Interestingly,

   as.list(substitute(...()))

also works.

On Sun, Aug 12, 2018 at 1:16 PM, Duncan Murdoch
 wrote:
> On 12/08/2018 4:00 PM, Henrik Bengtsson wrote:
>>
>> Hi. For any number of *known* arguments, we can do:
>>
>> one <- function(a) list(a = substitute(a))
>> two <- function(a, b) list(a = substitute(a), b = substitute(b))
>>
>> and so on. But how do I achieve the same when I have:
>>
>> dots <- function(...) list(???)
>>
>> I want to implement this such that I can do:
>>
>>> exprs <- dots(1+2)
>>> str(exprs)
>>
>> List of 1
>>   $ : language 1 + 2
>>
>> as well as:
>>
>>> exprs <- dots(1+2, "a", rnorm(3))
>>> str(exprs)
>>
>> List of 3
>>   $ : language 1 + 2
>>   $ : chr "a"
>>   $ : language rnorm(3)
>>
>> Is this possible to achieve using plain R code?
>
>
> I think so.  substitute(list(...)) gives you a single expression containing
> a call to list() with the unevaluated arguments; you can convert that to
> what you want using something like
>
> dots <- function (...) {
>   exprs <- substitute(list(...))
>   as.list(exprs[-1])
> }
>
> Duncan Murdoch
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute() on arguments in ellipsis ("dot dot dot")?

[Jeroen Ooms]

On Sun, Aug 12, 2018 at 10:00 PM, Henrik Bengtsson
 wrote:
> Hi. For any number of *known* arguments, we can do:
>
> one <- function(a) list(a = substitute(a))
> two <- function(a, b) list(a = substitute(a), b = substitute(b))
>
> and so on. But how do I achieve the same when I have:
>
> dots <- function(...) list(???)
>
> I want to implement this such that I can do:
>
>> exprs <- dots(1+2)
>> str(exprs)
> List of 1
>  $ : language 1 + 2
>
> as well as:
>
>> exprs <- dots(1+2, "a", rnorm(3))
>> str(exprs)
> List of 3
>  $ : language 1 + 2
>  $ : chr "a"
>  $ : language rnorm(3)
>
> Is this possible to achieve using plain R code?

You could use match.call, for example:

  dots <- function(...) match.call(expand.dots = FALSE)[['...']]

Note that this returns a pairlist, so if you want an ordinary list you
should wrap it in as.list()

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute() on arguments in ellipsis ("dot dot dot")?

[Duncan Murdoch]

On 12/08/2018 4:00 PM, Henrik Bengtsson wrote:

Hi. For any number of *known* arguments, we can do:

one <- function(a) list(a = substitute(a))
two <- function(a, b) list(a = substitute(a), b = substitute(b))

and so on. But how do I achieve the same when I have:

dots <- function(...) list(???)

I want to implement this such that I can do:


exprs <- dots(1+2)
str(exprs)

List of 1
  $ : language 1 + 2

as well as:


exprs <- dots(1+2, "a", rnorm(3))
str(exprs)

List of 3
  $ : language 1 + 2
  $ : chr "a"
  $ : language rnorm(3)

Is this possible to achieve using plain R code?


I think so.  substitute(list(...)) gives you a single expression 
containing a call to list() with the unevaluated arguments; you can 
convert that to what you want using something like


dots <- function (...) {
  exprs <- substitute(list(...))
  as.list(exprs[-1])
}

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute() on arguments in ellipsis ("dot dot dot")?

[Henrik Bengtsson]

Hi. For any number of *known* arguments, we can do:

one <- function(a) list(a = substitute(a))
two <- function(a, b) list(a = substitute(a), b = substitute(b))

and so on. But how do I achieve the same when I have:

dots <- function(...) list(???)

I want to implement this such that I can do:

> exprs <- dots(1+2)
> str(exprs)
List of 1
 $ : language 1 + 2

as well as:

> exprs <- dots(1+2, "a", rnorm(3))
> str(exprs)
List of 3
 $ : language 1 + 2
 $ : chr "a"
 $ : language rnorm(3)

Is this possible to achieve using plain R code?

Thanks,

Henrik

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

[peter dalgaard]

On May 16, 2013, at 15:06 , McGehee, Robert wrote:

> Duncan, Thank you for the clarification on how delayedAssign works. Should 
> R-level interfaces to promise objects ever become available, I expect they 
> would at time come in handy.
> 
> On the subject of substitute and delayedAssign, I do have a follow-up 
> question for the list. I'm trying to convert a named list of expression 
> objects into an environment of promise objects. After conversion, each 
> expression in the list will be automatically evaluated when the variable with 
> the same name is accessed in the environment. Effectively, I'm trying to 
> create a hash table of promise objects.
> 
> Here's the code I wrote that works just fine.
> 
> x <- list(a=3, b=expression(a+2), sleep=expression(Sys.sleep(2)))
> env <- new.env()
> for (i in seq(x)) {
>   key <- names(x)[i]
>   .Internal(delayedAssign(key,
>  eval(substitute(x[[i]], list(x=x, 
> i=i)))[[1]],
>  eval.env=env, assign.env=env))
> } 
> env$b # 3+2
> [1] 5
> env$sleep # Sleeps for 2 seconds
> NULL  
> 
> The "problem" is that R CMD check complains that I shouldn't be using 
> .Internal() to access the delayedAssign function. However, if I don't use 
> .Internal(), then delayedAssign puts another substitute around my call that 
> prevents the 'i' iterator variable from being evaluated at the correct time, 
> which causes all variables to get the value x[[i]] for the very last value of 
> 'i'.
> 
> Can I safely ignore this R CMD check warning about .Internal, or is there a 
> better way to write this code?

These things are slippery, but the usual way out is to figure out exactly which 
expression you want to call, compute the expression unevaluated, and evaulate 
it.

Something like

e <- bquote(delayedAssign( .(names(x)[i]), .(x[[i]]), eval.env=env, 
assign.env=env))
print(e)
eval(e)

(of course remove the print(e) once you're sure that it is doing the right 
thing)



> 
> Thanks, Robert
> 
> 
> 
> -----Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com] 
> Sent: Wednesday, May 15, 2013 6:04 PM
> To: McGehee, Robert
> Cc: R-Devel (r-devel@r-project.org)
> Subject: Re: [Rd] Substitute unaware when promise objects are evaluated
> 
> On 13-05-15 11:54 AM, McGehee, Robert wrote:
>> R-devel,
>> I used the 'substitute' function to create labels for objects inside an 
>> environment, without actually evaluating the objects, as the objects might 
>> be promises.
>> 
>> However, I was surprised to see that 'substitute' returns the expression 
>> slot of the original promise even after the promise has been forcibly 
>> evaluated. (Doesn't the promise go away after evaluation?) This behavior 
>> probably falls under the "...no guarantee that the resulting expression 
>> makes any sense" clause of the ?substitute documentation, but in case 
>> there's something actually wrong here, I thought I'd send an example.
> 
> I think you misunderstand promises.
> 
> A promise has two (or three, depending how you count) parts:  an 
> expression with an associated environment, and a value.  The value isn't 
> filled in until the expression is evaluated, but the expression doesn't 
> go away then.  You can still see it until you change the variable that 
> holds the promise.
> 
> 
>> Here's an example showing how the evaluated expression returned by 
>> substitute does not match the actual variable value:
>> 
>>> env <- new.env()
>>> z <- 0
>>> delayedAssign("var", z+2, assign.env=env)
>>> substitute(var, env=env)
>> z + 2
> 
> The documentation for substitute may not be clear on this, but for a 
> promise, the env argument will be ignored.  It was the eval.env argument 
> to delayedAssign that set the promise's environment.
> 
>>> force(env$var)
>> [1] 2
>>> z <- 10
>>> substitute(var, env=env)
>> z + 2
>>> eval(substitute(var, env=env))
>> [1] 12
>>> force(env$var)
>> [1] 2
>> 
>> Is there any obvious way to code around this behavior, e.g. can I explicitly 
>> check if an object in an environment is an unevaluated promise?
> 
> Not at R level. In C code you could, but you probably shouldn't.  Think 
> of promises as values where you can look up the expression that gave the 
> value, and sometimes delay the calculation until you need it.
> 
> Duncan Murdoch
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

[Peter Meilstrup]

On Fri, May 17, 2013 at 2:47 AM, Duncan Murdoch wrote:

> On 13-05-16 11:17 PM, Peter Meilstrup wrote:
>
>> On Thu, May 16, 2013 at 6:06 AM, McGehee, Robert <
>> Robert.McGehee@geodecapital.**com >
>> wrote:
>>
>>  Duncan, Thank you for the clarification on how delayedAssign works.
>>> Should
>>> R-level interfaces to promise objects ever become available, I expect
>>> they
>>> would at time come in handy.
>>>
>>> On the subject of substitute and delayedAssign, I do have a follow-up
>>> question for the list. I'm trying to convert a named list of expression
>>> objects into an environment of promise objects. After conversion, each
>>> expression in the list will be automatically evaluated when the variable
>>> with the same name is accessed in the environment. Effectively, I'm
>>> trying
>>> to create a hash table of promise objects.
>>>
>>>
>> Populating a new environment with promises happens to be what "calling a
>> function" in R does anyway, so an elegant way to accomplish this goal is:
>>
>> makePromiseEnv <- function(expressions, parent=parent.frame()) {
>>  f <- function() environment()
>>  formals(f) <- as.pairlist(expressions)
>>  environment(f) <- parent
>>  f()
>> }
>>
>>  e <- makePromiseEnv(alist(a = {print("hello"); 4}, b = {print("again");
>>>
>> 6}))
>>
>>> e$a
>>>
>> [1] "hello"
>> [1] 4
>>
>>> e$a
>>>
>> [1] 4
>>
>>> e$b
>>>
>> [1] "again"
>> [1] 6
>>
>>> e$b
>>>
>> [1] 6
>>
>>
> I like that solution, except for one thing:  I don't see an easy way to
> control the environment where those expressions will be executed.  Since
> you've set them as defaults on the arguments, they will be evaluated in the
> evaluation frame of f(), and that might not be what we want. An obvious
> example of the problem would be
>
> e <- makePromiseEnv(alist(a = ls()))
>
> I don't know what Robert would want
>
> e$a
>
> to print, but one somewhat natural version would be to have it evaluate
> the ls() in the environment from which makePromiseEnv was called, i.e. the
> global environment in this case.  Neither your solution nor mine do this,
> but I can see how to modify mine, since it makes the evaluation environment
> of the expression explicit.  Can you see a modification that would do that
> with your approach?
>
> Duncan Murdoch
>

Sure, you could pass the expressions as arguments to f instead of as the
defaults. In this case do.call does the construction of promises.

makePromiseEnv2 <- function(expressions, envir=parent.frame()) {
  f <- function() environment()
  arglist <- expressions
  arglist[] <- list(quote(expr=))   #delete defaults, keep names
  formals(f) <- as.pairlist(arglist)
  do.call(f, expressions, envir=envir)
}

e <- makePromiseEnv2(alist(a=ls()))

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

[Duncan Murdoch]

On 13-05-16 11:17 PM, Peter Meilstrup wrote:

On Thu, May 16, 2013 at 6:06 AM, McGehee, Robert <
robert.mcge...@geodecapital.com> wrote:


Duncan, Thank you for the clarification on how delayedAssign works. Should
R-level interfaces to promise objects ever become available, I expect they
would at time come in handy.

On the subject of substitute and delayedAssign, I do have a follow-up
question for the list. I'm trying to convert a named list of expression
objects into an environment of promise objects. After conversion, each
expression in the list will be automatically evaluated when the variable
with the same name is accessed in the environment. Effectively, I'm trying
to create a hash table of promise objects.



Populating a new environment with promises happens to be what "calling a
function" in R does anyway, so an elegant way to accomplish this goal is:

makePromiseEnv <- function(expressions, parent=parent.frame()) {
 f <- function() environment()
 formals(f) <- as.pairlist(expressions)
 environment(f) <- parent
 f()
}


e <- makePromiseEnv(alist(a = {print("hello"); 4}, b = {print("again");

6}))

e$a

[1] "hello"
[1] 4

e$a

[1] 4

e$b

[1] "again"
[1] 6

e$b

[1] 6



I like that solution, except for one thing:  I don't see an easy way to 
control the environment where those expressions will be executed.  Since 
you've set them as defaults on the arguments, they will be evaluated in 
the evaluation frame of f(), and that might not be what we want. An 
obvious example of the problem would be


e <- makePromiseEnv(alist(a = ls()))

I don't know what Robert would want

e$a

to print, but one somewhat natural version would be to have it evaluate 
the ls() in the environment from which makePromiseEnv was called, i.e. 
the global environment in this case.  Neither your solution nor mine do 
this, but I can see how to modify mine, since it makes the evaluation 
environment of the expression explicit.  Can you see a modification that 
would do that with your approach?


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

[Peter Meilstrup]

On Thu, May 16, 2013 at 6:06 AM, McGehee, Robert <
robert.mcge...@geodecapital.com> wrote:

> Duncan, Thank you for the clarification on how delayedAssign works. Should
> R-level interfaces to promise objects ever become available, I expect they
> would at time come in handy.
>
> On the subject of substitute and delayedAssign, I do have a follow-up
> question for the list. I'm trying to convert a named list of expression
> objects into an environment of promise objects. After conversion, each
> expression in the list will be automatically evaluated when the variable
> with the same name is accessed in the environment. Effectively, I'm trying
> to create a hash table of promise objects.
>

Populating a new environment with promises happens to be what "calling a
function" in R does anyway, so an elegant way to accomplish this goal is:

makePromiseEnv <- function(expressions, parent=parent.frame()) {
f <- function() environment()
formals(f) <- as.pairlist(expressions)
environment(f) <- parent
f()
}

> e <- makePromiseEnv(alist(a = {print("hello"); 4}, b = {print("again");
6}))
> e$a
[1] "hello"
[1] 4
> e$a
[1] 4
> e$b
[1] "again"
[1] 6
> e$b
[1] 6

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

[Duncan Murdoch]

On 16/05/2013 9:06 AM, McGehee, Robert wrote:

Duncan, Thank you for the clarification on how delayedAssign works. Should 
R-level interfaces to promise objects ever become available, I expect they 
would at time come in handy.

On the subject of substitute and delayedAssign, I do have a follow-up question 
for the list. I'm trying to convert a named list of expression objects into an 
environment of promise objects. After conversion, each expression in the list 
will be automatically evaluated when the variable with the same name is 
accessed in the environment. Effectively, I'm trying to create a hash table of 
promise objects.

Here's the code I wrote that works just fine.

x <- list(a=3, b=expression(a+2), sleep=expression(Sys.sleep(2)))
env <- new.env()
for (i in seq(x)) {
key <- names(x)[i]
.Internal(delayedAssign(key,
   eval(substitute(x[[i]], list(x=x, 
i=i)))[[1]],
   eval.env=env, assign.env=env))
}   
env$b # 3+2
[1] 5
env$sleep # Sleeps for 2 seconds
NULL

The "problem" is that R CMD check complains that I shouldn't be using 
.Internal() to access the delayedAssign function. However, if I don't use .Internal(), 
then delayedAssign puts another substitute around my call that prevents the 'i' iterator 
variable from being evaluated at the correct time, which causes all variables to get the 
value x[[i]] for the very last value of 'i'.

Can I safely ignore this R CMD check warning about .Internal, or is there a 
better way to write this code?


You should never call .Internal.  Arguments to internal functions may 
change without notice.


Here's one way to write your example without it.

x <- list(a=3, b=expression(a+2), sleep=expression(Sys.sleep(2)))
env <- new.env()

mydelay <- function(i) {
  expr <- x[[i]]
  name <- names(x)[i]
  do.call(delayedAssign, list(x=name, value=substitute(eval(expr), 
list(expr=expr)),

  eval.env=env, assign.env=env))
}

for (i in seq(x)) mydelay(i)

Duncan Murdoch




Thanks, Robert



-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sent: Wednesday, May 15, 2013 6:04 PM
To: McGehee, Robert
Cc: R-Devel (r-devel@r-project.org)
Subject: Re: [Rd] Substitute unaware when promise objects are evaluated

On 13-05-15 11:54 AM, McGehee, Robert wrote:
> R-devel,
> I used the 'substitute' function to create labels for objects inside an 
environment, without actually evaluating the objects, as the objects might be 
promises.
>
> However, I was surprised to see that 'substitute' returns the expression slot of the 
original promise even after the promise has been forcibly evaluated. (Doesn't the promise go 
away after evaluation?) This behavior probably falls under the "...no guarantee that 
the resulting expression makes any sense" clause of the ?substitute documentation, but 
in case there's something actually wrong here, I thought I'd send an example.

I think you misunderstand promises.

A promise has two (or three, depending how you count) parts:  an
expression with an associated environment, and a value.  The value isn't
filled in until the expression is evaluated, but the expression doesn't
go away then.  You can still see it until you change the variable that
holds the promise.


> Here's an example showing how the evaluated expression returned by substitute 
does not match the actual variable value:
>
>> env <- new.env()
>> z <- 0
>> delayedAssign("var", z+2, assign.env=env)
>> substitute(var, env=env)
> z + 2

The documentation for substitute may not be clear on this, but for a
promise, the env argument will be ignored.  It was the eval.env argument
to delayedAssign that set the promise's environment.

>> force(env$var)
> [1] 2
>> z <- 10
>> substitute(var, env=env)
> z + 2
>> eval(substitute(var, env=env))
> [1] 12
>> force(env$var)
> [1] 2
>
> Is there any obvious way to code around this behavior, e.g. can I explicitly 
check if an object in an environment is an unevaluated promise?

Not at R level. In C code you could, but you probably shouldn't.  Think
of promises as values where you can look up the expression that gave the
value, and sometimes delay the calculation until you need it.

Duncan Murdoch


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Substitute / delayedAssign (was: Substitute unaware when promise objects are evaluated)

[McGehee, Robert]

Duncan, Thank you for the clarification on how delayedAssign works. Should 
R-level interfaces to promise objects ever become available, I expect they 
would at time come in handy.

On the subject of substitute and delayedAssign, I do have a follow-up question 
for the list. I'm trying to convert a named list of expression objects into an 
environment of promise objects. After conversion, each expression in the list 
will be automatically evaluated when the variable with the same name is 
accessed in the environment. Effectively, I'm trying to create a hash table of 
promise objects.

Here's the code I wrote that works just fine.

x <- list(a=3, b=expression(a+2), sleep=expression(Sys.sleep(2)))
env <- new.env()
for (i in seq(x)) {
key <- names(x)[i]
.Internal(delayedAssign(key,
   eval(substitute(x[[i]], list(x=x, 
i=i)))[[1]],
   eval.env=env, assign.env=env))
}   
env$b # 3+2
[1] 5
env$sleep # Sleeps for 2 seconds
NULL  

The "problem" is that R CMD check complains that I shouldn't be using 
.Internal() to access the delayedAssign function. However, if I don't use 
.Internal(), then delayedAssign puts another substitute around my call that 
prevents the 'i' iterator variable from being evaluated at the correct time, 
which causes all variables to get the value x[[i]] for the very last value of 
'i'.

Can I safely ignore this R CMD check warning about .Internal, or is there a 
better way to write this code?

Thanks, Robert



-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com] 
Sent: Wednesday, May 15, 2013 6:04 PM
To: McGehee, Robert
Cc: R-Devel (r-devel@r-project.org)
Subject: Re: [Rd] Substitute unaware when promise objects are evaluated

On 13-05-15 11:54 AM, McGehee, Robert wrote:
> R-devel,
> I used the 'substitute' function to create labels for objects inside an 
> environment, without actually evaluating the objects, as the objects might be 
> promises.
>
> However, I was surprised to see that 'substitute' returns the expression slot 
> of the original promise even after the promise has been forcibly evaluated. 
> (Doesn't the promise go away after evaluation?) This behavior probably falls 
> under the "...no guarantee that the resulting expression makes any sense" 
> clause of the ?substitute documentation, but in case there's something 
> actually wrong here, I thought I'd send an example.

I think you misunderstand promises.

A promise has two (or three, depending how you count) parts:  an 
expression with an associated environment, and a value.  The value isn't 
filled in until the expression is evaluated, but the expression doesn't 
go away then.  You can still see it until you change the variable that 
holds the promise.


> Here's an example showing how the evaluated expression returned by substitute 
> does not match the actual variable value:
>
>> env <- new.env()
>> z <- 0
>> delayedAssign("var", z+2, assign.env=env)
>> substitute(var, env=env)
> z + 2

The documentation for substitute may not be clear on this, but for a 
promise, the env argument will be ignored.  It was the eval.env argument 
to delayedAssign that set the promise's environment.

>> force(env$var)
> [1] 2
>> z <- 10
>> substitute(var, env=env)
> z + 2
>> eval(substitute(var, env=env))
> [1] 12
>> force(env$var)
> [1] 2
>
> Is there any obvious way to code around this behavior, e.g. can I explicitly 
> check if an object in an environment is an unevaluated promise?

Not at R level. In C code you could, but you probably shouldn't.  Think 
of promises as values where you can look up the expression that gave the 
value, and sometimes delay the calculation until you need it.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute unaware when promise objects are evaluated

[Duncan Murdoch]

On 13-05-15 11:54 AM, McGehee, Robert wrote:

R-devel,
I used the 'substitute' function to create labels for objects inside an 
environment, without actually evaluating the objects, as the objects might be 
promises.

However, I was surprised to see that 'substitute' returns the expression slot of the 
original promise even after the promise has been forcibly evaluated. (Doesn't the promise 
go away after evaluation?) This behavior probably falls under the "...no guarantee 
that the resulting expression makes any sense" clause of the ?substitute 
documentation, but in case there's something actually wrong here, I thought I'd send an 
example.


I think you misunderstand promises.

A promise has two (or three, depending how you count) parts:  an 
expression with an associated environment, and a value.  The value isn't 
filled in until the expression is evaluated, but the expression doesn't 
go away then.  You can still see it until you change the variable that 
holds the promise.




Here's an example showing how the evaluated expression returned by substitute 
does not match the actual variable value:


env <- new.env()
z <- 0
delayedAssign("var", z+2, assign.env=env)
substitute(var, env=env)

z + 2


The documentation for substitute may not be clear on this, but for a 
promise, the env argument will be ignored.  It was the eval.env argument 
to delayedAssign that set the promise's environment.



force(env$var)

[1] 2

z <- 10
substitute(var, env=env)

z + 2

eval(substitute(var, env=env))

[1] 12

force(env$var)

[1] 2

Is there any obvious way to code around this behavior, e.g. can I explicitly 
check if an object in an environment is an unevaluated promise?


Not at R level. In C code you could, but you probably shouldn't.  Think 
of promises as values where you can look up the expression that gave the 
value, and sometimes delay the calculation until you need it.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Substitute unaware when promise objects are evaluated

[McGehee, Robert]

R-devel,
I used the 'substitute' function to create labels for objects inside an 
environment, without actually evaluating the objects, as the objects might be 
promises.

However, I was surprised to see that 'substitute' returns the expression slot 
of the original promise even after the promise has been forcibly evaluated. 
(Doesn't the promise go away after evaluation?) This behavior probably falls 
under the "...no guarantee that the resulting expression makes any sense" 
clause of the ?substitute documentation, but in case there's something actually 
wrong here, I thought I'd send an example.

Here's an example showing how the evaluated expression returned by substitute 
does not match the actual variable value:

> env <- new.env()
> z <- 0
> delayedAssign("var", z+2, assign.env=env)
> substitute(var, env=env)
z + 2
> force(env$var)
[1] 2
> z <- 10
> substitute(var, env=env)
z + 2
> eval(substitute(var, env=env))
[1] 12
> force(env$var)
[1] 2

Is there any obvious way to code around this behavior, e.g. can I explicitly 
check if an object in an environment is an unevaluated promise?

Thanks, 
Robert

> R.version
   _
platform   x86_64-pc-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  3
minor  0.0
year   2013
month  04
day03
svn rev62481
language   R
version.string R version 3.0.0 (2013-04-03)
nickname   Masked Marvel

Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Direct: (617)392-8396

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute adds id attribute?

[Hadley Wickham]

> Well, yes; you can get there more quickly as follows:
>
>> x <- as.name("foo")
>> attr(x,"id") <- 7913
>> x
> foo
> attr(,"id")
> [1] 7913
>> substitute(foo)
> foo
> attr(,"id")
> [1] 7913
>
> I.e. if you ever put an attribute on a symbol, it stays there "forever". The 
> fix is probably to forbid setting attributes on symbols (as we already do for 
> environments and NULL) but I bet that breaks something...

Hmmm, thanks.  No idea what's putting it there, but at least I know
where to start.

Hadley


-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute adds id attribute?

[peter dalgaard]

On Mar 20, 2012, at 22:31 , Hadley Wickham wrote:

> Hi all,
> 
> I can't figure out how to make this problem easily reproducible, but I
> can demonstrate it very simply, so I hoped someone might be able to
> suggest a place to start:
> 
>> f <- function(x) substitute(x)
>> f(x)
> x
>> f(mpg)
> mpg
> attr(,"id")
> [1] 11
> 
> It works as expected in a clean R session:
> 
>> f <- function(x) substitute(x)
>> f(x)
> x
>> f(mpg)
> mpg
> 
> but not after the following code
> 
> library(devtools)
> install_github("staticdocs")
> library(staticdocs)
> build_package("ggplot2", tempdir())
> 
> Any ideas?
> 

Well, yes; you can get there more quickly as follows:

> x <- as.name("foo")
> attr(x,"id") <- 7913
> x
foo
attr(,"id")
[1] 7913
> substitute(foo)
foo
attr(,"id")
[1] 7913

I.e. if you ever put an attribute on a symbol, it stays there "forever". The 
fix is probably to forbid setting attributes on symbols (as we already do for 
environments and NULL) but I bet that breaks something...
 




> Thanks,
> 
> Hadley
> 
> -- 
> Assistant Professor / Dobelman Family Junior Chair
> Department of Statistics / Rice University
> http://had.co.nz/
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Substitute adds id attribute?

[Hadley Wickham]

Hi all,

I can't figure out how to make this problem easily reproducible, but I
can demonstrate it very simply, so I hoped someone might be able to
suggest a place to start:

> f <- function(x) substitute(x)
> f(x)
x
> f(mpg)
mpg
attr(,"id")
[1] 11

It works as expected in a clean R session:

> f <- function(x) substitute(x)
> f(x)
x
> f(mpg)
mpg

but not after the following code

library(devtools)
install_github("staticdocs")
library(staticdocs)
build_package("ggplot2", tempdir())

Any ideas?

Thanks,

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute with plots (PR#10987)

[bob . ohara]

Full_Name: Bob O'Hara
Version: 2.6.2
OS: Windows
Submission from: (NULL) (128.214.72.197)


Wishlist: This is a documentation problem/complaint/whinge.

The help for substitute() tells us "The typical use of substitute is to create
informative labels for data sets and plots."  But the example given is trivial
and not a lot of use for the sorts of labels we usually require.  FAQ 7.13
explains how to substitute values into plot labels, so it would be useful to put
this as an example in the help page too.

Actually, a few more examples might be useful, so we don't have to guess what
order to put the substitute, paste, and expression (or eval, bquote and paste)!

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute() bug? (PR#10525)

[Duncan Murdoch]

[EMAIL PROTECTED] wrote:
> The first four lines of code below work as normal.  The fifth thorows  
> an error: "Error in paste(theta[1], "=", 5) : object "theta" not found"
>
>
> x=rnorm(1000);
> bob=density(x);
> topp=5;
> plot(bob,xlab="", ylab="",  
> main=substitute(paste(theta[1],"=",topp),list(topp=topp)), type="l");
> plot(bob$y~bob$x,xlab="", ylab="",  
> main=substitute(paste(theta[1],"=",topp),list(topp=topp)), type="l");
>   
I'm not sure this is a bug, but if it is, it's in 
graphics:::plot.formula, not in substitute.  The problem is that 
substitute returns an unevaluated call, and plot.formula tries to 
evaluate it.  You can avoid the bug by wrapping the substitute call in 
as.expression.

The docs for plotmath say that it requires an expression, but "in most 
cases" language objects will be coerced to one:  it appears this is one 
of the cases where that is not true.

Duncan Murdoch
>
> Note that theta is not defined anywhere:
>
> ls()
>   [1] "bob"  "dline""dplot""dpt"  "less" "lesseq"
>   [7] "more" "moreeq"   "peak" "peakline" "peakplot" "pop"
> [13] "topp" "x"
>
>
> Version:
>   platform = i386-apple-darwin8.10.1
>   arch = i386
>   os = darwin8.10.1
>   system = i386, darwin8.10.1
>   status =
>   major = 2
>   minor = 6.1
>   year = 2007
>   month = 11
>   day = 26
>   svn rev = 43537
>   language = R
>   version.string = R version 2.6.1 (2007-11-26)
>
> Locale:
> C
>
> Search Path:
>   .GlobalEnv, package:stats, package:graphics, package:grDevices,  
> package:utils, package:datasets, package:methods,
>
> 
>
> Jeffrey Ross-Ibarra
> email: [EMAIL PROTECTED]
> web: rossibarra.googlepages.com
> Dept. Ecology and Evolutionary Biology
> University of California
> Irvine, Ca. 92697
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute() bug? (PR#10525)

[rossibarra]

The first four lines of code below work as normal.  The fifth thorows  
an error: "Error in paste(theta[1], "=", 5) : object "theta" not found"


x=rnorm(1000);
bob=density(x);
topp=5;
plot(bob,xlab="", ylab="",  
main=substitute(paste(theta[1],"=",topp),list(topp=topp)), type="l");
plot(bob$y~bob$x,xlab="", ylab="",  
main=substitute(paste(theta[1],"=",topp),list(topp=topp)), type="l");


Note that theta is not defined anywhere:

ls()
  [1] "bob"  "dline""dplot""dpt"  "less" "lesseq"
  [7] "more" "moreeq"   "peak" "peakline" "peakplot" "pop"
[13] "topp" "x"


Version:
  platform = i386-apple-darwin8.10.1
  arch = i386
  os = darwin8.10.1
  system = i386, darwin8.10.1
  status =
  major = 2
  minor = 6.1
  year = 2007
  month = 11
  day = 26
  svn rev = 43537
  language = R
  version.string = R version 2.6.1 (2007-11-26)

Locale:
C

Search Path:
  .GlobalEnv, package:stats, package:graphics, package:grDevices,  
package:utils, package:datasets, package:methods,



Jeffrey Ross-Ibarra
email: [EMAIL PROTECTED]
web: rossibarra.googlepages.com
Dept. Ecology and Evolutionary Biology
University of California
Irvine, Ca. 92697

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute and expression (Peter Dalgaard)

[Peter Dalgaard]

John Maindonald wrote:
> In this connection, note the following
>
>  > a4 <- 4
>  > plotThis <- bquote(alpha==.(a), list(a=a4))
>  > do.call(plot, list(1:10, main=do.call(expression, c(plotThis
>  > do.call(plot, list(1:10, main=do.call(expression, plotThis)))
> Error in do.call(expression, plotThis) : second argument must be a list
>
>  > ## Whereas plotThis has class "call", c(plotThis) has class "list"
>  > class(plotThis)
> [1] "call"
>  > class(c(plotThis))
> [1] "list"
>
>  > ## Thus, the following is possible:
>  > do.call(plot, list(1:10, main=do.call(expression, list(plotThis
>
>
> Marc Schwartz pointed out to me., some considerable time ago,
> that one could use bquote() and .() to create the elements of a
> list object whose elements can be plotted in parallel as required,
> e.g., for axis labels, thus:
>
>  > plot(1:2, 1:2, xaxt="n")
>  > arg1 <- bquote(""< .(x), list(x=1.5))
>  > arg2 <- bquote("">= .(x), list(x=1.5))
>  > axis(1, at=1:2, labels=do.call(expression, list(arg1, arg2)))
>
> For a unified approach to use of do.call(expression, ...), maybe
> one should use bquote() and .()?
>
>   
I think I'd prefer as.expression() in both cases:

do.call(plot, list(1:10, main=as.expression(plotThis)))

axis(1, at=1:2, labels=as.expression(list(arg1, arg2)))



-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute and expression (Peter Dalgaard)

[John Maindonald]

In this connection, note the following

 > a4 <- 4
 > plotThis <- bquote(alpha==.(a), list(a=a4))
 > do.call(plot, list(1:10, main=do.call(expression, c(plotThis
 > do.call(plot, list(1:10, main=do.call(expression, plotThis)))
Error in do.call(expression, plotThis) : second argument must be a list

 > ## Whereas plotThis has class "call", c(plotThis) has class "list"
 > class(plotThis)
[1] "call"
 > class(c(plotThis))
[1] "list"

 > ## Thus, the following is possible:
 > do.call(plot, list(1:10, main=do.call(expression, list(plotThis


Marc Schwartz pointed out to me., some considerable time ago,
that one could use bquote() and .() to create the elements of a
list object whose elements can be plotted in parallel as required,
e.g., for axis labels, thus:

 > plot(1:2, 1:2, xaxt="n")
 > arg1 <- bquote(""< .(x), list(x=1.5))
 > arg2 <- bquote("">= .(x), list(x=1.5))
 > axis(1, at=1:2, labels=do.call(expression, list(arg1, arg2)))

For a unified approach to use of do.call(expression, ...), maybe
one should use bquote() and .()?

John Maindonald email: [EMAIL PROTECTED]
phone : +61 2 (6125)3473fax  : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.


On 18 Jul 2007, at 8:00 PM, [EMAIL PROTECTED] wrote:

> From: Peter Dalgaard <[EMAIL PROTECTED]>
> Date: 18 July 2007 1:39:50 AM
> To: Deepayan Sarkar <[EMAIL PROTECTED]>
> Cc: R Development Mailing List <[EMAIL PROTECTED]>
> Subject: Re: [Rd] substitute and expression
>
>
> Deepayan Sarkar wrote:
>> On 7/16/07, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
>>
>>> Deepayan Sarkar wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm trying to understand whether the use of substitute() is
>>>> appropriate/documented for plotmath annotation. The following two
>>>> calls give the same results:
>>>>
>>>>
>>>>
>>>>> plot(1:10, main = expression(alpha == 1))
>>>>> do.call(plot, list(1:10, main = expression(alpha == 1)))
>>>>>
>>>>>
>>>> But not these two:
>>>>
>>>>
>>>>
>>>>> plot(1:10, main = substitute(alpha == a, list(a = 2)))
>>>>> do.call(plot, list(1:10, main = substitute(alpha == a, list(a =  
>>>>> 2
>>>>>
>>>>>
>>>> Error in as.graphicsAnnot(main) : object "alpha" not found
>>>>
>>>> (as a consequence, xyplot(..., main = substitute(alpha)) doesn't
>>>> currently work.)
>>>>
>>>> On the other hand, this works:
>>>>
>>>>
>>>>
>>>>> foo <- function(x) plot(1, main = x)
>>>>> foo(substitute(alpha))
>>>>>
>>>>>
>>>> I'm not sure how to interpret ?plotmath; it says
>>>>
>>>>  If the 'text' argument to one of the text-drawing functions
>>>>  ('text', 'mtext', 'axis', 'legend') in R is an expression, the
>>>>  argument is interpreted as a mathematical expression...
>>>>
>>>> and uses substitute() in its examples, but
>>>>
>>>>
>>>>
>>>>> is.expression(substitute(alpha == a, list(a = 1)))
>>>>>
>>>>>
>>>> [1] FALSE
>>>>
>>>>
>>> I think you need to take plotmath out of the equation and study the
>>> difference between objects of mode "call" and those of mode
>>> "expression". Consider this:
>>>
>>>> f <- function(...)match.call()
>>>> do.call(f, list(1:10, main = substitute(alpha == a, list(a = 2
>>> function(...)match.call()
>>> (1:10, main = alpha == 2)
>>>> do.call(list, list(1:10, main = substitute(alpha == a, list(a =  
>>>> 2
>>> Error in do.call(list, list(1:10, main = substitute(alpha == a,  
>>> list(a =
>>> 2 :
>>> object "alpha" not found
>>>
>>> The issue is that function ends up with an argument  alpha == 2  
>>> which it
>>> proceeds to evaluate (lazily), where a direct call sees
>>> substitute(.). It is a general problem with the do.call  
>>> mechanism
>>> that it effectively pre-evaluates the argument list, which can  
>>> confuse

Re: [Rd] substitute and expression

[Peter Dalgaard]

Deepayan Sarkar wrote:
> On 7/16/07, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
>   
>> Deepayan Sarkar wrote:
>> 
>>> Hi,
>>>
>>> I'm trying to understand whether the use of substitute() is
>>> appropriate/documented for plotmath annotation. The following two
>>> calls give the same results:
>>>
>>>
>>>   
 plot(1:10, main = expression(alpha == 1))
 do.call(plot, list(1:10, main = expression(alpha == 1)))

 
>>> But not these two:
>>>
>>>
>>>   
 plot(1:10, main = substitute(alpha == a, list(a = 2)))
 do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2

 
>>> Error in as.graphicsAnnot(main) : object "alpha" not found
>>>
>>> (as a consequence, xyplot(..., main = substitute(alpha)) doesn't
>>> currently work.)
>>>
>>> On the other hand, this works:
>>>
>>>
>>>   
 foo <- function(x) plot(1, main = x)
 foo(substitute(alpha))

 
>>> I'm not sure how to interpret ?plotmath; it says
>>>
>>>  If the 'text' argument to one of the text-drawing functions
>>>  ('text', 'mtext', 'axis', 'legend') in R is an expression, the
>>>  argument is interpreted as a mathematical expression...
>>>
>>> and uses substitute() in its examples, but
>>>
>>>
>>>   
 is.expression(substitute(alpha == a, list(a = 1)))

 
>>> [1] FALSE
>>>
>>>   
>> I think you need to take plotmath out of the equation and study the
>> difference between objects of mode "call" and those of mode
>> "expression". Consider this:
>>
>>  > f <- function(...)match.call()
>>  > do.call(f, list(1:10, main = substitute(alpha == a, list(a = 2
>> function(...)match.call()
>> (1:10, main = alpha == 2)
>>  > do.call(list, list(1:10, main = substitute(alpha == a, list(a = 2
>> Error in do.call(list, list(1:10, main = substitute(alpha == a, list(a =
>> 2 :
>> object "alpha" not found
>>
>> The issue is that function ends up with an argument  alpha == 2 which it
>> proceeds to evaluate (lazily), where a direct call sees
>> substitute(.). It is a general problem with the do.call mechanism
>> that it effectively pre-evaluates the argument list, which can confuse
>> functions that rely on accessing the original argument expression. Try,
>> e.g., do.call(plot, list(airquality$Wind, airquality$Ozone)) and watch
>> the axis labels.
>> 
>
> Right. Lazy evaluation was the piece I was missing.
>
>   
>> Does it work if you use something like
>>
>>  main = substitute(quote(alpha == a), list(a = 2))?
>> 
>
> Not for xyplot, though I haven't figured out why. Turns out this also
> doesn't work:
>
>   
>> plot(y ~ x, data = list(x = 1:10, y = 1:10), main = substitute(alpha))
>> 
> Error in as.graphicsAnnot(main) : object "alpha" not found
>
> I'll take this to mean that the fact that substitute() works sometimes
> (for plotmath) is an undocumented side effect of the implementation
> that should not be relied upon.
>   
Probably the correct solution is to use expression objects. More or less
the entire reason for their existence is this sort of surprises.

plot(y ~ x, data = list(x = 1:10, y = 1:10), main =
as.expression(substitute(alpha==a, list(a=2

I'm not going to investigate why this is necessary in connection with
plot(), but the core issue is probably

> e <- quote(f(x)) ; e[[2]] <- quote(2+2)
> e
f(2 + 2)
> f <- quote(f(2+2))
> identical(e,f)
[1] TRUE

notice that since the two calls are identical, there is no way for e to
detect that it was called with x replaced by an object of mode "call".
Or put differently, objects of mode call tend to lose their
"personality" in connection with computing on the language. 


-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute and expression

[Deepayan Sarkar]

On 7/16/07, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> Deepayan Sarkar wrote:
> > Hi,
> >
> > I'm trying to understand whether the use of substitute() is
> > appropriate/documented for plotmath annotation. The following two
> > calls give the same results:
> >
> >
> >> plot(1:10, main = expression(alpha == 1))
> >> do.call(plot, list(1:10, main = expression(alpha == 1)))
> >>
> >
> > But not these two:
> >
> >
> >> plot(1:10, main = substitute(alpha == a, list(a = 2)))
> >> do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2
> >>
> > Error in as.graphicsAnnot(main) : object "alpha" not found
> >
> > (as a consequence, xyplot(..., main = substitute(alpha)) doesn't
> > currently work.)
> >
> > On the other hand, this works:
> >
> >
> >> foo <- function(x) plot(1, main = x)
> >> foo(substitute(alpha))
> >>
> >
> > I'm not sure how to interpret ?plotmath; it says
> >
> >  If the 'text' argument to one of the text-drawing functions
> >  ('text', 'mtext', 'axis', 'legend') in R is an expression, the
> >  argument is interpreted as a mathematical expression...
> >
> > and uses substitute() in its examples, but
> >
> >
> >> is.expression(substitute(alpha == a, list(a = 1)))
> >>
> > [1] FALSE
> >
> I think you need to take plotmath out of the equation and study the
> difference between objects of mode "call" and those of mode
> "expression". Consider this:
>
>  > f <- function(...)match.call()
>  > do.call(f, list(1:10, main = substitute(alpha == a, list(a = 2
> function(...)match.call()
> (1:10, main = alpha == 2)
>  > do.call(list, list(1:10, main = substitute(alpha == a, list(a = 2
> Error in do.call(list, list(1:10, main = substitute(alpha == a, list(a =
> 2 :
> object "alpha" not found
>
> The issue is that function ends up with an argument  alpha == 2 which it
> proceeds to evaluate (lazily), where a direct call sees
> substitute(.). It is a general problem with the do.call mechanism
> that it effectively pre-evaluates the argument list, which can confuse
> functions that rely on accessing the original argument expression. Try,
> e.g., do.call(plot, list(airquality$Wind, airquality$Ozone)) and watch
> the axis labels.

Right. Lazy evaluation was the piece I was missing.

> Does it work if you use something like
>
>  main = substitute(quote(alpha == a), list(a = 2))?

Not for xyplot, though I haven't figured out why. Turns out this also
doesn't work:

> plot(y ~ x, data = list(x = 1:10, y = 1:10), main = substitute(alpha))
Error in as.graphicsAnnot(main) : object "alpha" not found

I'll take this to mean that the fact that substitute() works sometimes
(for plotmath) is an undocumented side effect of the implementation
that should not be relied upon.

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute and expression

[Gabor Grothendieck]

On 7/16/07, Deepayan Sarkar <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm trying to understand whether the use of substitute() is
> appropriate/documented for plotmath annotation. The following two
> calls give the same results:
>
> > plot(1:10, main = expression(alpha == 1))
> > do.call(plot, list(1:10, main = expression(alpha == 1)))
>
> But not these two:
>
> > plot(1:10, main = substitute(alpha == a, list(a = 2)))
> > do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2
> Error in as.graphicsAnnot(main) : object "alpha" not found
>
> (as a consequence, xyplot(..., main = substitute(alpha)) doesn't
> currently work.)

If your question is really about do.call then use the quote = TRUE argument.
Then both of the above work:

plot(1:10, main = substitute(alpha == a, list(a = 2)))
do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2))),
quote = TRUE)

plot(1:10, main = expression(alpha == 1))
do.call(plot, list(1:10, main = expression(alpha == 1)), quote = TRUE)

Another possibility is just to make sure you are passing an expression so
that the first one would become:

plot(1:10, main = substitute(alpha == a, list(a = 2)))
do.call(plot, list(1:10, main = as.expression(substitute(alpha == a,
list(a = 2)


>
> On the other hand, this works:
>
> > foo <- function(x) plot(1, main = x)
> > foo(substitute(alpha))
>
> I'm not sure how to interpret ?plotmath; it says
>
> If the 'text' argument to one of the text-drawing functions
> ('text', 'mtext', 'axis', 'legend') in R is an expression, the
> argument is interpreted as a mathematical expression...
>
> and uses substitute() in its examples, but
>
> > is.expression(substitute(alpha == a, list(a = 1)))
> [1] FALSE
>

I am not sure what examples you are referring to but if you read the
Value section in ?substitute it does say that substitute typically
returns call objects but may return a name object and in principle
can return others too so they need not be expressions.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute and expression

[Peter Dalgaard]

Deepayan Sarkar wrote:
> Hi,
>
> I'm trying to understand whether the use of substitute() is
> appropriate/documented for plotmath annotation. The following two
> calls give the same results:
>
>   
>> plot(1:10, main = expression(alpha == 1))
>> do.call(plot, list(1:10, main = expression(alpha == 1)))
>> 
>
> But not these two:
>
>   
>> plot(1:10, main = substitute(alpha == a, list(a = 2)))
>> do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2
>> 
> Error in as.graphicsAnnot(main) : object "alpha" not found
>
> (as a consequence, xyplot(..., main = substitute(alpha)) doesn't
> currently work.)
>
> On the other hand, this works:
>
>   
>> foo <- function(x) plot(1, main = x)
>> foo(substitute(alpha))
>> 
>
> I'm not sure how to interpret ?plotmath; it says
>
>  If the 'text' argument to one of the text-drawing functions
>  ('text', 'mtext', 'axis', 'legend') in R is an expression, the
>  argument is interpreted as a mathematical expression...
>
> and uses substitute() in its examples, but
>
>   
>> is.expression(substitute(alpha == a, list(a = 1)))
>> 
> [1] FALSE
>   
I think you need to take plotmath out of the equation and study the 
difference between objects of mode "call" and those of mode 
"expression". Consider this:

 > f <- function(...)match.call()
 > do.call(f, list(1:10, main = substitute(alpha == a, list(a = 2
function(...)match.call()
(1:10, main = alpha == 2)
 > do.call(list, list(1:10, main = substitute(alpha == a, list(a = 2
Error in do.call(list, list(1:10, main = substitute(alpha == a, list(a = 
2 :
object "alpha" not found

The issue is that function ends up with an argument  alpha == 2 which it 
proceeds to evaluate (lazily), where a direct call sees 
substitute(.). It is a general problem with the do.call mechanism 
that it effectively pre-evaluates the argument list, which can confuse 
functions that rely on accessing the original argument expression. Try, 
e.g., do.call(plot, list(airquality$Wind, airquality$Ozone)) and watch 
the axis labels.

Does it work if you use something like

 main = substitute(quote(alpha == a), list(a = 2))?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute and expression

[Deepayan Sarkar]

Hi,

I'm trying to understand whether the use of substitute() is
appropriate/documented for plotmath annotation. The following two
calls give the same results:

> plot(1:10, main = expression(alpha == 1))
> do.call(plot, list(1:10, main = expression(alpha == 1)))

But not these two:

> plot(1:10, main = substitute(alpha == a, list(a = 2)))
> do.call(plot, list(1:10, main = substitute(alpha == a, list(a = 2
Error in as.graphicsAnnot(main) : object "alpha" not found

(as a consequence, xyplot(..., main = substitute(alpha)) doesn't
currently work.)

On the other hand, this works:

> foo <- function(x) plot(1, main = x)
> foo(substitute(alpha))

I'm not sure how to interpret ?plotmath; it says

 If the 'text' argument to one of the text-drawing functions
 ('text', 'mtext', 'axis', 'legend') in R is an expression, the
 argument is interpreted as a mathematical expression...

and uses substitute() in its examples, but

> is.expression(substitute(alpha == a, list(a = 1)))
[1] FALSE

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute and S4 objects

[John Chambers]

First, by "doesn't work" you mean the printed output.  The value 
returned is the same.

Second, the problem is not a general one with S4 methods but with 
primitive functions.  To see this, define a real function with a similar 
method:

 > setGeneric("foo", function(e1, e2) standardGeneric("foo"))
[1] "foo"

 > setMethod("foo", "num", function(e1, e2) {
cat("Computing\n", deparse(substitute(e1)), "+", 
deparse(substitute(e2)),
"\n")
[EMAIL PROTECTED] + e2@ x
})

[1] "foo"
 > foo(a,b)
Computing
 a + b
[1] 1.8

The problem with primitives, such as `+`, is that they aren't called in 
the way functions are normally called.  If my understanding is correct, 
substitute() with one argument uses the "promise" objects corresponding 
to the formal arguments in order to extract the unevaluated expression.  
There are no such things with primitives.

I think you need to use a different function for whatever you really wanted.

Franck Arnaud wrote:
> Hi all,
> I don't understand why this does not what I expect :
>
> ## code start here ##
> setClass("num",representation(x="numeric"))
>
> num<-function(x) new("num",x=x)
>
> add<-function(e1,e2) {
> cat("Computing
> ",deparse(substitute(e1)),"+",deparse(substitute(e2)),"\n")
> [EMAIL PROTECTED]@x
> }
>
> setMethod("+","num",function(e1,e2) {
> cat("Computing
> ",deparse(substitute(e1)),"+",deparse(substitute(e2)),"\n")
> [EMAIL PROTECTED]@x
> })
>
>
> a<-num(3.2)
> b<-num(-1.4)
>
> add(a,b)
> a+b
> ## code ends here ##
>
> a+b does not work : I would like that add(a,b) and a+b give the exact same
> result
> I've seen a post on R-devel, but the answer seemed not to apply here.
> I've tried to use deparse(substitute(e1,sys.frame (-1))) and
> deparse(substitute(e1,sys.frame(-2))) (as it was advised by GG in january
> 2006). But it did not work.
>
> Therefore, i'm looking for 1) an explanation for this phenomenon (link to a
> doc, anything) and/or 2) a way to do what i want, if it is possible.
>
> Thanks a lot
>
>   [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute and S4 objects

[Franck Arnaud]

Hi all,
I don't understand why this does not what I expect :

## code start here ##
setClass("num",representation(x="numeric"))

num<-function(x) new("num",x=x)

add<-function(e1,e2) {
cat("Computing
",deparse(substitute(e1)),"+",deparse(substitute(e2)),"\n")
[EMAIL PROTECTED]@x
}

setMethod("+","num",function(e1,e2) {
cat("Computing
",deparse(substitute(e1)),"+",deparse(substitute(e2)),"\n")
[EMAIL PROTECTED]@x
})


a<-num(3.2)
b<-num(-1.4)

add(a,b)
a+b
## code ends here ##

a+b does not work : I would like that add(a,b) and a+b give the exact same
result
I've seen a post on R-devel, but the answer seemed not to apply here.
I've tried to use deparse(substitute(e1,sys.frame (-1))) and
deparse(substitute(e1,sys.frame(-2))) (as it was advised by GG in january
2006). But it did not work.

Therefore, i'm looking for 1) an explanation for this phenomenon (link to a
doc, anything) and/or 2) a way to do what i want, if it is possible.

Thanks a lot

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute creates an object whichprints incorrectly (PR#9427)

[Duncan Murdoch]

On 1/7/2007 6:55 PM, [EMAIL PROTECTED] wrote:
>> I think we should get rid of source attributes completely, 
>> since they are no longer needed, but your comment still 
>> applies to source references. We should strip them when code 
>> gets modified.
>>
>> Duncan Murdoch
> 
> I would be very concerned about losing source attributes-- it would
> break a lot of my code :(! It's very useful to have a single portable R
> object that contains the whole of a function, including its printable
> representation with full comments and formatted in whatever style the
> author prefers (and indeed the documentation, in the way I work); I use
> .Rdata files to swap multiple functions & data with colleagues all the
> time.
> 
> Source references-to-files entail having to keep track of separate
> files, so are much less portable.
> 
> I haven't had time to follow Duncan's recent changes on source
> references, but would it also be possible to use the new
> attribute-attaching-indexing mechanism to point to places in the
> 'source' attribute rather than in a file? That might offer the best of
> both worlds to dinosaurs like me who rely on source attributes...

You can do essentially that using a reference to a srcfilecopy, instead 
of a srcfile.  It keeps a copy of the source. The difference between 
this and your proposal is that if there are multiple functions defined 
in the same file, the source references of all of them refer to the same 
copy of the source file (so you can see the comments that came between 
the function definitions, etc.)

What is not done yet (and I probably won't have time to do for 2.5.0) is 
working out exactly what the user interface is that determines whether a 
srcfilecopy gets produced automatically.  Right now it only happens if 
you parse using the text= arg instead of the file= arg, but clearly 
there are situations where you'd want to save a copy even though you're 
reading from a file.

Duncan Murdoch

> 
> Mark Bravington
> 
> CSIRO Mathematical & Information Sciences
> Marine Laboratory
> Castray Esplanade
> Hobart 7001
> TAS
> 
> ph (+61) 3 6232 5118
> fax (+61) 3 6232 5012
> mob (+61) 438 315 623
>  
> 
>>>> Perhaps the compromise has to be to warn people that 
>> keep.source=TRUE 
>>>> can be dangerous in this way, both in the help informaton for 
>>>> options() and for substitute().
>>>>
>>>> ?
>>>>
>>>> Bill Venables.
>>>>
>>>> -Original Message-
>>>> From: Peter Dalgaard [mailto:[EMAIL PROTECTED]
>>>> Sent: Friday, 22 December 2006 9:47 PM
>>>> To: Venables, Bill (CMIS, Cleveland)
>>>> Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
>>>> Subject: Re: [Rd] substitute creates an object which prints 
>>>> incorrectly
>>>> (PR#9427)
>>>>
>>>> [EMAIL PROTECTED] wrote:
>>>>   
>>>>> The function "substitute" seems to fail to make a genuine 
>>>>> substitution, although the printed verision seems fine.  
>> Here is an 
>>>>> example.
>>>>>
>>>>>   
>>>>> 
>>>>>> m <- substitute(Y <- function(x) FUN(x+1),
>>>>>> 
>>>>>>   
>>>>> + list(Y = as.name("y"), FUN = as.name("sin")))
>>>>>   
>>>>> 
>>>>>> m
>>>>>> 
>>>>>>   
>>>>> y <- function(x) sin(x + 1)
>>>>>   
>>>>> 
>>>>>> eval(m)
>>>>>> y
>>>>>> 
>>>>>>   
>>>>> function(x) FUN(x+1)
>>>>>
>>>>> However the story doesn't end there.  The substitution appears to 
>>>>> have been made, even though the printed version, this 
>> time, suggests 
>>>>> otherwise.
>>>>>
>>>>>   
>>>>> 
>>>>>> y(pi)
>>>>>> 
>>>>>>   
>>>>> [1] -0.841471
>>>>>   
>>>>> 
>>>>>> sin(pi+1)
>>>>>> 
>>>>>>   
>>>>> [1] -0.841471
>>>>>   
>>>>>
>>>>>   
>>>>> 
>>>> Yes, this is (fairly) well known. It has to do with the 
>> retention of 
>>>> function source.
>>>>
>>>> The thing to notice 

Re: [Rd] substitute creates an object whichprints incorrectly (PR#9427)

[Mark.Bravington]

> I think we should get rid of source attributes completely, 
> since they are no longer needed, but your comment still 
> applies to source references. We should strip them when code 
> gets modified.
> 
> Duncan Murdoch

I would be very concerned about losing source attributes-- it would
break a lot of my code :(! It's very useful to have a single portable R
object that contains the whole of a function, including its printable
representation with full comments and formatted in whatever style the
author prefers (and indeed the documentation, in the way I work); I use
.Rdata files to swap multiple functions & data with colleagues all the
time.

Source references-to-files entail having to keep track of separate
files, so are much less portable.

I haven't had time to follow Duncan's recent changes on source
references, but would it also be possible to use the new
attribute-attaching-indexing mechanism to point to places in the
'source' attribute rather than in a file? That might offer the best of
both worlds to dinosaurs like me who rely on source attributes...

Mark Bravington

CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
 

> 
> > 
> >> Perhaps the compromise has to be to warn people that 
> keep.source=TRUE 
> >> can be dangerous in this way, both in the help informaton for 
> >> options() and for substitute().
> >>
> >> ?
> >>
> >> Bill Venables.
> >>
> >> -Original Message-
> >> From: Peter Dalgaard [mailto:[EMAIL PROTECTED]
> >> Sent: Friday, 22 December 2006 9:47 PM
> >> To: Venables, Bill (CMIS, Cleveland)
> >> Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
> >> Subject: Re: [Rd] substitute creates an object which prints 
> >> incorrectly
> >> (PR#9427)
> >>
> >> [EMAIL PROTECTED] wrote:
> >>   
> >>> The function "substitute" seems to fail to make a genuine 
> >>> substitution, although the printed verision seems fine.  
> Here is an 
> >>> example.
> >>>
> >>>   
> >>> 
> >>>> m <- substitute(Y <- function(x) FUN(x+1),
> >>>> 
> >>>>   
> >>> + list(Y = as.name("y"), FUN = as.name("sin")))
> >>>   
> >>> 
> >>>> m
> >>>> 
> >>>>   
> >>> y <- function(x) sin(x + 1)
> >>>   
> >>> 
> >>>> eval(m)
> >>>> y
> >>>> 
> >>>>   
> >>> function(x) FUN(x+1)
> >>>
> >>> However the story doesn't end there.  The substitution appears to 
> >>> have been made, even though the printed version, this 
> time, suggests 
> >>> otherwise.
> >>>
> >>>   
> >>> 
> >>>> y(pi)
> >>>> 
> >>>>   
> >>> [1] -0.841471
> >>>   
> >>> 
> >>>> sin(pi+1)
> >>>> 
> >>>>   
> >>> [1] -0.841471
> >>>   
> >>>
> >>>   
> >>> 
> >> Yes, this is (fairly) well known. It has to do with the 
> retention of 
> >> function source.
> >>
> >> The thing to notice is that it is only the printing of y that is 
> >> really confused. If you do
> >>
> >> dput(y)
> >> attr(y, "source")
> >> attr(y, "source") <- NULL
> >> y
> >>
> >> then you should see the point. The tricky bit is that the "source" 
> >> attribute exists in an intermediate form inside m. Notice that m 
> >> contains, not the function itself, but a call to the function 
> >> `function`
> >>
> >> which creates the function when eval'ed. This call contains the 
> >> function
> >>
> >> source as its 4th element (look at m[[3]][[4]] in your 
> example), and 
> >> you
> >>
> >> might try setting it to NULL and see how things will clear up.
> >>
> >> The issue with substitute is that it cannot sensibly 
> substitute into 
> >> character vectors, so it just leaves  the source as is, 
> which gives 
> >> the symptoms you see. It could, however, and probably should, 
> >> recognize calls to `function` and NULL out their 4th element. It 
> >> c

Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)

[Bill.Venables]

[EMAIL PROTECTED] (i.e. I) wrote:

> 3. Modify substitute() so that it strips source attributes (or
anything
> else apparently visible that it will not manipulate) from objects.
> Sorry folks, too dangerous.  (I concede this appears to be a bit of an
> overkill, too.)

Peter Dalgaard responded:
  
Actually, this is the easier fix to my mind. Where do you see the
danger?

To which I reply:

Well, if it's feasible, I'd recommend this as the way to go.  My
detached 
phrase "Sorry folks, too dangerous" was simply my wondering how we might

field the inevitable howls of protest when people find that something
has 
changed.  I know people will notice since this is a glych I spotted when

trying to debug someone else's code, but that person, at least, will 
applaud I'm sure.

In short, I don't think there are any real dangers.  I just thought it 
would slow things down too much, but perhaps not.

Bill Venables.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)

[murdoch]

On 12/23/2006 5:28 AM, Peter Dalgaard wrote:
> [EMAIL PROTECTED] wrote:
>> Thanks Peter.  I see the dilemma.  It is serious in my view, though,
>> even if I can't see an elegant way round it.
>>
>> I guess the only possibilities are
>>
>> 1. Only keep the source in printing or, much more seriously, dumping, if
>> the source attribute parses to an object structually identical to the
>> function itself (even I can see this is going to be impractical)
>>
>>   
> Yes, dumping is the serious issue here. One should also consider that 
> inconsistencies can be created by other means than substitute(), e.g. by 
> brute force.
> 
>> 2. Make the default keep.source option FALSE rather than TRUE and warn
>> people that switching it on can be unsafe in language manipulation.
>> This would be practical, I suggest, if comments were kept as part of the
>> function itself, as well as in the source attribute, but if comments are
>> only kept in the source attribute (as appears to be the case now) I
>> concede this becomes impractical.
>>
>>   
> The whole source attribute construction was created because there was no 
> way (that we could find, anyway) to make comment and whitespace handling 
> sane without either changing the language or making the parser insanely 
> complicated. Old R hacks will remember how comments intended for the end 
> of a for loop could move to the top when the function was listed.
> 
> The basic issue is that S's syntactic sugar coat was modeled on C, but C 
> is a compiled language, so its parsers just skip comments and 
> whitespace. Trying to retain comments leads to complications Even in 
> a simple function call f(a=b), there are 7 places to stick in comments, 
> so at the very least you need to deal with pre-comments, post-comments, 
> and sometimes in-the-middle-comments. And what is worse, there are 
> ambiguities, which make automatic parser generators unhappy: Does a 
> comment between two expressions belong with the former or the latter? Etc...
> 
>> 3. Modify substitute() so that it strips source attributes (or anything
>> else apparently visible that it will not manipulate) from objects.
>> Sorry folks, too dangerous.  (I concede this appears to be a bit of an
>> overkill, too.)
>>
>>   
> Actually, this is the easier fix to my mind. Where do you see the danger?

I think we should get rid of source attributes completely, since they 
are no longer needed, but your comment still applies to source 
references. We should strip them when code gets modified.

Duncan Murdoch

> 
>> Perhaps the compromise has to be to warn people that keep.source=TRUE
>> can be dangerous in this way, both in the help informaton for options()
>> and for substitute().
>>
>> ?
>>
>> Bill Venables.
>>
>> -Original Message-
>> From: Peter Dalgaard [mailto:[EMAIL PROTECTED] 
>> Sent: Friday, 22 December 2006 9:47 PM
>> To: Venables, Bill (CMIS, Cleveland)
>> Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
>> Subject: Re: [Rd] substitute creates an object which prints incorrectly
>> (PR#9427)
>>
>> [EMAIL PROTECTED] wrote:
>>   
>>> The function "substitute" seems to fail to make a genuine
>>> substitution, although the printed verision seems fine.  Here is an
>>> example.
>>>
>>>   
>>> 
>>>> m <- substitute(Y <- function(x) FUN(x+1), 
>>>> 
>>>>   
>>> + list(Y = as.name("y"), FUN = as.name("sin")))
>>>   
>>> 
>>>> m
>>>> 
>>>>   
>>> y <- function(x) sin(x + 1)
>>>   
>>> 
>>>> eval(m)
>>>> y
>>>> 
>>>>   
>>> function(x) FUN(x+1)
>>>
>>> However the story doesn't end there.  The substitution appears to have
>>> been made, even though the printed version, this time, suggests
>>> otherwise.
>>>
>>>   
>>> 
>>>> y(pi)
>>>> 
>>>>   
>>> [1] -0.841471
>>>   
>>> 
>>>> sin(pi+1)
>>>> 
>>>>   
>>> [1] -0.841471
>>>   
>>>
>>>   
>>> 
>> Yes, this is (fairly) well known. It has to do with the retention of 
>> function source.
>>
>> The thing to notice is that it is only the printing of y that is really 
>> confused. If you do
>>
>> dput(y)
>> attr(y, "source")
>> attr(y, "

Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)

[Duncan Murdoch]

On 12/23/2006 5:28 AM, Peter Dalgaard wrote:
> [EMAIL PROTECTED] wrote:
>> Thanks Peter.  I see the dilemma.  It is serious in my view, though,
>> even if I can't see an elegant way round it.
>>
>> I guess the only possibilities are
>>
>> 1. Only keep the source in printing or, much more seriously, dumping, if
>> the source attribute parses to an object structually identical to the
>> function itself (even I can see this is going to be impractical)
>>
>>   
> Yes, dumping is the serious issue here. One should also consider that 
> inconsistencies can be created by other means than substitute(), e.g. by 
> brute force.
> 
>> 2. Make the default keep.source option FALSE rather than TRUE and warn
>> people that switching it on can be unsafe in language manipulation.
>> This would be practical, I suggest, if comments were kept as part of the
>> function itself, as well as in the source attribute, but if comments are
>> only kept in the source attribute (as appears to be the case now) I
>> concede this becomes impractical.
>>
>>   
> The whole source attribute construction was created because there was no 
> way (that we could find, anyway) to make comment and whitespace handling 
> sane without either changing the language or making the parser insanely 
> complicated. Old R hacks will remember how comments intended for the end 
> of a for loop could move to the top when the function was listed.
> 
> The basic issue is that S's syntactic sugar coat was modeled on C, but C 
> is a compiled language, so its parsers just skip comments and 
> whitespace. Trying to retain comments leads to complications Even in 
> a simple function call f(a=b), there are 7 places to stick in comments, 
> so at the very least you need to deal with pre-comments, post-comments, 
> and sometimes in-the-middle-comments. And what is worse, there are 
> ambiguities, which make automatic parser generators unhappy: Does a 
> comment between two expressions belong with the former or the latter? Etc...
> 
>> 3. Modify substitute() so that it strips source attributes (or anything
>> else apparently visible that it will not manipulate) from objects.
>> Sorry folks, too dangerous.  (I concede this appears to be a bit of an
>> overkill, too.)
>>
>>   
> Actually, this is the easier fix to my mind. Where do you see the danger?

I think we should get rid of source attributes completely, since they 
are no longer needed, but your comment still applies to source 
references. We should strip them when code gets modified.

Duncan Murdoch

> 
>> Perhaps the compromise has to be to warn people that keep.source=TRUE
>> can be dangerous in this way, both in the help informaton for options()
>> and for substitute().
>>
>> ?
>>
>> Bill Venables.
>>
>> -Original Message-
>> From: Peter Dalgaard [mailto:[EMAIL PROTECTED] 
>> Sent: Friday, 22 December 2006 9:47 PM
>> To: Venables, Bill (CMIS, Cleveland)
>> Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
>> Subject: Re: [Rd] substitute creates an object which prints incorrectly
>> (PR#9427)
>>
>> [EMAIL PROTECTED] wrote:
>>   
>>> The function "substitute" seems to fail to make a genuine
>>> substitution, although the printed verision seems fine.  Here is an
>>> example.
>>>
>>>   
>>> 
>>>> m <- substitute(Y <- function(x) FUN(x+1), 
>>>> 
>>>>   
>>> + list(Y = as.name("y"), FUN = as.name("sin")))
>>>   
>>> 
>>>> m
>>>> 
>>>>   
>>> y <- function(x) sin(x + 1)
>>>   
>>> 
>>>> eval(m)
>>>> y
>>>> 
>>>>   
>>> function(x) FUN(x+1)
>>>
>>> However the story doesn't end there.  The substitution appears to have
>>> been made, even though the printed version, this time, suggests
>>> otherwise.
>>>
>>>   
>>> 
>>>> y(pi)
>>>> 
>>>>   
>>> [1] -0.841471
>>>   
>>> 
>>>> sin(pi+1)
>>>> 
>>>>   
>>> [1] -0.841471
>>>   
>>>
>>>   
>>> 
>> Yes, this is (fairly) well known. It has to do with the retention of 
>> function source.
>>
>> The thing to notice is that it is only the printing of y that is really 
>> confused. If you do
>>
>> dput(y)
>> attr(y, "source")
>> attr(y, "

Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)

[Peter Dalgaard]

[EMAIL PROTECTED] wrote:
> Thanks Peter.  I see the dilemma.  It is serious in my view, though,
> even if I can't see an elegant way round it.
>
> I guess the only possibilities are
>
> 1. Only keep the source in printing or, much more seriously, dumping, if
> the source attribute parses to an object structually identical to the
> function itself (even I can see this is going to be impractical)
>
>   
Yes, dumping is the serious issue here. One should also consider that 
inconsistencies can be created by other means than substitute(), e.g. by 
brute force.

> 2. Make the default keep.source option FALSE rather than TRUE and warn
> people that switching it on can be unsafe in language manipulation.
> This would be practical, I suggest, if comments were kept as part of the
> function itself, as well as in the source attribute, but if comments are
> only kept in the source attribute (as appears to be the case now) I
> concede this becomes impractical.
>
>   
The whole source attribute construction was created because there was no 
way (that we could find, anyway) to make comment and whitespace handling 
sane without either changing the language or making the parser insanely 
complicated. Old R hacks will remember how comments intended for the end 
of a for loop could move to the top when the function was listed.

The basic issue is that S's syntactic sugar coat was modeled on C, but C 
is a compiled language, so its parsers just skip comments and 
whitespace. Trying to retain comments leads to complications Even in 
a simple function call f(a=b), there are 7 places to stick in comments, 
so at the very least you need to deal with pre-comments, post-comments, 
and sometimes in-the-middle-comments. And what is worse, there are 
ambiguities, which make automatic parser generators unhappy: Does a 
comment between two expressions belong with the former or the latter? Etc...

> 3. Modify substitute() so that it strips source attributes (or anything
> else apparently visible that it will not manipulate) from objects.
> Sorry folks, too dangerous.  (I concede this appears to be a bit of an
> overkill, too.)
>
>   
Actually, this is the easier fix to my mind. Where do you see the danger?

> Perhaps the compromise has to be to warn people that keep.source=TRUE
> can be dangerous in this way, both in the help informaton for options()
> and for substitute().
>
> ?
>
> Bill Venables.
>
> -Original Message-
> From: Peter Dalgaard [mailto:[EMAIL PROTECTED] 
> Sent: Friday, 22 December 2006 9:47 PM
> To: Venables, Bill (CMIS, Cleveland)
> Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
> Subject: Re: [Rd] substitute creates an object which prints incorrectly
> (PR#9427)
>
> [EMAIL PROTECTED] wrote:
>   
>> The function "substitute" seems to fail to make a genuine
>> substitution, although the printed verision seems fine.  Here is an
>> example.
>>
>>   
>> 
>>> m <- substitute(Y <- function(x) FUN(x+1), 
>>> 
>>>   
>> + list(Y = as.name("y"), FUN = as.name("sin")))
>>   
>> 
>>> m
>>> 
>>>   
>> y <- function(x) sin(x + 1)
>>   
>> 
>>> eval(m)
>>> y
>>> 
>>>   
>> function(x) FUN(x+1)
>>
>> However the story doesn't end there.  The substitution appears to have
>> been made, even though the printed version, this time, suggests
>> otherwise.
>>
>>   
>> 
>>> y(pi)
>>> 
>>>   
>> [1] -0.841471
>>   
>> 
>>> sin(pi+1)
>>> 
>>>   
>> [1] -0.841471
>>   
>>
>>   
>> 
> Yes, this is (fairly) well known. It has to do with the retention of 
> function source.
>
> The thing to notice is that it is only the printing of y that is really 
> confused. If you do
>
> dput(y)
> attr(y, "source")
> attr(y, "source") <- NULL
> y
>
> then you should see the point. The tricky bit is that the "source" 
> attribute exists in an intermediate form inside m. Notice that m 
> contains, not the function itself, but a call to the function `function`
>
> which creates the function when eval'ed. This call contains the function
>
> source as its 4th element (look at m[[3]][[4]] in your example), and you
>
> might try setting it to NULL and see how things will clear up.
>
> The issue with substitute is that it cannot sensibly substitute into 
> character vectors, so it just leaves  the source as is, which gives the 
> symptoms you see. It could, however, and probably should, recognize 
&

Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)

[Bill.Venables]

Thanks Peter.  I see the dilemma.  It is serious in my view, though,
even if I can't see an elegant way round it.

I guess the only possibilities are

1. Only keep the source in printing or, much more seriously, dumping, if
the source attribute parses to an object structually identical to the
function itself (even I can see this is going to be impractical)

2. Make the default keep.source option FALSE rather than TRUE and warn
people that switching it on can be unsafe in language manipulation.
This would be practical, I suggest, if comments were kept as part of the
function itself, as well as in the source attribute, but if comments are
only kept in the source attribute (as appears to be the case now) I
concede this becomes impractical.

3. Modify substitute() so that it strips source attributes (or anything
else apparently visible that it will not manipulate) from objects.
Sorry folks, too dangerous.  (I concede this appears to be a bit of an
overkill, too.)

Perhaps the compromise has to be to warn people that keep.source=TRUE
can be dangerous in this way, both in the help informaton for options()
and for substitute().

?

Bill Venables.

-Original Message-
From: Peter Dalgaard [mailto:[EMAIL PROTECTED] 
Sent: Friday, 22 December 2006 9:47 PM
To: Venables, Bill (CMIS, Cleveland)
Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
Subject: Re: [Rd] substitute creates an object which prints incorrectly
(PR#9427)

[EMAIL PROTECTED] wrote:
> The function "substitute" seems to fail to make a genuine
> substitution, although the printed verision seems fine.  Here is an
> example.
>
>   
>> m <- substitute(Y <- function(x) FUN(x+1), 
>> 
> + list(Y = as.name("y"), FUN = as.name("sin")))
>   
>> m
>> 
> y <- function(x) sin(x + 1)
>   
>> eval(m)
>> y
>> 
> function(x) FUN(x+1)
>
> However the story doesn't end there.  The substitution appears to have
> been made, even though the printed version, this time, suggests
> otherwise.
>
>   
>> y(pi)
>> 
> [1] -0.841471
>   
>> sin(pi+1)
>> 
> [1] -0.841471
>   
>
>   
Yes, this is (fairly) well known. It has to do with the retention of 
function source.

The thing to notice is that it is only the printing of y that is really 
confused. If you do

dput(y)
attr(y, "source")
attr(y, "source") <- NULL
y

then you should see the point. The tricky bit is that the "source" 
attribute exists in an intermediate form inside m. Notice that m 
contains, not the function itself, but a call to the function `function`

which creates the function when eval'ed. This call contains the function

source as its 4th element (look at m[[3]][[4]] in your example), and you

might try setting it to NULL and see how things will clear up.

The issue with substitute is that it cannot sensibly substitute into 
character vectors, so it just leaves  the source as is, which gives the 
symptoms you see. It could, however, and probably should, recognize 
calls to `function` and NULL out their 4th element. It cannot be done 
completely failsafe though (`function` could result from a computation, 
or even be part of the substitution), so one has to decide that the 
extreme cases are too extreme worry about them.
 
-pd

> Bill Venables 
> CMIS, CSIRO Laboratories, 
> PO Box 120, Cleveland, Qld. 4163 
> AUSTRALIA 
> Office Phone (email preferred): +61 7 3826 7251 
> Fax (if absolutely necessary):+61 7 3826 7304 
> Mobile (rarely used):+61 4 1963 4642 
> Home Phone:  +61 7 3286 7700 
> mailto:[EMAIL PROTECTED] 
> http://www.cmis.csiro.au/bill.venables/ 
>
>
> --please do not edit the information below--
>
> Version:
>  platform = i386-pc-mingw32
>  arch = i386
>  os = mingw32
>  system = i386, mingw32
>  status = 
>  major = 2
>  minor = 4.1
>  year = 2006
>  month = 12
>  day = 18
>  svn rev = 40228
>  language = R
>  version.string = R version 2.4.1 (2006-12-18)
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
>
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
>
ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>
> Search Path:
>  .GlobalEnv, .R_Store, package:RODBC, package:xlsReadWrite,
> package:cluster, package:vegan, package:ASOR, package:stats,
> package:graphics, package:grDevices, package:utils, package:datasets,
> .R_Data, .R_Utils, package:svIDE, package:tcltk, package:methods,
> Autoloads, package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)

[Gabor Grothendieck]

Try issuing the command:

   options(keep.source = FALSE)

prior to running the code you displayed to force the actual source,
rather than the source attribute, to be displayed by print when printing
functions.

On 12/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The function "substitute" seems to fail to make a genuine
> substitution, although the printed verision seems fine.  Here is an
> example.
>
> > m <- substitute(Y <- function(x) FUN(x+1),
> + list(Y = as.name("y"), FUN = as.name("sin")))
> > m
> y <- function(x) sin(x + 1)
> > eval(m)
> > y
> function(x) FUN(x+1)
>
> However the story doesn't end there.  The substitution appears to have
> been made, even though the printed version, this time, suggests
> otherwise.
>
> > y(pi)
> [1] -0.841471
> > sin(pi+1)
> [1] -0.841471
> >
>
> Bill Venables
> CMIS, CSIRO Laboratories,
> PO Box 120, Cleveland, Qld. 4163
> AUSTRALIA
> Office Phone (email preferred): +61 7 3826 7251
> Fax (if absolutely necessary):+61 7 3826 7304
> Mobile (rarely used):+61 4 1963 4642
> Home Phone:  +61 7 3286 7700
> mailto:[EMAIL PROTECTED]
> http://www.cmis.csiro.au/bill.venables/
>
>
> --please do not edit the information below--
>
> Version:
>  platform = i386-pc-mingw32
>  arch = i386
>  os = mingw32
>  system = i386, mingw32
>  status =
>  major = 2
>  minor = 4.1
>  year = 2006
>  month = 12
>  day = 18
>  svn rev = 40228
>  language = R
>  version.string = R version 2.4.1 (2006-12-18)
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
> LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
> ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>
> Search Path:
>  .GlobalEnv, .R_Store, package:RODBC, package:xlsReadWrite,
> package:cluster, package:vegan, package:ASOR, package:stats,
> package:graphics, package:grDevices, package:utils, package:datasets,
> .R_Data, .R_Utils, package:svIDE, package:tcltk, package:methods,
> Autoloads, package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute creates an object which prints incorrectly (PR#9427)

[Peter Dalgaard]

[EMAIL PROTECTED] wrote:
> The function "substitute" seems to fail to make a genuine
> substitution, although the printed verision seems fine.  Here is an
> example.
>
>   
>> m <- substitute(Y <- function(x) FUN(x+1), 
>> 
> + list(Y = as.name("y"), FUN = as.name("sin")))
>   
>> m
>> 
> y <- function(x) sin(x + 1)
>   
>> eval(m)
>> y
>> 
> function(x) FUN(x+1)
>
> However the story doesn't end there.  The substitution appears to have
> been made, even though the printed version, this time, suggests
> otherwise.
>
>   
>> y(pi)
>> 
> [1] -0.841471
>   
>> sin(pi+1)
>> 
> [1] -0.841471
>   
>
>   
Yes, this is (fairly) well known. It has to do with the retention of 
function source.

The thing to notice is that it is only the printing of y that is really 
confused. If you do

dput(y)
attr(y, "source")
attr(y, "source") <- NULL
y

then you should see the point. The tricky bit is that the "source" 
attribute exists in an intermediate form inside m. Notice that m 
contains, not the function itself, but a call to the function `function` 
which creates the function when eval'ed. This call contains the function 
source as its 4th element (look at m[[3]][[4]] in your example), and you 
might try setting it to NULL and see how things will clear up.

The issue with substitute is that it cannot sensibly substitute into 
character vectors, so it just leaves  the source as is, which gives the 
symptoms you see. It could, however, and probably should, recognize 
calls to `function` and NULL out their 4th element. It cannot be done 
completely failsafe though (`function` could result from a computation, 
or even be part of the substitution), so one has to decide that the 
extreme cases are too extreme worry about them.
 
-pd

> Bill Venables 
> CMIS, CSIRO Laboratories, 
> PO Box 120, Cleveland, Qld. 4163 
> AUSTRALIA 
> Office Phone (email preferred): +61 7 3826 7251 
> Fax (if absolutely necessary):+61 7 3826 7304 
> Mobile (rarely used):+61 4 1963 4642 
> Home Phone:  +61 7 3286 7700 
> mailto:[EMAIL PROTECTED] 
> http://www.cmis.csiro.au/bill.venables/ 
>
>
> --please do not edit the information below--
>
> Version:
>  platform = i386-pc-mingw32
>  arch = i386
>  os = mingw32
>  system = i386, mingw32
>  status = 
>  major = 2
>  minor = 4.1
>  year = 2006
>  month = 12
>  day = 18
>  svn rev = 40228
>  language = R
>  version.string = R version 2.4.1 (2006-12-18)
>
> Windows XP Professional (build 2600) Service Pack 2.0
>
> Locale:
> LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
> ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
>
> Search Path:
>  .GlobalEnv, .R_Store, package:RODBC, package:xlsReadWrite,
> package:cluster, package:vegan, package:ASOR, package:stats,
> package:graphics, package:grDevices, package:utils, package:datasets,
> .R_Data, .R_Utils, package:svIDE, package:tcltk, package:methods,
> Autoloads, package:base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute creates an object which prints incorrectly (PR#9427)

[Bill . Venables]

The function "substitute" seems to fail to make a genuine
substitution, although the printed verision seems fine.  Here is an
example.

> m <- substitute(Y <- function(x) FUN(x+1), 
+ list(Y = as.name("y"), FUN = as.name("sin")))
> m
y <- function(x) sin(x + 1)
> eval(m)
> y
function(x) FUN(x+1)

However the story doesn't end there.  The substitution appears to have
been made, even though the printed version, this time, suggests
otherwise.

> y(pi)
[1] -0.841471
> sin(pi+1)
[1] -0.841471
>

Bill Venables 
CMIS, CSIRO Laboratories, 
PO Box 120, Cleveland, Qld. 4163 
AUSTRALIA 
Office Phone (email preferred): +61 7 3826 7251 
Fax (if absolutely necessary):+61 7 3826 7304 
Mobile (rarely used):+61 4 1963 4642 
Home Phone:  +61 7 3286 7700 
mailto:[EMAIL PROTECTED] 
http://www.cmis.csiro.au/bill.venables/ 


--please do not edit the information below--

Version:
 platform = i386-pc-mingw32
 arch = i386
 os = mingw32
 system = i386, mingw32
 status = 
 major = 2
 minor = 4.1
 year = 2006
 month = 12
 day = 18
 svn rev = 40228
 language = R
 version.string = R version 2.4.1 (2006-12-18)

Windows XP Professional (build 2600) Service Pack 2.0

Locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MON
ETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252

Search Path:
 .GlobalEnv, .R_Store, package:RODBC, package:xlsReadWrite,
package:cluster, package:vegan, package:ASOR, package:stats,
package:graphics, package:grDevices, package:utils, package:datasets,
.R_Data, .R_Utils, package:svIDE, package:tcltk, package:methods,
Autoloads, package:base

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute(INDICES) in by.data.frame returns invalid multi-line (PR#9109)

[murdoch]

On 7/28/2006 7:53 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Philip Kensche
> Version: 2.3.0

This version is obsolete, but the error does occur in the current R-patched.

> OS: Redhat Linux
> Submission from: (NULL) (131.174.88.204)
> 
> 
> Try this:
> 
> --
> x <- data.frame(the.first.column=c("A"), the.second.column=c("b"),
> the.third.column=c("d"), and.many.more.columns=c("e"))
> 
> by(x, paste(x$the.first.column, x$the.second.column, x$and.many.more.columns,
> sep="."), function (y) { print("Hello!") })
> --
> 
> The following error message is produced on my system:
> 
> Error in "names<-.default"(`*tmp*`, value = c("paste(x$the.first.column,
> x$the.second.column, x$and.many.more.columns, ",  :
> 'names' attribute [2] must be the same length as the vector [1]
> 
> Calling substitute(INDICES) after debug(by.data.frame) returns:
> --
> paste(x$the.first.column, x$the.second.column, x$and.many.more.columns,
> sep = ".")
> --
> i.e. the sep = ... is on the next line.

The problem is that

  names(IND) <- deparse(substitute(INDICES))

wraps the long expression; a patch is to replace that line with

  names(IND) <- deparse(substitute(INDICES), width=500)

which would need a much longer line to trigger the error, or

  names(IND) <- deparse(substitute(INDICES))[1]

I'll do the latter, and look for other instances of the same sort of thing.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute(INDICES) in by.data.frame returns invalid multi-line name (PR#9108)

[Duncan Murdoch]

On 7/28/2006 7:53 AM, [EMAIL PROTECTED] wrote:
> Full_Name: Philip Kensche
> Version: 2.3.0

This version is obsolete, but the error does occur in the current R-patched.

> OS: Redhat Linux
> Submission from: (NULL) (131.174.88.204)
> 
> 
> Try this:
> 
> --
> x <- data.frame(the.first.column=c("A"), the.second.column=c("b"),
> the.third.column=c("d"), and.many.more.columns=c("e"))
> 
> by(x, paste(x$the.first.column, x$the.second.column, x$and.many.more.columns,
> sep="."), function (y) { print("Hello!") })
> --
> 
> The following error message is produced on my system:
> 
> Error in "names<-.default"(`*tmp*`, value = c("paste(x$the.first.column,
> x$the.second.column, x$and.many.more.columns, ",  :
> 'names' attribute [2] must be the same length as the vector [1]
> 
> Calling substitute(INDICES) after debug(by.data.frame) returns:
> --
> paste(x$the.first.column, x$the.second.column, x$and.many.more.columns,
> sep = ".")
> --
> i.e. the sep = ... is on the next line.

The problem is that

  names(IND) <- deparse(substitute(INDICES))

wraps the long expression; a patch is to replace that line with

  names(IND) <- deparse(substitute(INDICES), width=500)

which would need a much longer line to trigger the error, or

  names(IND) <- deparse(substitute(INDICES))[1]

I'll do the latter, and look for other instances of the same sort of thing.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] substitute(INDICES) in by.data.frame returns invalid multi-line name (PR#9108)

[pkensche]

Full_Name: Philip Kensche
Version: 2.3.0
OS: Redhat Linux
Submission from: (NULL) (131.174.88.204)


Try this:

--
x <- data.frame(the.first.column=c("A"), the.second.column=c("b"),
the.third.column=c("d"), and.many.more.columns=c("e"))

by(x, paste(x$the.first.column, x$the.second.column, x$and.many.more.columns,
sep="."), function (y) { print("Hello!") })
--

The following error message is produced on my system:

Error in "names<-.default"(`*tmp*`, value = c("paste(x$the.first.column,
x$the.second.column, x$and.many.more.columns, ",  :
'names' attribute [2] must be the same length as the vector [1]

Calling substitute(INDICES) after debug(by.data.frame) returns:
--
paste(x$the.first.column, x$the.second.column, x$and.many.more.columns,
sep = ".")
--
i.e. the sep = ... is on the next line.

Greetings,

Philip

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute() changed since R2.3.0 (2006-02-02 r37243)?

[Duncan Murdoch]

On 4/3/2006 8:08 AM, Henrik Bengtsson wrote:
> Follow up:  I've downloaded todays R v2.3.0 alpha (2006-04-02 r37626)
> for Windows and the below bug has been fixed:
> 
>> yaa <- function(...) substitute(list(...))
>> yaa(foo(x,y,...,z))
> list(foo(x, y, ..., z))
> 
> Thank you (Duncan!?)

Yes, I think it's fixed.  I also caught the older bug that

substitute(list(..., z), list(z=1))

returned list(..., z), instead of list(..., 1).  The presence of both 
bugs within a few lines of each other in the source made repairs much 
more interesting.

Duncan Murdoch

> Henrik
> 
> On 3/29/06, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
>> On 29 Mar 2006 11:58:34 +0200, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
>> > "Henrik Bengtsson" <[EMAIL PROTECTED]> writes:
>> >
>> > > Hi,
>> > >
>> > > I've got the following two versions of R on WinXP:
>> > >
>> > > A) R Version 2.3.0 Under development (unstable) (2006-02-02 r37243)
>> > > B) R Version 2.3.0 Under development (unstable) (2006-03-27 r37579)
>> > >
>> > > and a the following "test.R" script:
>> > >
>> > > foo <- function(path, ...) { print(path) }
>> > > bar <- function(x, ...) foo(...)
>> > > wow <- function(x, ...) capture.output(foo(...))
>> > > bar(1, path=2)
>> > > print(wow(1, path=2))
>> > >
>> > > With A, I get:
>> > >
>> > > > source("test.R")
>> > > [1] 2
>> > > [1] "[1] 2"
>> > >
>> > > But with B, I get
>> > > > source("test.R")
>> > > [1] 2
>> > > Error in print(path) : argument "path" is missing, with no default
>> > >
>> > > Further debugging led me to the following test2.R script:
>> > >
>> > > foo <- function(path, ...) { print(path) }
>> > > bar <- function(x, ...) foo(...)
>> > > wow <- function(x, ...) yaa(foo(...))
>> > > yaa <- function(...) substitute(list(...))
>> > > bar(1, path=2)
>> > > print(wow(1, path=2))
>> > >
>> > > With A, I get
>> > >
>> > > > source("test2.R")
>> > > [1] 2
>> > > list(foo(...))
>> > >
>> > > But with B, I get
>> > >
>> > > > source("test.R")
>> > > [1] 2
>> > > list(foo())
>> > >
>> > > Note that '...' is missing in the latest version.  I don't think this is 
>> > > wanted.
>> >
>> > I suspect that you're right. Just for reproduction purposes: The
>> > script is not needed, and the whole thing simplifies to the two lines:
>> >
>> > yaa <- function(...) substitute(list(...))
>> > yaa(foo(...))
>> >
>> > which gives list(foo()) in 2.3.0 alpha and used to give list(foo(...)).
>>
>> And, yaa(foo(x,y,...,z)) gives list(foo(x, y, z)) but used to give
>> list(foo(x, y, ..., z)).
>>
>> /Henrik
>>
>> >
>> > --
>> >O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
>> >   c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
>> >  (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 
>> > 35327918
>> > ~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907
>> >
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute() changed since R2.3.0 (2006-02-02 r37243)?

[Henrik Bengtsson]

Follow up:  I've downloaded todays R v2.3.0 alpha (2006-04-02 r37626)
for Windows and the below bug has been fixed:

> yaa <- function(...) substitute(list(...))
> yaa(foo(x,y,...,z))
list(foo(x, y, ..., z))

Thank you (Duncan!?)

Henrik

On 3/29/06, Henrik Bengtsson <[EMAIL PROTECTED]> wrote:
> On 29 Mar 2006 11:58:34 +0200, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> > "Henrik Bengtsson" <[EMAIL PROTECTED]> writes:
> >
> > > Hi,
> > >
> > > I've got the following two versions of R on WinXP:
> > >
> > > A) R Version 2.3.0 Under development (unstable) (2006-02-02 r37243)
> > > B) R Version 2.3.0 Under development (unstable) (2006-03-27 r37579)
> > >
> > > and a the following "test.R" script:
> > >
> > > foo <- function(path, ...) { print(path) }
> > > bar <- function(x, ...) foo(...)
> > > wow <- function(x, ...) capture.output(foo(...))
> > > bar(1, path=2)
> > > print(wow(1, path=2))
> > >
> > > With A, I get:
> > >
> > > > source("test.R")
> > > [1] 2
> > > [1] "[1] 2"
> > >
> > > But with B, I get
> > > > source("test.R")
> > > [1] 2
> > > Error in print(path) : argument "path" is missing, with no default
> > >
> > > Further debugging led me to the following test2.R script:
> > >
> > > foo <- function(path, ...) { print(path) }
> > > bar <- function(x, ...) foo(...)
> > > wow <- function(x, ...) yaa(foo(...))
> > > yaa <- function(...) substitute(list(...))
> > > bar(1, path=2)
> > > print(wow(1, path=2))
> > >
> > > With A, I get
> > >
> > > > source("test2.R")
> > > [1] 2
> > > list(foo(...))
> > >
> > > But with B, I get
> > >
> > > > source("test.R")
> > > [1] 2
> > > list(foo())
> > >
> > > Note that '...' is missing in the latest version.  I don't think this is 
> > > wanted.
> >
> > I suspect that you're right. Just for reproduction purposes: The
> > script is not needed, and the whole thing simplifies to the two lines:
> >
> > yaa <- function(...) substitute(list(...))
> > yaa(foo(...))
> >
> > which gives list(foo()) in 2.3.0 alpha and used to give list(foo(...)).
>
> And, yaa(foo(x,y,...,z)) gives list(foo(x, y, z)) but used to give
> list(foo(x, y, ..., z)).
>
> /Henrik
>
> >
> > --
> >O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
> >   c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> >  (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
> > ~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907
> >

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] substitute() bug by you ? [forwarded]

[Duncan Murdoch]

On 3/29/2006 7:48 AM, Martin Maechler wrote:
> Hi Duncan,
> 
> Just in case you haven't been alerted yet;
> I think the bug mentioned is caused by this change in coerce.c :

Thanks, I was just coming to the same conclusion.  I'll look into it.

Duncan
> 
> 
> r37269 | murdoch | 2006-02-05 18:00:54 +0100 (Sun, 05 Feb 2006) | 7 lines
> 
> Changes to substitute and findVar:
> In C, substitute( , R_NilValue) does no substs, just
> getting PREXPRs, while substitute( , R_GlobalEnv) does
> substitutions.
> 
> In R:  substitute( , .GlobalEnv) is just like
> R_NilValue above, as is substitute( , NULL).
> 
> 
> Regards,
> Martin
> 
> 
> --- start of forwarded message ---
> From: Peter Dalgaard <[EMAIL PROTECTED]>
> To: "Henrik Bengtsson" <[EMAIL PROTECTED]>
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] Substitute() changed since R2.3.0 (2006-02-02 r37243)?
> Date: 29 Mar 2006 11:58:34 +0200
> 
> "Henrik Bengtsson" <[EMAIL PROTECTED]> writes:
> 
>> Hi,
>>
>> I've got the following two versions of R on WinXP:
>>
>> A) R Version 2.3.0 Under development (unstable) (2006-02-02 r37243)
>> B) R Version 2.3.0 Under development (unstable) (2006-03-27 r37579)
>>
>> and a the following "test.R" script:
>>
>> foo <- function(path, ...) { print(path) }
>> bar <- function(x, ...) foo(...)
>> wow <- function(x, ...) capture.output(foo(...))
>> bar(1, path=2)
>> print(wow(1, path=2))
>>
>> With A, I get:
>>
>>> source("test.R")
>> [1] 2
>> [1] "[1] 2"
>>
>> But with B, I get
>>> source("test.R")
>> [1] 2
>> Error in print(path) : argument "path" is missing, with no default
>>
>> Further debugging led me to the following test2.R script:
>>
>> foo <- function(path, ...) { print(path) }
>> bar <- function(x, ...) foo(...)
>> wow <- function(x, ...) yaa(foo(...))
>> yaa <- function(...) substitute(list(...))
>> bar(1, path=2)
>> print(wow(1, path=2))
>>
>> With A, I get
>>
>>> source("test2.R")
>> [1] 2
>> list(foo(...))
>>
>> But with B, I get
>>
>>> source("test.R")
>> [1] 2
>> list(foo())
>>
>> Note that '...' is missing in the latest version.  I don't think this is 
>> wanted.
> 
> I suspect that you're right. Just for reproduction purposes: The
> script is not needed, and the whole thing simplifies to the two lines:
> 
> yaa <- function(...) substitute(list(...))
> yaa(foo(...))
> 
> which gives list(foo()) in 2.3.0 alpha and used to give list(foo(...)).
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute() changed since R2.3.0 (2006-02-02 r37243)?

[Henrik Bengtsson]

On 29 Mar 2006 11:58:34 +0200, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> "Henrik Bengtsson" <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I've got the following two versions of R on WinXP:
> >
> > A) R Version 2.3.0 Under development (unstable) (2006-02-02 r37243)
> > B) R Version 2.3.0 Under development (unstable) (2006-03-27 r37579)
> >
> > and a the following "test.R" script:
> >
> > foo <- function(path, ...) { print(path) }
> > bar <- function(x, ...) foo(...)
> > wow <- function(x, ...) capture.output(foo(...))
> > bar(1, path=2)
> > print(wow(1, path=2))
> >
> > With A, I get:
> >
> > > source("test.R")
> > [1] 2
> > [1] "[1] 2"
> >
> > But with B, I get
> > > source("test.R")
> > [1] 2
> > Error in print(path) : argument "path" is missing, with no default
> >
> > Further debugging led me to the following test2.R script:
> >
> > foo <- function(path, ...) { print(path) }
> > bar <- function(x, ...) foo(...)
> > wow <- function(x, ...) yaa(foo(...))
> > yaa <- function(...) substitute(list(...))
> > bar(1, path=2)
> > print(wow(1, path=2))
> >
> > With A, I get
> >
> > > source("test2.R")
> > [1] 2
> > list(foo(...))
> >
> > But with B, I get
> >
> > > source("test.R")
> > [1] 2
> > list(foo())
> >
> > Note that '...' is missing in the latest version.  I don't think this is 
> > wanted.
>
> I suspect that you're right. Just for reproduction purposes: The
> script is not needed, and the whole thing simplifies to the two lines:
>
> yaa <- function(...) substitute(list(...))
> yaa(foo(...))
>
> which gives list(foo()) in 2.3.0 alpha and used to give list(foo(...)).

And, yaa(foo(x,y,...,z)) gives list(foo(x, y, z)) but used to give
list(foo(x, y, ..., z)).

/Henrik

>
> --
>O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
>   c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
>  (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
> ~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907
>
>


--
Henrik Bengtsson
Mobile: +46 708 909208 (+2h UTC)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Substitute() changed since R2.3.0 (2006-02-02 r37243)?

[Peter Dalgaard]

"Henrik Bengtsson" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I've got the following two versions of R on WinXP:
> 
> A) R Version 2.3.0 Under development (unstable) (2006-02-02 r37243)
> B) R Version 2.3.0 Under development (unstable) (2006-03-27 r37579)
> 
> and a the following "test.R" script:
> 
> foo <- function(path, ...) { print(path) }
> bar <- function(x, ...) foo(...)
> wow <- function(x, ...) capture.output(foo(...))
> bar(1, path=2)
> print(wow(1, path=2))
> 
> With A, I get:
> 
> > source("test.R")
> [1] 2
> [1] "[1] 2"
> 
> But with B, I get
> > source("test.R")
> [1] 2
> Error in print(path) : argument "path" is missing, with no default
> 
> Further debugging led me to the following test2.R script:
> 
> foo <- function(path, ...) { print(path) }
> bar <- function(x, ...) foo(...)
> wow <- function(x, ...) yaa(foo(...))
> yaa <- function(...) substitute(list(...))
> bar(1, path=2)
> print(wow(1, path=2))
> 
> With A, I get
> 
> > source("test2.R")
> [1] 2
> list(foo(...))
> 
> But with B, I get
> 
> > source("test.R")
> [1] 2
> list(foo())
> 
> Note that '...' is missing in the latest version.  I don't think this is 
> wanted.

I suspect that you're right. Just for reproduction purposes: The
script is not needed, and the whole thing simplifies to the two lines:

yaa <- function(...) substitute(list(...))
yaa(foo(...))

which gives list(foo()) in 2.3.0 alpha and used to give list(foo(...)).

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Substitute() changed since R2.3.0 (2006-02-02 r37243)?

[Henrik Bengtsson]

Hi,

I've got the following two versions of R on WinXP:

A) R Version 2.3.0 Under development (unstable) (2006-02-02 r37243)
B) R Version 2.3.0 Under development (unstable) (2006-03-27 r37579)

and a the following "test.R" script:

foo <- function(path, ...) { print(path) }
bar <- function(x, ...) foo(...)
wow <- function(x, ...) capture.output(foo(...))
bar(1, path=2)
print(wow(1, path=2))

With A, I get:

> source("test.R")
[1] 2
[1] "[1] 2"

But with B, I get
> source("test.R")
[1] 2
Error in print(path) : argument "path" is missing, with no default

Further debugging led me to the following test2.R script:

foo <- function(path, ...) { print(path) }
bar <- function(x, ...) foo(...)
wow <- function(x, ...) yaa(foo(...))
yaa <- function(...) substitute(list(...))
bar(1, path=2)
print(wow(1, path=2))

With A, I get

> source("test2.R")
[1] 2
list(foo(...))

But with B, I get

> source("test.R")
[1] 2
list(foo())

Note that '...' is missing in the latest version.  I don't think this is wanted.

/Henrik

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel