[MUD-Dev] Introduction

[Miroslav Silovic]

> In <199705140820.KAA20287 at regoc.srce.hr>, on 05/14/97 
>    at 08:27 PM, silovic at srce.hr (Miroslav Silovic) said:
> 
> >Okay, a few examples: One of the situations that happens often is a
> >function returning either result or 'I couldn't do it'. With typed
> >system, you need to return two values explicitely. With untyped, you
> >can return either a list of (integer) 0 (assuming that result is a
> >list).
> 
> This would seem to presume that all types are simple types and thus
> there are no aggregate, complex, or user-defined types in your
> language implementation.  Why not have the function call return a
> structure or equivalent?  (cf ColdX's frobs (which I don't like BTW as
> they seem a hacked design solution))

Returning a structure is kind of sucky - if failure is signaled, the
rest of the structure is meaningless, which is kinda sucky - in fact,
it's *much* less safe than the dynamic type (if you forget to check
the structure for failure, you'll continue to process unspeficied list,
getting unpredicted result, but *NO ERROR*).

As I said later in the post, there are strongly typed languages that
actually handle this right. But a programmer used to C++ type system
probably wouldn't think of any of the tricks that can be done. 

Of course, this is getting far away from the topic. :) Perhaps the
main thing is that neither I, nor many other people, want to think
about 'what will go into each variable' when it's far more natural
to thin about 'what *is* in each variable'. This is personal preferance,
of course, and my main point, as stated in the original post, was
that one should carefully (and I mean, *BLOODY* carefully) think
about the typing choice. The convenience of static typing IMHO can
be sacrificed, but only if you're ready to reap all the gains (i.e.
dynamically compile the MUD code into C or C++).

	Miro