New AGI Compiler Issues

sonneveld Hi there...

ok, pretty near to releasing the first version of the compiler but I'm having a few problems with the preprocessor of all things.

How is #define meant to work in the current agi studio compiler?

#define ego o0
follow.ego(o1, ...);

does NOT produce follow.o0(o1...) and then an error in the current compiler.

Does the compiler only resolve preprocessor definitions when it's expecting a variable? Not really a preprocessor then.. like a mid-processor or something.

If this is the case, then I might have to add another preprocessor phase where it rewrites any #define's that only refer to a variable/other resource to a separate symbol.

- Nick
sonneveld I didn't want to say much on the board before because I wasn't sure what was going in.. I didn't want to promote vapourware so all the features here are fully working at the moment.

this is the new compiler's current feature set:

- almost completely backwards compatible with current one. *var=XXX; indirection isn't available yet because I'm trying to make it more general. (ie, use *var as an argument to a command)

- message concatenation. You can create msgs by stringing msgs and vars together with the concatenation operator like this:
#define catage v20
"the cat is " . catage . " years old."

- message checking. Checks messages for sanity. Doesn't allow '%' or '\' at end of message (can crash interpreter). IF % is used inappropriately (like "100% fit"), it will put a '\' in front of it with a warning.

- control statements. Supports while, do..while, for and switch. If statements don't require {} brackets around single statements. Supports any type of complex boolean expression but the output needs a bit more optimisation.

- reserve variables. Defined on command line for now.
nagilc source.als -o logic.10 -r 250-255,150,160
Complex code usually only needs 2-3 vars max. (I haven't done any formal testing.. this is just from experience)

- complex expressions. Allows any type of arrangement of expressions supported by the C syntax. So you can now do a v10 = (v20*v40) + (v30*v50);

I haven't added anything too crazy yet. The aim for the first release is to be backwards compatible and add some badly needed features.

- Nick
Joel From the agi studio help file:

"Define names can only be used in arguments of commands (including gotos and the v0 == 3 type syntax), although some compilers may allow you to use them anywhere."
sonneveld hrmm.. thanks for the Joel. I will have to work around it I guess.

- Nick
Andrew_Baker Yeah, follow.ego, one of those crappy ego-centric functions. It would be better if it was follow(ego, object, blah).... but, anyway, Joel's right. Your parser should detect the opening parentheses and set the state THEN to replace defines with their compiled literals.


Except... what about in arithmetic?! Oh, $#!^.

Maybe Sierra-Online had a) A different name for the follow.ego command or b) a different defined name for object 0.
sonneveld ...or they used proper symbols for their vars 'n stuff.

Symbols can contain type information and the compiler will be explicity looking for them. o0,2,3,4.. v0,1,2,3.. are predefined symbols in the agi compiler.

#defines are a preprocessor command which means they're meant to be resolved in any part of the code. you can use #defines for macros (or little mini-functions) but that would be impossible if you could only allow them when expecting it.

ie, instead of #define ego o0
#define timeHour v100
#define state v101
#message m3 "hello world"
#define hello m3

it would be obj ego as o0;
var timeHour as v100;
var state as v100;
msg hello as m3 = "hello world"

They probably didn't have the "as o0" bit but I was trying to find a nice way of making a symbol an alias of something else. Any other ideas for that?

- Nick
Joakim
Nick Sonneveld wrote:

How is #define meant to work in the current agi studio compiler?

#define ego o0
follow.ego(o1, ...);

does NOT produce follow.o0(o1...) and then an error in the current compiler.

Does the compiler only resolve preprocessor definitions when it's expecting a variable? Not really a preprocessor then.. like a mid-processor or something.


Uhm. Your example looks a bit odd to me. I don't think you would ever use #define to substitute a substring of a variable or command. But it should be perfectly legal (untested in AGI Studio) to do the following;

#define cat o1
#define egofollow(a) follow.ego(a)

egofollow(cat);

/ Joakim
sonneveld What I meant was that that code compiles fine in the current compiler because it only resolves #defines when it's expecting an argument (I believe)

- Nick
sonneveld
maybe I should have done:

#define ego o0
follow.ego(o1, ...);
set.view(ego, 10);

as an example instead.

This is possible code since ego is defined a lot.

- Nick
CESS.tk
Nick Sonneveld wrote:
(...All those things from the second post...)
- Nick
Sounds great! Really lookin forward to it!
sonneveld I'm glad some of those features look good. :) Switches will be very handy for different states of a room. Or for a logic that contains different functions to be called.

I'm thinking about scrapping actual preprocesor #defines and just leaving it like the current compiler. As in, you can only #define strings, variables or other predefined symbols.

When I start working on proper variable allocation.. I'll introduce a "traditional" mode that includes this special case of #define and #message. That way, I can include proper #defines with macro's 'n stuff.

- Nick