> it avoids ambiguity by using ordered choice (the first matching rule wins)
PEG parsing tool authors often say that ordered choice solves the problem of ambiguity, that's very misleading.
Yes, ordered choice is occasionally useful as a way to resolve grammatic overlap. But as a grammar author, it's more common for me to want to express unordered choice between two sub-grammars. A tool that supports unordered choice will then let you know when you have an unexpected ambiguity.
PEG-based tools force you to use ordered choice for everything. You may be surprised later to find out that your grammar was actually ambiguous, and the ambiguity was "resolved" somewhat arbitrarily by picking the first sub-grammar.
> This makes working with Ohm/PEGs less painful in the initial phase of a project.
I do agree with this. But then what happens in the later phases? Do you switch to a tool that supports unordered choice to see if you have any ambiguities? And potentially have to change your grammar to fix them?
Now I'm curious -- is that here a way to do this that avoids downloading any more than strictly necessary?
The command above downloads the whole repo history. You could do a depth=1 to skip the history, but it still downloads the he latest version of the entire repo tree.
While Python is not high performance overall, people have spent a ton of time optimizing the memory management. So while it's not definitive proof of reference counting being slow, it seems like a fair initial question.
Re: "it's well understood reference counting is garbage collection". I think this might just be a terminology thing.
There appear to be two ways the terms are categorized:
1. "reference counting" and "garbage collection" are two types of automatic memory management/reclamation.
2. "reference counting" and "tracing garbage collection" are two types of garbage collection.
I think mbrodersen is using #1.
(Back in the 90s and 2000s I feel like #1 was much more prevalent. But #2 seems to have gained popularity since then. My theory is that whoever started writing the Wikipedia content for this stuff picked #2.)
There are many factors to take into account, but this article focuses on the "operating reliably in production" factor and says that MySQL has fewer surprises:
As for Postgres, I have enormous respect for it and its engineering and capabilities, but, for me, it’s just too damn operationally scary. In my experience it’s much worse than MySQL for operational footguns and performance cliffs, where using it slightly wrong can utterly tank your performance or availability. In addition, because MySQL is, in my experience, more widely deployed, it’s easier to find and hire engineers with experience deploying and operating it. Postgres is a fine choice, especially if you already have expertise using it on your team, but I’ve personally been burned too many times.
> All notable AI techniques to date specify in exhausting detail the thought processes that the AI should execute in carefully constructed algorithms.
I'm not knowledgeable about AI, but from some of of the game-playing AI research I've read about, it seems like we provide in exhaustive detail the rules and objectives and the AI figures out (though a very resource-hungry process) an "algorithm" (e.g. encoded as a neural network) to play the game well.
I'm not saying that's close to human thought, but it seems far beyond having to "specify in exhausting detail the thought processes that the AI should execute in carefully constructed algorithms."
PEG parsing tool authors often say that ordered choice solves the problem of ambiguity, that's very misleading.
Yes, ordered choice is occasionally useful as a way to resolve grammatic overlap. But as a grammar author, it's more common for me to want to express unordered choice between two sub-grammars. A tool that supports unordered choice will then let you know when you have an unexpected ambiguity.
PEG-based tools force you to use ordered choice for everything. You may be surprised later to find out that your grammar was actually ambiguous, and the ambiguity was "resolved" somewhat arbitrarily by picking the first sub-grammar.
> This makes working with Ohm/PEGs less painful in the initial phase of a project.
I do agree with this. But then what happens in the later phases? Do you switch to a tool that supports unordered choice to see if you have any ambiguities? And potentially have to change your grammar to fix them?