EDL V.Next

[luiscubal]

In the announcement post Josh made, I wrote about making EDL independent of C++, with only a few select features and some interoperability functions.
I think I ought to be more specific. So I decided to post some thoughts here for discussion.

So here goes:

some script:

Code: [Select]

//Basic EDL
var x = 1; //Single-line comment
/*block comment*/
x = 2; //reassign

//Enter static typing
int y = 3;
y = x;

x = "str";
y = x; //enigma::cast_exception

const z = 2; //type of z is inferred.
z = 3; //error

if z > 1 then begin //GML compatibility
    show_message("foo");
end

So, essentially, GML with a few new features.
But that's not all.

some function file. Different from plain scripts since it can contain multiple functions.

Code: [Select]

int foo = 2;
string bar = "xyz";
vector<float> baz;

type xyz = struct __cpp_pod__ /*plain old data*/ {
   enigma::cpp_interop::type_int x;
   enigma::cpp_interop::type_int y;
   enigma::cpp_interop::type_float z;
};

foreign(cpp) void some_namespace::some_cpp_function(xyz foo, xyz* bar, xyz& baz);

C++ file:

Code: [Select]

#include <iostream>
#include "enigma.h"

using std::cout;
using std::endl;

struct xyz{
    int x;
    int y;
    float z;
};

namespace some_namespace {
    ENIGMA_EXPORT void some_cpp_function(xyz foo, xyz* bar, xyz& baz) {
          cout << "hello, world\n" << endl;
    }
}

So, basic types: void, int, uint, char, byte, sbyte, short, ushort, long, ulong, float, double, string, vector<T>, vector<T>::iterator/const_iterator, var(if it can be considered a type at all), T*, T&, map<K, V>, map<K, V>::iterator, lambda types(?), maybe others, such as types from C++ people might find useful. Maybe vector types too? I'm pretty sure LLVM handles vector types really well.
Extra types would be defined in enigma::cpp_interop, to ensure maximum compatibility.
Additionally, one could define other types (enigma::object_id?)

Code: [Select]

type mycallback = void(var sender, string message);
...
mycallback self.on_talk; //statically typed fields? Maybe some other syntax?
...
self.on_talk = [](var sender, string message) { /* do something here*/ };


Code: [Select]

//Unified API to easily handle save games, in the proper directories
var app = new GameApplication("my-game-name");

var saveslot = app.createSaveSlot("slot-" + 3); //c++-style strings are the default, although I guess one could make C-style strings
let(const savegame = saveslot.open("mydata", FileAccess::Write, FileMode::Binary)) {

byte bytes[] = {12, 13, 14, 15};
savegame.write(bytes);

} //savegame goes out of scope here, so it's destructed(and therefore closed)

//also, app.deleteSlot, app.slotExists, app.openSlot, etc.
//Essentially, each game has a global GameApplication instance, each save slot has a SaveSlot, and each save slot has as many files as the developer sees fit.
//Internally, ENIGMA may decide to compress all save slot files in a single zlib file, if Josh wishes to do so

I thought about all of this literally as I was writing it, so except inconsistencies, bad solutions, etc.
Fell free to discuss and take only the good parts. As you may have noticed, I have quickly scripted not only a language, but also some APIs, feel free to discard some parts of this post.

[RetroX]

Question: What is the point of a let statement?  Why not just use { } ?

[luiscubal]

I like let, but I'd happily abandon it. I think it makes the fact that the object is going to be destroyed after that scope ends more explicit but, again, I'd be happy to drop it entirely.

[Josh @ Dreamland]

I keep giving this another lookover, but every time I see it, I just think, "Fuck everything about this."

I mean, calling class::something() on a typeless variable? Fuck that. People want compile-time "too many arguments to..." errors. I can't offer that if people can flop entire class types whenever the fuck they want, without any kind of predetermination.

foreign()? __cpp_pod__? ENIGMA_EXPORT? What the shit are these? How about, instead of dropping breadcrumb trails for the compiler, we just say what the fuck we want as we want it? Like with strong types, and by just giving access to scripting in the native language.

[luiscubal]

I mean, calling class::something() on a typeless variable? Fuck that. People want compile-time "too many arguments to..." errors. I can't offer that if people can flop entire class types whenever the fuck they want, without any kind of predetermination.

