[MUD-Dev] Languages

[Chris Gray]

[Miro:]

:> 'nil' is a language construct. It is defined to be equal to no pointer,
:> and to be such that any pointer can be compared for equality against it,
:> and such that it can be assigned to any pointer type. I'm not sure where
:> the concept first originated, but I think AlgolW had one (spelled 'null'),
:> and I know Algol68 has one. Internally to the parser, it has type
:> <NIL-TYPE>, and all type-checking code knows about it.
:
:Ah, just as I expected... But if you have type checking, you could just
:as well replace it with true type dispatch and use dynamic types
:instead? :)

The type of 'nil' is not visible to the programmer - there is no way
to "name" it in the language. As it should be. There is no way to type
check at run-time, since there is no way to produce a value of unknown
type at run time. The only dynamic typing happens when you fetch a
function value from the db - you must specify the result and parameter
types when you call it, and the system will get upset if they do not
match at run-time.

'nil' is used just like many programmers use 'NULL' in C. (To be pendantic,
it is like many programmers use '0' in C, since that is how one writes
that value in C.) I don't see any reason to add new constructs for a
situation that is actually quite simple - that of checking if (or making)
a reference refers to anything or not.

:(note that if MUD is hard to debug because of no debug support, dynamic
:typing is not the one to blame. Stack trace is your friend in all
:dynamic languages, starting with LISP - and it's something that is
:far harder to program in a static language, although not at all
:impossible).

Full tracebacks are quite simple in AmigaMUD - since the entire internal
representation of functions is available at run-time, the traceback code
just needs to run down the parameter lists to obtain their types.
[Clarification: the internal representation is available to the system
(of course!) but not to MUD programmers. They *can* get a decompiled
text form via a builtin, however.]

:As you can see, the propagation chain gets VERY complicated. The most
:natural (whatever it means - I'm far for claiming that this is the only
:way) is to pass the message through object-to-object method calls.
:But this requires hypertext 'somthing' to be tangible, propagatable
:object. This is the problem that had to be solved. :)

To understand further, I'll have to ask for more details on what the
embedded hypertext stuff can do. Is it links like in traditional
hypertext (ala Ted Nelson), or is it font-control, etc.?

:Principal languages that make great reading:

Actually, I was just concerned with the MUD languages that those of us
in this mailing list had developed. More general-purpose languages are
likely covered in an easier-to-read format in my 20 years of SigPLAN
Notices.

:As for the MUD languages, the Cold manual is at
:
:http://ice.cold.org:1180/bin/help?node=$help_coldc

This would be more useful. Hopefully my browser is able to handle whatever
is spit out. Is there a straight-text form that I could read more at my
leisure?

:MOO manuals should be easy to find and is a canon example of the
:server that is secure enough to allow user-level programming (but
:is too slow for it. ;) )

I've read some of the stuff on MOO, and have more here to go through.

:And reading up on C, C++ and Java goes without saying. :)

I was writing an ANSI C compiler at work when the draft was being worked
on, so I've seen far too much of that. I've read enough on C++ to know
that its unlikely I'll ever use it, and I fail to see any contributions
it has made to the state of the art (fight'n words, I know!). I do need
to read up on Java, however.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA