The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
My first two 'smart' phones were Lumia WP's. I just retired the last one a few months ago due to a damaged screen. Like you, I had simple needs...phone, email, and music player mostly...and didn't care much about the lack of apps.
The new android phone took a little getting used to but it really is a better device than the WPs, maybe only due to the fact that it is newer, charges faster, and hold a charge longer.
I wonder how many other WP users (dying breed) are still out there.
So Parsley is cool, but the hand written parser I wrote for Slang is under 100K, and the Generated one is 939K. The latter parser is slower, but more accurate, and otherwise better, but not 10 times the size better.
For comparison, Antlr's grammar for parsing C#6 was worth about 800K and change of C# source code but it didn't parse so i don't know if it was complete, or what was wrong with it.
I'm considering a code synthesis approach which might make the generated code smaller, especially for loops but i don't know how much i can really save here, but the emitted code would look cooler. =P - closer to hand written code.
People say size doesn't matter these days. (Apparently its all in how you use it) but by my rough calculations, this is the difference between 40-50k of binary size and closer to 500k of binary size when its compiled. That means cache lines and locality are going to take a hit i think, because the working set has to grow accordingly though i would need to do extensive comparison testing before i could be sure of any of that. Still, it doesn't look good.
They are wrong and always have been. Just because people have large disk drives and mass amounts of memory does not mean that lean and mean is not preferable to bloat code.
I have seen code that only took 100k to do the same thing that someone did in over 1000K. Just remember Complex is easy, but simple is hard. Beautiful code is simple and easy to understand, but is often hard to create.
On a C compiler that does not do optimization "i = ++n" is much more efficient than "i = n++". On a C++ compiler that does optimization (when dealing with classes) the difference in efficiency is much worse (n++ is a very bad habit to fall into).
The goal of code generation should be concise efficient code.
Sorry, I think a got off subject. Just keep in mind that even generated code should be reviewed.
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
Most of the size here is taken up by the FIRST set comparison in the if statement - canonical LL(1). Note that 121 *was* a constant, but since it's only ever used internally by the parser, and never seen outside of it, i removed the constants like this from the list of fields in the class (there can be hundreds of these in a real world grammar). I had to make a call between code size and readability in that instance. The constant is literally "FactorExpression" and always followed by it's string name so I favored size over using a constant here.
Anything seen publicly has constant symbols and when it has constants, the generated code uses the constants.
Funny how the code generator uses Yoda conditions - Wikipedia[^], even though it should be immune to the '==' -> '=' typo problem for which they were invented in the first place.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)