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

[Tobias Boege]

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

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk