Stefan Manegold wrote:
> On Thu, Oct 11, 2007 at 06:02:12PM +0200, Martin Kersten wrote:
>
>>> On 11-10-2007 17:45:46 +0200, [EMAIL PROTECTED] 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.
>>
>
> ========
> [EMAIL PROTECTED] mclient -d demo -l mal
> mal>b:= bbp.bind("test");
> mal>io.print(b);
> MAPI = [EMAIL PROTECTED]: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
>>> [email protected]
>>> 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
>> [email protected]
>> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-developers
