AngelScript: The Revenge

[Tamamo]

AS has it's own limitations

[Saffith]

Well, there are limitations of the language itself and limitations of the implementation. In ZScript's case, there are plenty of each. Whatever else might be said about them, AngelScript, Lua, and Python all have a lot fewer of the former.

[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.

[Tamamo]

@Gleeok
Just cause your compiler know the types, doesn't mean it knows the scope of it's functions and such. We need function callbacks and message handlers for that sole reason. Since you seem to be so set and determine on simplifying the syntax; which is something i have been completely against since the start of this discussion. This is for several reasons. First I hate the simplification of C to ZScript, Second people need to learn to adapt. I'm not even a programmer, I'm a freaking artist and I can learn a programming language easily if I put my mind to it. Anyways will simply move on from this project. And start dedicating my fulltime to other projects. Adios Amigos

[Gleeok]

@Gleeok
Just cause your compiler know the types, doesn't mean it knows the scope of it's functions and such. We need function callbacks and message handlers for that sole reason. Since you seem to be so set and determine on simplifying the syntax; which is something i have been completely against since the start of this discussion. This is for several reasons. First I hate the simplification of C to ZScript, Second people need to learn to adapt. I'm not even a programmer, I'm a freaking artist and I can learn a programming language easily if I put my mind to it. Anyways will simply move on from this project. And start dedicating my fulltime to other projects. Adios Amigos

Not sure I understand what you mean? I'm talking about the angelscrit compiler and the author of the language. I'm not talking about removing any functionality of the language. Anyways, that functionality is not complete so it's kind of moot.

Callbacks ARE being put in, that's kind of a main point.

[DarkDragon]

I think it's important to keep in mind a separation between the semantics we want, and the details of the syntax.

Moving to message handlers is a big change in semantics and it's important that we hash out the details of how we want scripts to interact with the game engine and with each other using this system.

Syntax is important, especially for easing the transition from other languages to AS, but much less urgent to argue about right now since it is easier to change (by modifying AS, or preprocessing) than core semantics.