Compiler Issues

sonneveld ok, for the first revision of the compiler (which will probably still be a long way off.. but I'm working on prototypes) we will want:

- backwards compatibility. you should be able to compile all current scripts and all disassembled scripts
- parsing of variables in strings
- complicated if statements, with or without curly brackets
- possibly while, for, switch 'n all that
- reserved variables for compiler

- Nick
sonneveld parsing of variables in strings: there are a few methods we could use... off the top of my head. do you want to be able to use variable names in strings like this: "hey, my name is %m{ego_name} by the way" "I am %v{age}-and-a-bit years old" this doesn't do anything for backwards compatibility since all variables are defined as %v4 in the current scripts. This also means I will have to parse strings. however the current logic syntax lets you break up strings like this: "string" "string 2" for new lines. what if we extend that for inserting variables? "I am " age "-and-a-bit years old" // agi's current method with vars as well or "I am " . age . "-and-a-bit years old" // php type or "I am " + age + "-and-a-bit years old" // basic? I propose we use some sort of joining symbol like '.' or '+' for clarity but keep a space for backwards compatibility (and only between strings) -- the compiler could take the strings and variables to join them up into one big string. another thing that could be nice is if it found common substrings and saved space by only refering to that ie "cats and dogs" . " love rain." "my neighbour used to" . " love rain." would produce 3 strings: #message 1 "cats and dogs%s3" #message 2 "my neighbour used to%s3" #message 3 " love rain."
sonneveld ok, for more complicated statements in agi like:

size = width*w_size + height*h_size + offset;

you would need several statements like:

temp = width; // notice the temp var
temp *= w_size;
size = height;
size *= h_size;
size += temp;
size += ofset;

otherwise you would get an error. The top is preferable but the compiler needs to be able to access a stack or some predefined temporaries. The compiler doesn't know which variables you are using so you'll have to tell it

A proper stack's possible but not really feasible because you might start overwriting necessary info by accident. Until the next revision of the syntax, I think the author will have to predefine temporaries via a directive like this:

#define COMP_TEMP v10, v13, v14, [v20..v100]

or

#define COMP_TEMP1 v10
#define COMP_TEMP2 v20

or

#compiler_temp v10, v13... etc, etc

COMP_TEMP is just one name.. you could use REG or C_REG or COMP_FUNNY_THINGS

Several (say 5) could be set aside in a revision of template agi game. If the compiler needs more than 5, or it's trying to compile a game that hasn't set aside any, it could stop with an error and tell the user that it needs to set aside some (with helpful info on how).

any ideas?

- Nick
sonneveld new commands / if you want to try something like this: #define myvar v30 myvar = 10; sound(myvar, f50); if (obj.in.box(10, 5, 20,myvar,50)) {} you would be stuck because sound and obj.in.box don't allow variables as a parameter, only numeric constants. so I just thought, any command that doesn't let you pass a variable name as a parameter, create a new one that does. any new commands that we decide to create later on (like new mouse commands), should only accept variables since you can pass a constant number by putting it in a temporary and then passing the temporary as a variable. It would be easy to implement in NAGI, could *probably* implement into a dos version of the interpreter like agi mouse was. Of course, there are people who only want to develop games for the original agi platform (i have got nothing against that btw) so this would be wasted on them but I can't think of any other work around apart from lots of if statements if (myvar==1) { sound(1); } else if (myvar == 2) { sound (2); } .... etc. the compiler would have to give an error if it doesn't have any alternative. there would have to be some sort of communciation to tell the user that this specific code will only run on later interpreters (which we don't get at the moment if we use v3 commands in a v2 interpreter) - Nick
sonneveld said evaluations:

would there be people interested in simplifying said statements?

if (said("open door|cupboard")
{ printf("open? you're morally opposed to opening doors."); }

if (said("take fruit|meat|bread"))
{ printf("you're on a diet remember?"); }

would expand to:

if (said("take", "fruit") || said("take", "meat")
|| said("take", "bread") )
{ printf("you're on a diet remember?"); }

- Nick
Joel Okay, for strings:

I'd prefer something like the "I am %v(age) years old." model, since it's the most like what's already in the language. I don't see any backwards compatibility issues there, since presumably the compiler would still accept the "I am %v200 years old." format. If it's currently possible for the game to see "I am %v(age) years old." and print it out literally, then there could a simple method for allowing the literal string to still be printed.

For temporaries:

I think the new compiler directive sounds like the best approach to me. That would be pretty straightforward to use, I think.

For new commands:

I don't have a preference about them.

For said tests:

I guess that new syntax would be ok, but there seems to be potential for ambiguity, as in this case:

if (said("talk to girl|bills sister")

Does that get translated to:

if (said("talk", "girl") || said("talk", "bills sister"))

or does it get translated to:

if (said("talk", "girl", "sister") || said("talk", "bills", "sister"))

Ok, it's a slightly contrived example, but the point is that the potential for that kind of thing exists and might get in the way.
sonneveld strings: yep.. I realise those are problems.. another one is if you have a word with a space in it like "sleeping potion"

does said ("sleeping potion") expand to said("sleeping", "potion") or said ("sleeping potion") ?

It depends on if those words exist in the dictionary I guess. You could rely on the fact that it should match the largest string.. but you would have to keep that documented.. and post warnings if any ambiguities came up (shift/reduce errors). it shouldn't break compatibility though..

to help fix your problem, you could introduce brackets as well.

if (said("talk to girl|(bills sister)")

don't worry about it being contrived though, I need people to find holes in the syntax.

strings: in the end, it will be get converted to "%v" format.. ie "cat" . age . "dog" will get converted to "cat%v{age}dog" which will get converted to "cat%v200dog" but I'll see if I can keep that option.

- Nick
Brian_Provinciano You could have a look at SCI Studio is possibly use it's compiler's code/syntax for said statements. The syntax works quite well and eliminates issues like the one above.

The %v for strings is nice, but I prefer ("the age is"+age+" ok!"). It'll look better with syntax highlighting :)
sonneveld page in scistudio's tutorial:
http://www.bripro.com/scistudio/tutorial/chapter16.html

one thing i don't understand in relation to semantic references, why can't you go '(turn/on),start / machine' and not use the semantic reference.
(instead of (turn<on) )

is this parsed by the interpreter or does the compiler put some work into it?

---

I wonder if we could use a * or a ? to represent "anyword" or "rol"

- Nick
Brian_Provinciano The compiler parses these, but most if not all should be able to be handled with an AGI compiler. SCI sentences are broken down into a max 3 parts (words) after removing things like the, a, etc.

SCI saids use brackets a little differently than one would expect. For example, you can't go (((this/that))),[[[hi,(there)]]].
AGI1122 Will the compiler support different types of programming such as oop, if that is even possible?
sonneveld I don't think oop would be possible.. but it depends on what you're after.. it might be possible to try joel's suggestion in another thread:

o1.animate(xx);
o3.draw();

- Nick
Brian_Provinciano The new compiler is a great idea, but I think that AGI is so simple, that virtually anything you do to it's language would make it more complicated. However, for more advanced AGI programmers, it would be very useful.

I also think that the o1.animate() type thing is a VERY good idea!
sonneveld Another idea I had was to replace commands like load.logics() and load.logics.v() with just one "overloaded" load.logics() and let the compiler determine whether to use the .v version or not. num constants could be put in a temp var and then used as a var.

there'd have to be other checking as well.. so you couldn't try and pass a num constant to something that's expecting a var that it can change..

- Nick
Brian_Provinciano That's a great idea as well. However, I don't suggest backwards compatibility if you want to make it as full featured and high-level as possible. If you toss the backwards compatibility, you can create the ultimate AGI compiler, which truely could be easier to use!
sonneveld this is true.. but who am I designing it for? the handful of people now who have their old code? or newbies who haven't seen agi logic before?

I want to design for both.. backwards compatibility isn't as big an issue as I thought it would be though.

- Nick
Brian_Provinciano True, but if you are going to make it a completely new concept rather than an extended version, you might want it to be on it's own/not backwards compatible.

Removing the compatibility, you could create whole new source file formats, with function blocks and such. You could make it structured, so it doesn't just start at the top, it starts at a "room100:init() {}" block or something.

I think a great thing for it would be to have something like:

---

room:init()
{
/* which would actually be treated as "room.pic.load()"
* or "this.pic.load()", but since it's in the room block,
* it's not needed */
pic.load();
pic.draw();
pic.discard();

set.horizon(37);

statusline.off();

input.prevent();

setControl(PROGRAM);

pic.show();

screen.display(10,1," Intro/Opening screen");
}

room:doit()
{
if(have.key() || ctlJOYSTICK) {
menu.enable();

screen.lines.clear(22, 24, 0);

ego.motion.stop();
DISABLE_GAME_FUNCTIONS = FALSE;

room.changeTo(aNameOfAnotherRoom); // ie. "room002" or "kitchen"
}

// onExit()
room.exit()
{
screen.print("BYE!")
}

Well, those are my ideas :) dO with them what you wish!
sonneveld actually.. I suggested something along those lines in the other thread on high level compilers..

- Nick
sonneveld Currently all the commands don't return anything except through affecting variables. So I was thinking that perhaps you could rearrange it a bit and make one of them a "return variable"

umm.. I'll try and explain...

normally random works like this:
random(10, 100, v10);
where v10 is the variable where the random number is.

It would be cool if you could do something like this:
position(o5, random(0, 160), random(0, 200));

which would expand to:
random(0, 160, tempvar1);
random(0, 200, tempvar2);
position.v(o5, tempvar1, tempvar2);

This actually uses two ideas.. overloading random so you can return. and overloading position so it uses position.v if you use variables..

- Nick