[Rd] level of mutability for the type of a SEXP
lgautier at gmail.com
Sat Feb 23 15:39:03 CET 2008
2008/2/22, Prof Brian Ripley <ripley at stats.ox.ac.uk>:
> On Tue, 19 Feb 2008, Laurent Gautier wrote:
> > Dear list,
> > I am writing C code to interface with R, and I would like to know the
> > level of mutability for the type of a SEXP.
> > I see that there is a macro/function TYPEOF(), and that it can be used
> > as an l-value, as well as a macro/function SET_TYPEOF().
> The macros are not available to user code, so TYPEOF is not available to
> use as an l-value.
Is the general rule that no macro is available to user code ?
> > My question is "should the type be considered immutable, or it can it
> > change after the SEXP has been created and used for a while ?".
> > I understand that a call to TYPEOF will not perform any conversion,
> > and my question is only about being sure that once the type of a given
> > SEXP is set it cannot change.
> It is SEXPRECs that have types, and their type can be changed and in a few
> cases is in R's internal code. You should only change type between
> SEXPREC types with the same structure, e.g. from VECSXP to EXPRSXP or
> DOTSXP to LISTSXP. I am unaware of any examples where this happens that
> involve a SEXPREC pointed to by a SEXP not in the internal code concerned.
Thanks for your answer.
As you point it out, I overlooked the fact that a SEXP is merely a pointer,
and therefore will not change type.
I systematically looked for usages of TYPEOF/SET_TYPEOF in the base code,
and I could only find use of the macros beyond shortly after the
instantiation of a new object.
> Since a SEXP is a pointer, the type of the SEXPREC it points to can change
> (as which SEXPREC it is can) and frequently does -- that is one way
> arguments are coerced.
> The R Internals manual has the details of the SEXPRECs and their
I will read more about them.
> I don't see the value of knowing though. Anyone who needs to ask about R
> internals should regard the arguments passed to .Call/.External calls as
> read-only and also assume that there is no simultaneous evaluation going
> on that might change them.
My purpose is not to write C code called from R, but to make an
interface between a scripting language and an embedded R.
The reason for my question is that I would like to type a little R
objects accessed from that foreign language, and would not like to see
their type change along the evaluation of R code, and without the
pointer from the scripting language knowing.
The pass-by-value paradigm should not make such things possible, but I
was considering that C-level memory optimization tricks could be
recycling part of object structures (I may or may not be worth the
effort, my little knowledge of SEXPRECs did not give any hint).
> Brian D. Ripley, ripley at stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-devel