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]]
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
On Fri, Aug 30, 2013 at 2:49 PM, ???????? ????? <oboturov at gmail.com> 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
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, ???????? ????? <oboturov at gmail.com> 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel