[DGD] Zero, was Re: LPC repository

[Felix A. Croes]

Azhrarn wrote:
>[...]
> It is not a problem solely belonging in the realm of adition, though. How about
> 	mixed x;
> 	mapping m;
> 	x = ???
> 	m = x;
> Since (int)0 is a valid value for m, I guess this should be OK, if x was 
> assigned (int)0, but not for (int)5??? (I don't have a DGD here, so I have not 
> tested it, I am merely rambling over the inconsistencies of classic LPC).

Quite.  Once you get rid of 0 for uninitialized values, you can also
remove mixed, and improve typechecking overall.


> > A change I would prefer (which would make the server incompatible with
> > LPmud 2.4.5, and thus was abandoned with regret) would be to initialize
> > variables to `null' rather than integer 0, `null' being a special value
> > that is equal to nothing but itself, and has typeof(null) == T_NONE.
> > Null can then be a safe neutral element for addition.
>
> This would be much better, but what should the semantics of mappings be then? 
> Are the value of a non-existant key, (int)0 or null?

Null of course, and map["foo"] = null; would remove it from the mapping.


> I think all these things are manifestations of the same basic problem. The level 
> of type information in LPC datatypes.
> - The initialization of all variables to (int)0 is supported by firm historical
>   reasons, but not much else. Why are variables of types string, array or
>   mapping assigned a value, that are obviously outside there domain?
> - However the problem arises in the mappings as well, since the null value
>   returned for non-existing keys, should really be a null complient to some
>   unknown datatype.
> - The semantics of the null element in the different datatypes should be
>   something like:
>     int:     0
>     float:   0.0
>     string:  ""
>     array:   ({})
>     mapping: ([])
>   The last two however have very different behaviours, consider since x[1] is
>   valid for the empty mapping, but illegal for the empty array.

Note that I did not say that I wanted null to be valid in any kind of
expression other than plain assignment (I don't).  Rather, making null to
be so would be a less messy change.

A better solution would be to also have proper initializers for variables.
The current scheme that is used in other LPC servers I consider to be
a failure: it does nothing that is not better done in the create function.
The MOO model might be more appropriate.

If I ever change DGD to use null for uninitialized values, it will be
after I have found a good initializer solution.


> I don't think that problem is really solvable in LPC at all, since there are 
> places in LPC programs where the type information exists only in the head of the 
> programmer, if even there :-).

DGD makes checks for runtime types on access.  For instance, int *foo is
checked to hold either an array or 0 when accessed, and its elements must
be integers.  However, no runtime error results if foo holds an array of
strings, and the elements are not accessed.

Regards,
Dworkin