Poll
Question: How should an object-local and a script-local integer be defined?
local int, int - 12 (63.2%)
int, var int - 6 (31.6%)
localv int, int - 0 (0%)
Special Event - 1 (5.3%)
Total Members Voted: 19

Pages: « 1 2 3 4 5 »
  Print  
Author Topic: Another choice.  (Read 9791 times)
Offline (Unknown gender) Grundoko
Reply #15 Posted on: March 12, 2010, 05:31:57 PM
Member
Joined: Sep 2008
Posts: 22

View Profile Email
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.
Logged
Offline (Unknown gender) Micah
Reply #16 Posted on: March 12, 2010, 05:43:31 PM

Resident Troll
Joined: May 2008
Posts: 129

View Profile
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.
Logged
Offline (Male) Josh @ Dreamland
Reply #17 Posted on: March 12, 2010, 07:30:42 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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?
« Last Edit: March 12, 2010, 07:40:02 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) The 11th plague of Egypt
Reply #18 Posted on: March 12, 2010, 09:24:02 PM
Member
Joined: Dec 2009
Posts: 284

View Profile
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!
« Last Edit: March 12, 2010, 09:25:40 PM by The 11th plague of Egypt » Logged
Offline (Unknown gender) Grundoko
Reply #19 Posted on: March 12, 2010, 09:27:20 PM
Member
Joined: Sep 2008
Posts: 22

View Profile Email
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.
Logged
Offline (Male) Josh @ Dreamland
Reply #20 Posted on: March 12, 2010, 09:46:43 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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.
« Last Edit: March 12, 2010, 09:49:55 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) The 11th plague of Egypt
Reply #21 Posted on: March 13, 2010, 12:22:42 AM
Member
Joined: Dec 2009
Posts: 284

View Profile
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?
Logged
Offline (Male) Josh @ Dreamland
Reply #22 Posted on: March 13, 2010, 12:25:48 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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
« Last Edit: March 13, 2010, 12:33:13 AM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) Game_boy
Reply #23 Posted on: March 13, 2010, 06:16:00 AM
Member
Joined: Apr 2008
Posts: 228

View Profile
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.


« Last Edit: March 13, 2010, 06:20:37 AM by Game_boy » Logged
Offline (Male) Josh @ Dreamland
Reply #24 Posted on: March 13, 2010, 10:09:12 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) Micah
Reply #25 Posted on: March 13, 2010, 12:26:43 PM

Resident Troll
Joined: May 2008
Posts: 129

View Profile
"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.
Logged
Offline (Unknown gender) Game_boy
Reply #26 Posted on: March 13, 2010, 03:33:55 PM
Member
Joined: Apr 2008
Posts: 228

View Profile
@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.

Logged
Offline (Male) Josh @ Dreamland
Reply #27 Posted on: March 13, 2010, 04:35:54 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
"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. ;)

« Last Edit: March 13, 2010, 06:22:52 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) notachair
Reply #28 Posted on: March 13, 2010, 06:22:16 PM

Definitely not a chair
Contributor
Joined: Feb 2008
Posts: 299

View Profile
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...
Logged
Offline (Male) Josh @ Dreamland
Reply #29 Posted on: March 13, 2010, 07:07:32 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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.
« Last Edit: March 13, 2010, 07:12:40 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Pages: « 1 2 3 4 5 »
  Print