[MUD-Dev] Languages

[Chris Gray]

[Miro:]

:Neat. So what's the type of nil? :) It's obviously not a list. How do
:you declare it? And why is it better than completely generic types (if
:you still have to check whether it's a list or nil in every list
:operation, you could just as well check for all other types)?

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

:Actually I'm really interested about your method of client-dependant
:hypertext formatting. Start a new thread? :)

I'm not sure its worth it. My approach to multi-mode output is quite a
bit different to what it sounds like yours is. I don't have any actual
hypertext (hmm, well sort-of). Basically, there are builtin functions
which append stuff to a buffer of binary data heading out to the current
client (which is "current" can switch quickly, if code does something
which requires data going to some other client - I really ought to have
a whole list of buffers, rather than just one). Stuff that can be appended
includes:

    - text, already pre-formatted for the client, based on window-size
	information from the client
    - simple graphical drawing operations
    - commands to load images (from the client machine) and display them
	somewhere in the graphics window
    - sound output, voice output
    - commands to display "buttons" in the graphics window, which the
	user can click on to trigger server calls
    - commands to define similar "clickable areas"
    - commands relating to the client caching of "subroutines" of these
	kinds of things

All of this is done internal to the server - the language itself doesn't
have to handle the resulting binary mishmash. So, if MUD code wants to
modify the stream on a per-client basis, it must do so at the time it
does the calls to generate the stream. For example, the placement of
some standard sets of "buttons" depends on the resolution of the client
window (you can let them auto-scale, but it looks ugly!).

To clarify a bit about text output. In the MUD code, you just do something
like	Print("This is some text to send to the client.\n");	and the
formatting of it for the client window will be handled by the system.
There was some earlier discussion on this, relating to indentation.

:Err, no, if you said it was safe, I believe you. This is independant
:statement: I don't like thinking about implementation when designing
:the language. It can destroy the design (the problem is called
:'premature optimization'). I'm not saying it did, in your case...
:How about starting serious thread on language design, with concrete
:language proposals?

OK, thanks. We could try to get a discussion going on MUD languages, but
I'll bet it would be hard to avoid getting trapped into religious issues!
Perhaps the best way to start would be if those with existing languages
could point out where we can find documentation on those languages. I'm
assuming I'm not the only one that's far enough into the cycle to have
such documentation? I just looked, and the two files that are my main
programming docs (not including the builtins) amount to 4600 lines. Too
much to put on this list, but I can make them available for ftp if anyone
wants to get into that much detail.

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