"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message
> Is this it?
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26411

Nope, that's not it.  I think it was DMDFE that I was thinking about.

In article <ddb9ho$jua$1@digitaldaemon.com>, Shammah Chancellor says...
>
>In article <ddamm3$2uu2$1@digitaldaemon.com>, Burton Radons says...
>
>>digc has a tool for stripping function bodies.  The problem is that because of D's VERY complex versioning and debugging syntax there is no way to handle stripping robustly without understanding the entire language; it must parse the whole thing.  Which is a pickle, since D is not simple to parse at all and some of its syntax is so subtle that you practically need to depend upon DMD.  I think Ben has the right idea.
>
>
>Funny, I thought D was supposed to be easy to parse?

Compared to C++, I think it is much easier to parse. Also, if the purpose doesn't require perfectly correct parsing (e.g. version isn't used or nesting comments don't need to be quite handled right) it is pretty easy.

Also, it'd be easier if Walter would quit adding cool new features to the language. It's hard to keep up with all of the constant improvements. ;)

jcc7

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:ddbc30$mcj$1@digitaldaemon.com...
> Shammah Chancellor wrote:
> > In article <ddamm3$2uu2$1@digitaldaemon.com>, Burton Radons says...
> >>digc has a tool for stripping function bodies.  The problem is that because of D's VERY complex versioning and debugging syntax there is no way to handle stripping robustly without understanding the entire language; it must parse the whole thing.  Which is a pickle, since D is not simple to parse at all and some of its syntax is so subtle that you practically need to depend upon DMD.  I think Ben has the right idea.
> > Funny, I thought D was supposed to be easy to parse?
> I guess it's relative.
> For someone who wrote a C++ compiler, D would probably be very easy to
> parse.

Well, that's true <g>.

Some things that make D easy to parse:

1) Clean separation between tokenizing and semantic processing - parsing
fits neatly in between.
2) The parser fits in one file, 4592 lines of code.
3) The parser is provided free with D. Is it that hard to understand?

Some things that make D harder to parse:

1) It's not LALR(1), arbitrary lookahead is required for some constructs
2) There are a lot of constructs

Pascal is trivial to parse, and Java isn't much harder. D is still easier to parse than C, and orders of magnitude easier than C++.

"J C Calvarese" <technocrat7@gmail.com> wrote in message news:ddbhgl$spl$1@digitaldaemon.com...
> Compared to C++, I think it is much easier to parse. Also, if the purpose doesn't require perfectly correct parsing (e.g. version isn't used or
nesting
> comments don't need to be quite handled right) it is pretty easy.

Since the source to the lexer is provided, there's no excuse for not doing comments right <g>.

Walter wrote:
> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message
> news:ddbc30$mcj$1@digitaldaemon.com...
> 
>>Shammah Chancellor wrote:
>>
>>>In article <ddamm3$2uu2$1@digitaldaemon.com>, Burton Radons says...
>>>
>>>>digc has a tool for stripping function bodies.  The problem is that
>>>>because of D's VERY complex versioning and debugging syntax there is no
>>>>way to handle stripping robustly without understanding the entire
>>>>language; it must parse the whole thing.  Which is a pickle, since D is
>>>>not simple to parse at all and some of its syntax is so subtle that you
>>>>practically need to depend upon DMD.  I think Ben has the right idea.
>>>
>>>Funny, I thought D was supposed to be easy to parse?
>>
>>I guess it's relative.
>>For someone who wrote a C++ compiler, D would probably be very easy to
>>parse.
> 
> 

[snip]
> 3) The parser is provided free with D. Is it that hard to understand?
Yes, it's provided, but it doesn't work out of the box, and the code is not documented.

In article <ddc0vf$1kj7$3@digitaldaemon.com>, Walter says...
>
>
>"J C Calvarese" <technocrat7@gmail.com> wrote in message news:ddbhgl$spl$1@digitaldaemon.com...
>> Compared to C++, I think it is much easier to parse. Also, if the purpose doesn't require perfectly correct parsing (e.g. version isn't used or
>nesting
>> comments don't need to be quite handled right) it is pretty easy.
>
>Since the source to the lexer is provided, there's no excuse for not doing comments right <g>.

