[DGD] Zero, was Re: LPC repository

[Claus Draeby]

Dworkin wrote:
> [...]
> What about "foo" + 5; did you go all the way and make the string cast
> necessary for non-zero integer values, too?
No, I did not. I have changed it only for (int)0. My reason is that (int)0 is a 
special element anyway.
> 
> What I dislike about the change is that 0 is at the same time an integer
> value, and a neutral element for the other types.  Thus, intvar + ({ })
> is legal when intvar has the value 0, but illegal when it has value 1.
> This is especially obvious for floatvar + intvar, where there are numbers
> on both sides, but again the expression leads to an error when the
> integer is non-zero.
I basically agree. However the trouble only arise when types are decided 
runtime, rather than compile time. And from my experience the by far most 
frequent cause of runtime type errors are array or mapping variables that takes 
the special value (int)0. Hence my `patch' is that, a patch. I admit, it does 
not address the real problem.

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).
> 
> 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?

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.

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 :-).

However a null type would reduce the problems dramatically, and some arbitrary 
decision could then be taken on null[5].

Azhrarn



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