[Monetdb-developers] Simple bat operations

Martin Kersten Martin.Kersten at cwi.nl
Fri Oct 12 16:39:09 CEST 2007


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 at 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 at host$ mclient -d demo -l mal
> mal>b:= bbp.bind("test");
> mal>io.print(b);
> MAPI  = monetdb at 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.html#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 at 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/monetdb-developers
>>     
>
>   





More information about the developers-list mailing list