Preprocessor macros?

Okay, bear with me, this is my first post, but I'm somewhat confident that this is the right area, althought this doesn't have to do with money and/or ratings.

I'm slowly learning the scripting, but one thing I'm running up against is the integer type instead of int. No, I'm not asking for a new type, but it got me thinking... Scripts could be better with preprocessor macros. (Showing my bias, I'd prefer C compiler notation)

In laymen's terms, this is code in the script that is run at compile time, not at runtime, and affects how the compiler reads the human-readable code that it turns into computer-readable code. How about an example?

integer foo;
for (foo = 0; foo < 25; foo++)
{DoSomeFunction(foo);}

To the good coder, the question arises: What's 25? Why 25? Is it number of sides? Favorite day of the month? If maintaining this, what should 25 be changed to? What other places have to be changed to the same value? The solution is a variable.

integer NUMOFSTEPS = 25;
...
integer foo;
for (foo = 0; foo < NUMOFSTEPS; foo++)
{DoSomeFunction(foo);}

This has its own problems, as this new variable can be accidentally set (If NUMOFSTEPS=foo, instead of NUMOFSTEPS==foo) and more so, slows the server and script down, requiring additional memory for the variable and additional lookups.

http://secondlife.com/badgeo/wakka.php?wakka=StyleGuide

Has a debate where speed is a tradeoff of maintainability. This is one debate that could be made moot.

#define NUMOFSTEPS 25
...
integer foo;
for (foo = 0; foo < NUMOFSTEPS; foo++)
{DoSomeFunction(foo);}

This has all the advantages of the first version (Speed and space) and the advantages of the second version (Maintainability). But this is a facile example. With just a few commands, quite a few speed/use problems can be resolved.

Functions now can be inlined, speeding up runtime
#define DoSomeFunction(foo) llSay(0,(string) foo)

They now can be pass by reference, making some functions possible.
#define PushStack(foo,bar) bar = bar+foo

Furthermore, functions that are actually #define s make unrolling loops much more maintainable.

And this is a biggie for me: Debug code, also something that is a huge slowdown during runtime, could be left in without slowdowns.

integer DEBUG = 0;
...
if (DEBUG) {llWhisper(0,"I'm debugging!";} //Slow: DEBUG must be looked up, then the if structure run.

#define DEBUG 0
#if (DEBUG)
llWhisper(0,"I'm debugging!";
#endif //Fast! Because DEBUG is set 0, this code doesn't exist in the bytecode at all. All the comparing was done once long ago before the script started.

Oh, and of course, lastly, it serves as a replacement for typedef.
#define int integer

And structs, if you ignore the list speed issue.
#define nameEntry list
// string firstName;
// string lastName;
#define SetFirstName(foo,bar) foo=llDeleteSubList(foo,0,1) + [bar]
#define GetFirstName(foo,bar) foo=llList2String(foo,0)
etc...


In conclusion, I would like the following preprocessor macros be added to the scripting compiler:

#define -label-[(-args-)] -value-
#if (-boolean conditional-)
#endif

#undef, #ifdef, #ifndef, and family could be included, but those three are essential.

How about it?

Oh PLEASE no. Yes, macros can be nice in C/C++, but they also have a dark, ugly side. Have you ever seen a macro-heavy C project? You get to the point where you really can't tell what's happening for all the #ifdefs strewn about the file. Macros lend the programmer the ability to do pretty silly and obscure things very easily. They destroy readability while lending just a little bit of a speed boost, and that only in some cases. Some people have campaigned for removing macros entirely from C++... I don't think we should add them to LSL.

One nice thing about LSL is it's relatively simple -- simple to read, simple to code in, simple to parse, probably simple to execute. While it would be presumably easy to add C-style preprocessing to LSL (just pipe it through CPP, assuming such a thing can be done based on the SL architecture), the first two "simples" go down a bit.

For some people like you or me, it may not affect our ability to code too much since we're already accustomed to CPP directives, it will likely totally confuse newbies. Don't forget, for some people, LSL is their first language. While I wouldn't necessarily recommend LSL as a first language due to a lack of an introduction to LSL for programming newbies, I know people who have picked it up as their first language. As far as scripting languages go, LSL is currently pretty simple and accessible, and I think CPP directives could drastically alter that.

In the end, I see what you're saying; it could make your job much easier. However, the downsides are just too strong for me to agree that CPP directives should be added. It is possible to get by without them... you can do everything in your examples and more without CPP macros. Efficiency? Toss that out the window, because you're really not going to be able to drastically affect execution times with modifications such as CPP macros allow you.

How about a 'const' type? That would speed up execution times, anything referencing the variable would just be compiled into some bytecode instruction with a literal parameter.

true.

Have a search through the forums for ESL.

Azelda

Hmm. I must admit that I hadn't thought about the possibility of LSL being the first programming language of some. In truth, that's actually kind of scary. Part of me wants to say, "Why should I be held back because of new coders?" and I would argue that any new tool, in the wrong hands, can wreak havoc, and while bad coders will always write bad code, it is good to have good tools for good coders.

However, I admit that preprocessor macros, while they can be useful (if not essential in cross-platform code and when stdio.h isn't stdio.h), were meant as a stopgap solution until typedef and friends came out, and the compiler did some tail-recursion and inlining. And like all stopgaps, there is a valid danger of it gaining a life of its own.

I can get behind const. It has even one advantage that #define doesn't: String literals are more likely to be bulkier than a single variable.

Honestly, I would like to see some more powerful concepts brought to fruition. If preprocessors never come to be, but we
have structures or true objects instead of several lists or a hodgepodge list, I will not complain in the slightest.

(Note to self: research the linked script calling. That might serve as a replacement, if
the whole 'return is an event, not a returned value' doesn't prove too problematic.)

A quick and dirty search for esl was unfruitful; the search engine found esl too small a word to search for. I shall look into this further, later.

Obligatory silly thought: Wow. Wait until they hear for my suggestion to introduce (void *)!

1) I love #define!
2) I am so behind this idea of a const type, or type modifier.
3) ESL is a quick hack Az came up with. Basically, you code in this "extended LSL" and use the C preprocessor to generate the real LSL code for you.

Yeah, const is a solution I could be quite happy with.

...although, the huge mess that is const in C and C++ (something like 8 or 9 different meanings depending on usage) is scary I think such nastiness could be avoided.

What 9 different meanings? oO