ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on December 02, 2011, 11:25:03 am

Title: EDL 3 Proposals
Post by: Josh @ Dreamland on December 02, 2011, 11:25:03 am
By my calculations, this will be the third time we've changed EDL's featureset considerably. In the beginning, I was just going to support GML as laid out in 6.1. Over time, I decided, "fuck that, we need real constructs and language features." Since then, a lot has been changing, even in the world of computer science as a whole. For instance, C++'s feature set has grown sharply with the publishing of the most recent ISO. So basically, I guess we need to start discussing EDL tuneups before I go ahead and write up the new parser.

Biggest changes proposed:

Now, the point of this thread is to present what we want added, get more suggestions for what to add, and also, to deliberate on how these features will interact when they are added.

For example, how do we want Lambdas to look? How do we want arrays to look? How do we want preprocessors to look?
Originally, my proposal for preprocessors was [[ifdef BUILD_WINDOWS]]do_something_with_the_registry_or_something()[[endif]].
And, well, most languages use [...] for arrays. [1, 2, 3, 4, 5].
And, C++ uses [] to indicate lambda. [](int a) { return a + 1; }

So, with a good enough parser, no worries, right? Not really; some of these get ambiguous.
What if I want a singleton array of a singleton array of a variable called pragma? [[pragma]]. Oops. Even if ENIGMA got it right, the highlighter wouldn't, so it'd be ugly as hell. So, do I ask users to simply put spaces between their brackets? I think not. The best option is to use something else for one of them. For example, [%ifdef BUILD_WINDOWS%]. Since % is a binary operator, any mention of it after a [ or before a ] is invalid. So now, how to distinguish [] as an empty array and [] as a lambda? I think that'll mostly take care of itself, since in a lambda the next token must be ().

With that, here are our current proposals:

C++ structs
Can be used in any code that uses the structure individually, declared for the whole object with local struct, or declared for the whole game with global struct. The latter will require reparse of the entire game, similar to placing the structure in definitions. As such, it may be dropped or discouraged.

Lambdas
Rusky's proposal for lambdas is to mirror C#'s syntax. mylambda = (x,y) => { x + y }. For simpler expressions, square = x => x*x

Inline Arrays
Basically, [] instantiates an array of variants as its own class, including a length member. There would be functions taking Array& as an argument. Var would be able to easily produce an Array& in O(1), and there would be a var::var(Array) constructor. What this means is, you'd be able to do this:
Code: (EDL) [Select]
var a = [1, 2, 3, 4, 5];
a = reverse(a);

Array assign
One of MATLAB and other language's brighter ideas, this could be enabled with a special case in the parser:
Code: (EDL) [Select]
var a, b, c;
[a, b, c] = get_abc();
Where get_abc(); returns Array.

Some things I'm presently pondering:
1. Can the new parser have the ass to choose between mean(double,double), mean(varargs&), and mean(Array)?
2. Can we scrap Array altogether and just use var, or would a separate array class be more efficient?

So anyway, if you don't like a proposal, if you have a better idea, or if you have something new you would like to see in the language, let us know.
Peace.
Title: Re: EDL 3 Proposals
Post by: TheExDeus on December 02, 2011, 11:52:57 am
Most of the ideas are great, though making all of that for the parser will take freaking years.

Though about arrays, why does it change arrays into function right now? Like "if(ass[0])" is "if (ass(0))". I know that its probably because they can have dynamic size and they don't have a specific type (variant I guess is a type). Its just that I had problems with some array declaration before. For example, this errors:
Code: [Select]
int some_array[10];
some_array[5]=10;
Quote
Preprocessor_Environment_Editable/IDE_EDIT_objectfunctionality.h:37:17: error: 'some_array' cannot be used as a function
While this works fine:
Code: [Select]
local int some_array[15];Also, this errors:
Code: [Select]
n=15;
local int some_array[n];
I guess you get the point. So basically, will this get fixed when you change the array system?

edit: Also, btw, this code freezes not only LGM but crashes the whole JAVA VM:
Code: [Select]
local int intensity_res=32,
intmap_w=int(room_width/intensity_res),
intmap_h=int(room_height/intensity_res);
local int intensity_map[][];
for (int i=0; i<=intmap_w; i++){
    for (int c=0; c<=intmap_h; i++){
        intensity_map[i][c]=0;
    }
}
I found that a few weeks ago, but I didn't have the time to post, and I just remember about it.
Title: Re: EDL 3 Proposals
Post by: Josh @ Dreamland on December 02, 2011, 11:57:29 am
It's so var can do 2-dimensional array subscripts at once. It was for array[1,2] originally, but erroneously gets replaced with () in more cases.
Title: Re: EDL 3 Proposals
Post by: TheExDeus on December 02, 2011, 01:38:46 pm
OOOOOOOOoooooooooooooooooooohhhhhhhhhhhhhhhhhhhh.
Title: Re: EDL 3 Proposals
Post by: luiscubal on December 02, 2011, 01:49:22 pm
Don't forget support for type inference(auto), which is pretty much mandatory when it comes to lambdas.
Title: Re: EDL 3 Proposals
Post by: Josh @ Dreamland on December 02, 2011, 03:49:08 pm
Well, I've actually still not decided whether or not to rely fully on C++11. I figure this new parser is going to need to be able to do type inference for itself. But sure, I think an auto keyword in the spec would be a good idea.
Title: Re: EDL 3 Proposals
Post by: Rusky on December 02, 2011, 04:05:16 pm
Global structs probably the most useful kind, so if you're going to provide a cross-language implementation there should be some resource similar to definitions that lets you define them. Maybe with an (optional?) graphical editor. It might even make sense to extend EDL enough that you can entirely replace Definitions (modulo #include) and just use that.

If you're going with lambdas, you can either rely on C++11 or write your own implementation by generating and constructing a class with operator() for each lambda. If you want captured variables to work outside the enclosing scope, you'll have to figure out what they are anyway, so you may as well go with generating your own classes since that will work on old/non-C++11 compilers.

I like the idea of arrays as a separate type- it makes var-compatibility simpler. You can pass/return arrays but not vars, etc. Also destructuring assignment is cool.
Title: Re: EDL 3 Proposals
Post by: luiscubal on December 02, 2011, 04:17:09 pm
For C++11 lambdas, I believe the actual type of the lambdas is undefined by the spec. The only requirement is that lambdas that do not capture variables must be cast-able to function pointers.
So, if Josh intends to have type inference on his parser, he'll *have* to provide his own lambda implementation.

That is, unless Josh can use some Clang magic powder to make that problem go away.
Title: Re: EDL 3 Proposals
Post by: Josh @ Dreamland on December 02, 2011, 04:36:08 pm
Clang's no longer in the picture. I figure if I'm to maintain ENIGMA's interface with a C++ parser, it should be my own.

As for Array being a separate type--I realized it's not just a good idea, it's necessary. If I want Arrays of Arrays of Arrays of variants, I need some way of representing that which is independent of var, which can only store 2D arrays.
Title: Re: EDL 3 Proposals
Post by: Rusky on December 02, 2011, 05:37:28 pm
luiscubal: the spec does, however, require that lambdas be capturable by e.g. std::function<int(int, int)>
Title: Re: EDL 3 Proposals
Post by: RetroX on December 03, 2011, 11:05:49 am
In addition, std::function is polymorphic, meaning that std::function<int(int, int)> can be converted to std::function<int(double, double)>.
Title: Re: EDL 3 Proposals
Post by: Fede-lasse on December 03, 2011, 04:47:42 pm
inb4 i make another idc-as-long-as-i-can-code-gml post
Title: Re: EDL 3 Proposals
Post by: The 11th plague of Egypt on December 04, 2011, 09:02:22 am
I'm using Java right now for a school project, and I find it somewhat quirky.

It has and extensive standard library, but that's its main probem when it comes to deprecating stuff in order to innovate.

The more functionalities you add, the more you'll have to support.

As for Enigma, some of us just wanted a quick and (slightly less) dirty GM clone.

Anyway, I know GM sucks because it takes too much effort to build a simple textbox, nevermind a whole GUI.
Than there is another big problem with slowness and the confusion between classes and instances.

But still, sometimes I find myself wanting to go back to that old and simple piece of crap.
Title: Re: EDL 3 Proposals
Post by: Josh @ Dreamland on December 04, 2011, 09:50:53 am
It's kind of easy to maintain backwards compatibility with a languages with as few features as GML. The point's to add functionality for people who find +=1 to be futile and who like to use static typing. And real structures.
Title: Re: EDL 3 Proposals
Post by: Rusky on December 04, 2011, 06:18:42 pm
GM will have structures and will compile GML before ENIGMA has a parser.

:troll:
Title: Re: EDL 3 Proposals
Post by: TheExDeus on December 04, 2011, 07:29:38 pm
GM will have structures and will compile GML before ENIGMA has a parser.

:troll:
Its funny because its true.
:troll:
Title: Re: EDL 3 Proposals
Post by: Josh @ Dreamland on December 04, 2011, 11:05:05 pm
GM will have structures and will compile GML before ENIGMA has a parser.

:troll:
Its funny because its true.
:troll:

GM will cost a dollar for every week it takes us to finish ENIGMA.

:troll:
Title: Re: EDL 3 Proposals
Post by: RetroX on December 05, 2011, 05:59:16 pm
GM will have structures and will compile GML before ENIGMA has a parser.

:troll:
Its funny because its true.
:troll:

GM will cost a dollar for every week it takes us to finish ENIGMA.

:troll:

So, ENIGMA won't ever de done?
Title: Re: EDL 3 Proposals
Post by: Josh @ Dreamland on December 05, 2011, 06:35:13 pm
:troll:
Title: Re: EDL 3 Proposals
Post by: Fede-lasse on December 06, 2011, 03:52:23 am
^