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

Announcements / Re: Another choice.
« on: March 14, 2010, 11:05:04 AM »

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.
  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."

  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?

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;

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]
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.

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)

/* New: */
for (int i=0; i<10; i+=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 ("\\")
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.

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.

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

Announcements / Re: Another choice.
« on: March 13, 2010, 10:09:12 AM »
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.

Announcements / Re: Another choice.
« on: March 13, 2010, 12:25:48 AM »
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

Announcements / Re: Another choice.
« on: March 12, 2010, 09:46:43 PM »

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.

Announcements / Re: Another choice.
« on: March 12, 2010, 07:30:42 PM »
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?

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. >_>

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.

Some languages are fuck ugly and require too much typing AND too many shift presses. >_<

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.

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.

Announcements / Re: Another choice.
« on: March 12, 2010, 11:17:19 AM »

Yep. Hence the poll.

I'd rather not distinguish between events, though.

Announcements / Re: Another choice.
« on: March 12, 2010, 10:51:08 AM »
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.


for (var int i = 0; i < 10; i++)
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.

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.

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

Announcements / Re: I hate the last ten days before a release.
« on: March 12, 2010, 09:35:02 AM »
The 11th plague of Egypt, retep998--
When R4 is compiling again, I'll match the list of functions from the parser against the list of functions that need done, and anyone who can code can look for a function or set of functions they feel they are capable of implementing. If you're not good with community projects, I can look them over and implement them for you.

Fetching the list of unfinished functions after that will be as simple as matching the list with the tree again.

Those who do have experience with SVN, I can probably give you permissions to commit code.