ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on March 12, 2010, 09:45:55 AM

Title: Another choice.
Post by: Josh @ Dreamland on March 12, 2010, 09:45:55 AM
In R3, you were allowed to say "int a;" in a code piece to declare "a" as C++'s fastest type. To declare it as a local variable to the object, however, I made you say "localv int a;". Well, that system was brutally easy to implement. However, it's not so convenient to type.

When I started the project, I was enamored by how similar C++ and GML were. I saw "var" as a data type; GM's only data type.  It was only logical that var should be a class.

However, long, long ago, NoodleNog suggested that to declare script-local variables, of type "int" for example, you should use "var int" rather than just "int." This makes it a bit of a hassle to declare script-locals, but then actual object-local variables are simply declared as "int."

He was presenting this to me as I suggested ambiguating the word "local" to use. Locals would be declared one-time, preferably in create events but technically in any event, as "local int a;".

My first choice was actually to have Ism add an event for such declarations; in this event, you would have only your locals declared. It seems rather unprofessional in retrospect, but would technically be as easy as adding semicolons and copying over the code to the front of the structure. :P It would make my life easier, but it would leave a bad feeling in my stomach and would cause Ism a good amount of work, possibly delaying the project further.

I was going to just go with the first option (which I will cast a vote on this time), but I figured I'd give you all a chance to toss it around and/or shoot flames at it first.

To clarify, no outcome of this poll will affect backwards-compatibility with Game Maker. This is purely an extension of the language. Undeclared variables will be treated as local vars. "localv var" and "local var" are meaningless.

Anyway, same drill as last time.
Peace.
Title: Re: Another choice.
Post by: retep998 on March 12, 2010, 09:51:35 AM
IF YOU MAKE ME TO HAVE TO DECLARE LOCAL JUST TO MAKE A DAMN OBJECT-LOCAL VARIABLE I'M GOING TO KILL YOU AND MAKE MY OWN PRIVATE BUILD OF ENIGMA JUST TO HAVE IT AS A SIMPLE INT.

I vote "int, var int"
Title: Re: Another choice.
Post by: Rusky on March 12, 2010, 10:23:31 AM
"int, var int" is probably closest to GM's functionality, and omitting the type would default to var as in GM. So long as code from GM behaves the same way in Enigma, it should be okay. It would be nice to be able to disable automatic member creation and manage members yourself, though, in which case "int foo" would be script-local like C++. Not sure how I would resolve this in the long run; I really dislike GM's behavior.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 12, 2010, 10:51:08 AM
retep998--
That was what I was thinking at first, but then I realized that I would be saying "var int" a lot more often than "local int." And if I forgot the "var," I'd be in danger of bizarre performance.

Consider

for (var int i = 0; i < 10; i++)
vs
for (int i = 0; i < 10; i++)

If ENIGMA moved the initialization of the local in the second example to the constructor of the object (as it should, technically), "i" would resume at 10 and the loop wouldn't do anything. That would be bad. :v:

Not to mention you'd be wasting the memory if you forgot the var. Though, that goes both ways.

Rusky--
Not anymore, I don't think. GM7(?) implements this syntax:

global var a;

Which they advertise as eliminating the need to use "global." in future references.
Implementing "local int a" would be no different.

Title: Re: Another choice.
Post by: retep998 on March 12, 2010, 11:12:43 AM
Hmmm.....
...
Hmmmmm......
...
DAMNIT!
...
How about...
"int, var int" during creation events
and
"local int, int" during all other events

And also, it's "globalvar" not "global var"
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 12, 2010, 11:17:19 AM
Quote
Hmmm.....
...
Hmmmmm......
...
DAMNIT!

Yep. Hence the poll.

I'd rather not distinguish between events, though.
Title: Re: Another choice.
Post by: retep998 on March 12, 2010, 11:21:04 AM
We're screwed either way....
Hmmmmmm.....
This is where I hate enigma (gm plus c++ = gmc++ o_0 The gmc is really low to begin with, so that ain't saying much about enigma)
Eh, I change my vote to the first thingy "local int, int"
I prefer the normal c++ way of
class shithead{
public:
string typeofshit;
};
gmc++ just doesn't work very well...
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 12, 2010, 12:22:27 PM
Vote changing's enabled, I believe. Feel free.

There was another problem with operator++, but I don't think we need a poll for that.
Title: Re: Another choice.
Post by: retep998 on March 12, 2010, 12:31:03 PM
You should totally call the language gmc++
Title: Re: Another choice.
Post by: Rusky on March 12, 2010, 01:31:09 PM
localvar then, maybe?
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 12, 2010, 01:52:45 PM
Well, I'd take localv over that. Two less letters, and such. May as well just go with local, in the end.
Title: Re: Another choice.
Post by: retep998 on March 12, 2010, 02:03:37 PM
Well, I'd take localv over that. Two less letters, and such. May as well just go with local, in the end.

Add support for all 3 then
localvar
localv
local
:D
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 12, 2010, 02:58:54 PM
This is another case of GML vs C++

We'll have a GM audience, but we want to be serious too.

I'd vote for int and var int because it would make GM ports easier, but if local int is more C++ friendly, then go for it.

We don't need a var since we can use all the types we want. If we really want var to mean temporary, then call it "temp".
Title: Re: Another choice.
Post by: luiscubal on March 12, 2010, 03:35:39 PM
Some languages allow post-fix types, such as ActionScript.

var x : int = 2;

What about this possibility?
Basically, every single local/global declaration rule would be the same as GM's, except for an optional suffix. This doesn't seem to conflict with GM's way, although I'm not sure I understood the problem.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 12, 2010, 03:45:24 PM
The 11th plague of Egypt--
Neither interfere with porting GM games to ENIGMA; it's a new concept to GM users and it can be interpreted either way.

luis--
Some languages are fuck ugly and require too much typing AND too many shift presses. >_<
Title: Re: Another choice.
Post by: Grundoko on March 12, 2010, 05:31:57 PM
I don't think we should need to write local in front of local variables. That would make basically every GML script that uses local variables (99.9%) incompatable.
Title: Re: Another choice.
Post by: Micah on March 12, 2010, 05:43:31 PM
The whole `var` class thing doesn't work the same way as GM's `var` keyword. I was under the impression that Enigma was aiming for backwards-compatibility wherever possible (without doing something like including a huge fat GCC in the executable, as would be required for `execute_string`).

So my suggestion is to make Enigma scripts not have any idea that the class `var` even exists, and if you ran a normal GM game in Enigma, every variable would be a `var`. To use C++ types, "int, var int" would then be the best choice.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 12, 2010, 07:30:42 PM
Grundoko--
This is only while declaring them, which is entirely optional. GM offers no such functionality.
Here, "local" means "object-local." GM doesn't offer a method of declaring things, it leaves them all var. ENIGMA does this by default; declaring them is an extension of GML. "local var" does essentially nothing.

"The whole `var` class thing doesn't work the same way as GM's `var` keyword."
Care to back this up with examples?
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 12, 2010, 09:24:02 PM
Local sounds ok, especially if you DON'T NEED to write it (as Josh wrote).

Var is something we should be able to do without, it's a GM abomination!
Title: Re: Another choice.
Post by: Grundoko on March 12, 2010, 09:27:20 PM
So, are you saying writing local in front of a variable does the same thing as writing nothing in front of a variable, but can be used to make code more legible?

If so, that sounds like a good idea, and I'll likely start putting local in front of my variables, so I can read everything better.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 12, 2010, 09:46:43 PM
Grundoko:

No, "local" tells the compiler that the following declaration belongs to the current instance rather than the current script.
In GM, "var" declares variables in the current script, and these variables are freed after the script is called. There is no way to declare an instance-local variable (such as x or y) in GM, because there is no need to; GM's only type is var. In ENIGMA, however, we have more than one type. So.

In GM, you'd say
Code: [Select]
  var i;
  for (i = 0; i < 10; i += 1)
    ...
in ENIGMA, you'd say
Code: [Select]
  for (var i = 0; i < 10; i += 1)
    ...
OR you can say
Code: [Select]
  for (int i = 0; i < 10; i += 1)
    ...
That's an easy way to speed up your code, since int is more than 10x faster than var in ENIGMA alone (there's really no point comparing it to GM's var's speed).

However, as I said, GM doesn't offer a way to declare object-local variables like x and y, because its only type is var. To bring other types into the mix, R3 used a keyword "localv."

Saying "localv int a;" made sure that "a" was the same variable in all codes called from that object, and ensured that it was an int.

Now, I can leave it like it is, or I can change "localv" to "local," or I can remove "local" entirely and use "var int" when declaring SCRIPT-local variables, making our for loop from before look like this:

Code: [Select]
  for (var int i = 0; i < 10; i += 1)
    ...


SO. If we use "local" this way, here's the layout:
local int a; //Declares variable "a" as an integer. "a" behaves like variables such as "x" and "y".
int a; //Declares variable "a" in the current script. It cannot be used in other events or codes, like "var a" in GML.
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 13, 2010, 12:22:42 AM
SO. If we use "local" this way, here's the layout:
local int a; //Declares variable "a" as an integer. "a" behaves like variables such as "x" and "y".
int a; //Declares variable "a" in the current script. It cannot be used in other events or codes, like "var a" in GML.
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.
So writing a=0 means writing var a=0 in the sense of GM var?
But then our object create events are still screwed. Or you mean something like local var a?
And var int a=0 or local int a=0 would be 2 other completely different things.

Then we have 3 ways of declaring a variable: 1 for retro-compatibility and 2 to define?
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 13, 2010, 12:25:48 AM
Quote
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.
I meant object-local that time, yes. Fix'd:
a = 0; //"a" is assumed to be an OBJECT-local variable, accessible from all events, and will be given type "var" if no one else says anything.

And yes, I suppose, but two overlap.
1) Not declaring variable: Both GM and ENIGMA assume object-local var
2) var a: Both assume script-local var
    int a: ENIGMA assumes script-local int
3) local int a: ENIGMA creates object-local int
Title: Re: Another choice.
Post by: Game_boy on March 13, 2010, 06:16:00 AM
I'd prefer "int a" to mean object-local int, and "local int a" to mean script-local. So none of the options on the poll, but if it was there it would be "int, local int". But to make it compatible with GM, "var int" should be a script-local var type. Since "a" is declaring an object-local variable, and by saying "int a" I only want to change its type to integer, not to make it script-local as well.

So:

a (object-local var type)
int a (object-local int type)
local int a (script-local int type)
var a (script-local var type)

Result: compatible with GM, but declaring a type doesn't make it script-local automatically, which I would call unexpected behaviour.


Title: Re: Another choice.
Post by: Josh @ Dreamland on March 13, 2010, 10:09:12 AM
Game_boy--
I wasn't sure what people expected. When I say "int x;" in any language of that syntax, I expect "x" to last only as long as the script does. I was hoping to glean an accurate representation of the GM mindset; I just assumed that like "var a;", users would expect "int a;" to make a script-local, and would never even consider modifying object-locals like "x" and "y". But then again, I can see it becoming confusing when they want to identify that a regular local they are using as that particular type.

The thing is, when they discover that ENIGMA has types, will they treat them exactly like var, or will they assume they can just la-dee-dah define object-locals with it?

How many will actually go to the manual to see how they work? Assuming I ever even write a manual. I'm lazy with easy tasks that take time. If they all went to the manual, I think "local int" would be perfect for object-locals. Since that probably won't happen, I need to know the mindset and minimize damage when they misuse it.
Title: Re: Another choice.
Post by: Micah on March 13, 2010, 12:26:43 PM
"The whole `var` class thing doesn't work the same way as GM's `var` keyword."
Care to back this up with examples?
The `var` keyword in GM is not analogous to a type name in C++.

In GM, the scope of a variable is decided by the keyword, or lack thereof, that you use. Nothing means object scope, `var` means script-/event-local scope. `globalvar` means global scope.

In C++, the scope of a variable is decided by where it is declared. In a class definition is object scope, inside function or control-flow {}s is block-local scope, and outside functions is global scope. The keyword you use defines the type.
Title: Re: Another choice.
Post by: Game_boy on March 13, 2010, 03:33:55 PM
@Josh

I think GM users would expect (certainly I would) anything to be object-scope unless it has var or globalvar in it. So 'int a' being object-scope. 'int a' also changing the scope as well as type would not be expected. I didn't know, before reading these posts, that var was a type itself nor that 'int a' in C/C++ would be local-scope. That's the initial mindset of a GM user.

But then, no one would use 'int' in Enigma if they didn't know what it was for. So as long as it's clear in the manual / wherever they learn that Enigma allows you to use "int" that it also changes scope unless you say local int or whatever, you don't have to be overly concerned.

Basically, anything a GM user could currently write should behave 100% like GM for better or worse. Anything Enigma does extra can behave how you want it to as long as you make it clear in the place where they'll learn you can.

Title: Re: Another choice.
Post by: Josh @ Dreamland on March 13, 2010, 04:35:54 PM
"In GM, the scope of a variable is decided by the keyword... In C++, the scope of a variable is decided by where it is declared"
Are you suggesting that in GM, where it is declared has nothing to do with it? Certainly you aren't, since you said "`var` means script-/event-local scope" and didn't seem to think that was decided at random...

Let's look at JavaScript.

function script0()
{
  var a; // "a" is local to script0()
  b = 0; // b is local to the current context, such as a web page
}

This is probably a better example of var scoping, with var working just like a class in C++, and behavior of undeclared variables mirroring that of GM. JavaScript, of course, is classless, so you won't see that done with any type other than var. Does that make var JS and GML's only type, or just another keyword? The behavior is the same; that makes it a matter of opinion.

Game_boy:
I understand. In fact, that's a really good point. Give it a vote. ;)

