[DGD]Type checking.

[Felix A. Croes]

John "West" McKenna <john at ucc.gu.uwa.edu.au> wrote:

> I've just spent a few minutes most perplexed by an interesting quirk in
> DGD's typechecking.  The driver will complain about type mismatches as
> early as it can, but it seems to be rather slack - errors that I thought
> would be raised at compile-time can be raised at run-time (thinking about
> it, maybe that's deliberate - the return value of a function can be nil,
> and it's quite legal to assign that to any type of variable, so the
> compiler can't know that it's an error).

In typechecking mode 2, you can't assign nil to an int or float variable.
That is the whole point of nil.

DGD's typechecking is quite incomplete, however.


> But that's not all.
>
> string *foo;
>
> void bar(string frog) {
>   /* do something with frog */
> }
>
> void create() {
>   foo=({ this_user() });
>   bar(foo);
> }
>
> Does not give a run-time error when you assign ({ this_user() }) to foo.
> The error comes when you try to call bar().

Yes.  This could be flagged both as a compile-time error and an early
run-time error, and both opportunities are missed.

LPC has some typechecking quirks that are hard to get around, mostly
due to the existence of the "mixed" type.  Also, doing runtime
typechecking of arrays can be quite expensive.  Java has solved this
in a way that avoids typechecking of each element of an array at
runtime, but unfortunately even Java cannot avoid expensive runtime
type checks altogether (though Sun has claimed that it does).

You can expect the above to result in a compile-time error at some time
in the future of DGD's development.  Runtime typechecking probably
will not change.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd