[MUD-Dev] Introduction

[coder at ibm.net]

On 16/05/97 at 08:20 PM, silovic at srce.hr (Miroslav Silovic) said: >> 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*).

True.  My intent more was to raise the general point that most MUD
languages don't support any form of user-defined aggregate/complex types
outside of lists.  While I don't either (yet), I consider this a key
weakness that needs addressing.  I'll be satisfied when I can make a
full-blown object a sub-member of a list, or defined internally to another
object (nested objects), etc.

For RC's what I've done is to build in an exception mechanism into my
language.  Essentially a method call can do one of two things:

  It can return a value, or it can raise an exception.  

  On the implementation side this is actually handled by having all
methods return a tuple where one side is the exception level (E_OKAY
meaning no exception and to continue normal processing), and the other
side of the tuple being the RC.  

  The language then auto-checks the RC's for non-E_OKAY exception values
and then kicks in appropriate processing as needed (standard nested
try/catch stuff, unwind the stack etc).

  As happens the RC value is still obtainable after tn exception -- it
just must be done by a matching handler.

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

Ture.  I'm blundering over my own weaknesses there with my strict
procedural background: C++, C, shell, Ada, Cobol, BASIC, PDP-11 Assembler
etc.

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

I tend to prefer typeless languages for these sorts of uses.  Of course
they are typed under the covers (internal representation, automatic
translations, and all that rot), but from the user prorgrammer's PoV
they're typeless and he need never care.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...