Title: Re: Another choice.
Post by: notachair on March 13, 2010, 06:22:16 PM
Josh, what's your goal for ENIGMA when it comes to GM interoperability? Effortless conversion to ENIGMA, or requiring changes during conversion that would be more intuitive?

But then, you are throwing this choice out to us...
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 13, 2010, 07:07:32 PM
The changes that I've made polls for so far (or may yet make polls for) don't affect GM interoperability. However, I intend for ENIGMA-GM communication to be one-way. I'm kind of glad that most users are going with my take on this issue, because part of the philosophy behind these changes is for ENIGMA to be able to see off its users with a smile instead of a sore ass.

Game_boy admits to not thinking of "var" being a type; he never expected to see anything other than var in GM, I guess. I was always on the lookout for something other than "var," I didn't think a keyword very useful that just says something is local. And when I heard the word "declaration" attached to it, and started catching wind of more powerful languages than GM, I just kind of assumed (correctly) that they would parallel this structure with less ambiguous types.

Game_boy: when you think about "var" as a class rather than simply a keyword, does it seem more logical? Or less?

Right now, GM is breeding a wave of people who don't understand that == is an operator. I can't allow ENIGMA to be like that. This is what will happen as a result:

The ENIGMA default configuration when creating a new file is currently as follows:
Strings:GM Style ("\")
Comparison:= or ==
Operator ++:Enabled
struct {}:Treat } as };

When importing a GM file, a separate set of default settings will be used, currently differing by one setting:
Strings:GM Style ("\")
Comparison:= or ==
Operator ++:Disabled
struct {}:Treat } as }; (inapplicable)

The settings for either can be modified at any time, and will be saved with the EGM file.

Now, with that in mind, what I meant by "see[ing] off its users with a smile" is this: As users become used to ENIGMA, they'll start looking through its new features. The most obvious features will likely be the first they use, take the for loop example from before. What they once knew in GML will be made easier (and much, much faster) in EDL:
Code: [Select]
/* Old: */
var i;
for (i=0; i<10; i+=1)
  draw_circle(x-16+random(32),y-16+random(32),random(5)+5,1);

/* New: */
for (int i=0; i<10; i+=1)
  draw_circle(x-16+random(32),y-16+random(32),random(5)+5,1);

Now users can legitimately declare their variables inside a for loop (with better scoping) and can take advantage of a type literally hundreds of times faster than what they are used to.

This will be revolutionary for all of ten uses, and they'll be accustomed to it like everyone else. It'll once more be no big deal.

Then they'll find other nice things:

Code: [Select]
/* Before: */
var a;
a = ds_list_create();

/* After: */
list a;

Or object-local:
Code: [Select]
/* Before: */
a = ds_list_create();

/* After: */
local list a;


And then, as they get used to that:
Code: [Select]
local list<int> a;

Slowly, their default options list will get closer to mine:
Strings:C++ Style ("\\")
Comparison:==
Operator ++:Enabled
struct {}:ISO

At that point, ENIGMA will, like GM, cease being a challenge. Maybe cease to offer what they feel they need. Also like in GM, maybe they'll start developing for the project; DLLs or, since this is compiled, just a new library. And if ENIGMA still isn't enough for them anymore, they can move on, knowing a decent amount of a pretty good language.
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 14, 2010, 06:23:26 AM
GM strings are already "\\"

Local becomes necessary when you think in C++ terms

In C++ if you declare a variable inside a function (Gm users please think of a C++ function as a GML script), only that function will be able to see it.
Now, since we are declaring a variable inside an event, only that event should be able to use it. If you want an object-wise variable, you should use
a keyword, like the one you use global in a GM event to declare a global variable.

However, events are something that really confused me when I started C++. Even in GM, you should just use the create and the step event, since
all the others are easily implementable and just mess up the code so you have to go back and forth to understand the simplest piece of code.

For example, all the keyboard and mouse events can recreated in the step event using a single line of code each.

Everybody, if you want to add a C++ feature, it's better not add it in a GM style.
Title: Re: Another choice.
Post by: score_under on March 14, 2010, 07:02:31 AM
it's better not add it in a GM style.
Which, IIRC, is the use of some badly-made GEX, and the "feature" being added is usually a little get_string box which accepts a single password to set lives to 200 or something, and does a show_message on both correct and incorrect attempts. And then people post in the topic saying "Wow, this is amazing" and "How do I install GEX?".
Title: Re: Another choice.
Post by: Game_boy on March 14, 2010, 08:51:22 AM
"Game_boy: when you think about "var" as a class rather than simply a keyword, does it seem more logical? Or less?"

*head explodes*

So var and int are like GM objects now? Is that what you mean? And they can have their own variables?

