[Rd] level of mutability for the type of a SEXP

Laurent Gautier 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
>  structure.

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 mailing list