I'm not sure what you're talking about.  If you are talking about "typeless.something()" then I don't think it's possible to have a compile-time error in a dynamically typed environment. So you'd probably want to make "dynamicallytyped.something" a compile-time error(except for stuff like x, y, room_width, etc.)
If you are talking about "class::something(typeless)", then I really don't see the problem at all. I mean, there's nothing about that that the *current* EDL doesn't have right? I mean, ENIGMA already has to allow vars to be passed to GML functions, even if those GML functions are meant to be restricted to some specific types, right?

In other words, I have no idea what you mean.

foreign()? __cpp_pod__? ENIGMA_EXPORT? What the shit are these? How about, instead of dropping breadcrumb trails for the compiler, we just say what the fuck we want as we want it? Like with strong types, and by just giving access to scripting in the native language.

You're in a bad mood, but anyway, I was trying to make it easier for the compiler to tell when it was supposed to be interoping with C++. ENIGMA_EXPORT was just in case you wanted to do something obscure with EDL functions(like special calling conventions, or no name mangling for instance), and is unneeded otherwise.
__cpp_pod__ was meant to help the EDL compiler know that a struct was meant to be a POD. Again, a detail many ENIGMA users wouldn't care about but important when interfacing with C++. If you think automatically detecting PODs would work and be intuitive, then I see no reason to keep it.
As for foreign(), it is - again - a way to let EDL know that it is interfacing with C++, to be careful about calling conventions and (depending on internal implementations), possibly generate wrapper functions if convenient for the compiler. Additionally, foreign() could do neat tricks such as meaningful compile-time errors like "attempting to use C++ function, but program is compiled for JS"(and if EDL was to be directly compiled to JS and use some weird trick to convert the rest of C++ to JS, foreign would be helpful to detect when to perform those interoperability tricks).

Also, you seem to be on a bad mood.

[Josh @ Dreamland]

Nah, I'm just insane.

...Okay, maybe the volumes of school shit I have to deal with are getting to me.

Anyway, I'll probably end up adding those things to ENIGMA in hell, but until then, I'm going to pass on them. I might allow the C++ auto keyword, but I don't want to ambiguate var--in GML, and in JavaScript, var can change types dynamically. I don't want people to think they can flop from map to list on a whim.

Anyway, the compiler can currently identify C++ terms just fine. The issue is in type resolution with those. My C parser's argument type tracking isn't there, and its template resolution is abysmal.

[luiscubal]

I don't want people to think they can flop from map to list on a whim.

They can't? You mean, EDL won't feature dynamic typing?
You do realize this means massive GML incompatibility, right?
I made this entire thing assuming that dynamic typing(GML's and JavaScript's var) was a must-have for EDL.

[Josh @ Dreamland]

EDL allows flopping between real and string, as in GML. It also allows flopping between ds_stack and ds_list, etc, because all of them are represented by integers. If this ever ceased to be the case...

If I really wanted, I could implement a highly unsafe integer conversion for all C++ containers and user structures, but that'd end up being pointless. Even with the ability to integerize complicated data structures on a whim, calling a generic method like erase() or length() or size() on one of them would be impossible to syntax check without some sort of type tracing that would involve going out of scope. Way out of scope. Like, the entire game, every time I need to make sure that call applies.

GM's typing is only dynamic because it doesn't offer a way of storing anything locally. Dynamic typing between all native classes has never been a plan in ENIGMA--Its availability in JavaScript is a side effect that will ultimately not be supported except in native scripts.

Perhaps in the future I will look into standardizing containers for EDL and at that point will look into making sure they all have those methods available to prevent compile errors. Still, the efficiency of the operation would bother me. I'm basically content to keep segregating functions like ds_blah from blah<blahblah> until users develop the ability to type things manually.

[Rusky]

EDL only features dynamic typing between double and std::string, and only if you declare something as var (explicitly or implicitly). Thus, anything written in GM will work, and anything taking advantage of new types will be statically typed.

If you ask me, I think this is more evidence of stockholm syndrome than anything else, but...

edit: what happened to the forum telling you when someone posted before you?

[Josh @ Dreamland]

Good question.

Also, which part is Stockholm Syndrome? I just see it as business strategy; any more I'm just trying to assemble an engine, and GML is along for the ride.