|
An LR parser works like this
Fetch = tokenFoo
Fetch = tokenBar
Fetch = tokenBaz
// parser recognizes those three in a row so it reduces to a rule
Foobar -> tokenFoo tokenBar tokenBaz
You don't get the rule to reduce to until after the tokens are read. You have no idea how many tokens it takes to resolve a rule until after the fact. Which is fine. Usually.
So to build a tree, you have to keep a stack, push any tokens fetched, and then whenever you reduce to a rule, you pop the tokens on the right hand side of the rule, and push a new token for the left hand side of the rule. Easy.
The trouble is when an error is encountered. You won't necessarily get the right number of tokens back
(the parser can actually handle this part, but the tree builder can't)
Fetch = tokenFoo
Fetch = error
Reduce = FooBar -> tokenFoo error ???
Ouch. I don't have enough tokens.
The trouble is, I don't know I don't have enough tokens until the stack is empty.
So basically, I can't even build trees from a shift reduce/LR parser if there are errors in the input.
This is BAD.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
honey the codewitch wrote: This is BAD.
Why?
Do you want fail-fast or fault-tolerant?
|
|
|
|
|
Because one of the points of a parser generator is having both of those things.
*sigh*
It's not really complete without error recovery
Still, I was looking, and I see Gold Parser's parser doesn't do error recovery either.
It's not right though. It's just not right.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
*needless* *heedless* *hopeless* *headmess*
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Reading thru The Mythical Man Month and there are quite a few interesting items.
Gutless Estimating
Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.
An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices --- wait or eat it raw. Software customers have had the same choices.
The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save --— burned in one part, raw in another.
Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineering.
It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole profession can only profit from sharing such data. Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.
I'm pretty sure that estimating hasn't changed at all since this was originally written (1982 or so).
|
|
|
|
|
And like an omelette, you have to break a few eggs to get the job done.
|
|
|
|
|
Marc Clifton wrote: And like an omelette, you have to break a few eggs to get the job done.
And just un-like an omelette, the software job is never, ever done
|
|
|
|
|
Quote: Alberto Einsteinious* Software is never complete, it is only released.
*fake quote (of course)-but it's still true.
|
|
|
|
|
Surely you keep your omelette up to date with the latest frying pans and optional herbs and spices?
|
|
|
|
|
...and if you rush the chicken to produce eggs quicker, you'll end up with a burnt out chicken before long.
I'm sure plenty more valid analogies can be added. C'mon CP, don't let me down...
|
|
|
|
|
dandy72 wrote: I'm sure plenty more valid analogies can be added. C'mon CP, don't let me down..
PHB Wisdom: If the chicken has already crossed the road, then you no longer have to implement Agile.
|
|
|
|
|
raddevus wrote: If the chicken has already crossed the road, then you no longer have to implement Agile. No, no, no - that's not how Agile™ works. The chicken stops every six inches while it walks across the road (these are 'sprints'). It verifies with the stakeholder (aka the farmer) at each point that he's getting what he wants, i.e. the chicken across the road. The farmer can adjust the chicken's route any time he likes.
Of course, none of the principals notice the traffic on the road...
Software Zen: delete this;
|
|
|
|
|
|
That's easy. Use git for source control so that nobody really understands what a 'commit' does.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: That's easy. Use git for source control so that nobody really understands what a 'commit' does.
Wow! You've obviously ascended into Management!
|
|
|
|
|
Them's fightin' words! Put 'em up!
Software Zen: delete this;
|
|
|
|
|
|
F***ing yes.
|
|
|
|
|
A bug in the hand in worth two in the SQL.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: A bug in the hand in worth two in the SQL.
I live by these words!!
|
|
|
|
|
|
Animal Farm
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
|
|
|
|
|
dandy72 wrote: and if you rush the chicken to produce eggs quicker, you'll end up with a burnt out chicken before long.
And yet sales keeps telling the customers that the company has a golden goose.
|
|
|
|
|
Marc Clifton wrote: you have to break a few eggs to get the job done I know a fellow who uses that expression often, mostly to excuse the collateral damage caused by various upgrades. I'm glad he doesn't run an airline.
|
|
|
|
|
raddevus wrote: since this was originally written (1982 or so). Try 1975.
/ravi
|
|
|
|