If so, I can see why 'int, var int' makes no sense. But why do int and var being GM objects mean that their scope is in the script only?

I'm confused by the terminology here. I'm not really sure what you mean by 'class', 'keyword', 'type' or what 'local' would be (keyword? class?).

Title: Re: Another choice.
Post by: Josh @ Dreamland on March 14, 2010, 11:05:04 AM
Game_boy:

It would really blow your mind at this point if I described the difference between objects in GM and objects in C++, but basically the difference is that in C++, it's legal to say "object0 a;" instead of instance_create(object0). The implications of doing this would be difficult to explain here, so for now, disregard that.


I guess I'll start by elaborating on terms.
Type:
  Most decent languages have some sort of data type. All languages work with data types internally. Even the really ugly one my favorite critics were just about to cite. These tell the compiler and, ultimately, the computer, what the program will be doing with a certain block of memory. Types can have different sizes and different precision, and allow different features. For example, those coming from Game Maker unknowingly work with two types: "double" (called "real") and "string" (called the same). Both of these are represented by the type "var."

Class:
  In Object-Oriented Programming, a class is a method of communicating to the compiler how a chunk of memory is laid out. "Structure," or "struct," is synonymous with "class" for our purposes. They can be used to lump a bunch of variables in one place, and are great for working with arrays of multiple values without going multidimensional. For example, you could store a direction and a magnitude to represent a vector in memory. In C++, that would look like this:
Code: [Select]
struct vector
{
  double direction;
  double magnitude;
}

You could then declare and manipulate an array of them like this:
Code: [Select]
  vector a[100];
  a[0].magnitude = 0;
  a[0].direction = 0;
Pretty convenient, huh?

Keyword:
We'll define keyword for now as words like "if" and "while," and in option 1 of this poll, "local." These keywords don't represent anything: think about it. They are used entirely to tell the compiler how to treat code (note that a type name tells the *computer* as well as the compiler how to treat something physical, namely memory). "If" tells the compiler to make the computer execute the next command conditionally. "While" tells it to keep executing it conditionally. "Local" tells ENIGMA, in one word, "don't declare this HERE; move it to the struct declaration."

By those definitions, "local" as denoted by option 1 would be a keyword, as described in that section above. "Var," however, remains ambiguous: it could do one of two things:
1) Tell Game Maker that this variable should be treated local to the script, as a keyword (Wow! that's what var does!)
2) Tell Game Maker that the following name should be declared in this scope as a block of memory to be treated as either a string or real (Wow! that's what var does too!)

So when we start adding more types, it's a matter of which is more convenient to assume.

Prototype Releases 1-3 all have var declared as a class. This makes it integrate flawlessly with C++; the behavior is very, very similar to GM. But it's not identical:

For years, the community has complained (or at least, the ones that are more aware of other languages) that Game Maker handles scopes badly. These are the people that would choose Option 1 in a pinch. However, there *are* differences in behavior, as outlined here:

Code: [Select]
if (true)
{
  var a;
  a = 3.14;
}
show_message(string(a));

The above code would do two different things in ENIGMA and GM6. I have no information on GM7 and 8.
In ENIGMA, it would print 0.
In Game Maker 6, it would print 3.14.

The reason for this is ambiguous.
1) Mark didn't think it through well enough and did a bad job implementing scopes. (This would not be a first, sorry folks).
2) Mark intended for "var" only to signify that the variable was local to the code.

Option two looks *really* attractive to the common onlooker now (A certain someone was about to start typing a heated response).
However, here's behavioral evidence for option 1 (assume that "a" is declared in the create event as "a = 0" and that this code is run for one step prior):

Code: [Select]
show_message(string(a));
a = 3.14;
var a;
a = 2;

This will print 3.14 again, meaning that Mark's parser is only aware of the point in time that the variable was declared. So, what was it?
1) Did he forgot/feel too lazy to go back over the code making "a" local throughout?
2) Did he intend for the keyword to not be retroactive? That makes it behave more like a declaration than a keyword...
3) Did he, again, really mean for it to be used as a declarator (type name) but fail to implement scopes?


Hope this helps.
Title: Re: Another choice.
Post by: retep998 on March 14, 2010, 11:11:12 AM
This is the behavior of gm:

Quote
1) Tell Game Maker that this variable should be treated local to the script, as a keyword (Wow! that's what var does!)
2) Mark intended for "var" only to signify that the variable was local to the code.
2) Did he intend for the keyword to not be retroactive? That makes it behave more like a declaration than a keyword...
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 14, 2010, 11:15:05 AM
For the first pair, 1 and 2 were both defining var's behavior.
The second and third, we can't make that assumption...

