A few questions about Core internals.

[Yukiko]

I wasn't sure where to post this so if the moderators think it needs moving, please do so.

I suppose these are directed to the inner circle of the POLitburo, ie. them folks what knows how to code in C and understands how the POL Core and eCompile performs its magic.

Mind you these are mostly to satisfy my curiosity but they do have their practical side too.

My first question is about the way eCompile handles include files. Let's say I have an include file named utilities.inc. Within this file I have defined 20 functions. utilities.inc has no included files. Now I create a script in which I include utilities.inc. In this script I only call one function from utilities.inc and that function does not call any of the other 19 functions contained within the include file. When I compile my script does eCompile include the entire utilities.inc file in the ECL file or just the compiled code for my function I called from my script?

These next questions are regarding modules *.em files. Module files appear to be just text files and nothing more. A few years ago I examined a a couple in a hex editor and found them to contain only the text that one would see if the file is loaded into a text editor. Prior to that I had thought they were similar to Pascal's units which are pre-compiled blocks of code that add functionality to a program. I assumed this because the statement to invoke both modules, use for POL, and units, uses for Pascal, is so similar. So here are my questions:

1. What exactly are the modules? I'm not sure what I am asking with this question. I guess I want to know why have them? Why not just add these functions as Core functions? I suppose the answer to this will depend on what the answer to question 3 is.

2. How does invoking a module add functionality to the Core?

3. Are the functions contained within the modules already part of the POL Core but not made available until invoked?

4. Does invoking a module add to the size of the compiled ECL file by including some or all of the function(s)'s code from the module?

5. Based on the answer to question 3, are constants defined within a module added to the "global" constant symbol table (forgive any ignorance on my part of how POL handles things internally) or, if the functions contained within a module are already defined in the Core are the constants as well?

As I said these are mostly to satisfy my curiosity but as I begin to examine the source code for POL Core maybe the answers will help me to learn how it works.

[kevin]

When I compile my script does eCompile include the entire utilities.inc file in the ECL file or just the compiled code for my function I called from my script?

Only function calls that are called are included in the compiled .ecl. Try generating a .lst listfile with ecompile -- not on my home computer so i'm not sure what the flag is -- and you'll see what functions are included.

1. What exactly are the modules?

Modules are "core" functions in that they correspond to a c++ method inside the pol executable. It's the only way to interact between your escript file and any worthwhile functions -- like Print() -- that are not basic escript syntax -- like if-then-else statements.

2. How does invoking a module add functionality to the Core?

Invoking a module adds functionality to the script. The functionality is already present in the core.

3. Are the functions contained within the modules already part of the POL Core but not made available until invoked?

Saying "use util" will bring the UtilExecutorModule into scope, allowing those functions to be called. It's basically a lookup table, mapping an escript-function-name to a C++ function/method, for example. See UtilExecutorMod's function_table

4. Does invoking a module add to the size of the compiled ECL file by including some or all of the function(s)'s code from the module?

The compiled ECL will have to increase in size in order to signify "please use this function present inside util". The core maps an escript module such as "util" to the proper C++ executor class "UtilExecutorModule", then maps RandomDiceRoll to "UtilExecutorModule::mf_RandomDiceRoll" by the function_table (see above)

5. Based on the answer to question 3, are constants defined within a module added to the "global" constant symbol table ...

Constants within module.em are there just for the coder's convenience. You could technically remove all those const definitions and just put the actual value in all your eScript function calls, and that is the value that will be passed to the C++ corresponding function. Some constants are not defined anywhere within the core code (such as _DEFAULT_REALM_ or whatever it is called) but others are such as MOVEITEM_FORCELOCATION to make core code more readable; they obviously must have the same definition within the .em and the core.

Hope that helps.

[Yukiko]

Thank you Kevin!

You did indeed help my understanding of how the internal handling of include and modules work.

It appears that modules are similar to Pascal's units. The difference being that POL Core already contains the added functionality and only needs the use statement to notify eCompile to make a particular module's functions accessible (bring them into scope). Pascal's units on the other hand were actually pre-compiled code that the Pascal compiler linked into a compiled program.

As you can tell, I am an "old-timer". I was fortunate to have worked with UCSD Pascal on an Apple II computer. The UCSD Pascal environment and POL are quite similar in that the "operating system" (the Pascal pMachine and POL Core) executes pseudo-code. I guess that's why I like POL so much.

At any rate, thanks again.