Date   
native API documentation

Lukas Stadler
 

Hi,

also, in the meantime, Karl took the time to push additional API documentation (mostly done by Andrew Runnalls) to my github “API documentation” repository.
The automatically generated html documentation is available at https://lukasstadler.github.io/RAPI/html/
The list of functions is a good starting point: https://lukasstadler.github.io/RAPI/html/globals_func.html

This repo now contains documentation for ~100 functions and adds parameter names for 172 functions (almost all provided by Karl).
Even though it doesn’t cover all of the API, this would already be very helpful for someone looking at native code that interfaces with R.

I know that there’s differing opinions as to whether doxygen is the right technology, and what exactly the documentation of functions should contain, but the documentation in this form exists and is already useful.
So I’d ultimately like to bring this topic up with r-devel as well, separated into the parameter names and doxygen comments.

Best,
 Lukas

Re: native API documentation

Alexander Bertram
 

Many thanks for this Lukas and Karl, very helpful. 

I've integrated the documentation into Renjin's compatibility layer- very helpful!

Best,
Alex


On Fri, Jan 13, 2017 at 3:38 PM Lukas Stadler <lukas.stadler@...> wrote:
Hi,

also, in the meantime, Karl took the time to push additional API documentation (mostly done by Andrew Runnalls) to my github “API documentation” repository.
The automatically generated html documentation is available at https://lukasstadler.github.io/RAPI/html/
The list of functions is a good starting point: https://lukasstadler.github.io/RAPI/html/globals_func.html

This repo now contains documentation for ~100 functions and adds parameter names for 172 functions (almost all provided by Karl).
Even though it doesn’t cover all of the API, this would already be very helpful for someone looking at native code that interfaces with R.

I know that there’s differing opinions as to whether doxygen is the right technology, and what exactly the documentation of functions should contain, but the documentation in this form exists and is already useful.
So I’d ultimately like to bring this topic up with r-devel as well, separated into the parameter names and doxygen comments.

Best,
 Lukas

_______________________________________________
Rconsortium-wg-api mailing list
Rconsortium-wg-api@...
https://lists.r-consortium.org/mailman/listinfo/rconsortium-wg-api

Re: trimming down the native API

Karl Millar
 

Thanks for doing this.


A few comments:

- Having files with the same name but in different directories can get
confusing. It'd be good to have distinct names.

- I think the changes to Rinterface.h and Rembedded.h may cause
problems with code that embeds R, e.g. RStudio. Looking at the
functions, there's not much benefit to making them private, so I'd
recommend leaving them alone.

- From Rinternals.h, we might want to keep the following functions for
use in packages:
MAYBE_SHARED, NO_REFERENCES etc.
Rf_installDDVAL
R_RegisterFinalizerEx, R_MakeWeakRefC are referenced in 'Writing R
Extensions', so should probably be kept.

- I'd also recommend looking closely at the functions required by the
packages in src/library. Some of them probably should be kept.


Other functions and variables from Rinternals.h that I think we should
look into making private at time permits:
MARK
VECTOR_PTR
MISSING / SET_MISSING
INTERNAL
HASHTAB / SET_HASHTAB
PRSEEN
SET_PRVALUE
R_InBCInterpreter
R_RestartToken
R_dot_*
R_signal_*_error
R_curErrorBuf
R_cycle_detected

Karl

On Fri, Jan 13, 2017 at 5:52 AM, Lukas Stadler <lukas.stadler@...> wrote:
Happy new year to you all!

One outcome of the discussions in this group and last year’s RIOT workshop
is that the native API deserves a cleanup, moving out things that aren’t
needed as a first step.

My colleague Zbynek took the time to go over the whole API and move all
functionality that is not used into separate header files that are not part
of the public include directory.
He was able to move out 183 functions, and all packages from CRAN (that we
were able to build without special setup) work fine with the changes.

The changes are available as a PR on github:
https://github.com/zslajchrt/r-source/pull/2/files
github also provides a raw diff:
https://patch-diff.githubusercontent.com/raw/zslajchrt/r-source/pull/2.diff

I’d like to gather feedback before suggesting this change to r-devel:
- do you think there’s a better approach than having separate header files
in include/private? our goal was to keep the changes to the main codebase
minimal.
- are there functions or macros that shouldn’t be moved although they are
currently not used by any packages on CRAN?
- are there functions or macros that this patch doesn’t move but we should
still try to move, although this will require fixes in some packages?