The third option specifically seems contradictory to the philosophy of a keyword. Defining where the var is coming from should be retro-active. You mentioned function declarations in Python; same principle. Most people put their vars at the top. Most Python people put their imports at the top.

I believe the manual uses the word "declare" for "var," which is basically all the proof I need that Mark intended it to be like a real language... Think JavaScript scoping, again. I'll look for the page in question.

Essentially,
Quote
Josh @ Dreamland:
he whole dilemma here is that we don't know what Mark was thinking because he implemented it badly
retep998:
WHO CARES WHAT HE WAS THINKING????
retep998:
I LIKE IT THAT WAY
retep998:
AND IT WORKS
Josh @ Dreamland:
well, if we're going to turn this into a huge genetic fallacy we may as well have our facts straight
Josh @ Dreamland:
haha.
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 14, 2010, 11:21:45 AM
No, let's try to explain what a type is.

A type is the type of the variable you want to declare. This is how you use it in C++

char is the type used to declare a character variable
char a = 'a';

int is the type used to declare an integer variable
int a = 1;

double is the type used to declare a double precision floating point variable
double a = 3,14;

var is an all comprehensive type: you can use it to declare any type of variable you want, it makes your life simpler,
but it performs bad
var a = 'a';
var b = 1;
var c = 3,14;

In GM you can declare a variable without defining its type.
b = 1;
In C++, you NEED to declare the type, or it won't work.
Of course Enigma will make it work anyway, but it will perform less faster.

In C++, and in any real coding language, when you declare a variable, that variable will only be usable inside the block of code you declare it in.
So, in GML you can do this
for ( i=0; i<10; i+=1)
{
a=i;
}
a=3;

In C++ the variable "a" will be deallocated after the last }, so if you wanted to use "a" outside the block, you have to declare it outside
int a;
for (int i=0; i<10; i++)
{
a=i;
}
a=3;

So, if you make any int variable work at an object level, instead of deallocating it, that will break an important C++ feature.
Please people, vote for the first option, your GML programs will work anyway, but you won't break our C++ codes.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 14, 2010, 11:23:23 AM
My thoughts ^

Breaks this v
Code: [Select]
if (true)
{
  var a;
  a = 3.14;
}
show_message(string(a));

And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."
Title: Re: Another choice.
Post by: Game_boy on March 14, 2010, 12:19:31 PM
OK. I think I understand.

My main principle is that whatever Josh does shouldn't break a single line of GM, not even in odd cases no one uses. So:

"a" should work exactly like GM
"var a" should work exactly like GM
"globalvar a" should work exactly like GM
Everything else should work like "local int, int" because that's how C++ should work.

And the manual/website should go out of its way to point that out, with examples, because it'll be the first Enigma-specific feature a GM user adopts. Whereas the C++ users will get used more easily to the idea that GM is backwards with var.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 14, 2010, 12:44:11 PM
Game_boy: Should make that a priority, actually.

All of those will. Even global var, which will be done like so:
#define globalvar global var
...heh.
Title: Re: Another choice.
Post by: polygone on March 14, 2010, 01:49:57 PM
My thoughts ^

Breaks this v
Code: [Select]
if (true)
{
  var a;
  a = 3.14;
}
show_message(string(a));

And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."
Whoever uses that code in gml is retarded, who cares how gml handles it, it shouldn't be written.
Title: Re: Another choice.
Post by: Game_boy on March 15, 2010, 12:33:13 PM
Quote
Whoever uses that code in gml is retarded, who cares how gml handles it, it shouldn't be written.

Slippery slope to all GM code being retarded, C++ is much better. Which may be true, but that's not the point.

Everything GM does but Enigma doesn't will make a the number of people who switch smaller. No matter how justified the reason for the incompatibility is.

Title: Re: Another choice.
Post by: polygone on March 15, 2010, 02:38:03 PM
I would be highly surprised if there is one single user using that code that will switch from GM to Enigma, it's irrelevant. The reasons for this:

1) Most users only declare var at the top of a script.
2) Most people with the knowledge to use var would not make such a mistake.
3) I would also expect an average GM user switching to Enigma to be more intelligent.

Quote
Slippery slope to all GM code being retarded
That above code is illogical it shouldn't even be used in GM, the same is not said for all gml.
Title: Re: Another choice.
Post by: IsmAvatar on March 15, 2010, 06:00:44 PM
Doesn't really matter if it should or shouldn't be used - someone uses it in some game, and they expect to convert said game directly to C++ with Enigma, which is a fairly reasonable expectation. Suppose the following:

