[dmd-internals] How important are the exact formats of __DATE__, __TIME__, and __TIMESTAMP___?

Jonathan M Davis jmdavisProg at gmx.com
Wed Mar 9 14:17:57 PST 2011


On Wednesday, March 09, 2011 13:00:25 Jacob Carlborg wrote:
> On 9 mar 2011, at 20:18, Jonathan M Davis wrote:
> > On Wednesday, March 09, 2011 09:28:05 Jacob Carlborg wrote:
> >> On 9 mar 2011, at 05:52, Jonathan M Davis wrote:
> >>> On Tuesday 08 March 2011 20:46:49 Andrei Alexandrescu wrote:
> >>>> I understand. If I could, I'd kindly discourage you from working on
> >>>> it. Its existence would stifle the impetus to work on general lexing
> >>>> and parsing frameworks (a la highly integrated lex/yacc using D's
> >>>> generational capabilities). Those in turn would push the compiler
> >>>> forward and would help fixing bugs, and would offer the proverbial
> >>>> fishing rod (tools for parsing any language) instead of fish (a lexer
> >>>> and a parser for D itself).
> >>> 
> >>> Well, I fully support a generic lexer, but I also see value in a lexer
> >>> which closely follows what the front end is doing for D. But it's not
> >>> like I've been making huge progress on it and am about to submit it for
> >>> review. I have too much other stuff on my plate to blow through it like
> >>> that.
> >>> 
> >>> Though honestly, if I were to be writing a lexer and/or parser for a
> >>> compiler of any kind, I'd just do it by hand. It's a lot more flexible
> >>> that way. So, even if a solid, generic D lexing tool existed, I'm not
> >>> sure that I'd use it for anything.
> >>> 
> >>> In any case, as I understood it, the result of that original discussion
> >>> was that we wanted to have a generic lexing solution (and presumably a
> >>> corresponding parsing solution following that) but that we still want a
> >>> lexer and parser for D which are close to what the C++ front end is
> >>> doing. So, as requested, I've slowly been working on that.
> >>> 
> >>> - Jonathan M Davis
> >>> _______________________________________________
> >>> dmd-internals mailing list
> >>> dmd-internals at puremagic.com
> >>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> >> 
> >> I completely agree with this, that we need a D lexer (preferably a whole
> >> frontend) written in D, included in the standard library. I even hope
> >> that one day DMD will use that lexer.
> >> 
> >> BTW, are basing your work on DDMD?
> > 
> > No. I haven't looked at DDMD. Walter wanted a fairly direct port of the
> > C++ frontend (with appropriate tweaks for D, but he wants to make sure
> > that it's straightforward to port fixes from one to the other). So, I've
> > just been directly, porting the C++ frontend, adjusting it to be
> > somewhat more idiomatic D as appropriate but generally keeping it fairly
> > close to the C++ implementation.
> > 
> > - Jonathan M davis
> > _______________________________________________
> > dmd-internals mailing list
> > dmd-internals at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/dmd-internals
> 
> Well, that exactly what DDMD does.

Well, I may look at it at some point then, but I'd first have to get permission 
from whoever it is that works on that due to the difference in license. I have 
permission to port Walter's C++ code to D and put it under Boost, but that 
permission doesn't cover code which is derived from it. Also, it's not like I 
can quite take what they did in ddmd  anyway, since the interface to using the 
lexer is going to be different (though presumably, most of the ddmd code would 
still work mostly as-is if they haven't changed it much).

However, since I really should be properly understanding the lexer to get this 
right anyway, and since by far the best way to do that is port it, I'm more or 
less inclined to just port it. I'll much better understand what changes need to 
be made to make it properly work with a range API and whatever is else 
appropriate for a D lexer in Phobos which is divorced from the compiler itself 
if I actually do the work to port it myself.

- Jonathan M Davis


More information about the dmd-internals mailing list