The patch is not set in stone, we’re happy to make any changes (or perform
other tasks) that will make it easier for r-devel to accept these changes.
For some code-related comments it may be simpler to post on github (because
you can add comments to specific lines in the changes).

Best,
Lukas

_______________________________________________
Rconsortium-wg-api mailing list
Rconsortium-wg-api@...
https://lists.r-consortium.org/mailman/listinfo/rconsortium-wg-api

Error checks in FFI functions

Mick Jordan
 

What is the expectation on error checking arguments to native functions? For example:

rffi.CAR(1)
*** caught segfault ***
address 0x1, cause 'memory not mapped'

because CAR just assumes it's a list.


But other functions throw errors or check their args to the extent that they at least avoid a crash.

Mick

Re: trimming down the native API

Lukas Stadler
 

Hi Karl!

Thanks for your comments, see my answers inline…

- Lukas

On 18 Jan 2017, at 8:01, Karl Millar <kmillar@...> wrote:

Thanks for doing this.


A few comments:

- Having files with the same name but in different directories can get
confusing. It'd be good to have distinct names.
The problem with using different names is that you have to come up with new names ;-)
Any suggestions?

- I think the changes to Rinterface.h and Rembedded.h may cause
problems with code that embeds R, e.g. RStudio. Looking at the
functions, there's not much benefit to making them private, so I'd
recommend leaving them alone.
Ah, yes, CRAN packages aren’t representative for that part of the API.
I actually think that this part should be extended with enough API to allow RStudio to work without copying stuff from GNU R header files, but that’s another story ;-)

- From Rinternals.h, we might want to keep the following functions for
use in packages:
MAYBE_SHARED, NO_REFERENCES etc.
I disagree on those - they expose details about the GC, so that they shouldn’t be part of the API needlessly.

Rf_installDDVAL
This is just a cached shortcut for sprintf(“..%d”, i) and Rf_install, I don’t see a reason for this to be in the API.

R_RegisterFinalizerEx, R_MakeWeakRefC are referenced in 'Writing R
Extensions', so should probably be kept.
Indeed, we should keep them if they are referenced in the docs.
However, AFAICS this whole concept of weak references seems to be used so little that there could be a separate discussion as to whether it’s necessary, and whether there’s enough usages to be confident that it works in the first place.

- I'd also recommend looking closely at the functions required by the
packages in src/library. Some of them probably should be kept.
The packages in src/library can still access everything - they have a closer relationship anyway, e.g., they use the Defn.h header file which spills many internal details.

Other functions and variables from Rinternals.h that I think we should
look into making private at time permits:
MARK
This one may actually be unused, hard to look for because it’s such a common identifier.
VECTOR_PTR
I fear that Rcpp relies heavily on this..?
MISSING / SET_MISSING
SET_MISSING is only used once in the sprint package, MISSING appear to be unused.
INTERNAL
Another function difficult to look for because of a common identifier :-) seems like it’s only used in Rcpp.
HASHTAB / SET_HASHTAB
These are used by a couple of packages, but it seems doable.
PRSEEN
Rcpp is the only user here, that should be possible.
SET_PRVALUE
This one looks like an oversight, it should be removed.
R_InBCInterpreter
Agreed, no usages anyway.
R_RestartToken
Agreed, no usages anyway.
R_dot_*
Agreed, no usages anyway.
R_signal_*_error
Agreed, no usages anyway.
R_curErrorBuf
Rcpp11 and Rhpc are the only users at the moment, that should be possible.
R_cycle_detected
Agreed, no usages anyway.

Seems like we missed a few opportunities in the initial go.
We’ll update the github PR accordingly.

- Lukas



Karl


On Fri, Jan 13, 2017 at 5:52 AM, Lukas Stadler <lukas.stadler@...> wrote:
Happy new year to you all!

One outcome of the discussions in this group and last year’s RIOT workshop
is that the native API deserves a cleanup, moving out things that aren’t
needed as a first step.

My colleague Zbynek took the time to go over the whole API and move all
functionality that is not used into separate header files that are not part
of the public include directory.
He was able to move out 183 functions, and all packages from CRAN (that we
were able to build without special setup) work fine with the changes.

The changes are available as a PR on github:
https://github.com/zslajchrt/r-source/pull/2/files
github also provides a raw diff:
https://patch-diff.githubusercontent.com/raw/zslajchrt/r-source/pull/2.diff

I’d like to gather feedback before suggesting this change to r-devel:
- do you think there’s a better approach than having separate header files
in include/private? our goal was to keep the changes to the main codebase
minimal.
- are there functions or macros that shouldn’t be moved although they are
currently not used by any packages on CRAN?
- are there functions or macros that this patch doesn’t move but we should
still try to move, although this will require fixes in some packages?

The patch is not set in stone, we’re happy to make any changes (or perform
other tasks) that will make it easier for r-devel to accept these changes.
For some code-related comments it may be simpler to post on github (because
you can add comments to specific lines in the changes).

Best,
Lukas

_______________________________________________
Rconsortium-wg-api mailing list
Rconsortium-wg-api@...
https://lists.r-consortium.org/mailman/listinfo/rconsortium-wg-api

Re: trimming down the native API

Karl Millar
 

For filenames, first it looks like we could simply remove a lot of files with a small amount of effort:
   - private/Linpack.h     The functions here are documented as being unused in R.
   - R-ftp-http.h              No longer exists as it's all been moved to private/R-ftp-http.h
   - private/Memory.h     Contains a single function (R_gc_running) which could be re-added to the public API or moved to Defn.h
   - private/Rdynload.h  Contains a single function (R_getDllInfo) which could be re-added to the public API or moved to Defn.h
   - private/Rmath.h       Contains a single function (Rf_logspace_sum) which could be re-added to the public API.
   - private/Rinterface.h  Should all be made public.

After this, the only two filename clashes are Utils.h and Rinternals.h.  private/Utils.h looks like a random collection of functions, which would fit nicely in Defn.h which also looks like a random collection of functions.  private/Rinternals.h could be named Rprivate.h or R_private_internals.h or something similar.


For VECTOR_PTR, Rcpp uses the macro version using USE_RINTERNALS.  The public function contains just an immediate call to Rf_error() saying not to use that function, so there shouldn't be any code that depends on it doing something useful.

Karl


On Tue, Jan 24, 2017 at 9:14 AM, Lukas Stadler <lukas.stadler@...> wrote:
Hi Karl!

Thanks for your comments, see my answers inline…

- Lukas

> On 18 Jan 2017, at 8:01, Karl Millar <kmillar@...> wrote:
>
> Thanks for doing this.
>
>
> A few comments:
>
> - Having files with the same name but in different directories can get
> confusing.  It'd be good to have distinct names.
The problem with using different names is that you have to come up with new names ;-)
Any suggestions?

> - I think the changes to Rinterface.h and Rembedded.h may cause
> problems with code that embeds R, e.g. RStudio.  Looking at the
> functions, there's not much benefit to making them private, so I'd
> recommend leaving them alone.
Ah, yes, CRAN packages aren’t representative for that part of the API.
I actually think that this part should be extended with enough API to allow RStudio to work without copying stuff from GNU R header files, but that’s another story ;-)

> - From Rinternals.h, we might want to keep the following functions for
> use in packages:
>    MAYBE_SHARED, NO_REFERENCES etc.
I disagree on those - they expose details about the GC, so that they shouldn’t be part of the API needlessly.

>    Rf_installDDVAL
This is just a cached shortcut for sprintf(“..%d”, i) and Rf_install, I don’t see a reason for this to be in the API.

>    R_RegisterFinalizerEx, R_MakeWeakRefC are referenced in 'Writing R
> Extensions', so should probably be kept.
Indeed, we should keep them if they are referenced in the docs.
However, AFAICS this whole concept of weak references seems to be used so little that there could be a separate discussion as to whether it’s necessary, and whether there’s enough usages to be confident that it works in the first place.

> - I'd also recommend looking closely at the functions required by the
> packages in src/library.  Some of them probably should be kept.
The packages in src/library can still access everything - they have a closer relationship anyway, e.g., they use the Defn.h header file which spills many internal details.

