> I'm now evaluating the decision to continue with yacc (and write a complete
> D grammar myself)

I hope you go with this, a yacc grammar would be awesome, but I think D wont fit into LL(1) parsers ?  Either way a d-parser of some sort would be a great tool for alot of people.

Good luck!

C

On Thu, 15 Apr 2004 15:42:49 +0000 (UTC), Dave Sieber <dsieber@spamnot.sbcglobal.net> wrote:

> "Ivan Senji" <ivan.senji@public.srce.hr> wrote:
>
>> I have writen an LR(1) parser (in D) and i would like to test it with
>> Dgrammar.
>> So i need LR(1) or a little worse grammar (it can be a little worse
>> because my parser is nondeterministic). What tool? No idea yet. But
>> when i think of a way to generate some output who knows :)
>
> Sounds fascinating!
>
>> Can't wait to see this support, are yout using some grammar for this?
>
> I'm now evaluating the decision to continue with yacc (and write a complete
> D grammar myself), or to use Walter's front-end code and adapt it to Visual
> Studio's extensibiity model.
>
> I think I will stay with the Flex lexer I wrote, because it is working very
> well now for syntax coloring, and I've defined custom color classes for all
> the integral types (decimal, octal, hex, binary), floats and imaginaries,
> strings (regular and wysisyg), and several comment styles (/* normal */, /+
> D nesting style +/ , and a few Doxygen styles).
>



-- 
D Newsgroup.

C <dont@respond.com> wrote:

> I hope you go with this, a yacc grammar would be awesome, but I think D wont fit into LL(1) parsers ?  Either way a d-parser of some sort would be a great tool for alot of people.

I agree that a grammar would be valuable, but I'm also looking at my goal, which is full Intellisense and Class View support for D in Visual Studio. For it to be as good as I desire, it must be as correct as possible -- something which Microsoft themselves have not achieved with their C++ support in VS.NET. Luckily, D is simpler than C++, but when I talked with the Visual C++ team in Redmond, I learned that they were not using the same C++ parser in VS.NET as in the compiler (oops!), and thus while the compiler got everything right, VS.NET did not. I definitely do not want to repeat that mistake with D (easier said than done. The MS crew were all very smart guys, but we're simply talking about two different requirement sets: a compiler vs. a syntax-directed editor).

I look at what Walter has in the front-end code, and it is much better than a parser I could write myself from scratch, and it's already done. With a yacc grammar, because of its limitations, you usually have to make it dumber than you would like, and use semantic analysis to get things right. Walter has already done all that. I'd be reinventing the wheel, and I doubt I understand the language as well as he does.

My only real hesitation is that it would take a lot of tweaking to adapt Walter's code for Visual Studio (which I'm willing to do), but when he comes out with a new version, or maybe adds some new features, I'd have to go back and re-tweak his code again :-(  Of course, I'd have to do that with a yacc grammar too.

> Good luck!

Thanks, I'll need it :-)

-- 
dave

"Dave Sieber" <dsieber@spamnot.sbcglobal.net> wrote in message news:Xns94CC668C5785Fdsiebersbc@63.105.9.61...
> I agree that a grammar would be valuable, but I'm also looking at my goal, which is full Intellisense and Class View support for D in Visual Studio. For it to be as good as I desire, it must be as correct as possible -- something which Microsoft themselves have not achieved with their C++ support in VS.NET. Luckily, D is simpler than C++, but when I talked with the Visual C++ team in Redmond, I learned that they were not using the
same
> C++ parser in VS.NET as in the compiler (oops!), and thus while the compiler got everything right, VS.NET did not. I definitely do not want to repeat that mistake with D (easier said than done. The MS crew were all very smart guys, but we're simply talking about two different requirement sets: a compiler vs. a syntax-directed editor).

With D, I wanted to make it easy to make tools for D that needed a parser, so the language is designed to be easy to parse. The entire parser is contained in parse.h/parse.c. The entire lexer is in lexer.h/lexer.c. Parsing C++ is fiendishly complicated, and doing it 100% correct requires building most of a C++ front end, a 10 year task. A major design goal of D is to avoid that problem.

> I look at what Walter has in the front-end code, and it is much better
than
> a parser I could write myself from scratch, and it's already done. With a yacc grammar, because of its limitations, you usually have to make it dumber than you would like, and use semantic analysis to get things right. Walter has already done all that. I'd be reinventing the wheel, and I
doubt
> I understand the language as well as he does.

I think as much as possible adapting parse.h/parse.c will get you better results.

> My only real hesitation is that it would take a lot of tweaking to adapt Walter's code for Visual Studio (which I'm willing to do), but when he comes out with a new version, or maybe adds some new features, I'd have to go back and re-tweak his code again :-(  Of course, I'd have to do that with a yacc grammar too.

I doubt any big changes to the grammar are coming, so any changes that do come should be easy to fold in if you keep the parse.c you started with, and diff the new one against it to see what changed.

"Walter" <walter@digitalmars.com> wrote:

> I doubt any big changes to the grammar are coming, so any changes that do come should be easy to fold in if you keep the parse.c you started with, and diff the new one against it to see what changed.

Thanks for the reassuring answers, Walter. I think that helps me make up my mind :-)

-- 
dave