Except that LPC isn't C. LPMUD is named after its creator Lars Pensjo, and LPC is simply the name he chose since he made his language look like C in general structure.
What LPMUD does is take LPC code you wrote (you being the mudlib author, or any builder who's worked on your MUD), tokenize them into an internal stack machine language, and then interpret that stack code.
In particular, during each processing loop, each object is given a limit of how many "eval ticks" it can use, which more or less corresponds to how many LPC stack machine instructions it can execute, before it is halted and processing moves on to the next object. This protects the MUD from runaway code, be it in the form of a while(1) loop, or just a crazy-CPU-intense process that would cause lag for everyone else.
Note that objects may call functions from other objects, but all stack code counts towards that first object's eval limit. To work around that limitation, the driver provides a call_out() method which can be used to schedule a future function call (the delay can be 0, meaning as soon as you can schedule it). As with batch processing on mainframes, this allows the user to break their long-running process up into smaller chunks, each calling the next chunk before it runs out of time so as to complete the task without halting the entire system.
The use of LEX (and YACC/BISON) are in constructiing the LPC parser and state machine, not to compile LPC code into C (although earlier versions of MudOS *DID* try to allow for that, as a potential way to speedup CPU intensive LPC code… it never worked well).
I know the discussion moved on a bit from here but I wanted to clear up what I meant.
I am not asserting that LPC is C.
I said, or meant to, that without C LPC wouldnt have existed as it does. C provides the tools to construct the language itself.
Beyond allowing for LPC to exist as a superset of C (as a huge custom parsing engine)… from my understanding, it at it's core entirely runs ON c.
The lex/yacc parsing allow LPC to exist, and translate what it does from being in your mind, to reality. So, you write LPC, the parser/compiler combo then compile a C file, written in LPC as a new program and link it into the rest at runtime. While not written in C directly, this is a C based action, by the core parsing and compiling engines(lex and yacc), of which the LPC language (which only exists as a parsed entity from them - eg super fancy script language) springs out of.
The base files made by lex arent .c on a lark.
So, to say it is not C at all is disingenuous. Is C removed from what the creator does in any way? Yes.
At the end of the day were both using C to power our MUDs, HOW we utilize that power, or what extending or replacing of language semantics (if a scripting language, however advanced or not) are used was not my point.
Saying that straight C compares to LPC would be like trying to compare a Bicycle and a Motorcycle. Which I wasn't doing. Either have their uses, and in circumstances one is better than the other. Regardless, I found some nice lessons in finally understanding that LPC is, nuts and bolts level, just a really really fancing scripting language built on C.
I can see your confusion with C/LPC. From some of the LPC docs, it seems the ones creating it were trying to remove the need for a coder on a MUD, and handle some of the issues with modifying the primitive and heavily hard coded codebases of the time. For some reason, and I contend it was to be a (C) coder want-to-be they (probably more the mudlib writer) decided to use the extension .c instead of .lpc for their files. As far as I know, the lpc files are interpreted by the driver and not converted to c then compiled.
10 Jun, 2014, quixadhal wrote in the 23rd comment:
Actually, you're partly right.
While LPC wouldn't have existed with the same syntax it has now, without C, C is not the end-all language which everything in the universe has to credit. When I went to college, C was an amusing oddity that geeks learned…. but Pascal was THE language everyone used. Had I gone to school a few years earlier, it probably would have been FORTRAN. Without C, maybe we'd have had LPP instead, with a Pascal-like syntax.
Historically, the C language was developed because the people writing it were ALSO writing UNIX, and they wanted a "portable assembly language" that would make it easier to write the majority of their new OS, only using raw assembly for the bootstrap and the initial compiler.
LPC, however, is NOT C. LPC is a language which works, on a fundamental level, differently than C does. It looks like C, because that was the language its creator (Lars Pensjo) was most familiar with, and he probably believed having it share much of the same basic syntax would make it easier for other MUD coders to learn.
Saying that LPC is a superset of C, just because all current LPC drivers are written in C. is wrong. If you wanted to take the time and effort, you could write an LPC driver in Python, and it would operate exactly like FluffOS does today. The fact is, an LPC coder never has to deal with C, in any way at all. Even the efuns which are provided by the driver are black boxes, and could be implemented in any language whatsoever. I would suggest you take another look at what an interpreter actually is. By your definition, every "scripting" language, which includes perl, ruby, python, lua, and some versions of basic, is just "a really fancy scripting language built on C".
There was some interesting discussion a whlie back about making an LPC.NET driver, which would cause LPC to become a first class language on the .NET platform, allowing you to freely mix it with Visual BASIC, C#, or even C++. Of course, nobody has the energy and patience to actually do it, but it's not impossible. There is a Visual COBOL.NET out there. :)
I think it foolish to assume that all languages are of equal utility. Having had no experience really with Pascal or Fortran it's hard to say anything about them, but there must be a reason for so many languages to borrow the syntax (and perhaps the quirks) of C instead of a different language. I might argue that if it looks like C and acts like C then for all intents and purposes it is C or is built on C. The underlying language of implementation, I would presume, is essentially irrelevant except where it shows up in the implemented language and since I can't imagine how to analyze that it's hard to know, but it's entirely possibly that your example "scripting" languages shows themselves to be descendants of C in one more respects that cannot be done away with by changing the language that the interpreter or compiler is written in.
20 Jun, 2014, quixadhal wrote in the 25th comment:
There is a reason… C is popular. As we all know, popularity > usefulness, correctness, or even sanity in our culture.
And while there are lots of languages out there today that "look like C", most of them do NOT "act like C". You're only seeing the superficial similarity because you haven't worked with them. You should also conider that C didn't evolve in a vacuum, nor was it designed to be a general purpose language. Indeed, quite the opposite.
C was descended from BCPL and has similarities to Pascal as well, because those are what Kernigan, Ritchie, and Thompson were familiar with. The language developed hand-in-hand with UNIX, because that's what it was written to implement. Namely, Ritchie and Thompson designed UNIX to be a new operating system for the PDP-8. At that time, most OS's were written in assembly, meaning you had to rewrite everything when you moved to a new machine, even if that machine were similar, like a PDP-11.
Kernigan and Ritche's idea was to make a "portable assembly" language that would be easier to work with than pure assembly (having higher level loops and conditionals), and would still more-or-less directly translate… meaning it would be easy to write a new compiler for a new architecture, and thus get an OS ported much faster than it usually took.
THAT is why C became so popular. Nothing magical. Not because it was so much better than everything else for writing arbitrary code. Because it made it very EASY to get a new hardware system into a useable state. Once you got your new hardware running, why not write more stuff in C since it was already there?