View mode: basic / threaded / horizontal-split · Log in · Help
July 05, 2012
Re: Let's stop parser Hell
On Thu, Jul 5, 2012 at 10:00 PM, Tobias Pankrath <tobias@pankrath.net> wrote:
> On Thursday, 5 July 2012 at 18:17:06 UTC, Philippe Sigaud wrote:
>>
>> As a parser proper, Pegged is awful :-) Nothing I'm ashamed of, as I learn
>> by coding. Hey, I just received the Dragon Book (International Edition),
>
>
> If you are interested in parsing, than I wouldn't recommend the dragon book,
> but
> this one http://dickgrune.com/Books/PTAPG_2nd_Edition/Additional.html
>
> It really is an awesome book.

Hey, good catch! I saw this one a few months ago and forgot about it.
Having half a book being annotated bibliography (IIUC) scared me.

Hmm 72 € by Springer, 55 € on Amazon. Something is not right.
Paperback vs perfect bound maybe?

Is "Modern Compiler Design" by the same authors any good?
July 05, 2012
Re: Let's stop parser Hell
On Thu, Jul 5, 2012 at 10:02 PM, Roman D. Boiko <rb@d-coding.com>
wrote (on children)
> I have four, from 1 to 7 years old... Wouldn't call them a problem, though
> :)))

Better not telling my wife. She's making noises about having a fourth.
July 05, 2012
Re: Let's stop parser Hell
On 7/5/12 3:54 PM, Philippe Sigaud wrote:
> (Hesitating between 'The Art of the Metaobject Protocol' and
> 'Compilers, Techniques and Tools', right now)

Former sux latter rox.

Andrei
July 05, 2012
Re: Let's stop parser Hell
On Thursday, 5 July 2012 at 20:28:32 UTC, Philippe Sigaud wrote:
> Hmm 72 € by Springer, 55 € on Amazon. Something is not 
> right.
> Paperback vs perfect bound maybe?

http://www.komkon.org/~sher/books/parsing_techniques_2008.pdf
Not sure that it is legal, but definitely free.
July 05, 2012
Re: Let's stop parser Hell
Le 05/07/2012 18:32, Roman D. Boiko a écrit :
> On Thursday, 5 July 2012 at 16:14:27 UTC, Jacob Carlborg wrote:
>> Original post:
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/DCT_use_cases_-_draft_168106.html#N168141
>>
>
> OK, fairly complete. Let it be the starting point. Why not put it on
> some wiki, then add some more, discuss, vote, etc.? Meanwhile create a
> matrix of features implemented in each of interesting standardization
> candidates. And pick up one of them as "standard" or "reference" parser.
>
> My vote would be for Pegged, I guess.

Why not program instead of doing bureaucracy ?
July 05, 2012
Re: Let's stop parser Hell
On Thursday, 5 July 2012 at 22:11:41 UTC, deadalnix wrote:
> Why not program instead of doing bureaucracy ?

To avoid programming things which are not needed or don't fit. 
I've thrown away several implementations already... time to 
reflect a little :)

But, actually, for DCT I do know what I need to do. That 
suggestion was with respect to any candidate for becoming 
standard. Everybody understands that their way (likely 
differently than others).
July 05, 2012
Re: Let's stop parser Hell
Le 05/07/2012 18:28, Jonathan M Davis a écrit :
> On Thursday, July 05, 2012 18:04:11 Roman D. Boiko wrote:
>> On Thursday, 5 July 2012 at 15:40:53 UTC, Jacob Carlborg wrote:
>>> On 2012-07-05 15:08, Roman D. Boiko wrote:
>>>> Anyway I propose to enumerate major use cases first.
>>>
>>> Haven't we already done that a couple of times.
>>
>> Well, we did something like that for DCT... but I doubt that it
>> would fit general needs.
>>
>> If we had, why haven't they been analyzed, classified, discussed,
>> etc.? Or have they?
>
> It's been discussed before, but there are some obvious use cases such as
> syntax highlighting, code formatting, and manipulation of D source files (e.g.
> to strip out the unit tests).
>
> We need to have a lexer in Phobos which parsers D code and generates a range
> of tokens, and we need to have a parser in Phobos which operates on a range of
> tokens. As discussed previously, there is desire to have the lexer and parser
> ported from dmd's frontend to D for Phobos so that what we get is easily
> maintainable alongside dmd's frontend and produces the same results (and is
> fast).

You never looked at dmd frontend soure code don't you ? It is a horror 
museum, and if we want to have something in D, I certainly wouldn't copy 
that.
July 05, 2012
Re: Let's stop parser Hell
Le 06/07/2012 00:21, Roman D. Boiko a écrit :
> On Thursday, 5 July 2012 at 22:11:41 UTC, deadalnix wrote:
>> Why not program instead of doing bureaucracy ?
>
> To avoid programming things which are not needed or don't fit. I've
> thrown away several implementations already... time to reflect a little :)
>
> But, actually, for DCT I do know what I need to do. That suggestion was
> with respect to any candidate for becoming standard. Everybody
> understands that their way (likely differently than others).
>

Well you did the mistake to introduce an over complex mechanism in 
log(n) to get back to source code when an obvious one in O(1) exists.

Let me doubt.
July 05, 2012
Re: Let's stop parser Hell
On Thursday, 5 July 2012 at 22:32:29 UTC, deadalnix wrote:
> Well you did the mistake to introduce an over complex mechanism 
> in log(n) to get back to source code when an obvious one in 
> O(1) exists.
>
> Let me doubt.

I'm fine with that, let you doubt.
July 06, 2012
Re: Let's stop parser Hell
On Friday, July 06, 2012 00:24:11 deadalnix wrote:
> Le 05/07/2012 18:28, Jonathan M Davis a écrit :
> > On Thursday, July 05, 2012 18:04:11 Roman D. Boiko wrote:
> >> On Thursday, 5 July 2012 at 15:40:53 UTC, Jacob Carlborg wrote:
> >>> On 2012-07-05 15:08, Roman D. Boiko wrote:
> >>>> Anyway I propose to enumerate major use cases first.
> >>> 
> >>> Haven't we already done that a couple of times.
> >> 
> >> Well, we did something like that for DCT... but I doubt that it
> >> would fit general needs.
> >> 
> >> If we had, why haven't they been analyzed, classified, discussed,
> >> etc.? Or have they?
> > 
> > It's been discussed before, but there are some obvious use cases such as
> > syntax highlighting, code formatting, and manipulation of D source files
> > (e.g. to strip out the unit tests).
> > 
> > We need to have a lexer in Phobos which parsers D code and generates a
> > range of tokens, and we need to have a parser in Phobos which operates on
> > a range of tokens. As discussed previously, there is desire to have the
> > lexer and parser ported from dmd's frontend to D for Phobos so that what
> > we get is easily maintainable alongside dmd's frontend and produces the
> > same results (and is fast).
> 
> You never looked at dmd frontend soure code don't you ? It is a horror
> museum, and if we want to have something in D, I certainly wouldn't copy
> that.

I have definitely looked at dmd's frontend's source code. The idea behind 
copying the lexer and parser from there is then that they'd match the 
compiler, which would make it much easier to keep them in sync with changes to 
the compiler. Whether that's what someone would have written had they done it 
purely in D initially is pretty much irrelevant.

- Jonathan M Davis
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home