[Scilab-users] Multiple files of functions with the same name

[Llelan D.]

Thank you all for your kind replies. Samuel has come up with what seems 
to be the only workable solution using the namespaces provided by 
library variables (I'll explain after a couple of points and an example).

----------
The rest of the replies have to do with either loading and running each 
implementation sequentially, or manually renaming the loaded function 
variables.

As I explained in the OP:
* Both functions MUST be resident without clashing so they both can be 
run. Constantly reloading, re-interpreting, and recompiling each 
function for what may be millions of times per match is pathetically 
inefficient.
* The .sci files might not only implement the specified function 
prototype, they might also implement many support functions. Since the 
implementation files might be written by 3rd parties (such as in a 
tournament), the support function names can not be known beforehand. So, 
it is impossible to know what to rename after an exec() is done, and 
I've never found a way to list what functions are loaded by an exec().

As to the confusion of what is being done: This is a description of a 
generic process that can be applied to a great variety of algorithm 
profiling and tournament situations. The overall products that might use 
this are not important. The ability to have functions with the same name 
and prototype implemented in different .sci files resident in the same 
session is.

However, I'll give you a concrete example:
Some years ago, a tournament was held for response algorithms to the 
Iterated Prisoner's Dilemma (see http://www.prisoners-dilemma.com for 
details). Competitors would each implement a set of "personalities" each 
of which implements a "responseString = response(iGame, lastScore)" 
prototype. The tournament software expects to see in the tournament 
directory a set of directories each named for a competitor. In each 
competitor directory is a set of personality directories each of which 
holds the implementation of the response prototype function and possibly 
many other support functions. While the competitor names are registered 
unique, the personality and support function names might not be. Each 
competitor is paired against each other competitor where each 
personality of one competitor is played against each personality of the 
other 20 times. The average score for each personality and competitor is 
accumulated and the competitor(s) with the highest average score wins. 
With hundreds of competitors, some using dozens of personalities and 
many with the same names but different implementations, the number of 
games can easily run into the hundreds of thousands.

In this scenario, the personalities should not be constantly reloaded, 
re-interpreted, and re-compiled for each and every call. The whole 
tournament would be uselessly bogged down.

----------
The library solution proposed by Samuel can deal with this since the 
loaded library functions can be qualified with the library variable 
name. For example: Two libraries are created in directories testLib1 and 
testLib2, each of which implements the "y = test(x)" prototype. After 
using the lib() function to load both to two variables called testLib1 
and testLib2, you can call either testLib1.test(2) or testLib2.test(2) 
without having to reload anything. There is a little annoying magic 
where the variable "test" will be assigned to whatever library was last 
loaded but, if you do not use that variable, there is no problem, unless 
you run into variable space overruns (I do wish there was a way to not 
do that).

For tournament software, it is important to be able to require 
competitors to submit implementation sources so that you can verify 
nothing goes on that breaks the rules. Scilab allows you to create the 
libraries without external utilities all in the same language. Setting 
funcprot(2) makes sure that competitor implementations do not try to 
futz with the environment used by the other competitor but still allows 
the qualified libraries with functions of the same name to be loaded. 
I've tested this and it works.

Thank you Samuel for your solution to this. I am greatly appreciative.

However – namespaces or qualified names are definitely needed in Scilab.