ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on August 21, 2009, 10:49:19 pm

Title: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 21, 2009, 10:49:19 pm
In fear of some readers being more pious than others, I'd like to clear some things up.
In other words, stop reading at the first big caption.


In summary, Rusky's trying to get me to use a token tree parser by starting work on one as a proof of concept. I assume he will continue to develop it from time to time, until it actually competes with the one I wrote as a competent proof of concept or until I'm all done. Whichever comes first.

I met it with some pretty harsh skepticism. But it's not because I feel token trees are bad.

A tree is a very useful tool. It will allow you to easily skip over large chunks of data to weed out only what you need. They are used in probably more than 90% of modern parsers. I'm not looking up an actual statistic, sorry math fans.

However, I don't feel they're appropriate for the formatter-type parser.

The entire point of the formatter parser is to add semicolons and weed out variable names by declaration. It doesn't really call for a tree, in my opinion.

Here's a sample code:
Code: [Select]
a=0b=1
That code is valid GML. So now, how do we deal with it?

Those who are weak of heart should stop reading now.

Token tree method:
The code is read into memory in a structure called a tree. A representation is depicted below:
Code: [Select]
=
├─a
└─0
=
├─b
└─1
To save size, a symbol table is used. It's basically a list of variable names/other things that appear in the code. The table makes comparison of strings from the time of its completion onward operate in constant time by comparing them as an index, not byte for byte. (Means it's efficient)
The code is then rebuilt with all proper punctuation.

My method:
The code undergoes a (somewhat) organized series of stream-like modification.

First, the code is reread into its current buffer free of comments and excess whitespace. This won't affect the code above.
Next, a second block of memory is allocated the size of the first. The first is named code, the second synt.

They look like this:
Code: [Select]
a=0b=1
Code: [Select]
n=0n=0
Next, the blocks are reallocated at twice the size for all upcoming changes. A pass is made that keeps a look out for patterns of tokens. You'll notice above in the syntax string that variable names have been replaced with n, while numbers have been replaced with 0. This is so only one check has to be made to tell what any given character in the code is a part of.

Notice the "0n". A pass is made to look out for things like that.


More complicated code
Trees are usually, or at least very often, done by using a parser generator of sort, which takes a grammar file that can be easily edited. It organizes the process by giving what I've seen to be a regex-like interface for manipulating what patterns of tokens the parser looks for.

My method's basically a hard-coded version of that. I specify what tokens require a semicolon between them in a separate function, instead of using a generator that reads that info from a text file.

In the code
Code: [Select]
if 0a=10else b=10 the token tree would do just what it did above, using if as a root of another sublevel, then putting the next = token inside it. It would then look up the rules for what's inside if to see what it puts next.

