Show Posts

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.


Messages - Josh @ Dreamland

2281
Announcements / Re: Quick Poll
« on: March 14, 2010, 03:39:08 PM »
Like I said, C++ people make this particular mistake a lot. It happens, and it could likely piss people off.

2282
Announcements / Re: Another choice.
« 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.

2283
Announcements / Re: Another choice.
« 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."

2284
Announcements / Re: Another choice.
« 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.

2285
Announcements / Re: Another choice.
« 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.

2286
Announcements / Re: Another choice.
« 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.

2287
Announcements / Re: Another choice.
« 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. ;)


2288
Announcements / Re: Another choice.
« 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.

2289
Announcements / Re: Another choice.
« 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

2290
Announcements / Re: Another choice.
« 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.

2291
Announcements / Re: Another choice.
« 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?

2292
Website Bugs / Re: Too much forum crashing
« on: March 12, 2010, 03:47:57 PM »
Yeah. Good thing I'm not paying money for this server or anything, or that might actually piss me off. >_>

2293
Announcements / Re: Another choice.
« 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. >_<

2294
Announcements / Re: Another choice.
« 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.

2295
Announcements / Re: Another choice.
« 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.