Hi Dan, For what it's worth, Renjin requires LISTSXPs to hold either a LISTSXP or a NULL, and this appears to be largely the case in practice based on running tests for thousands of packages (including cross compiled C code). I can only remember it being briefly an issue with the rlang package, but Lionel graciously changed it: https://github.com/r-lib/rlang/pull/579
Best, Alex On Mon, Sep 7, 2020 at 1:24 PM Dan Kortschak via R-devel < r-devel@r-project.org> wrote: > > Hello, > > I am writing an R/Go interoperability tool[1] that work similarly to > Rcpp; the tool takes packages written in Go and performs the necessary > Go type analysis to wrap the Go code with C and R shims that allow the > Go code to then be called from R. The system is largely complete (with > the exception of having a clean approach to handling generalised > attributes in the easy case[2] - the less hand holding case does handle > these). Testing of some of the code is unfortunately lacking because of > the difficulties of testing across environments. > > To make the system flexible I have provided an (intentionally > incomplete) Go API into the R internals which allows reasonably Go > type-safe interaction with SEXP values (Go does not have unions, so > this is uglier than it might be otherwise and unions are faked with Go > interface values). For efficiency reasons I've avoided using R internal > calls where possible (accessors are done with Go code directly, but > allocations are done in R's C code to avoid having to duplicate the > garbage collection mechanics in Go with the obvious risks of error and > possible behaviour skew in the future). > > In doing this work I have some questions that I have not been able to > find answers for in the R-ints doc or hadley/r-internals. > > 1. In R-ints, the LISTSXP SEXP type CDR is said to hold "usually" > LISTSXP or NULL. What does the "usually" mean here? Is it possible > for the CDR to hold values other than LISTSXP or NULL, and is > this NULL NILSXP or C NULL? I assume that the CAR can hold any type > of SEXP, is this correct? > 2. The LANGSXP and DOTSXP types are lists, but the R-ints comments on > them do not say whether the CDR of one of these lists is the same at > the head of the list of devolves to a LISTSXP. Looking through the > code suggests to me that functions that allocate these two types > allocate a LISTSXP and then change only the head of the list to be > the LANGSXP or DOTSXP that's required, meaning that the tail of the > list is all LISTSXP. Is this correct? > > The last question is more a question of interest in design strategy, > and the answer may have been lost to time. In order to reduce the need > to go through Go's interface assertions in a number of cases I have > decided to reinterpret R_NilValue to an untyped Go nil (this is > important for example in list traversal where the CDR can (hopefully) > be only one of two types LISTSXP or NILSXP; in Go this would require a > generalised SEXP return, but by doing this reinterpretation I can > return a *List pointer which may be nil, greatly simplifying the code > and improving the performance). My question her is why a singleton null > value was chosen to be represented as a fully allocated SEXP value > rather than just a C NULL. Also, whether C NULL is used to any great > extent within the internal code. Note that the Go API provides a > mechanism to easily reconvert the nil's used back to a R_NilValue when > returning from a Go function[3]. > > thanks > Dan Kortschak > > [1]https://github.com/rgonomic/rgo > [2]https://github.com/rgonomic/rgo/issues/1 > [3]https://pkg.go.dev/github.com/rgonomic/rgo/sexp?tab=doc#Value.Export > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Alexander Bertram Technical Director *BeDataDriven BV* Web: http://bedatadriven.com Email: a...@bedatadriven.com Tel. Nederlands: +31(0)647205388 Skype: akbertram [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel