Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / [DarkGDK] The EcoScript Programming Language

Author
Message
Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 24th Sep 2009 00:08
Another one!

EcoScript

So this is my new attempt at a scripting language. This one has many improvements over all it's predecessors, but many similarities as well.

Here are a list of current features:
- Dynamically typed, so variables aren't bound to a single type
- Runs of a Virtual Machine (VM), which makes it easy to utilise as a scripting language
- Supports Object Oriented Programming (OOP), so classes can be created and used within the program
- C-Style syntax: though this is perhaps not appropriate for a community of BASIC users, this is designed for DarkGDK
- Ability to initialize objects and their subsequent fields using arrays


Being a WIP, it is not complete. Still many features to be added (as it stands, it's still not actually Turing-complete). Here are a list of proposed features, coming soon:
- Control structures (if statements, loops, etc)
- API to C++, so source codes written in EcoScript can be used from C++. Also allowed the ability to pass C++ functions to be used in EcoScript
- A DBPro plugin, so it can be used in the same way from DBPro
- Include other, already compiled source files



Now, here are a few things that it supports, that DBPro doesn't support:
- OOP, as already stated
- Ability to store arrays in classes (roughly equivalent to types in DBPro)
- Ability to pass arrays to/from functions
- Ability to pass objects to functions by reference (passing them out of functions doesn't actually work, because that would require a much more complex way of dealing with garbage collection, which I don't know how to do yet)
- Ability to create arrays syntactically using braces {}, i.e., {1, 2, 3}


So what does EcoScript look like? Well, here's a small example:



There.

"everyone forgets a semi-colon sometimes." - Phaelax
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 24th Sep 2009 06:15
Looks cool, but why must you specify 'this' as a parameter in all methods? It seems like a pointless waste of typing, and is '.' used for dereferencing both pointers and non pointer types? As you said 'this' is a pointer.

Most importantly, what's the interface between C++ and this like? Is it as powerful as lua, i.e. where you can create classes(tables+metatables) from C++ and allow the script to instantiate these and assign functions to variables in the class allowing them to get called(such as event callbacks)? This would essentially allow you to write C++ class methods via the script and depending on what methods, variables etc you expose to the script you'd be able to call actual C++ methods(not global functions) in the class from the script.

If you add in such features and the speed is comparable to lua then I may be interested, I'm currently using lua but its interface to C++ is a bit annoying and the various libraries to bind it to C++ are equally annoying.

Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 24th Sep 2009 17:05
Quote: "Looks cool, but why must you specify 'this' as a parameter in all methods? It seems like a pointless waste of typing, and is '.' used for dereferencing both pointers and non pointer types? As you said 'this' is a pointer."


All objects created are automatically pointers actually. It's easier to keep track of the data that way. The reason for the 'this' being the first parameter for methods is basically this (no pun intended): when you call a method, say, obj.method( 42 ), it's actually interpreted as method( &obj, 42 ). So 'this' is just a pointer of the type that the class is defining, and you access fields of 'this' as you would usually. No surprises that the fields must be defined before the methods are created.

This is pretty much what Python does.



Quote: "Most importantly, what's the interface between C++ and this like?"


Well as I said, there's not been any progress on that part yet really. But the primary feature will be that you'll be able to pass function pointers created in C++ to EcoScript. The problem however, due to the strict way that function pointers are defined in C++, you'll have to create abstract interfaces, which access EcoScript stack frames and push parameters, and return values, etc. Needless to say, I'll try and make this as simple as possible.

Other features will be things such as calling EcoScript functions manually (actually this is already implemented, since I had to have a mechanism to automatically call main(). There doesn't have to be a main entry point in the same way as C++, but to run any script, a function must be called. No operations can happen outside functions). Also the ability to read and set global variables will be added, and this will also apply to global objects. You'll have an interface that gets values in a manner like int val = script->getInt( "myglob[3].field" );

I may add a feature where you can pass variables to EcoScript that are created in C++, but that might not be needed, since you'll be able to set command line parameters in the functions that you call. That might actually be slightly neater, and will require no changes to the compiler.

"everyone forgets a semi-colon sometimes." - Phaelax
Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 14th Oct 2009 23:53 Edited at: 15th Oct 2009 00:04
After an important rewrite, I have added and improved many features.

All objects treated as references
This basically means that an object is a space in memory, and your variable simply points to it. Why is this good? Well, it means you get shallow copying, so, for example, if you pass an object as a parameter, it doesn't take a million cycles to copy all the data. The parameter simply points to the same place in memory.

Here's an example:


The good thing about this, from a game programming perspective, is, for example, say you want to update a player's state. Instead of having an array of players, and passing the index of the player you wish to update to the function, you can just pass the actual object player. This is faster than the method that DBPro users are used to.


Only issue left with this is that you have to manually delete memory, as such:


The useful thing about not scoping the objects however is that they can be passed out of functions. Take this for example:


Of course, that object isn't being deleted, so you'd actually have to assign it to a variable and then delete that.



Function overloading
The signature of a function in Eco isn't just it's name, but the name plus how many parameters it takes. You can call different functions that have the same name, but with different amounts of parameters.

For instance:


The output would be:



Constructors
In the previous version, constructors weren't supported for objects. Now they are necessary. Using the fact that you can have function overloading, objects can be created in many different ways.

Here's an example of a vector:


Constructors are written in a class in the same way any other method is written. No special syntax is required. Only thing that is required is that even if you don't need a constructor, it must still be present. For the vector example, you would just do this:



Recursive trees using classes
The old model for classes for Eco was basically a parent-child relationship. Each class had a parent (itself), and a child for each field. If the field was of another UDT, it too would be a parent, and have children. Needless to say, this meant that if you wanted to be recursive, you run out of memory.

Because objects are now treated as references, this isn't an issue. A class is basically just an identifier with a list of fields, which could be integers, floats, strings, or, other objects, even if they're of the same type of the class itself. Of course, the only way it would become recursive is using the constructors, because variables are dynamically typed.

Here's an example:




Access modifiers
Access modifiers allow you to restrict usage of class member variables and methods to outside users. Essentially this means that they can't fiddle around with things they shouldn't be.

This feature is almost complete, except that currently (since it's implementation just today), even if you use a member inside a class, it will still throw an error. I will get this fixed, but not now because I'm about to go out for a drink.

Anyway, it still gives it a snazzy java-ish look. Here's a simple vector class:



Plenty more features still to come. This is the result of many years of research and practice, so it would be nice to see some comments

"everyone forgets a semi-colon sometimes." - Phaelax
How is it going
16
Years of Service
User Offline
Joined: 18th Sep 2007
Location: California
Posted: 16th Oct 2009 07:19
this looks great man...
love the syntax
I've been thinking about trying to learn a scripting language( or making one) although I don't believe I'm qualified for the job...
Keep up the good work, I'd love to try it out when its done
Zotoaster
19
Years of Service
User Offline
Joined: 20th Dec 2004
Location: Scotland
Posted: 18th Oct 2009 02:32
Thank you. I'd be happy to release it sometime, but I don't think many people will want to use it until I make at least an IDE an a simple library that can be used to make games. Need to finish the core of the language first though.

"everyone forgets a semi-colon sometimes." - Phaelax

Login to post a reply

Server time is: 2024-05-19 15:48:43
Your offset time is: 2024-05-19 15:48:43