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