17 Jul, 2009, Silenus wrote in the 1st comment:
Votes: 0
I ran into a design issue with the LPC-like driver I am working on. The issue pertains to a certain aspect of the language design of LPC. This is the copious use of the preprocessor to resolve various issues with the portability of LPC code in spite of it running on a virtual machine. The things that has come to mind is whether it may or may not be possible to revisit the preprocessors role in the LPC system and perhaps "redesign" it. Fundamentally the preprocessor is responsible for handling some of the following "jobs":

1) aliasing names of files so one can move them around the directory structure (through the use of #include. files included typically consist of just a series of defines -> file paths)
2) #if #elif #else stuff to flag which version of the code to compile depending on global setup flags.
3) checking to see if a certain library external function is available or has been compiled into the system
4) forwarding various config options from the config file to the runtime system.

The question is whether it is possible to redesign this system so that it blends more naturally with the language rather as being obviously a separate system. This touches on a range of issues and to some extent has to do with the portability of LPC code even between two different compiles of the same driver. This is often "not possible" because of differences in the config options. For example one system might include one of the two builtin command processing systems (add_action or the contrib "Zork" parser) both or neither. Similar problems exist for things like inventory support and other complie time options.

The problem with the current system also is that despite the fact it's(LPC is) a runtime system it really lacks a global namespace. This leads to certain "nuances" in the use of the "class/struct" type in LPC where you could be passing back a struct/class to another "object" which resides in a different compiler namespace and isn't aware of the type introduced.

My thoughts are currently as follows (and I was curious if people knew of systems which have more uniform designs)-

1) It would be nice to not have to rely on the preprocessor for the aliasing problem. This seems relatively odd since alot of languages have module systems with simple semantics that dont need to rely on #define like macros.

2) Maybe introduce a global namespace (with proper encapsulation).

3) Reduce compile type options to some minimal set (ala DGD) and have some better mechanism for loading external function libraries. (Introduce reflection?).

If anyone had any thoughts on this I would appreciate it. Admittedly this is just a pet project of mine so it may not interest that many people :P.
17 Jul, 2009, David Haley wrote in the 2nd comment:
Votes: 0
I guess I don't really understand the specific problem area well enough to appreciate the nuances of the question, so I'm afraid I won't be of much help here. :thinking:
17 Jul, 2009, Cratylus wrote in the 3rd comment:
Votes: 0
sup
18 Jul, 2009, Tyche wrote in the 4th comment:
Votes: 0
FWIW, early versions of LPC (1.4.1, 2.4.5) used the gnu C preprocessor. That made it slightly challenging for me to port the code and create proper output with various Windows compilers, especially in regards to line numbers. I think what is inside MudOS is pretty much a recreation of the functionality that was used by LPC libraries with the C preprocessor. The functionality of the C preprocessor and its odd rules are much more tricksy than you would think.
0.0/4