Create event: i = 10 //maybe this represents lives
Some other event:
Code: [Select]
if (hits > 10) { //every 10 hits, they lose all their weapons
 var i;
 for (i = 0; i < 5; i += 1) { weapon[i] = 0; }
}
...
i -= 1; //we're reducing the number of lives this player has



Also, for amusement purposes, this is my 69th post...


Title: Re: Another choice.
Post by: polygone on March 15, 2010, 06:51:37 PM
Yes but I bet noone in the history of moving from GM to Enigma will ever use code in that format for the reasons mentioned above. I may be wrong perhaps one person may at some point may use it but it's really not even worth considering for the off change of slightly annoying that one person.
Title: Re: Another choice.
Post by: RetroX on March 15, 2010, 08:48:42 PM
Why not use ++ and -- instead of +=1 and -=1?
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 15, 2010, 08:59:34 PM
Didn't want to bring up that difference in example code of another difference.
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 16, 2010, 04:53:00 AM
Doesn't really matter if it should or shouldn't be used - someone uses it in some game, and they expect to convert said game directly to C++ with Enigma, which is a fairly reasonable expectation.
Directly converting GML to C++ is impossible. They should not expect it.

IMHO we are just trying to make C++ and GML live togheter.
Title: Re: Another choice.
Post by: Micah on March 16, 2010, 08:49:45 AM
How so? You can completely replicate every tiny bit of functionality of GML in C++. Even execute_string, although that would require packaging a C compiler with every program and would be stupid.
Title: Re: Another choice.
Post by: polygone on March 16, 2010, 10:49:41 AM
I completely agree with keeping everything compatible with gml but something like that is not a normal scenario, it's irrelevant, noone uses it and noone is supposed to use it.

It's like actively making Enigma return the previous script return value for a non-returning script like GM does. I'm not sure whether it does or not but actively making it do so would be pointless and a hindrance if that functionality is not desired in Enigma. Though it is a feature in GM and someone may perhaps use it stupidly the scenario is just not worth considering.

Will Enigma also include any bugs within GM so it is compatible?
Title: Re: Another choice.
Post by: Game_boy on March 16, 2010, 11:20:30 AM
I completely agree with keeping everything compatible with gml but something like that is not a normal scenario, it's irrelevant, noone uses it and noone is supposed to use it.

It's like actively making Enigma return the previous script return value for a non-returning script like GM does. I'm not sure whether it does or not but actively making it do so would be pointless and a hindrance if that functionality is not desired in Enigma. Though it is a feature in GM and someone may perhaps use it stupidly the scenario is just not worth considering.

Will Enigma also include any bugs within GM so it is compatible?

@last part - If they affect visible functionality in any way, I hope so.

If actively returning a script value changed any behaviour I'd expect that too. But I doubt it does, even in the worst-written GM code, so it can be removed.

I know it's not a 'normal' scenario, but which is easier - convincing all possible GM -> Enigma converts to code properly and recode all their old stuff properly, or just make Enigma work with it?
Title: Re: Another choice.
Post by: polygone on March 16, 2010, 11:52:29 AM
Replicating bugs would be retarded. I believe all the bugs left in GM7 occur in highly rare scenarios and actually replicating some of them (especially the ones regarding instance_deactivation) it would be an absolute nightmare to the verge of impossible to replicate them.

The only real incompatibilities would be that any written workarounds for the bugs might not work and to replicate bugs for the program so any written workarounds are still compatible is just about one of the most retarded concepts I can possibly conceive. :/

Quote
I know it's not a 'normal' scenario, but which is easier - convincing all possible GM -> Enigma converts to code properly and recode all their old stuff properly, or just make Enigma work with it?
You don't need to convince anyone as it's not going to affect anyone.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 16, 2010, 12:33:34 PM
Quote
Directly converting GML to C++ is impossible. They should not expect it.

IMHO we are just trying to make C++ and GML live togheter.

Call me a philosopher, but I'm not sure what you mean by "impossible" or "directly converting." ENIGMA's purpose is to convert GML to C++. I started the project because I noticed enough similarities in syntax that doing so would be relatively easy, in fact. Some things will obviously never work in plain C++, the first of those being with() {}.

@miky as well: Including a C++ compiler is certainly unnecessary for implementing execute_string() for backwards compatibility with GM, and is not really necessary for interpreting most C++ features, either. Yes, there are projects that can interpret C++, but I'm reasonably certain such projects are bloody massive. A smaller alternative is to do a bit more parsing and pass strings to Google V8 (A damn nice JavaScript JIT compiler). With V8, I can link in globals at runtime, and write a variable accessor class called Cthis, which will be appended before all locals (or all variables in general). So, the user's code will be for example, x = 0; y = 0;. It'll be passed to V8 as Cthis.x = 0; Cthis.y = 0;. V8 will call Cthis's accessor for "x," which is a C++ function I register. It'll behave just like GM's interpreter, only, sad as it may be, probably faster. The work for me would be so small as to be laughable.

a = 0;
var a;
a = 3;

Would work just like GM, because after they declare var, I just remove it and stop adding Cthis before the variable. This can be done entirely linearly, and without buffer resize as I can just space out "var" (as in, replace it with "   ").

The only things that may require a new buffer is adding semicolons to the code, which isn't always necessary in JavaScript, either; only when no newline is given. Hell, I might even be able to edit V8 to not require newline either, if I really wanted. Though, that's quite unlikely.

Did I mention it's JIT compiled?


As for scripts returning the value of the last-called script... Heh, that's kind of neat, I was unaware it did that; that's usually a behavior defined in interpreted language. I can't replicate that, as far as I know, simply by not providing a return value in lieu of the user's... I could if the last reference were left in EAX, which is unlikely.

I don't think I'll be replicating any useless GM bugs.
Title: Re: Another choice.
Post by: Micah on March 16, 2010, 12:44:25 PM
So...you're planning to compile to C++ and JavaScript for the same executable if they use `execute_string`? Really?
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 16, 2010, 01:13:42 PM
Would be too big and slow to include GCC with everything. I'll need to write a fifty-some line parser to make GML look like JavaScript, then presto.
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 16, 2010, 02:14:18 PM
Quote
Directly converting GML to C++ is impossible. They should not expect it.

IMHO we are just trying to make C++ and GML live togheter.

Call me a philosopher, but I'm not sure what you mean by "impossible" or "directly converting." ENIGMA's purpose is to convert GML to C++. I started the project because I noticed enough similarities in syntax that doing so would be relatively easy, in fact. Some things will obviously never work in plain C++, the first of those being with() {}.
By converting I mean translating, you are not going to convert GML into C++ like you convert English into French.
The conversion only happens under the table, but the user won't see their GML turned into C++.

Users will not use Enigma to convert their GML to C++, they'll use it so in order to take advantage of GML and C++.
No one wants to get rid of GML here.

Also, breaking one of the most idiotic features of GML in order to save one of the smartest features of C++ seems a good trade to me.
Title: Re: Another choice.
Post by: Micah on March 16, 2010, 04:45:31 PM
You'd think that, but Josh is actually hard-coding his parser around the syntactical similarities between GML and C++. So yes, he is converting GML into C++ like you convert English into French.

@Josh: Having two different runners for the same scripting language running in the same engine is stupid on many levels.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 16, 2010, 05:41:32 PM
@miky
Oh, you're right. I should just include the GCC with it like you first said; wouldn't want to risk the project looking "stupid" to someone.

Also, I'd really like to see an English->French translator hard coded over the two languages' twelve similarities.

@The 11th plague of Egypt
It's actually probable that the majority of users will try their best to avoid LGM, doing major development in Game Maker then bitching when they've used something ENIGMA doesn't support yet a month later when they're ready to compile.

"Also, breaking one of the most idiotic features of GML in order to save one of the smartest features of C++ seems a good trade to me."
Now this, I like.
Title: Re: Another choice.
Post by: RetroX on March 16, 2010, 06:51:20 PM
Also, I'd really like to see an English->French translator hard coded over the two languages' twelve similarities.
You mean not like Google translator!?!?

Where one person can suggest a translation and it becomes completely inaccurate!?
Title: Re: Another choice.
Post by: Game_boy on March 17, 2010, 12:25:41 PM
Wrong thread, sorry.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 17, 2010, 06:10:50 PM
If it's of any consolation, I replied to you in the wrong thread.
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 18, 2010, 09:18:14 AM
Any news about the project?
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 18, 2010, 09:28:47 AM
Posted about having to write an essay elsewhere. I'm nearly done.
Ism's getting Java to pass resources to DLLs and the like.
Title: Re: Another choice.
Post by: The 11th plague of Egypt on March 21, 2010, 12:40:15 PM
I'm curious. What language is the with() statement taken from? I use it to work with all the instances of a given object, I'm not sure that's good coding practice, but hell it's useful.
Title: Re: Another choice.
Post by: retep998 on March 21, 2010, 03:06:38 PM
I use it to work with all the instances of a given object, I'm not sure that's good coding practice, but hell it's useful.
It's definitely good coding practice in gm.
In most languages, if you want to iterate through instances you have to create your own lists of every instance.
Title: Re: Another choice.
Post by: Josh @ Dreamland on March 21, 2010, 06:41:30 PM
Yeah. I believe with() is Delphi, but I'm not certain. It'd make sense if it was. You can see it in JavaScript as well.