[458] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next last

Re: while, where, when, with -- WHAT?!

daemon@ATHENA.MIT.EDU (Sun Sep 25 15:04:05 1994 )

Date: Sun, 25 Sep 1994 14:58:55 -0400 (EDT)
From: James C Deikun <jcdst10+@pitt.edu>
To: Alex Stewart <stewarta@netcom.com>
Cc: coldstuff@MIT.EDU
In-Reply-To: <199409250754.AAA29028@netcom3.netcom.com>



On Sun, 25 Sep 1994, Alex Stewart wrote:

>   DO statement WHILE (expr) statement
> 
> with possibly the option of leaving off the "DO statement" part of things if
> one wanted to.

This is another one I kinda like, by the way, because it's more than just 
a band-aid, it has uses of its own.
 
> I dunno.. I'm thinking of giving up on this whole thing, actually.. I 
> do actually agree with Greg some on the reasons behind assignments as 
> statements (now that I think about things, I really kinda like the 
> design aspect of ColdC that there's only one actual operation (effect) 
> that can take place per line of code)..  

Note that this only truly applies if no method calls or primitives ever 
produce side effects, which really just isn't the case.

>                                          and I'm also not sure that 
> changing the while statement is a good way to do things either, because 
> people are generally very familiar with it the way it is currently and 
> it's easy to understand in its current form..  sigh. 

Well, the change you proposed is at least back-compatible and it also 
allows another familiar and fairly intuitive construct as a special case:

DO
  <stuff>
WHILE (<condition>);

> You can do this already, just change the parser code and recompile the server.

Not really, as this still doesn't allow more than one compiler to coexist 
(except by duplicating the in-server compiler and decompiler in ColdC 
anyway in order to translate).  It also doesn't allow the other benefits 
of low-level code access, such as workable debuggers.

> This is actually the kind of thing I'd like to avoid, tho, because it 
> means that no two ColdMUDs are likely to be able to use the same code, 
> effectively castrating any porting potential or collaboration between 
> systems.  Personally, I'd rather have everything stay the way it is 
> than "progress" in such a potentially disastrous direction (that's why 
> I'm discussing all of this here instead of just going ahead and making 
> my own changes). 

This isn't necessarily so.  At the very least, porting should be possible 
on an "assembly language" level.  More likely, the two MUDs would share 
at least one popular language compiler.  If something isn't portable, 
it's much more likely it'll be because someone hacked the core to improve 
it, or started with a different one entirely.  There are already tons of 
ColdMUDs with idiosyncratic cores that would make porting a chore, to say 
the least.  These kind of problems are much more work to deal with than 
simple language translation, as they affect semantics and code design.

James Deikun (James@JHM, James & Splat@BlueMOOn)