[MUD-Dev] Languages

[Chris Gray]

:Okay, let me explain. Failure and empty list are *not* always the same
:thing. Sometimes, empty list can be a valid result. For instance,
:suppose you have a queue of objects that pass some sort of event
:from one to the next, and suppose that there is also default action.
:In this case, it might be desired that there is a way to turn off
:default action. In this case, empty list *always* takes default action,
:while failure does nothing.

Hmm. I must be missing something. In my AmigaMUD language I can do:

    list thing contents;

    contents := ....;
    if contents = nil then
	/* there is no contents list */
    elif Count(contents) = 0 then
	/* the list is empty */
    else
	iterate through the list
    fi;

Here, an empty list and *no list* are different situations.

:You are wrong here - since I wrote parts of the Cold's hypertext system,
:I'd know. The problem is that when you use object-oriented design for
:hypertext, you need a way to pass it to the client objects. The problem
:is that clients often want *different* output. (example: Cold supports
:streaming HTML, like Pueblo, plain text, and ANSI highlighted text).
:This means that you have to format hypertext for each client. And then
:there should be a way to switch between hypertext and plaintext for
:the same datastructure, as plaintext is much tighter, dbsize-wise.
:So, for example, you can use both plaintext and hypertext for an
:object description, and you *HAVE* to pass it as a raw object to
:each client separately (yes, we considered pretty much every other
:method we could think of. This pretty much *is* the best way). With
:strongly-typed language, this is impossible to do. With ML-style
:strong typing, you could use discriminated unions, though - but
:I assumed you had something like C/C++ in mind when you talked about
:strong typing, and both have jokes of typesystems.

I guess we'll have to agree to disagree on that. Processing of output is
quite different from client to client in my system too. Things like display
output width, current indent, setting of the flag affecting the prefixing
of each output line with an '@' for "unsafe" output, etc. are all client
dependent. And yet the scenario doesn't have to worry about it - output
formatting etc. will just happen. Even the existence of the graphics/sound/
etc. support varies from client to client, as does the display resolution.
You may have been able to come up with only one method, given the design
base you have already picked, but that doesn't mean there aren't other
methods, given other design bases. Whatever, we've beaten this enough.

:As for the description, you miss the point again - for an item, you'd
:create a master object, and then keep just 3-4 integers in the contents
:list, basically object type and its age (if objects are wearing off with
:use). Everything else can be stored on the master object. Of course,
:I don't like MUDs with gather-equipment-then-go-out-and-kill centered
:game all that much, but this is very valid option for them. :)
:Remember, most LPs have problems precisely with this issue - when the
:number of things grow high, their db explodes. This very much fixes
:this issue, and you can /still/ make all the equipment permanent (i.e.
:not lost in reboots).

Gack! Are you seriously suggesting special interpretation of some
numbers rammed into a 'carrying' list, based on their position in that
list, or some such? Again, my approach gave me another alternative, which
is just as space efficient:

    newWhatever := CreateThing(modelWhatever);
    newWhatever at property := 136;

The only space used in 'newWhatever', asside from the small fixed overhead
for each 'thing', is 8 bytes used to identify and store the overriding
value of 'property'. A *heck* of a lot cleaner that trying to stuff
wierd things into lists. LP suffers bloat because it copies everything
on inheritance. It never even ocurred to me to do something like that,
so it came as a shock to me when I heard that others did things that
way. 'newWhatever' merely has a parent pointer to 'modelWhatever', and
can get values from there automatically.

:> :Uhhh, okay, I misunderstood a bit - it's not that unsafe. But again,
:> :why do you need it as part of the /language/ as opposed to part of the
:> :language /implementaion/?
:>
:> Umm, "its not that unsafe"? What is unsafe at all? And no, the fact that
:> I can efficiently implement the language isn't necessarily part of the
:> specification of the language, but it is certainly something that I will
:> be concerned about just as much as the details of the language spec.
:
:Don't worry about it too much. If Scheme can be compiled to run about
:as fast as C, then anything else can. :)

Grfff! Can you please tell me what you are saying is unsafe in my setup?
If there is a problem I want to fix it!

Perhaps it is time to take this off the mailing list?

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