Hello together,

after lurking around a little bit, I'm asking myself the following: is creating a D compiler (still) a relative easy task or is it getting too big for a small hobby-project?

As far as I understand, one of the goals of D is beeing easily parseable etc. to make it easier for a compiler. Now, creating a fundamental C compiler for one specific architecture is something a quite small project can do (like tinycc.org). On the other side there are the C++ compilers - are there meanwhile compilers who support the whole C++ standard ;-) ? But where is D?

F.ex. I'm concerned about things like putting the regular expression into the language itself mentioned here and there on the newsgroups. This instead of using libs would make creating a new compiler harder. Don't take this post as a vote against the regexps or sth. like that. I'm simply too uninformed to have a true opinion *g*. But is simplicity not only for the developers but also for the compiler still a design goal? If yes, could someone give a subjective classification?


BTW: Will 1.0 be really a stable specification on which a long-term project can be based upon or will this just mean "I'm advanced enough so you can work with me and now we start adding shiny features"?


Hopefully I'm not too bothersome with my rookie questions :-).

Thank you very much for reading and please excuse my bumpy english.

M

"Marcel Meyer" <meyerm-news01@fs.tum.de> wrote in message news:dt7m22$2h41$1@digitaldaemon.com...
> after lurking around a little bit, I'm asking myself the following: is
> creating a D compiler (still) a relative easy task or is it getting too
> big
> for a small hobby-project?
> As far as I understand, one of the goals of D is beeing easily parseable
> etc. to make it easier for a compiler. Now, creating a fundamental C
> compiler for one specific architecture is something a quite small project
> can do (like tinycc.org). On the other side there are the C++ compilers -
> are there meanwhile compilers who support the whole C++ standard ;-) ? But
> where is D?

D remains an easy to lex and easy to parse language. The semantic code is getting more complex. So it's not a hobby project, but it's not remotely as complex as a C++ compiler. It's probably about on par with a C compiler (the C preprocessor is remarkably complicated for something that should be so simple).

> F.ex. I'm concerned about things like putting the regular expression into
> the language itself mentioned here and there on the newsgroups. This
> instead of using libs would make creating a new compiler harder. Don't
> take
> this post as a vote against the regexps or sth. like that. I'm simply too
> uninformed to have a true opinion *g*. But is simplicity not only for the
> developers but also for the compiler still a design goal? If yes, could
> someone give a subjective classification?

Regex is complicated, but that won't matter, for the simple reason that one can just plug in one of many existing regex implementations (including std.regexp!) to handle that part.

> BTW: Will 1.0 be really a stable specification on which a long-term
> project
> can be based upon or will this just mean "I'm advanced enough so you can
> work with me and now we start adding shiny features"?

I don't see any problem with using D now for a long term project.

Marcel Meyer schrieb am 2006-02-18:
> Hello together,
>
> after lurking around a little bit, I'm asking myself the following: is creating a D compiler (still) a relative easy task or is it getting too big for a small hobby-project?
>
> As far as I understand, one of the goals of D is beeing easily parseable etc. to make it easier for a compiler. Now, creating a fundamental C compiler for one specific architecture is something a quite small project can do (like tinycc.org). On the other side there are the C++ compilers - are there meanwhile compilers who support the whole C++ standard ;-) ? But where is D?

Frontend: Writing a parser for D is a joy.
(About a year a go I wrote a parser for and in D with ca. 200LOC.)

> F.ex. I'm concerned about things like putting the regular expression into the language itself mentioned here and there on the newsgroups. This instead of using libs would make creating a new compiler harder.

Middleware: Much more straight forward than C++ but not trivial.
Do a diff between the source of DMD-0.146 and DMD-0.147 to see, that
regular expressions are almost exclusively  syntactic sugar for accessing the
lib.

> Don't take
> this post as a vote against the regexps or sth. like that. I'm simply too
> uninformed to have a true opinion *g*. But is simplicity not only for the
> developers but also for the compiler still a design goal? If yes, could
> someone give a subjective classification?

Let's find the balance between:
1) capabilities and restrains
2) simplicity and syntactic sugar
3) compiler implementation, runtime implementation and language usage

;)

Thomas

Marcel Meyer wrote:
> after lurking around a little bit, I'm asking myself the following: is
> creating a D compiler (still) a relative easy task or is it getting too big
> for a small hobby-project?

You might want to check out llvm ( http://llvm.org/ ) to use as a compiler middle-end/back-end, this would leave you with lexing, parsing and transforming to llvm-assembly.

Marco

Thomas Kuehne wrote:
> 
> Frontend: Writing a parser for D is a joy.
> (About a year a go I wrote a parser for and in D with ca. 200LOC.)
> 

A parser in 200 LoC? Surely you meant a lexer? Or perhaps it's the 200 LoC figure that is incorrect?


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

In article <dtn7bk$2b9a$1@digitaldaemon.com>, Bruno Medeiros says...
>
>Thomas Kuehne wrote:
>> 
>> Frontend: Writing a parser for D is a joy.
>> (About a year a go I wrote a parser for and in D with ca. 200LOC.)
>> 
>
>A parser in 200 LoC? Surely you meant a lexer? Or perhaps it's the 200 LoC figure that is incorrect?
>

I would tend to agree here Bruno. Just the parse.c file supplied with dmd's frontend is ~4700 LOC. The grammar file alone for my (incomplete) parser is ~1100. The Flex file is about 400 though, so maybe Thomas hand wrote the lexer in 200? Maybe a typo and he meant 2000?

My two cents,
Kelly Wilson

Bruno Medeiros schrieb am 2006-02-24:
> Thomas Kuehne wrote:
>> 
>> Frontend: Writing a parser for D is a joy.
>> (About a year a go I wrote a parser for and in D with ca. 200LOC.)
>> 
>
> A parser in 200 LoC? Surely you meant a lexer? Or perhaps it's the 200 LoC figure that is incorrect?

It is something inbetween. e.g. I was interrested in symbol resolution but didn't care about templates.

Thomas