[MUD-Dev] Languages

[Miroslav Silovic]

> [Clarification: the internal representation is available to the system
> (of course!) but not to MUD programmers. They *can* get a decompiled
                          ^^^^^^^^^^^^^^^

Builtin bytecode disassembler saved my rear end on at least one occasion.
And it's not hard to implement (it's great for bytecode compiler debugging).

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

Both, as well as tags for text generation (which may be context
dependant, as they can include senses). Once you allow each player
to 'see' the hypertext depending on its internal status, it has some
pretty neat consequences.

> :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?

There is, but I don't have the address at hand. :/

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

Good thinking!!! ;)

> to read up on Java, however.

You will find out that it didn't contribute much to the state of
the art once more.

	Miro