[Monetdb-developers] [M5] RFC: function shipping semantics
Martin.Kersten at cwi.nl
Thu Jul 12 15:40:09 CEST 2007
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
> 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";
> end func;
> m := remote.put("host", "user.func(:int):str");
> t := 5;
> q := remote.exec("host", m, 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
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.
> 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");
> 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
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.
> 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).
> 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.
> Monetdb-developers mailing list
> Monetdb-developers at lists.sourceforge.net
More information about the developers-list