> Other functions and variables from Rinternals.h that I think we should
> look into making private at time permits:
>   MARK
This one may actually be unused, hard to look for because it’s such a common identifier.
>   VECTOR_PTR
I fear that Rcpp relies heavily on this..?
>   MISSING / SET_MISSING
SET_MISSING is only used once in the sprint package, MISSING appear to be unused.
>   INTERNAL
Another function difficult to look for because of a common identifier :-) seems like it’s only used in Rcpp.
>   HASHTAB / SET_HASHTAB
These are used by a couple of packages, but it seems doable.
>   PRSEEN
Rcpp is the only user here, that should be possible.
>   SET_PRVALUE
This one looks like an oversight, it should be removed.
>   R_InBCInterpreter
Agreed, no usages anyway.
>   R_RestartToken
Agreed, no usages anyway.
>   R_dot_*
Agreed, no usages anyway.
>   R_signal_*_error
Agreed, no usages anyway.
>   R_curErrorBuf
Rcpp11 and Rhpc are the only users at the moment, that should be possible.
>   R_cycle_detected
Agreed, no usages anyway.

Seems like we missed a few opportunities in the initial go.
We’ll update the github PR accordingly.

- Lukas


>
> Karl
>
>
> On Fri, Jan 13, 2017 at 5:52 AM, Lukas Stadler <lukas.stadler@...> wrote:
>> Happy new year to you all!
>>
>> One outcome of the discussions in this group and last year’s RIOT workshop
>> is that the native API deserves a cleanup, moving out things that aren’t
>> needed as a first step.
>>
>> My colleague Zbynek took the time to go over the whole API and move all
>> functionality that is not used into separate header files that are not part
>> of the public include directory.
>> He was able to move out 183 functions, and all packages from CRAN (that we
>> were able to build without special setup) work fine with the changes.
>>
>> The changes are available as a PR on github:
>> https://github.com/zslajchrt/r-source/pull/2/files
>> github also provides a raw diff:
>> https://patch-diff.githubusercontent.com/raw/zslajchrt/r-source/pull/2.diff
>>
>> I’d like to gather feedback before suggesting this change to r-devel:
>> - do you think there’s a better approach than having separate header files
>> in include/private? our goal was to keep the changes to the main codebase
>> minimal.
>> - are there functions or macros that shouldn’t be moved although they are
>> currently not used by any packages on CRAN?
>> - are there functions or macros that this patch doesn’t move but we should
>> still try to move, although this will require fixes in some packages?
>>
>> The patch is not set in stone, we’re happy to make any changes (or perform
>> other tasks) that will make it easier for r-devel to accept these changes.
>> For some code-related comments it may be simpler to post on github (because
>> you can add comments to specific lines in the changes).
>>
>> Best,
>> Lukas
>>
>> _______________________________________________
>> Rconsortium-wg-api mailing list
>> Rconsortium-wg-api@...consortium.org
>> https://lists.r-consortium.org/mailman/listinfo/rconsortium-wg-api
>>


Re: trimming down the native API

Lukas Stadler
 

Let’s see how Dirk feels about VECTOR_PTR ;-)
Thanks for the filename proposals - I think that’s a good solution, I didn’t consider Defn.h as a target before.

- Lukas

On 24 Jan 2017, at 19:06, Karl Millar <kmillar@...> wrote:

For filenames, first it looks like we could simply remove a lot of files with a small amount of effort:
   - private/Linpack.h     The functions here are documented as being unused in R.
   - R-ftp-http.h              No longer exists as it's all been moved to private/R-ftp-http.h
   - private/Memory.h     Contains a single function (R_gc_running) which could be re-added to the public API or moved to Defn.h
   - private/Rdynload.h  Contains a single function (R_getDllInfo) which could be re-added to the public API or moved to Defn.h
   - private/Rmath.h       Contains a single function (Rf_logspace_sum) which could be re-added to the public API.
   - private/Rinterface.h  Should all be made public.

After this, the only two filename clashes are Utils.h and Rinternals.h.  private/Utils.h looks like a random collection of functions, which would fit nicely in Defn.h which also looks like a random collection of functions.  private/Rinternals.h could be named Rprivate.h or R_private_internals.h or something similar.


For VECTOR_PTR, Rcpp uses the macro version using USE_RINTERNALS.  The public function contains just an immediate call to Rf_error() saying not to use that function, so there shouldn't be any code that depends on it doing something useful.

Karl


On Tue, Jan 24, 2017 at 9:14 AM, Lukas Stadler <lukas.stadler@...> wrote:
Hi Karl!

Thanks for your comments, see my answers inline…

- Lukas

> On 18 Jan 2017, at 8:01, Karl Millar <kmillar@...> wrote:
>
> Thanks for doing this.
>
>
> A few comments:
>
> - Having files with the same name but in different directories can get
> confusing.  It'd be good to have distinct names.
The problem with using different names is that you have to come up with new names ;-)
Any suggestions?

> - I think the changes to Rinterface.h and Rembedded.h may cause
> problems with code that embeds R, e.g. RStudio.  Looking at the
> functions, there's not much benefit to making them private, so I'd
> recommend leaving them alone.
Ah, yes, CRAN packages aren’t representative for that part of the API.
I actually think that this part should be extended with enough API to allow RStudio to work without copying stuff from GNU R header files, but that’s another story ;-)

> - From Rinternals.h, we might want to keep the following functions for
> use in packages:
>    MAYBE_SHARED, NO_REFERENCES etc.
I disagree on those - they expose details about the GC, so that they shouldn’t be part of the API needlessly.

>    Rf_installDDVAL
This is just a cached shortcut for sprintf(“..%d”, i) and Rf_install, I don’t see a reason for this to be in the API.

>    R_RegisterFinalizerEx, R_MakeWeakRefC are referenced in 'Writing R
> Extensions', so should probably be kept.
Indeed, we should keep them if they are referenced in the docs.
However, AFAICS this whole concept of weak references seems to be used so little that there could be a separate discussion as to whether it’s necessary, and whether there’s enough usages to be confident that it works in the first place.

> - I'd also recommend looking closely at the functions required by the
> packages in src/library.  Some of them probably should be kept.
The packages in src/library can still access everything - they have a closer relationship anyway, e.g., they use the Defn.h header file which spills many internal details.

> Other functions and variables from Rinternals.h that I think we should
> look into making private at time permits:
>   MARK
This one may actually be unused, hard to look for because it’s such a common identifier.
>   VECTOR_PTR
I fear that Rcpp relies heavily on this..?
>   MISSING / SET_MISSING
SET_MISSING is only used once in the sprint package, MISSING appear to be unused.
>   INTERNAL
Another function difficult to look for because of a common identifier :-) seems like it’s only used in Rcpp.
>   HASHTAB / SET_HASHTAB
These are used by a couple of packages, but it seems doable.
>   PRSEEN
Rcpp is the only user here, that should be possible.
>   SET_PRVALUE
This one looks like an oversight, it should be removed.
>   R_InBCInterpreter
Agreed, no usages anyway.
>   R_RestartToken
Agreed, no usages anyway.
>   R_dot_*
Agreed, no usages anyway.
>   R_signal_*_error
Agreed, no usages anyway.
>   R_curErrorBuf
Rcpp11 and Rhpc are the only users at the moment, that should be possible.
>   R_cycle_detected
Agreed, no usages anyway.

Seems like we missed a few opportunities in the initial go.
We’ll update the github PR accordingly.

- Lukas


>
> Karl
>
>
> On Fri, Jan 13, 2017 at 5:52 AM, Lukas Stadler <lukas.stadler@...> wrote:
>> Happy new year to you all!
>>
>> One outcome of the discussions in this group and last year’s RIOT workshop
>> is that the native API deserves a cleanup, moving out things that aren’t
>> needed as a first step.
>>
>> My colleague Zbynek took the time to go over the whole API and move all
>> functionality that is not used into separate header files that are not part
>> of the public include directory.
>> He was able to move out 183 functions, and all packages from CRAN (that we
>> were able to build without special setup) work fine with the changes.
>>
>> The changes are available as a PR on github:
>> https://github.com/zslajchrt/r-source/pull/2/files
>> github also provides a raw diff:
>> https://patch-diff.githubusercontent.com/raw/zslajchrt/r-source/pull/2.diff
>>
>> I’d like to gather feedback before suggesting this change to r-devel:
>> - do you think there’s a better approach than having separate header files
>> in include/private? our goal was to keep the changes to the main codebase
>> minimal.
>> - are there functions or macros that shouldn’t be moved although they are
>> currently not used by any packages on CRAN?
>> - are there functions or macros that this patch doesn’t move but we should
>> still try to move, although this will require fixes in some packages?
>>
>> The patch is not set in stone, we’re happy to make any changes (or perform
>> other tasks) that will make it easier for r-devel to accept these changes.
>> For some code-related comments it may be simpler to post on github (because
>> you can add comments to specific lines in the changes).
>>
>> Best,
>> Lukas
>>
>> _______________________________________________
>> Rconsortium-wg-api mailing list
>> Rconsortium-wg-api@...consortium.org
>> https://lists.r-consortium.org/mailman/listinfo/rconsortium-wg-api
>>



extending R API with support for contexts

Lukas Stadler
 

Hi,

I'd like to propose an extension of the native API to expose some information about context objects.
Although you could consider them to be implementation details of R, you need at least some introspection to be able to write proper IDEs.
It should be possible, e.g., to write a tool like RStudio without copy-and-paste from internal header files.

I'd like to propose something along the lines of:
-------------------------
typedef void *RCNTXT;

// returns a handle to the current context object
RCNTXT R_getGlobalContext();

// returns the closest enclosing function context (even if, say, in the browser context) or NULL if no functions are being executed
RCNTXT R_getGlobalFunctionContext();

// returns caller context of a given context or NULL if there is no caller
RCNTXT R_getParentContext(RCNTXT c);

// returns environment of a given context
SEXP R_getContextEnvironment(RCNTXT c);

// return function of a given (function) context or NULL if given context is not function context
SEXP R_getContextFunction(RCNTXT c);

// returns a call site (language object) of a given context
SEXP R_getContextCall(RCNTXT c);

// returns a source ref of a given context
SEXP R_getContextSrcRef(RCNTXT c);

// are we currently debugging via browser function?
bool R_insideBrowser();

// is this a top level context
bool R_isGlobal(RCNTXT c);

// compares two context objects
bool R_isEqual(RCNTXT x, RCNTXT y);
-------------------------

Do you think that makes sense?
Any reason not to expose this information?
Were there previous attempts to add such an interface that I'm not aware of?

Best,
Lukas

Re: extending R API with support for contexts

Karl Millar
 

I think we need to be careful here if we want to maintain implementation flexibility.  IIRC, we've seen packages break due to incompatibilities between the way the AST interpreter and bytecode interpreter handle contexts.  In particular, this could cause issues with function inlining etc.

Changes I'd suggest:
  - Only function contexts are ever visible in the API.  R_getParentContext silently skips non-function contexts.
  - This should be placed in Rinterface.h, with clear comments stating that it's only intended for building interactive interfaces to R, and that code should not rely on the results having any particular values.
 - R_getContextSrcRef's documentation should state that it returns the srcref 'if available' and returns R_NilValue otherwise.
 - Rename R_getGlobal* to R_getCurrent* or R_getActive* for clarity
 - Top level context and global context aren't quite the same thing (the global context is a top level context, but not all top level contexts are the global context).  Which one(s) do we need to expose in the API?

Thanks,

Karl

On Mon, Jan 30, 2017 at 5:15 AM, Lukas Stadler <lukas.stadler@...> wrote:
Hi,

I'd like to propose an extension of the native API to expose some information about context objects.
Although you could consider them to be implementation details of R, you need at least some introspection to be able to write proper IDEs.
It should be possible, e.g., to write a tool like RStudio without copy-and-paste from internal header files.

I'd like to propose something along the lines of:
-------------------------
typedef void *RCNTXT;

// returns a handle to the current context object
RCNTXT R_getGlobalContext();

// returns the closest enclosing function context (even if, say, in the browser context) or NULL if no functions are being executed
RCNTXT R_getGlobalFunctionContext();

// returns caller context of a given context or NULL if there is no caller
RCNTXT R_getParentContext(RCNTXT c);

// returns environment of a given context
SEXP R_getContextEnvironment(RCNTXT c);

// return function of a given (function) context or NULL if given context is not function context
SEXP R_getContextFunction(RCNTXT c);

// returns a call site (language object) of a given context
SEXP R_getContextCall(RCNTXT c);

// returns a source ref of a given context
SEXP R_getContextSrcRef(RCNTXT c);

// are we currently debugging via browser function?
bool R_insideBrowser();

// is this a top level context
bool R_isGlobal(RCNTXT c);

// compares two context objects
bool R_isEqual(RCNTXT x, RCNTXT y);
-------------------------

Do you think that makes sense?
Any reason not to expose this information?
Were there previous attempts to add such an interface that I'm not aware of?

Best,
 Lukas



_______________________________________________
Rconsortium-wg-api mailing list
Rconsortium-wg-api@...consortium.org
https://lists.r-consortium.org/mailman/listinfo/rconsortium-wg-api