[Gambas-user] [Git][gambas/gambas][master] Get rid of unitialized variables warnings in the IDE source code.

[Jussi Lahtinen]

Full type safety is not the goal in my suggestion, but just to improve
developing speed by catching some bugs bit earlier.


Jussi

On Thu, Feb 15, 2018 at 5:58 AM, Adrien Prokopowicz <
adrien.prokopowicz at gmail.com> wrote:

> Le 15/02/2018 à 01:58, Tobias Boege a écrit :
>
>> On Thu, 15 Feb 2018, Jussi Lahtinen wrote:
>>
>>> On Thu, Feb 15, 2018 at 12:16 AM, Adrien Prokopowicz <
>>> adrien.prokopowicz at gmail.com> wrote:
>>>
>>> Le 14/02/2018 à 22:37, Jussi Lahtinen a écrit :
>>>>
>>>> Example if you declare function Test(x as integer) and call it
>>>>> Test("a"),
>>>>> there could be *compile* time error message about wrong type.
>>>>> TypeScript
>>>>> does that, even when it is otherwise dynamic language.
>>>>>
>>>>>
>>>>> Jussi
>>>>>
>>>>> On Wed, Feb 14, 2018 at 11:24 PM, Benoît Minisini <g4mba5 at gmail.com
>>>>> <mailto:g4mba5 at gmail.com>> wrote:
>>>>>
>>>>>      Le 14/02/2018 à 22:17, Jussi Lahtinen a écrit :
>>>>>
>>>>>          Btw, did you see my mail about type checking in dynamic
>>>>>          languages, like in TypeScript? I was just curious whether that
>>>>>          could be possible in some extend in Gambas.
>>>>>
>>>>>
>>>>>          Jussi
>>>>>
>>>>>
>>>>>      I saw the mail, but I have no idea what you were talking about.
>>>>>
>>>>>      --     Benoît Minisini
>>>>>
>>>>>
>>>> That would be very nice to have, but I'm not sure if this wouldn't clash
>>>> with the fact that Gambas has Duck Typing ? (altough I haven't seen it
>>>> used
>>>> anywhere, let alone mentioned in the documentation)
>>>>
>>>> --
>>>> Adrien Prokopowicz
>>>>
>>>> I don't think so. I think it would be having the best of the two
>>> worlds. Of
>>> course such static checking couldn't be done in a lot of cases in
>>> language
>>> like Gambas, but in these simple cases, why not?
>>> If the argument is "as object", then it could be checked against
>>> non-objects like integer. If it is "as variant", then it would have to be
>>> ignored for the check, unless you are going to check how the variant is
>>> used in the function/sub.
>>>
>>>
>> Gambas is very runtime-heavy. At the moment, the compiler doesn't even
>> care
>> to look for subs beyond the current compilation unit and defers all the
>> checks to runtime. If you call a function, the compiler will only check if
>> it exists to generate the calling code.
>>
>> Calling a sub "f()" if it doesn't exist, results in an "Unknown
>> identifier"
>> error. Calling a declared sub "f(x As Integer)" just with "f()" is OK at
>> compile-time because any kind of typechecking is still performed at run-
>> time. I agree that /this/ is a place where static analysis can be done.
>>
>> But the compiler already has no clue anymore as soon as you call into
>> another compilation unit, like with "A.f()". It doesn't even look into
>> class A even if it is part of the current project, since the compiler
>> is very well aware that any class can be overridden at runtime, by loading
>> components. The class A in the current project might be only a part of
>> the class A that is assembled at runtime.
>>
>> There is a silver lining though. Overriding classes in the global symbol
>> table has some rules, namely it happens by inheritance. All subs that you
>> override must have the same signature as in the class that is already
>> there.
>> If the compiler can get a hold of any method definition for A.f, it can
>> assume that no further component loading can change it and perform type
>> checking. You have to load and inspect the components your project uses to
>> do this. What it really can't determine is if a method will exist at
>> runtime,
>> thanks to Component.Load().
>>
>> All value containers in Gambas are precisely typed behind the scenes.
>> Every object has a link to its parent class and the C structs that store
>> Gambas Integers are well aware that they store an Integer. Gambas simply
>> isn't duck typing. It will *coerce* native datatypes automatically if
>> it can, and raise errors otherwise:
>>
>>    Public Sub f(x As Integer)
>>    ...
>>    End
>>
>>    f()     ' ERROR: not enough arguments
>>    f(0, 1) ' ERROR: too many arguments
>>    f(0)    ' obviously OK
>>    f("12") ' OK: String is coerced to Integer
>>    f("a")  ' ERROR: Type mismatch
>>    ' Notice that this code still compiles cleanly.
>>
>> But if you declare two identical classes (or Structs):
>>
>>    Public Struct A
>>      X As Integer
>>    End Struct
>>
>>    Public Struct B
>>      X As Integer
>>    End Struct
>>
>>    Public Sub Main()
>>      Dim h As A
>>      h = New B
>>    End
>>
>> then you get an error. Gambas doesn't let you violate the "h As A"
>> constraint just because B behaves like an A. You can achieve something
>> like that with the methods of the Object class in gb though.
>>
>> The bottom line is: Yes, I think static typechecking can be improved
>> in Gambas but you can't get safety guarantees because the checker has
>> to *ignore* cases where it can't find a symbol, which may be patched
>> in later via Component.Load() and overriding the global symbol table,
>> as dirty as that is.
>>
>> Regards,
>> Tobi
>>
>
> The second example you've shown is not duck typing, it would be
> transmutation I guess (and it's something i've only found possible in
> C/C++).
>
> You can actually have duck typing in Gambas : since you can call any
> method on any object, and the existence of this method is only checked at
> runtime, you can make functions that work with any object, as long as they
> implement method X() (see this example[0]).
>
> In the end though you are right, while we can improve compiler checks here
> and there, adding type safety would not only require quite an overhaul of
> the compiler, but it would be a breaking change to the language (between
> duck typing, dynamic symbol loading, or even the _unknown() special method
> which I completely forgot about).
>
> Maybe in 10 years for Gambas 4 ? /s :-)
>
> [0] https://gambas-playground.proko.eu/?gist=08f2c60469e876eeacc
> 75d1d2ff935e8
>
> --
> Adrien Prokopowicz
>
>
> --------------------------------------------------
>
> This is the Gambas Mailing List:
> https://lists.gambas-basic.org/listinfo/user
>
> Search the list:
> https://lists.gambas-basic.org/cgi-bin/search.cgi
>
> Hosted by https://www.hostsharing.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180215/ccb7af60/attachment-0001.html>