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, Оботуров Артем <obotu...@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@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
