This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
1186
Issues Help Desk / Re: Can't Install
« on: December 06, 2011, 10:55:06 pm »
You are able to compile now, dfanz0r?
1187
Issues Help Desk / Re: Can't Install
« on: December 06, 2011, 10:28:31 am »
Interesting. Is there a compileEGMf.dll in the main directory?
1188
Issues Help Desk / Re: Can't Install
« on: December 06, 2011, 01:38:06 am »
I'm not sure if polygone correctly conveyed how to fix this. The program we use to install MinGW, mingw-get, has run into problems recently that are beyond our control. In the meantime, you can deal with this simply by installing a correct version over the dead one using the installer found here. Just make sure you check that you want G++, Make, and Msys, if they are listed.
Also, polygone, it seems I wasn't paying attention. See if this fixes our problem: http://sourceforge.net/projects/mingw/files/Installer/mingw-get/mingw-get-0.4-alpha-1/mingw-get-0.4-mingw32-alpha-1-bin.zip/download
It seems to be from early November; I don't remember when the error surfaced.
Also, polygone, it seems I wasn't paying attention. See if this fixes our problem: http://sourceforge.net/projects/mingw/files/Installer/mingw-get/mingw-get-0.4-alpha-1/mingw-get-0.4-mingw32-alpha-1-bin.zip/download
It seems to be from early November; I don't remember when the error surfaced.
1190
Announcements / Re: EDL 3 Proposals
« on: December 04, 2011, 11:05:05 pm »GM will have structures and will compile GML before ENIGMA has a parser.Its funny because its true.
GM will cost a dollar for every week it takes us to finish ENIGMA.
1191
Announcements / Re: EDL 3 Proposals
« 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.
1193
Announcements / Re: EDL 3 Proposals
« 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.
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.
1194
Announcements / Re: EDL 3 Proposals
« 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.
1195
Announcements / Re: EDL 3 Proposals
« 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.
1196
Announcements / EDL 3 Proposals
« 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:
Array assign
One of MATLAB and other language's brighter ideas, this could be enabled with a special case in the parser:
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.
Biggest changes proposed:
- Use of C++ struct keyword in plain EDL. Since I started that JS port, which I thought TGMG was running with but I now guess is still my problem, a lot of turbulence erupted in maintaining a useful, cross-compatible language. While the Definitions resource provides excellent extensibility to the C++ version, some elements missing from GML are too basic to require to be defined in their respective languages. What I'm saying is, JavaScript makes it a bitch to define classes unless you understand what exactly a JavaScript class is, and this is likely the case for other languages we may support. The bottom line is, it would be nice if ENIGMA provided a syntactical wrapper for useful basics like structures.
- Rusky is getting his Lambdas. Now that C++ supports Lambdas, I don't see why not to support them in EDL.
- Inline array declaration. EDL is in dire need of some way to put numbers into arrays adequately.
- A more elegant preprocessor system should be available to the users. C has preprocessors that change how your code looks before it compiles. If you've used much EDL at all, you've used them, probably without noticing it. I would like to share that system with users; the issue is, C's are really ugly, and really bulky.
- EDL's understanding of types is getting an overhaul. We will now ensure that complicated expressions don't trip up the compile because ENIGMA can't adequately cast them. With this comes support for ENIGMA's varargs class.
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.
1197
Announcements / Re: New LGM Backend Map/List
« on: November 24, 2011, 11:11:55 am »
/kick Fede-lasse
1198
General ENIGMA / Re: FFI F'Up
« on: November 22, 2011, 06:31:42 pm »
I guess I could tell the makefile how to build it from scratch. I'll deal with that when I get home.
1199
Announcements / Re: New LGM Backend Map/List
« on: November 22, 2011, 02:17:37 pm »
So uh, when do I get my Definitions resource, IsmAvatar?
1200
General ENIGMA / Re: FFI F'Up
« on: November 22, 2011, 02:15:43 pm »
Three people have that problem, three people don't. I don't know what's causing it. FFI is relatively light weight; there's not much point to making it an extension. I suppose we can once that system is implemented for subsystems.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »