Re: [MUD-Dev] Language design

[cg#ami-cg,GraySage.Edmonton.AB.CA (Chris Gray)]

[Greg M:]
:I seem to remember that someone (Jeff Kesselman, I think) stated that when
:designing a language, they always went via one of two routes:
:
:   1. The language is tightly-bound to the task at hand
:   2. The language is very generic in nature
:
:What are the (dis)advantages of each? I suspect that a non-generic
:language would not be too extensible (and may cause problems if it went
:on to a public ftp-able release), what are your opinions on this? A
:generic language with libraries for specific purposes seems better than
:tying everything to the language itself, but this is pretty much 'the C/C++
:route'; I'm anxious to avoid making decisions solely on the basis of
:"It's all I know."

I have a hard time thinking of any disadvantages of using a more general
purpose language, combined with a number of built-in functions to
efficiently support the things that are used a lot by the expected code.
I don't think its any harder to make a general language - in fact it is
probably easier than having to add in a bunch of extra constructs for
the special stuff you want. It might be a slight bit less "convenient"
for users, if they have to use function call syntax instead of some
custom syntax, but its probably a lot easier to remember and get right!

I also don't think it is less efficient to use a general language. There
is more lost to things like unneccessary run-time checks than I can
imagine being gained by restricting the language in some way. The basic
implementation technique is far more important for speed concerns.

So, the only constructs I put in my language, other than fairly vanilla
generic stuff are things like the '@' operator to access attributes
on objects, and using subscripting to access list elements. Oh, and
the '--' operator for deleting attributes from objects (its all dynamic
in my system).

--
Chris Gray   cg#ami-cg,GraySage.Edmonton.AB.CA