[Rd] Type annotations for R function parameters.

[Duncan Murdoch]

On 13-08-30 7:22 AM, Оботуров Артем wrote:
> This essentially locks up the version of each package at the time of
> writing an adapter. This makes you to make review of changes before
> introducing an updated version of those packages into the system.

Yes, that's why I said this is hard.
>
> Also there could a register of converters written by package developers
> to cope with diversity of types.

Converters aren't sufficient.  For example, many functions that take 
input from files accept a filename as a character string or a connection 
object for the input parameter.  The character string is converted to a 
connection using file() (sometimes "" is converted to stdin() or 
stdout()), but often other things are done as well, e.g. code to close 
the connection at the end of the function call.

For example, here is the code that examines the "con" argument to the 
readLines() function:

     if (is.character(con)) {
         con <- file(con, "r")
         on.exit(close(con))
     }

The cat() function is a little more complicated, and the parse() 
function has much more extensive calculations involving its "file" 
argument, because it needs to set debugging information and produce 
diagnostic messages.

Duncan Murdoch


>
> On Friday, August 30, 2013, Duncan Murdoch wrote:
>
>     On 13-08-30 5:19 AM, Оботуров Артем wrote:
>
>         Hello.
>
>         One of my clients asked if it would be possible to have an IDE
>         which could
>         use type discovery for R functions to make flow-like
>         construction of an R
>         program. Something like a LabView graphical composition of
>         processing
>         elements.
>
>         They called this type of program composition a "workflow".
>
>         I looked at some of this programs, like:
>         * Orange http://orange.biolab.si/
>         * RedR http://www.red-r.org/
>         * Rattle http://rattle.togaware.com/
>         * Rpad https://code.google.com/p/__rpad/
>         <https://code.google.com/p/rpad/>
>
>         and all of them did type introspection (they made mapping between R
>         functions and their IDE's visual framework) by hand for each
>         function of
>         supported packages which is time and resource consuming.
>
>         So, to reduce an amount of code to be written for adapters
>         between R and
>         IDE some kind of annotations could be introduced over parameters
>         and return
>         values. Those could be optional and will help to discover type
>         information
>         for support of dynamic composition of programs.
>
>         Do you have any suggestions on the topic?
>
>
>     It's very common for R functions to accept many different types for
>     the same argument on input, and somewhat common for the type of
>     output to depend on the inputs, so this looks hard:  that's why
>     those front ends need work by hand.
>
>     Duncan Murdoch
>