Mine does this, instead:   semis->push(')','s'); write_symbol('(');
Which does nothing but insert a left parenthesis and tell it, next time it needs to insert a semicolon, use ')' instead. This is still done in that pass.
(If I were using only find and replace like I said I could, I'd replace "if(.*);" with "if\($0\)"  )

Rusky said he didn't add for loops to his proof of concept. Wouldn't make much sense for me to do so, because all I had to do to implement for() was push two semicolons and an end parenthesis onto the stack, like I did above.


Partitioning my parser
Rusky's other complaint is that my parser is divided into sections. One's responsible for syntax check, one's responsible for C definitions, one's responsible for adding semicolons/other GM-C replacements. I don't really see what there's to criticize about that, but here's a nice reason to do so...

The formatter parser has more passes and gets more attention than both the syntax check and C parsers combined. However... They're what Rusky will call a disaster, and what I'll tell you are faster than greased lightning.

Instead of lexing, they keep a couple variables handy (integers, actually) that I like to refer to as registers. (I may in fact devote a register to each of them, as they are so few.) They let the CFile parser identify what it's going through now. Each C++ key word has an ID. (not dissimilar to the symbol table of the token tree).
In addition to this ID, a second variable is kept indicating mode. I keep track of these mentally, because that's how I goddamn roll. (Ask score_under). That's the part that really makes Rusky cringe; I rarely comment, and I don't document, because I just memorize all the values, or review my thinking to get back to them.

This ID, however, is the difference between "using" and "using namespace", just for example.

( Typedef is handled differently. Typedef's value is 128 or some crap, so I can just OR whatever I have by it to indicate that I'm typedef'ing it. (C and C++ will let you totally whore typedef) )

The most complicated thing to deal with is what may require a stack, and that's pointers to arrays to pointers....of functions.


Now, here's the kicker: I use a tree to store scope data. Le gasp, right? Each variable is stored the same way. An integer can have members if I really want to. And I can tell you just from using them there how beautiful a system they can be. But knowing that, I still say a pair of aligned strings is the way to go with a formatter.


Benefits/Downfalls
Okay, this is the single longest thing I've ever typed up. If you did any more than just skim it, I feel sorry for you.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 22, 2009, 09:52:35 am
I comment my code anyways, but I normally don't comment it much.  Normally, I just put comments at the tops of different sections so I know what they do without looking in the code (even though I also make variable names and function names long and precise, which makes comments kind of pointless, but whatever).

I normally don't comment code like:
Code: [Select]
// if yspeed is greater than 0
if (yspeed>0)

Because that's obviously pointless.

Anyways, to be entirely honest, I never really understood how exactly your parser worked until now, and to be honest, it sounds like an efficient method that I might have actually thought of myself if I spent enough time on it.  Unlike other people, I know when my code could be done better, and I normally don't settle for anything less.  If I know I can do better, then I won't settle for a "good" method.

Probably why I don't get many projects done, lol.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 22, 2009, 10:09:02 am
That's why I've redone var at least 100 times.
I'll be modifying std::string next; have to make sure it can interface with var flawlessly. And boy do I have a plan for that.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 22, 2009, 10:12:29 am
I even modify my code to be consistent if I change one thing.  I used to use i+=1, which is okay, but once I changed it to i++ which was faster, I had to change all my previous scripts.  Same thing goes for ==true and ==false.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 22, 2009, 12:32:29 pm
Optimizing compiler should take care of all that, anyway.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 22, 2009, 12:37:46 pm
Yeah, but I still do it, anyways.  And interpreted languages like PHP aren't optimized.  In PHP, I even unset variables after I used them to make code run faster.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Micah on August 22, 2009, 12:49:07 pm
I even modify my code to be consistent if I change one thing.  I used to use i+=1, which is okay, but once I changed it to i++ which was faster, I had to change all my previous scripts.
Compiler optimizations aside, ++i is faster than i++, because i++ has to create a copy of i to evaluate to and increment the real one, while ++i just increments it.

Although I'll bet it doesn't matter with a decent compiler.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 22, 2009, 01:14:02 pm
The tree didn't leave out else. The printing code at the end left out else, and it took a single line to put it in: if (operands.size() == 3) { printf("else{"); operands[3]->print(); putchar('}'); }
Your complaints about unary are completely pointless. "Unless begged"? More like "unless specified". You use the same character, '-', for both binary and unary minus. All you have to do is add another operator.
Your special find-replace crap is a lot slower than an LR parser. Having to search through the entire string again to find declarations is dumb when you could just build a table of declarations as you go.
a = b ++ c is a problem in any parser, not just mine.
My parser is divided into phases. Each phase uses the information from the previous one, so it doesn't have to do any extra work, and it doesn't have to be divided into different programs either.

You say yours is faster, but is it more memory efficient? You have to store at least twice the size of the program. In programs that have a lot of uses of the same name, that wastes a lot of space. In programs that use identifiers like begin/end, if/else, anything like that, you waste space. Also, because you're using a tree for scope and a few stacks for parentheses, etc. you waste even more space- you're basically duplicating information.

The way you described a generated parser is wrong. You only use regular expressions for the lexer, and you don't even have to do that- you could write the lexer yourself if you wanted. All the lexer needs to do is separate the program into a list of tokens and send them to the parser. Then the parser uses a grammar, which looks something like this:
Code: [Select]
expr:
    NUMBER
  | NAME
  | '-' expr %prec UMINUS
  | expr '+' expr
  | expr '-' expr
  | expr '*' expr
  | expr '/' expr
  | '(' expr ')'
  ;
That tells the parser that an expression can be a number, a name, a negated expression (recursive definitions are awesome), an expression plus an expression, etc. The operators +, -, *, / and UMINUS have their precedences defined earlier. The %prec UMINUS tells the generator that the - in that production is the unary one (so it has higher precedence).
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: luiscubal on August 22, 2009, 04:24:32 pm
On Antlr, your snippet will cause a problem because it's left-recursive. I don't know about other generators.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 22, 2009, 08:13:55 pm
No, in antlr you're supposed to be left-recursive. Unless antlr sucks worse than I thought and it doesn't do LR parsers.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 22, 2009, 08:15:18 pm
Rusky, I don't see why you're trying so hard.  Josh's method is more efficient, and while it may seem more complex and less readable, there is no reason why it should not be obvious that it's a better method.

The lightbulb was originally an idea of something that burns so much electricity that it creates heat and then light (although hopefully more light than heat, unless it's a heat lamp).  Then, someone thought of florescent lightbulbs.  How do they work?  They glow.  That's it.  No burning up electricity in an extremely inefficient matter.  They just work.

A tree might work.  It was what was thought of first.  Is it the best method?
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 22, 2009, 08:17:41 pm
It's not merely less readable, it's unreadable. Also, this one is extremely readable, and you have no proof that it's more efficient.

Your little comment about the lightbulb is moronic. Have you ever written anything remotely parser-related? The only reason Josh's method is even maybe acceptable is because he's not really parsing it. He's just prettifying it so GCC can parse it. If he were going to compile it himself, his method would not work at all.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 22, 2009, 08:28:59 pm
The only reason Josh's method is even maybe acceptable is because he's not really parsing it. He's just prettifying it so GCC can parse it. If he were going to compile it himself, his method would not work at all.
Which is what the parser is supposed to do!  It's not a syntax checker.  It parses Game Maker syntax into C++ syntax.  If it's not good enough for Game Maker to read, it's not going to be parsed correctly, and it won't compile.  However, if Game Maker can read it, it will be made readable by the compiler.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 22, 2009, 08:40:33 pm
I believe this is the reason compilation was just "too difficult" for the Game Maker team. They were all thinking in a box; this is the way it must be done. We must use a tree; we can't leave it to a far more experienced, far longer lived team such as the G++ one.

I'll say it again; it takes some nerve to even think we can compete with that compiler. It's totally out of the question to even try. Drop your fantasies, -- or at least, scenarios for usefulness of a token tree -- and realize that there's no need for it. Retro's right: the point is to make it so GCC, a far more capable compiler than either of us could hope to write, can read it. Only this, and nothing more.


You just told me you no longer want to use a complete tree, just a ...not tree... generated parser. So. why don't we let this war die until then.

In fact, until anyone has something to showcase, I don't really want to hear any more about it. The flaming is starting to get on my nerves. So show your knowledge and exhibit your idea by posting progress, not by flaming the hell out of anyone that disagrees with you.


As for me...
Progress: CFile parser is working quite nicely. There's a scope problem I'm just about to fix: checking if a variable already exists to report redeclaration needs to be sensitive to what scope the originally declared thing is in.

For example.

Code: [Select]
struct a;
namespace b;
{
  int a;
}

Currently bitches that I'm naming two types in the declaration (int and ::a). It shouldn't do that.

All right, solved, 12 minutes later.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: luiscubal on August 23, 2009, 08:30:33 am
Actually, left recursivity is a fatal error in Antlr. So it does suck quite a lot ;)

Also, I think you're overkilling a few things. GCC does a lot, so why waste effort? GCC has a preprocessor. So why bother working on one? You could have the EDL go through the preprocessor, then your parser and THEN the C compiler itself. It could work...
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 23, 2009, 03:42:48 pm
GCC does a lot, so why waste effort? GCC has a preprocessor. So why bother working on one? You could have the EDL go through the preprocessor, then your parser and THEN the C compiler itself. It could work...
The preprocessor is mostly required for syntax checking, if I recall.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 23, 2009, 07:36:21 pm
The preprocessor is what handles #preprocessor directives.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 24, 2009, 08:52:52 am
If you can invoke just the preprocessor, you should do that on the EDL and then parse. That is what he was saying.

Quote from: RetroX
Which is what the parser is supposed to do!  It's not a syntax checker.  It parses Game Maker syntax into C++ syntax.  If it's not good enough for Game Maker to read, it's not going to be parsed correctly, and it won't compile.  However, if Game Maker can read it, it will be made readable by the compiler.
But it does need to give meaningful error messages when it fails.

@Josh: I have no problem with your method of converting to C++ to get compiled EDL. It's a great idea. I just think it's also a good idea to use the same ideology ("This tool has been around much longer and can definitely do the job, let's use it") and use a parser generator. It makes things so much easier, faster and clearer.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 24, 2009, 09:34:20 am
"This tool has been around much longer and can definitely do the job, let's use it"

Originally, the computer monitor was this big device that shot electrons out of an effing big tube onto a glass screen.  Eventually, someone was able to make a liquid crystal display, which used far less electricity to do the job, and it had a severe difference in quality from its successor.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 24, 2009, 10:22:42 am
He said g++ has been around longer and thus has been improved more. That is a valid argument- we don't need to compile anything ourselves. Yacc has been around much longer than Josh, and is a computer program, so it is easier to generate correct parsers with it.

You obviously still don't understand what is going on. All Josh's parser needs to do is make the code readable by a c++ compiler. It doesn't have to actually parse it. All your analogies to florescent lights and lcd screens are completely off. The reason his method is useful is because it's doing something different- it's not doing the same thing in a different way.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: score_under on August 24, 2009, 01:37:08 pm
Compiler optimizations aside, ++i is faster than i++, because i++ has to create a copy of i to evaluate to and increment the real one, while ++i just increments it.
No.

The only difference between i++ and ++i is when it is incremented - you still have to reference the variable if you are using it as part of another expression. No copies are created, either.

Rusky: Reinventing the wheel is good.
1- It allows you to improve.
2- Any bugs and you can find them pretty easily, as it's your own code
3- It's specialized. You can make your own optimizations.
4- Human-written is almost always better than auto-generated.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 24, 2009, 01:47:41 pm
Reinventing the wheel is not all good.
1- It allows you to improve, but it also allows you to inadvertently create new bugs
2- Anything that can introduce new bugs is only worth it if you need something to work differently
3- Do you really need specialization?
4- You misunderstand. The specification is human-written, and the driver program is human-written. All the generator does is run an algorithm on the grammar to generate the parse tables. You should read about LR parsers. Besides, that claim is completely ridiculous. Are you saying we should all use machine code? Are you saying nobody should use EDL?
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 24, 2009, 06:40:11 pm
Doesn't matter if the spec is human-authored or not. (And for all you know, it isn't. [That was a joke; you don't have to go calling people morons over it])
ENIGMA's API is human-written. GCC's optimizer is human-written. But there are some things that only a human can optimize.

Maybe a parser's not one of them; maybe it is. It doesn't really matter to me; my way will at very, very least keep up. And considering its comparative performance to GM, Which I'm not going to bother quantifying again, I'd say it'll do much more than that anyway.

Either way, if both methods had identical output with identical speed, I would still stick to this one simply because I'm already writing it, and I'm the only one that will ever be reading it. Anyone that thinks they have the incentive can fork the project and write their own parser that does what mine can.

Until then, we're sticking to what I'm writing.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 24, 2009, 08:08:22 pm
He said g++ has been around longer and thus has been improved more. That is a valid argument- we don't need to compile anything ourselves. Yacc has been around much longer than Josh, and is a computer program, so it is easier to generate correct parsers with it.

You obviously still don't understand what is going on. All Josh's parser needs to do is make the code readable by a c++ compiler. It doesn't have to actually parse it. All your analogies to florescent lights and lcd screens are completely off. The reason his method is useful is because it's doing something different- it's not doing the same thing in a different way.
Quote
In computer science and linguistics, parsing, or, more formally, syntactic analysis, is the process of analyzing a text, made of a sequence of tokens (for example, words), to determine its grammatical structure with respect to a given (more or less) formal grammar.
Essentially, parsing is taking text from one form and putting it to another, better form.  Something as simple as BBCode is "parsed".

The lightbulb worked for hundreds of years.  Because it has worked well for that long, does it mean that it's the best?  No.

It is impossible to re-invent the wheel.  It is one of the most simplistic machines, and now that you know how to make it work, you realize that is the only way to make it work.  By making it better, you would simply be modifying the current design and adding on to it.

However, a regular light bulb is not the only way to make something work.  You can make it differently, even though you know its current design which works so well.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 25, 2009, 08:41:59 am
And you still don't get the point. Even Josh knows his parser couldn't compile anything. When are you going to get that? The reason his method works is because all it has to do is modify the syntax so it's valid C++. C++ syntax is very close to GML anyway.

But your analogy doesn't make sense anyway. The lightbulb was around for hundreds of years, which is why it had time to be improved. GCC has been around for a long time, so it's had time for tons and tons of bugs to be fixed, tons of missing features to be added, and all those new additions tested as well.

Florescent bulbs are doing the same thing- putting out light. Josh's parser is not doing the same thing- it's just fixing would-be syntax errors. It doesn't even pay attention to semantics, which GCC absolutely has to.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 25, 2009, 09:51:00 am
I... I'll just stop.  You're not getting my point, and I don't think explaining anymore is going to make you change your mind.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 25, 2009, 10:05:04 am
I know what you mean. You're saying that we shouldn't just blindly use old methods because there might be better ones. But I'm saying that that doesn't apply to Josh's parser, because he's not trying to do the same thing.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: score_under on August 25, 2009, 04:16:13 pm
I... I'll just stop.  You're not getting my point, and I don't think explaining anymore is going to make you change your mind.
I don't think Rusky will get any point unless it agrees with his original ideas.

It's a man thing.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 25, 2009, 05:49:57 pm
Haha. If what I just explained wasn't your point, you're not doing a very good job of explaining it yourself.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: MrJackSparrow2 on August 25, 2009, 10:12:46 pm
I don't have enough knowledge to fight in this argument, however could we all calm down and stop bitching at each other about what a parser does, and efficiency of methods of parsing. Frankly, I only care to read about what Josh is doing, how things are going, etcetera. I could give a damn about these stupid metaphors, and fighting over things that doesn't help Josh one bit. Can we be less like the GMC, and more of a supportive community? I know it started out in a suggestive supporting tone, but that went to hell pretty fast. Not trying to shove a stick in anybodies ass, but this fighting in every one of Josh's new topics is childish and stupid in my opinion. Don't flame me for this; as the point of this post is to stop the trolling around. Thanks.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: notachair on August 26, 2009, 12:30:44 am
That's why I kept out of the fight :v:
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: score_under on August 26, 2009, 10:19:47 am
If what I just explained wasn't your point
But I'm saying that that doesn't apply to Josh's parser
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Micah on August 26, 2009, 06:43:19 pm
Well, it didn't.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 26, 2009, 08:56:28 pm
Innovation is great. That's what RetroX was saying.
Josh is innovating, but his innovation only applies to this precise situation.
Josh's method cannot be used for anything but this situation- converting to a similar, more strict syntax.
It's not like the florescent lightbulb innovation, or the LCD screen innovation, which are applicable in pretty much every situation.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 27, 2009, 03:01:05 pm
Now that I finally understand what you're trying to say, you're right.  He is not innovating, but rather, making a more specialized parser to fit ENIGMA's needs.  It's not going to be used for anything outside ENIGMA, so therefore, it is best to be optimized for this situation.

EDIT: Also, completely unrelated thing...
Well, remember what you said about linux registries?  Well, turns out all three major desktops have configuration registries.  GNOME has GConf, Xfce has XConf, and KDE has KConfig.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 27, 2009, 05:57:30 pm
What did I say about linux registries? Or do you mean someone else? I know (maybe I didn't when I said whatever it was you're talking about) about those, but usually only programs specific to those systems use them... apache, mysql, etc. don't use them afaik.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: score_under on August 28, 2009, 01:10:41 pm
EDIT: Also, completely unrelated thing...
Well, remember what you said about linux registries?  Well, turns out all three major desktops have configuration registries.  GNOME has GConf, Xfce has XConf, and KDE has KConfig.
Whoever said that probably meant that there is no "built-in" registry, so to speak - with Windows, it is unavoidable to have the registry on your computer, while with GConf, XConf, and KConfig, you have to write code for one of the 3 and hope that your user has GNOME/XFCE/KDE installed - in Windows, like it or not, the registry is a much more uniform beast.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 28, 2009, 09:33:50 pm
The registry is part of the effing filesystem in Windows.  At least Win7 and Vista updated NTFS so registry was an option of the filesystem, whereas in XP/2k it was hidden.

In Linux, those three are the most common ones (and to be entirely honest, even if someone has something else, they'll probably not want to be running ENIGMA, anyways, since it'll most likely be an ancient computer running puppy or something).
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: KaBob799 on August 29, 2009, 03:46:55 am
Quote
Josh is innovating, but his innovation only applies to this precise situation.
Not every innovation needs to be useful for everyone, as long as its useful for what it was designed for (aka, the precise situation)

Is this whole topic really just an argument saying that the parser should be rewritten so that it is able to do stuff it doesnt need to do?
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Micah on August 29, 2009, 09:31:29 am
The reason we were wanting Josh to write the parser with a generator like yacc was that it is much faster and easier to write, easier to debug, less hard-coded and therefore easier to understand and change, and it uses a much more flexible and proven method.

The reason Rusky and RetroX were arguing was that RetroX was being silly and thinking Josh's parser was a brilliant new way to do things, like a fluorescent lightbulb, when it's really the kind of parser someone would write when they haven't studied parsers. So of course it could work and probably will, pretty well, but it's not the best way to do things.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 29, 2009, 10:01:38 am
The reason Rusky and RetroX were arguing was that RetroX was being silly and thinking Josh's parser was a brilliant new way to do things, like a fluorescent lightbulb, when it's really the kind of parser someone would write when they haven't studied parsers. So of course it could work and probably will, pretty well, but it's not the best way to do things.
No, it was because Rusky was arguing seemingly like he had no idea what he was talking about, and was quick to "you're wrong, just because I'm right".  I actually have Josh on MSN, and I do happen to know what's going on.  I'm not an idiot, as I hope you should realize.  I just didn't understand what he was trying to argue, so I was providing the wrong argument in return.  Now, the argument is hopefully settled.  And Josh was in that argument, too, if you actually read it.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 29, 2009, 10:20:26 am
They're basically telling me that it'd be easier for me to use someone else's method, because mine's too hard for me to debug and understand.

Plus, if I use Yacc, other projects can make off with even more easily modifiable pieces of ENIGMA.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Micah on August 29, 2009, 10:31:54 am
Quote from: josh
Plus, if I use Yacc, other projects can make off with even more easily modifiable pieces of ENIGMA.
Wait, what? Why are you releasing under the GPL if you don't want other projects to be able to use pieces of ENIGMA? Just release under another license instead of purposely making your code unreadable. Instead of hurting your own ability to program ENIGMA as well as you could, you could just get at the root of the problem.

Wow.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: RetroX on August 29, 2009, 10:44:34 am
Quote from: josh
Plus, if I use Yacc, other projects can make off with even more easily modifiable pieces of ENIGMA.
Wait, what? Why are you releasing under the GPL if you don't want other projects to be able to use pieces of ENIGMA? Just release under another license instead of purposely making your code unreadable. Instead of hurting your own ability to program ENIGMA as well as you could, you could just get at the root of the problem.

Wow.
More like, they think that, but Josh is perfectly fine with making his code the way he is.  It works, and if people choose to modify the parser, they can, but they likely won't.  The GPL is more for ENIGMA's main functions, not the parser.  It's a good practice to give out the source for free software.  Otherwise, you're just an ass.  And besides, you have to give out the source with the way ENIGMA is set up right now.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 29, 2009, 10:53:18 am
It's not purposely illegible. This one's at least twice as legible as last time.

It's GPL so people can learn from my method, not make off with a syntax file.

And I'm hurting no one. I understand every last aspect of my parser, and modifying it is a breeze for me. I don't care about anyone else's modifying it; no one else develops it.

Besides, it makes me cringe every time a certain SOMEONE makes off with an entire CPP file. Especially when that someone asks me why the Windows one won't compile for Linux.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Micah on August 29, 2009, 11:03:06 am
Sorry, but if you're going to be
Quote from: RetroX
just an ass
, then at least be open about it and don't release the source code to the parts you don't want stolen.

Also, I'll bet modifying your parser wouldn't be such a breeze if you had to stop work on it for a few months.

It could happen; I don't care if nothing ever happens to you and you have a perfect memory and you're perfect.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Josh @ Dreamland on August 29, 2009, 11:24:16 am
There's a certain trust that comes with GPL software. If you're going to start a project under a new name with a new purpose that operates almost entirely off of code you stole from me, that's not right.

However, I don't really care, and I don't ask him to stop; I'm just not going to help him do it.

At this point, probably the only way anyone is going to be able to make off with my parser is if they have no intention to modify it. I still don't care. I'm not going out of my way to be a team player for Yacc just to make it easier for other people.

And I've stopped working on my parser for a month in the past, and still came back and modified exactly what I needed to. Actually, it was more like three or four months. And my memory is pretty damn good. Being perfect has nothing to do with it.


And now this brings me to trying to determine why you're so sore about me not using a parser generator. Most of the other teams have successfully devised an at least almost-working parser in it... Basically, if it's so damn easy to make a parser in it, what does anyone have to gain from me doing so? They can just off and make their own, just like Rusky.

Every benefit to using a generated parser that you named off, you later alienated to make a new case. You've managed to make me lose what little respect I had left for the idea.
Title: Re: Parsers -- A novel by Josh @ Dreamland
Post by: Rusky on August 29, 2009, 05:52:19 pm
What's wrong with someone forking a project, even if they don't call it that?

The purpose of using Yacc or any other generator is not only to make it easier for other people. It's to make it easier for everyone, yourself included.

Which benefits were alienated?