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

[Laurent Gautier]

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).


Thanks,


Laurent


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