|
A happy new year to all.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Happy New Year to you too!
|
|
|
|
|
HNYTYA (20 chars)
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
A euphony port alleyway!
Another yuppy yellow A.A.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Happy new year, OG! Good health and happiness!
/ravi
|
|
|
|
|
Happy new year!
I hope everyone’s had a chance to get some R&R over the break (refactoring and rewriting in my case. Ah, the peace and quiet of an empty office!)
cheers
Chris Maunder
|
|
|
|
|
Happy new year to everyone from me too.
If you are not criticized, you may not be doing much.
|
|
|
|
|
I wish for a very happy and fulfilling new year for everyone. 
|
|
|
|
|
|
Garfield is a real influencer 
|
|
|
|
|
I think I can parse anything with Parsley. I'm pretty confident in it at this point, despite its immaturity. It still is cranky because I'm not finished with it, but now all of the foundation is there.
It can parse C#. That's a tall order. With a little work (mostly lexer support for significant vs insignificant whitespace) I could parse Python. That would be easier given that lexer support because it's not so ambiguous.
I also never had to break from an LL(1) parser algorithm except in my hand-rolled routines.
Parsley will eventually be LL(k), i think. Or maybe LL(*). It depends on how big the code that gets generated winds up being.
It *did* generate a 1.3MB source file, but unlike the 800k source file i got from ANTLR for parsing C#6 (which didn't work) you can follow it in a debugger pretty easily, and Parsley actually parses C#, or at least the subset that is useful to me, though I'm confident by now i could pretty easily parse the rest of it too. I just don't have anywhere in the CodeDOM to put what i'd parse! CodeDOM knows nothing of things like anonymous methods or lambda expressions or LINQ
This is just so cool. I've been wanting to do this for a long time. (Parse C# with one of my parser generators that is)
I never thought it would wind up being a recursive descent parser generator that did it. I wrote it that way for a lark, but it worked out really well.
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.
|
|
|
|
|
Wow.. nothing gotta stop you now! 
|
|
|
|
|
I knew I'd nail it eventually. This is what I wrote Parsley for - to parse Slang.
It's bigger than a hand generated parser would be by a fair bit, but also my hand rolled parser barely did any error checking, and what it did report was dodgy.
Adding: I keep forgetting it's the new year. Happy new year!
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.
|
|
|
|
|
Yes, error checking isn't usually added until it starts to "work", so it can cause upheaval. But it's so much easier to debug if the parser--and also what is basically an interpreter, for me--can pinpoint where they failed, with a message that makes sense. And keep going, so that you don't have to uncover one problem at a time.
|
|
|
|
|
Greg Utas wrote: And keep going, so that you don't have to uncover one problem at a time.
That's one thing I haven't figured out how to do in recursive descent parsing - error recovery.
My PCK project does it but not this. Maybe down the road.
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.
|
|
|
|
|
To parse an expression, I call this:
bool Parser::GetCxxExpr(ExprPtr& expr, size_t end, bool force)
end is the position of the delimiter where the expression ends. It's found by doing a lookahead for the closing punctuation, which is one of ;},)]:= depending on the context. If something goes wrong while parsing the expression, a log containing the expression is generated and the parse resumes after end. I guess that makes it LL(*) if I remember correctly.
modified 1-Jan-20 8:25am.
|
|
|
|
|
LL(*) is top down left derivation parsing with arbitrary lookahead, so if you're using lookahead i think that qualifies?
Cast expressions would be very simple if it weren't for the ambiguity with subexpressions.
It's just
CastExpression = "(" Type ")" Expression;
But yeah.
SubExpression = "(" Expression ")";
Complicates things.
An LL(k) parser could solve it.
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.
|
|
|
|
|
You got me thinking, and what if you could use EBNF/XNBF/whatever to define error handling? I'm just now coming up with it, i don't even know if it will work but like:
PanicDefault<collapsed> = { #ERROR } "}";
PanicTypeDecl<collapsed,recover="TypeDecl"> = PanicDefault;
PanicMethod<collapsed,recover="Method"> = PanicDefault;
PanicArgList<collapsed,recover="ArgList"> = { #ERROR } (")"|",");
Something like that... I'll have to think on it.
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.
|
|
|
|
|
Well done, but watch out: the devil is in the detail 
|
|
|
|
|
Ah yes, the 90-10 rule. That last 10% takes 90% of the time. The curse of our existence. 
|
|
|
|
|
Greg Utas wrote: Ah yes, the 90-10 rule.
Man are you optimist... I would have said 95-5 or even 98-2  
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
And the 90% is mostly spent walking back and forth to the coffee machine.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I had to cut back on coffee after I finally realized that drinking too much of it gave me a chronic lightheaded feeling, the kind you get after staying in bed too long while ill. ![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
So now I spend the entire 90% talking to my rubber duck. 🦆
modified 1-Jan-20 11:02am.
|
|
|
|
|
Recursive descent parsers are the cat's ass! Others are inscrutable by comparison. In our compiler course, we had a choice of what kind of parser to implement. I was the only one who chose recursive descent. It was easy to enhance, so it ended up handling a larger subset of Algol than the others. But boy, was it slow! It was written in Simula-67, running on a PDP-10, and probably backtracked too much. Adding backtracking statistics would have revealed if it was doing something silly.
|
|
|
|
|
Did you know Raymond Burr had a brother that was a lumber jack?
His name was Tim!
Ok I'm bored, I promise this will be the last joke this year!
Did a little mechanic work today.
Put a rear end in a recliner!
JaxCoder.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
