That's a biggy for breakfast Fabian Groffen wrote:
Hi all,
I'd like some input on an issue that I can't get a clear vision on for now.
Recently I added the remote module in MonetDB 5 which basically has 3 functions which perform actions with a remote (MonetDB 5) server. The functions get, put and exec retrieve, store and execute an object from, to or on a remote host. get and put allow for retrieval and storage of basically any type, scalars, strings, BATs, etc. exec only executes functions available on the remote host. The idea is to have one to "put()" a function to the remote host, and then execute it, retrieving its return value. exec is currently implemented that way, however, get and put of functions is not because it is unclear to me how this should exactly happen. Simply put, function objects should be cast to strings before being thrown and reparsed at the other side.
For the case of put() I can think of the following which seems quite intuitive and ok to me:
function user.func(v:int):str; r := "something"; return(r); end func;
m := remote.put("host", "user.func(:int):str"); t := 5; q := remote.exec("host", m, t); io.print(q); ms:= inspect.toString("user","func"); remote.parse("host",ms); t:= 5; q:= remote.exec("host","user","func",t);
The example puts function func to the remote host and executes it with argument t which is 5. The return string kept in q will contain the string "something". Because the identifier of the function on the remote host is returned and assigned to m, the function can easily be
executed, since exec requires the function name as string. Currently that function name is just the function without its signature. The signature (which is not required, even not desired currently) can be deduced from the arguments given, resulting in a normal function resolution and (slightly misleading) error reporting if that fails.
The other way around (thus to get a remote function) is still unclear to me how to do it. I could imagine the following that should work:
v := remote.get("host", m); w := remote.get("host", "user.func(:int):str"); ms:= remote.get("host","inspect.toString(\"user\",\"func\");"); lang.parse(ms);
Problem with v is that m is not a full signature, so a conflict may just extend the arguments of toString arise if m is overloaded. This is not necessarily a problem, since m is a unique identifier, so no overloading for it exists. However, it is a requirement that a get after a put should always succeed and result in the same object that was put. The function returned will shield the old version in the symbol table. I consider it a garbage collection if we are looking for exact copies.
The bigger problem here, however, is how to deal with the function being get. Since a function cannot be stored in a variable in MAL, it has to be stored on the local machine, or its contents as a string returned. I don't see the problem. Either you reparse the string directly, which gives
No. The identifier is determined at the sending side. In case of a conflict, you either dump it in a 'private' remote module or rename the function locally first. the remote side control over the module it is placed into, or you overrule the remote side by doing something line lang.parse("myDefaultModule",ms);
In the first case the get() function would return its local identifier. In the latter case it would return a (big) string. In both cases, the function cannot be "used" as function in the program. A variable containing a function name cannot be used as in e.g.:
k := v(t);
where v, a variable, would be used as function, "dereferencing" v's value or something. Of course with a human factor one can do:
In general, in this case there is a role for a MAL-MAL translator that performs the resolution before execution. You simple accumulate the mapping in a table understood by the trafo.
io.print(v);
and use the value of v to construct a call to the locally stored function. In the case of a string, the function has to be made, which I don't know how to do that, but would give explicit control over its name to the program.
I don't think the concept of eval is clearing up things, as well as possible at all (if you think about the k := statement where only v should be expanded, not t neither k).
Ideas?
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers