[DGD]1.1.52

[Felix A. Croes]

Frank Schmidt <franks at colargol.tihlde.hist.no> wrote:

> On Fri, 5 Mar 1999, Felix A. Croes wrote:
>[...]
> > +  - allocate() now allocates an array of nil values.  New kfuns allocate_int()
> > +    and allocate_float() explicitly allocate arrays of those respective values.
>
> How about defining a kfun (could with advantage be called allocate_array):
>
>  varargs mixed *allocate(int size, mixed value)
>
> instead of having three different functions not really covering all needs
> (when you want value different from 0, 0.0 and nil or even an array of
> strings!). The function would return an array the size of the first
> argument with all elements containing values of the second. The second
> argument would default to nil naturally.

Good point.

I see the various allocate functions as allocating an array with
elements of a certain type, rather than a certain value.  0, 0.0 and
nil all represent the "uncreated" values for those types, rather than
actually meaningful values.

I agree that having 3 different allocate functions is cumbersome,
but I'm looking at something like

    varargs mixed *allocate(int size, int type)

instead.

I will try to resolve this over the weekend.  As a warning to people
who are upgrading: DGD can't deal with the removal of kfuns when
restoring from a state dump.  If I do decide to remove the two
new allocate kfuns, you won't be able to use a state dump from
1.1.52 with 1.1.53.  However, a state dump from 1.1.51 and before
will be fine.

If this causes big trouble for anyone, let me know.


> > +  - In a further bit of type matching cleanup, integer 0 and floating point 0.0
> > +    no longer test as equal.
>
> I do not understand the point of this. Not that I am an expert of ANSI C
> standards but shouldn't the lesser operand to ==(,) be automatically
> casted to the higher type? So the test of 0.0 == 0 should return !0. This
> extends to 1.0 == 1 and all operators, and could be further extended to
> LPC: (string)0 and 0, (object)0 and 0... etc.

In LPC, floats and ints are completely separate types.  For example,
the expression (2 == 2.0) will, depending on the level of typechecking,
result in a compile-time or runtime error.  LPC is unlike C in this
respect.

Nil tests as false in a truth expression.  You can use the `!'
operator to invert this:

    if (nil) { /* don't do this */ }
    if (!nil) { /* do this */ }

Nil is supposed to enable stronger typechecking, so I am rather
surprised to see you suggest that it should be the same as (string) 0
or (object) 0.  By the way, (string) 0 is the string "0".


> If you wish to differentiate types, you can always use typeof(). I don't
> think the types of the values and variables should interfere with the
> logical and mathematical expressions of C.

For the language C, I agree.  For LPC, I strongly disagree.


> One backwards compatibility issue. What will happen to:
>
>  object room;
>  room = clone_object("/foo/bar");
>  destruct_object(room);
>  if (!room) ...; /* Will this check be sufficient? */

Yes.


> And will operations with nil result in runtime error (making nil hopeless
> to use before you have tested for it), or will nil in some
> situations be "casted" to 0:
>
>  nil + 1 /* result of 1 would be nice */

Error.

>  if (nil == 0) ...; /* will never happen with typechecking = 2? */

Won't even compile, actually.

>  if (!nil) ...; /* should always happen? (logically same as above) */

Valid.

>  if (nil != 0) ...; /* is nill true then? */

Won't compile.

>  if (nil) ...; /* should never happen? (logically same as above) */

Valid.

> ..! Confusing.

You can use nil in these operations only:

    nil == string_or_object_or_array_or_mapping_value
    nil != string_or_object_or_array_or_mapping_value
    nil		/* as a truth value; false */
    !nil	/* 1 */

Regards,
Dworkin

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