AngelScript: The Revenge

[Dimentio]

Let's talk about the AS syntax really quick.

//note: code is gibberish, it doesn't do anything.

//HANDLES
void Foo(Ref@ ref) //option A:
{
  @ref = @Ref.Create(); //points to a new thingy.
  ref = otherRef; // now it value copies other thingy. whoops.
}

// confused yet? ...well then:

void Foo(Ref ref) //option B:
{
  ref = Ref.Create(); //points to a new thingy.
  ref = otherRef; // now it POINTS to other thingy instead.
}

int e = Enum::Value;
int i = A::B::Value; 
int v = this.Value;
int x = Object.Value;
Link::X = x;

..confused again?

int e = Enum.Value;
int i = A.B.Value; 
int v = this.Value;
int x = Object.Value;
Link.X = x;

// Current annoyance... but unlikely as part of the ZC script API. ...idk
void Foo(const int &in a, int &out b, Object &c)
{
}

//unless we allow unsafe references only "out&" or "&inout" is really useful.

Script language reference: http://www.angelcode.com/angelscript...oc_script.html
Other issues?

Looking at that syntax makes me feel like I'm looking through the source code, just to do a little scripting. I'm not entirely sure how this will help people learn the language?

[Gleeok]

Looking at that syntax makes me feel like I'm looking through the source code, just to do a little scripting. I'm not entirely sure how this will help people learn the language?

It's not. We have to set up how we want scripts to behave, and set up compiler options accordingly; perhaps even have some form of code standard. Have you ever been to an eye doctor and they asked you "A or B?" Well that's what we have to figure out. That code is purposely ugly for this purpose.

[Dimentio]

It's not. We have to set up how we want scripts to behave, and set up compiler options accordingly; perhaps even have some form of code standard. Have you ever been to an eye doctor and they asked you "A or B?" Well that's what we have to figure out. That code is purposely ugly for this purpose.

Ah. I vote on making it as close to ZScript as possible, without it's limitations.

[ZoriaRPG]

Ah. I vote on making it as close to ZScript as possible, without it's limitations.

Actually, that syntax is like ZScript. The reason you haven;t seen some of that, is because the parser doesn't handle all of the available C syntax that it could. There has been some improvement in that area. There's very little proper C syntax that it could not handle--or really, handle without a lot of work. It could theoretically do anything that a full C parser could do. Cpp syntax is something else, as it continually morphs with each new revision. There are things that cpp allows that I didn't know about until recently, and not all compilers may support them (read, CPP11), and yet others that it does not support, but compilers may (e.g. variable array declaration, supported by gcc).

How the hell would array pointers translate? That's a fundamental question, and concern.

[Gleeok]

Ah. I vote on making it as close to ZScript as possible, without it's limitations.

Probably the best possible answer. I will do that.


Sure. Right now I've got the parser and compiler working and can create and call scripts. The first test scripts should be forthcoming this week.

I'm going to experiment with the compiler options to see if I can get rid of handles or not. The docs are not clear on this. ("handles" are the Class@ c; @c = @something; Foo(@c); stuff)
[EDIT] This unfortunately produces weird compiler errors. "Normal" scripts and all engine declared things will not force scripts to use them, however if you write classes and want to communicate custom classes with each other then in those cases you will have to use them as parameters. It's likely most normal scripts won't ever need them... I think...

There's no ZC bindings for the time being until everything is tested fully, but I can put in a math library for collisions and vector math stuff. It is important to implement these c++ side to get all the performance benefits of c++ compiled code and have scripts use that directly with no intermediate layer. What I'm going for is at least a 20x performance increase over ZScript for common tasks. We'll see what happens.

[SUCCESSOR]

Probably the best possible answer. I will do that.


Sure. Right now I've got the parser and compiler working and can create and call scripts. The first test scripts should be forthcoming this week.

I'm going to experiment with the compiler options to see if I can get rid of handles or not. The docs are not clear on this. ("handles" are the Class@ c; @c = @something; Foo(@c); stuff)
[EDIT] This unfortunately produces weird compiler errors. "Normal" scripts and all engine declared things will not force scripts to use them, however if you write classes and want to communicate custom classes with each other then in those cases you will have to use them as parameters. It's likely most normal scripts won't ever need them... I think...

There's no ZC bindings for the time being until everything is tested fully, but I can put in a math library for collisions and vector math stuff. It is important to implement these c++ side to get all the performance benefits of c++ compiled code and have scripts use that directly with no intermediate layer. What I'm going for is at least a 20x performance increase over ZScript for common tasks. We'll see what happens.

Why would you get rid of handles?

[Tamamo]

Gleeok, please tell me you're joking for once. I really want my callback functions this time around.

[Gleeok]

Joking you say?! I never joke.

Why would you get rid of handles?

They're not needed since the compiler should be able to know all the types at compile. I remember years ago (2011?) Andreas said that for AS ver. 3.0 he wanted to revamp the language to allow this. There's a few options for this but it's not complete. There's no real reason other than simplifying the syntax for scripters to be closer to something more familiar like ZScript or CS.