Yes, there is an excuse: I'm not a C++ programmer. So there. When the D front end is written in D, that's when I wouldn't have an excuse. ;)

(But I still appreciate that you open-sourced it. And I like nested comments a lot, so please don't take them out.)

jcc7

In article <ddbeqm$pfc$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message
>> Is this it?
>>
>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26411
>
>Nope, that's not it.  I think it was DMDFE that I was thinking about.
>
>

No, I believe you were thinking of dlexer.d, which is a module that I wrote a while back.  It lexes D source code (as of a few versions back) and returns a list of tokens.  It works almost exactly like the C++ version that is in the front end, but it's written in D!

dlexer lives in the bindings project on dsource.org, here: http://svn.dsource.org/projects/bindings/trunk/dlexer.d

Whaddaya know, the guy that's hosting your webspace is the same guy that wrote a module you need.  Am I just not useful to you or what? =P  Well, that all depends on if you actually use the module in question.

Regards,
James Dunne

Hmm the dparse.d file on that site requires the dtypes module. Where is that?

In article <ddddg2$etj$1@digitaldaemon.com>, James Dunne says...
>
>In article <ddbeqm$pfc$1@digitaldaemon.com>, Jarrett Billingsley says...
>>
>>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message
>>> Is this it?
>>>
>>> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26411
>>
>>Nope, that's not it.  I think it was DMDFE that I was thinking about.
>>
>>
>
>No, I believe you were thinking of dlexer.d, which is a module that I wrote a while back.  It lexes D source code (as of a few versions back) and returns a list of tokens.  It works almost exactly like the C++ version that is in the front end, but it's written in D!
>
>dlexer lives in the bindings project on dsource.org, here: http://svn.dsource.org/projects/bindings/trunk/dlexer.d
>
>Whaddaya know, the guy that's hosting your webspace is the same guy that wrote a module you need.  Am I just not useful to you or what? =P  Well, that all depends on if you actually use the module in question.
>
>Regards,
>James Dunne

"James Dunne" <james.jdunne@gmail.com> wrote in message news:ddddg2$etj$1@digitaldaemon.com...
> No, I believe you were thinking of dlexer.d, which is a module that I
> wrote a
> while back.  It lexes D source code (as of a few versions back) and
> returns a
> list of tokens.  It works almost exactly like the C++ version that is in
> the
> front end, but it's written in D!

THAT'S THE ONE!

> dlexer lives in the bindings project on dsource.org, here: http://svn.dsource.org/projects/bindings/trunk/dlexer.d
>
> Whaddaya know, the guy that's hosting your webspace is the same guy that
> wrote a
> module you need.  Am I just not useful to you or what? =P  Well, that all
> depends on if you actually use the module in question.

Haha, how about a coincidence!  I ended up changing my little tool to look for //STRIP and //NOSTRIP comments in the source file that would turn on and off stripping of code between braces.  I only had a few problems, mostly caused by rogue braces that were on the same line as other code (see, I knew my coding style would pay off.. no code on the same line as a brace!), but other than that, it worked great.

I'll definitely check out / update your dlexer, though, as I'd like to write a somewhat more robust tool that can handle it without the //STRIP and //NOSTRIP directives.  Thanks!

>The open source maniac: We don't need that kind of abomination. Let some company create a commercial tool for people who need it. If you're not going to share your source, you don't deserve to use free tools. Developers who are working for free shouldn't waste their time programming a tool to help creating nonfree/closed-source software.
>
>The pragmatic: This kind of tool would be very useful but open source developers have no time to create one and commercial developers aren't interested in making tools for a language with tiny user (=customer) base.
>

Just an example: my app (lessequal.com/akide) is open source. Compiling and linking it takes 3 seconds on my pc when I pass all the files at once to dmd. But compiling each file w/o linking takes 40+ seconds! THIS IS SICK! Now I believe if we had headers it would take few seconds more than my 3... But now my source is so big I'd rather add intellisence to the ide (akide is developed on akide) and let it decide which files need recompiling instead of creating  all the headers... If I had to "rebuild all" more often my development should be SIGNIFICANTLY slower. So I don't know if we need tool to create headers or dmd should be smarter...