Re: [Rd] Type annotations for R function parameters.

[Оботуров Артем]

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.

Also there could a register of converters written by package developers to
cope with diversity of types.

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

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Type annotations for R function parameters.

[Brian Rowe]

The type constraints in lambda.r make this relatively easy. The idea is to add 
a declaration before a function that provides static typing on the function 
arguments. The type constraint also specifies the return type, so it would be 
straightforward to construct a graph. Where a type variable is used, then there 
would need to be a run-time determination for the actual types as happens in 
Haskell. Obviously to have a complete graph of a program would require the 
whole program to be written using lambda.r.

For example you can decorate two separate function clauses each with their own 
type constraint.

slice(x, pivot, inclusive) %::% a : numeric : logical : list
slice(x, pivot, inclusive=FALSE) %as% {
  left <- x[1:pivot]
  right <- x[(pivot+as.numeric(!inclusive)):length(x)]
  list(left, right)
}

slice(x, expression) %::% a : logical : list
slice(x, expression) %as% {
  left <- x[expression]
  right <- x[!expression]
  list(left, right)
}

This calls the first clause since the second argument is numeric.
> x <- rnorm(10)
> slice(x, 4)
[[1]]
[1]  1.2468112 -0.2795106  0.5775026  1.0521653

[[2]]
[1] -1.0493246 -2.0634126  0.0368455 -1.8431248 -0.3630197  0.1015901


This calls the second clause since x < 0 is logical.
> slice(x, x < 0)
[[1]]
[1] -0.2795106 -1.0493246 -2.0634126 -1.8431248 -0.3630197

[[2]]
[1] 1.2468112 0.5775026 1.0521653 0.0368455 0.1015901


This fails since no clause of the function accepts a character as the second 
argument.
> slice(x, 'a')
Error in UseFunction(slice, "slice", ...) :
  No valid function for 
'slice(c(1.24681120969809,-0.279510617209735,0.577502630574721,1.05216534148533,
 ...),a)'


Warm Regards,
Brian



On Aug 30, 2013, at 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/
> 
> 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?
> 
> Best regards,
> 
> Artem Oboturov
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [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/


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



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Type annotations for R function parameters.

[Deepayan Sarkar]

On Fri, Aug 30, 2013 at 2:49 PM, Оботуров Артем  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/
>
> 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?

See

http://bioconductor.org/packages/2.12/bioc/html/TypeInfo.html

-Deepayan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Type annotations for R function parameters.

[Duncan Murdoch]

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/

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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Type annotations for R function parameters.

[Оботуров Артем]

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/

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?

Best regards,

Artem Oboturov

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel