Stefan Manegold wrote:
On Thu, Oct 11, 2007 at 06:02:12PM +0200, Martin Kersten wrote:
On 11-10-2007 17:45:46 +0200, darabi@web.de wrote:
[...]
However, I have found one solution to my problem; if I type the left hand side, everything works:
mal>b:bat[:int,:int] := bbp.bind("test");
yes that is necessary. In general the type of the bind can not be known. and MAL requires strongly typed instructions.
======== user@host$ mclient -d demo -l mal mal>b:= bbp.bind("test"); mal>io.print(b); MAPI = monetdb@127.0.0.1:50001 QUERY = io.print(b); ERROR = !TypeException:user.main[1]:'b' may not be used before being initialized ========
Well, first of all, you have to be aware of the fact that you are working at the top level scope. This means that every statement is first packaged in a function main() and then executed. At the end of this call a decision should be made on what variables to retain. This is executed in MSresetvariables(). All temporary variables are removed immediately and also any variable for which we don't know its complete type. The latter is necessary to avoid errors to block re-use of the variable name in interactive mode. So in this example, where the underlying BAT exists, the instruction bbp.bind("test") succeeds, but leaves a partially typed object behind. This one is garbage collected, which means that io.print(b) references a variable that doesn't exist anymore. If you would have packaged both instructions in a function, it would work as expected, because io.print can handle any BAT thanks for being a 'pattern' function user.main():void; # 0 (main:void) b := bbp.bind("test"); # 1 CMDbbpbind (b:bat[:any,:any])<-(_2:str) io.print(b); # 2 IOprint_val (_3:void)<-(b:bat[:any,:any]) end main; These issues are discussed in the typing section of the MAL manual. http://monetdb.cwi.nl/projects/monetdb/MonetDB/Documentation/Type-Resolution...
A more informative error mesage might help --- from a user's point of view, variable 'b' has been initialized before it is used.
Not completely
In fact, the above b:bat[:int,:int] := bbp.bind("test"); is wrong --- or at least implies a silent cast from :oid to :int of the BAT's head --- since bind returns a bat[:oid,:any_1], i.e., only the tail type is "unknown" or "generic".
Here you have a point. The current impl of bbp.bind assumes correct specification/behavior. It should also check at runtime if the BAT is of the type expected.
Moreover, what's the actual problem with the io.print, here?
With the bbp.bind(), b get's bound to type :bat[:oid,:any], and pattern io.print(val:bat[:any_1,:any_2]):void is supposed to accept generic BATs with arbitrary head & tail types, right?
"Strict" typing should (IMHO) either (1) warn already with the bbp.bind call, respectively its assignment to b, that b's tail is not fully
As pointed out in the manual. The question is to what extend you want to support polymorphic behavior. In the example above live is 'easy' because the bat name is a constant.
specified, and hence should be specified explicitly, or (2) the error with io.print() should give some typing releated error message instead of complaining about a non-initialized variable that (froma user's point of view) has been initialized.
Just my humble suggestions ...
Stefan
--enable-optimize does not play a role in this process.
mal>io.print(b); #-----------------# # h t # name # int int # type #-----------------#
I will recompile without --enable-optimise.
Try --enable-debug to make sure you aren't bitten by an insane default of --enable-optimise=yes.
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers