[Rd] Capturing environment associated with a promise
Hi all, It's possible to capture the expression associated with a promise (using substitute). Is there any way to capture the environment associated with a promise? Similarly, is there any way to tell if something is a promise without accidentally evaluating it? Thanks! Hadley -- RStudio / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capturing environment associated with a promise
On 12-10-08 9:22 AM, Hadley Wickham wrote: Hi all, It's possible to capture the expression associated with a promise (using substitute). Is there any way to capture the environment associated with a promise? Similarly, is there any way to tell if something is a promise without accidentally evaluating it? Neither of those is possible in user-level code. The special functions get to see their arguments unevaluated, but users can't write specials, and there is no special to extract an environment from a promise. I think the reasoning is that it keeps the semantics simpler, but I can't remember the cases that make user-level promise handling problematic. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capturing environment associated with a promise
Promises are an implementation detail -- we need to be able to change them, optimize them away, etc, so there is a limit on what we want to expose. Allowing a query of whether a binding is delayed or not should be OK but would want to think that through more carefully before committing to this. luke On Mon, 8 Oct 2012, Hadley Wickham wrote: Hi all, It's possible to capture the expression associated with a promise (using substitute). Is there any way to capture the environment associated with a promise? Similarly, is there any way to tell if something is a promise without accidentally evaluating it? Thanks! Hadley -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Effect of the R framework on ctype.c
Sylvain,
I can see two possible reasons for this (both just speculative without an
actual example):
a) it could be a conflict in (probably system) headers. isupper is typically a
macro so I suspect what happens is that you have two definitions and depending
on the sequence of includes and only the first one wins. By including/removing
ctype.h you probably just change its sequence. Check the pre-processed .c files
containing the isupper() for each of the two cases to see how they differ.
b) locale issues in your system. The implementation of isupper() may respect
locales and R will setup the locale according to the environment, so maybe the
locale is not defining isupper as you think. Maybe a) is only triggered by b)
since the two versions may differ by locale.
There are other reasons one could think of (compiler bug when optimizing the
isupper('A') constant) - it's hard to tell without a way to reproduce it.
Cheers,
Simon
On Oct 8, 2012, at 10:11 AM, Sylvain Loiseau wrote:
Dear all,
I'm facing a strange behavior in the the C code of a R package. This package,
rcqp, is a wrapper on an existing program that I did not write, CWB.
In this package, on a linux (ubuntu and debian) system, the code :
printf(%d\n, isupper('A'));
outputs :
0
When compiled with the R framework (It behaves correctly when CWB is compiled
as a standalone program).
On mac osx, the code produce the expected output.
This unexpected output is observed only in the context of CWB compiled
through rcqp, only on linux (not mac osx), and only under certains
circumstances, since a minimal R package produce the expected output. Even in
CWB, this strange behavior is not observed in any part of the code.
When observed, a work-around for this problem is to remove the include in
which this very function, isupper, is defined:
#include ctype.h
Since the program is compiled and run correctly without this include,
isupper() seems to be also declared elsewhere or ctype to be found by another
mechanism, and the problem seems be due to interactions between the R headers
(?) and the include of the CWB code…
Have you already observed such an effect or do you have any hint?
Best,
Sylvain
-
Sylvain Loiseau
sylvain.lois...@univ-paris13.fr
Université Paris 13-Nord
Laboratoire Lexiques, Dictionnaires, Informatique
(UMR 7187 CNRS/Université Paris 13-Nord)
99 avenue Jean-Baptiste Clément
F-93410 Villetaneuse
__
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] Capturing environment associated with a promise
On Mon, Oct 8, 2012 at 9:22 AM, Hadley Wickham h.wick...@gmail.com wrote: Hi all, It's possible to capture the expression associated with a promise (using substitute). Is there any way to capture the environment associated with a promise? Similarly, is there any way to tell if something is a promise without accidentally evaluating it? Both of these are possible in C. See: https://stat.ethz.ch/pipermail/r-devel/2007-September/046943.html It shows how to query an object to see if its a promise and but rather than extract the environment it shows how to copy a promise without evaluating it; however, it was also my experience that these two were what was actually needed rather than being able to extract the environment. I would also recommend you do some testing since I found that adding promises did not always make as big a difference in performance as I had hoped and the added complexity may not be worth it in all cases. For example, I had a version of proto that supported promises but ggplot2 only ran slightly faster with it so I did not pursue it any further. On the other hand if you are doing it to support self-referential structures then that is a different matter. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
