www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D parser in tango or phobos

reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Hi

When building tools for manipulating d code, you practical always need a
parser.

So, why not include a d parser as part of the runtime library,
in that way the it is much easy to write code tools.

dmd itself might even use the same parser, which
will insure that the parser support the latest version of d and it will
be a nice start for a incremental d compiler.


-- 
Crowdnews.eu - a social news site based on sharing instead of voting.
Follow me on CrowdNews http://crowdnews.eu/users/addGuide/42/
Sep 02 2008
parent reply davidl <davidl 126.com> writes:
在 Tue, 02 Sep 2008 15:37:38 +0800，Knud Soerensen  
<4tuu4k002 sneakemail.com> 写道:


 Hi

 When building tools for manipulating d code, you practical always need a
 parser.

 So, why not include a d parser as part of the runtime library,
 in that way the it is much easy to write code tools.

 dmd itself might even use the same parser, which
 will insure that the parser support the latest version of d and it will
 be a nice start for a incremental d compiler.


It's not easy to have a complete working bug free parser.  
dsource.org/projects/dparser

and there're something else like Aziz's dil, and pragma's ddl subproject  
enki generated
dparser, also Jascha's parser generator APaGed(which is also capable of  
generating a
  simple parser).



dparser provides a lot more semantic analysis than those others as far as  
I can see, while
there're a lot bugs in it.

Dil should be the cleanest. There're a lot great ideas. While a lot  
semantics not done yet.

It's your choice to choose


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Sep 02 2008
parent reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
davidl wrote:

 在 Tue, 02 Sep 2008 15:37:38 +0800，Knud Soerensen
 <4tuu4k002 sneakemail.com> 写道:
 

 Hi

 When building tools for manipulating d code, you practical always need a
 parser.

 So, why not include a d parser as part of the runtime library,
 in that way the it is much easy to write code tools.

 dmd itself might even use the same parser, which
 will insure that the parser support the latest version of d and it will
 be a nice start for a incremental d compiler.


 
 It's not easy to have a complete working bug free parser.
 dsource.org/projects/dparser
 


I know this is why I made the suggestion.

The idea is that tool developer should have a stable platform
base his tool upon.

Such he doesn't have to patch the parser every time a new version of dmd
hits the web.


-- 
Crowdnews.eu - a social news site based on sharing instead of voting.
Follow me on CrowdNews http://crowdnews.eu/users/addGuide/42/
Sep 03 2008
parent reply davidl <davidl 126.com> writes:
在 Wed, 03 Sep 2008 21:51:47 +0800，Knud Soerensen  
<4tuu4k002 sneakemail.com> 写道:


 davidl wrote:

 在 Tue, 02 Sep 2008 15:37:38 +0800，Knud Soerensen
 <4tuu4k002 sneakemail.com> 写道:


 Hi

 When building tools for manipulating d code, you practical always need  
 a
 parser.

 So, why not include a d parser as part of the runtime library,
 in that way the it is much easy to write code tools.

 dmd itself might even use the same parser, which
 will insure that the parser support the latest version of d and it will
 be a nice start for a incremental d compiler.


 It's not easy to have a complete working bug free parser.
 dsource.org/projects/dparser


 I know this is why I made the suggestion.

 The idea is that tool developer should have a stable platform
 base his tool upon.

 Such he doesn't have to patch the parser every time a new version of dmd
 hits the web.


What you're asking is simply impossible. It's equivalent to why we don't  
have a bug-free
frontend.



-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Sep 03 2008
parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Wed, 03 Sep 2008 16:33:11 +0100, davidl <davidl 126.com> wrote:


 在 Wed, 03 Sep 2008 21:51:47 +0800，Knud Soerensen  
 <4tuu4k002 sneakemail.com> 写道:


 davidl wrote:

 在 Tue, 02 Sep 2008 15:37:38 +0800，Knud Soerensen
 <4tuu4k002 sneakemail.com> 写道:


 Hi

 When building tools for manipulating d code, you practical always  
 need a
 parser.

 So, why not include a d parser as part of the runtime library,
 in that way the it is much easy to write code tools.

 dmd itself might even use the same parser, which
 will insure that the parser support the latest version of d and it  
 will
 be a nice start for a incremental d compiler.


 It's not easy to have a complete working bug free parser.
 dsource.org/projects/dparser


 I know this is why I made the suggestion.

 The idea is that tool developer should have a stable platform
 base his tool upon.

 Such he doesn't have to patch the parser every time a new version of dmd
 hits the web.


 What you're asking is simply impossible. It's equivalent to why we don't  
 have a bug-free
 frontend.


Its not impossible just difficult.
One of the first questions some people ask when
told about a new language is "what is it written in?"
If its not written in itself they ask why. If the answer is not compelling  
they
may walk away.
If D ever intends to supplant C as the main systems programming language
it will have to get over this hurdle.
A problem is that the language is itself not that stable. You could write  
a D
compiler in D1.0 but why bother when it will soon be obsolete. Writing a D  
compiler in
D2.0 is a moving target which makes it harder to hit but to quote full  
metal jacket
"you've just got to lead them a bit".

Python has a python parser written in python. The main interpreter is  
written in C for portability.
That is a good reason and the same reason applies for D. Why in this day  
and age C++ isn't considered
portable by most such project is beyond me.
I particularly like gcc's approach of bootstraping itself to full  
functionality. Its a shame the insides
are so gnarly.

Regards,

Bruce.
Sep 06 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bruce Adams:

 One of the first questions some people ask when
 told about a new language is "what is it written in?"
 If its not written in itself they ask why. If the answer is not compelling  
 they may walk away.


Yet, probably 98% of programmers don't care of that. Like most programmers of

written in D, but there are more urgent/important things to do, I presume.



 A problem is that the language is itself not that stable. You could write  
 a D compiler in D1.0 but why bother when it will soon be obsolete.
 Writing a D compiler in D2.0 is a moving target


Creating a back-end requires lot of work, so it may be better to use the one of
GCC and LLVM, and save your time to improve the language itself.

And another possibility is to use D1 to write a compiler for D2 :-)



 Python has a python parser written in python. The main interpreter is  
 written in C for portability.


There is also a full Python interpreter (and JIT) written in Python in the
works, it's named PyPy.

Bye,
bearophile
Sep 06 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
bearophile wrote:

 Bruce Adams:

 One of the first questions some people ask when
 told about a new language is "what is it written in?"
 If its not written in itself they ask why. If the answer is not compelling  
 they may walk away.


 
 Yet, probably 98% of programmers don't care of that. Like most programmers of

written in D, but there are more urgent/important things to do, I presume.
 
 


Yeah, but none of those languages are languages targeted as substitutes 
of C++. D is. And yet the compiler software is not made in D, nor does 
the language designer use it (extensively at least).
So, that's something that could be improved, and not just for publicity 
reasons (having Walter program more in D would be a bit beneficial I 
think, although I wouldn't expect any major enlightenment out of it).

But I do agree that there are other more urgent/important things to work 
on first.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 19 2008
prev sibling next sibling parent reply Alexander Panek <alexander.panek brainsware.org> writes:
Bruce Adams wrote:

 On Wed, 03 Sep 2008 16:33:11 +0100, davidl <davidl 126.com> wrote:
 

 在 Wed, 03 Sep 2008 21:51:47 +0800，Knud Soerensen 
 <4tuu4k002 sneakemail.com> 写道:


 davidl wrote:

 在 Tue, 02 Sep 2008 15:37:38 +0800，Knud Soerensen
 <4tuu4k002 sneakemail.com> 写道:


 Hi

 When building tools for manipulating d code, you practical always 
 need a
 parser.

 So, why not include a d parser as part of the runtime library,
 in that way the it is much easy to write code tools.

 dmd itself might even use the same parser, which
 will insure that the parser support the latest version of d and it 
 will
 be a nice start for a incremental d compiler.


 It's not easy to have a complete working bug free parser.
 dsource.org/projects/dparser


 I know this is why I made the suggestion.

 The idea is that tool developer should have a stable platform
 base his tool upon.

 Such he doesn't have to patch the parser every time a new version of dmd
 hits the web.


 What you're asking is simply impossible. It's equivalent to why we 
 don't have a bug-free
 frontend.


 Its not impossible just difficult.
 One of the first questions some people ask when
 told about a new language is "what is it written in?"
 If its not written in itself they ask why. If the answer is not 
 compelling they
 may walk away.
 If D ever intends to supplant C as the main systems programming language
 it will have to get over this hurdle.
 A problem is that the language is itself not that stable. You could 
 write a D
 compiler in D1.0 but why bother when it will soon be obsolete. Writing a 
 D compiler in
 D2.0 is a moving target which makes it harder to hit but to quote full 
 metal jacket
 "you've just got to lead them a bit".
 
 Python has a python parser written in python. The main interpreter is 
 written in C for portability.
 That is a good reason and the same reason applies for D. Why in this day 
 and age C++ isn't considered
 portable by most such project is beyond me.
 I particularly like gcc's approach of bootstraping itself to full 
 functionality. Its a shame the insides
 are so gnarly.


I completely agree. Aside from the sheer prestige of having a D compiler 
written in D, I think the language and especially the compiler & 
toolchain quality itself would benefit from Walter excessively using his 
  own language. After all, he has to walk around the same traps 
everybody else does when using D/DMD. I also think D should provide a 
whole toolchain written in D1, namely frontend, backend, testing, 
documentation and building (we have the last one already with DSSS, 
fortunately). Another benefit of this would include the possibility to 
actually use the D frontend for third party tools, since it's written in 
D. Of course, we have an open source frontend already, but it's written 
in C and poorly documented - no offense intended -, thus actually not 
really usable unless you spend quite some time digging through the 
source and writing D wrappers for it.

Frankly said, I would have thought of D1 written in D1 as the next step 
in  language development, instead of a "forked" experimental D2 
compiler. But that's just me.

Kind regards,
Alex
Sep 06 2008
next sibling parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-09-06 19:56:25 +0200, Alexander Panek 
<alexander.panek brainsware.org> said:


 Bruce Adams wrote:

 On Wed, 03 Sep 2008 16:33:11 +0100, davidl <davidl 126.com> wrote:
 

 在 Wed, 03 Sep 2008 21:51:47 +0800，Knud Soerensen
<4tuu4k002 sneakemail.com> 写道:
 

 davidl wrote:

 在 Tue, 02 Sep 2008 15:37:38 +0800，Knud Soerensen
 <4tuu4k002 sneakemail.com> 写道:
 

 Hi
 
 When building tools for manipulating d code, you practical always need a
 parser.
 
 So, why not include a d parser as part of the runtime library,
 in that way the it is much easy to write code tools.
 
 dmd itself might even use the same parser, which
 will insure that the parser support the latest version of d and it will
 be a nice start for a incremental d compiler.
 
 


 
 It's not easy to have a complete working bug free parser.
 dsource.org/projects/dparser
 


 I know this is why I made the suggestion.
 
 The idea is that tool developer should have a stable platform
 base his tool upon.
 
 Such he doesn't have to patch the parser every time a new version of dmd
 hits the web.
 
 


 
 What you're asking is simply impossible. It's equivalent to why we 
 don't have a bug-free
 frontend.
 


 Its not impossible just difficult.
 One of the first questions some people ask when
 told about a new language is "what is it written in?"
 If its not written in itself they ask why. If the answer is not compelling they
 may walk away.
 If D ever intends to supplant C as the main systems programming language
 it will have to get over this hurdle.
 A problem is that the language is itself not that stable. You could write a D
 compiler in D1.0 but why bother when it will soon be obsolete. Writing 
 a D compiler in
 D2.0 is a moving target which makes it harder to hit but to quote full 
 metal jacket
 "you've just got to lead them a bit".
 
 Python has a python parser written in python. The main interpreter is 
 written in C for portability.
 That is a good reason and the same reason applies for D. Why in this 
 day and age C++ isn't considered
 portable by most such project is beyond me.
 I particularly like gcc's approach of bootstraping itself to full 
 functionality. Its a shame the insides
 are so gnarly.


 
 I completely agree. Aside from the sheer prestige of having a D 
 compiler written in D, I think the language and especially the compiler 
 & toolchain quality itself would benefit from Walter excessively using 
 his   own language. After all, he has to walk around the same traps 
 everybody else does when using D/DMD. I also think D should provide a 
 whole toolchain written in D1, namely frontend, backend, testing, 
 documentation and building (we have the last one already with DSSS, 
 fortunately). Another benefit of this would include the possibility to 
 actually use the D frontend for third party tools, since it's written 
 in D. Of course, we have an open source frontend already, but it's 
 written in C and poorly documented - no offense intended -, thus 
 actually not really usable unless you spend quite some time digging 
 through the source and writing D wrappers for it.
 
 Frankly said, I would have thought of D1 written in D1 as the next step 
 in  language development, instead of a "forked" experimental D2 
 compiler. But that's just me.
 
 Kind regards,
 Alex


I think that having a compiler of a language written in itself is 
certainly nice from the intellectual point of view, but not immediately 
useful in any sense, and frankly unimportant for most people, even if 
it gives some real benefits to the language development.

Anyway if for you it is so important go and help out
	http://code.google.com/p/dil/
:)
Fawzi
Sep 06 2008
next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Fawzi Mohamed wrote:

 On 2008-09-06 19:56:25 +0200, Alexander Panek 
 <alexander.panek brainsware.org> said:
 

 Bruce Adams wrote:

 On Wed, 03 Sep 2008 16:33:11 +0100, davidl <davidl 126.com> wrote:


 在 Wed, 03 Sep 2008 21:51:47 +0800，Knud Soerensen 
 <4tuu4k002 sneakemail.com> 写道:


 davidl wrote:

 在 Tue, 02 Sep 2008 15:37:38 +0800，Knud Soerensen
 <4tuu4k002 sneakemail.com> 写道:


 Hi

 When building tools for manipulating d code, you practical always 
 need a
 parser.

 So, why not include a d parser as part of the runtime library,
 in that way the it is much easy to write code tools.

 dmd itself might even use the same parser, which
 will insure that the parser support the latest version of d and 
 it will
 be a nice start for a incremental d compiler.


 It's not easy to have a complete working bug free parser.
 dsource.org/projects/dparser


 I know this is why I made the suggestion.

 The idea is that tool developer should have a stable platform
 base his tool upon.

 Such he doesn't have to patch the parser every time a new version 
 of dmd
 hits the web.


 What you're asking is simply impossible. It's equivalent to why we 
 don't have a bug-free
 frontend.


 Its not impossible just difficult.
 One of the first questions some people ask when
 told about a new language is "what is it written in?"
 If its not written in itself they ask why. If the answer is not 
 compelling they
 may walk away.
 If D ever intends to supplant C as the main systems programming language
 it will have to get over this hurdle.
 A problem is that the language is itself not that stable. You could 
 write a D
 compiler in D1.0 but why bother when it will soon be obsolete. 
 Writing a D compiler in
 D2.0 is a moving target which makes it harder to hit but to quote 
 full metal jacket
 "you've just got to lead them a bit".

 Python has a python parser written in python. The main interpreter is 
 written in C for portability.
 That is a good reason and the same reason applies for D. Why in this 
 day and age C++ isn't considered
 portable by most such project is beyond me.
 I particularly like gcc's approach of bootstraping itself to full 
 functionality. Its a shame the insides
 are so gnarly.


 I completely agree. Aside from the sheer prestige of having a D 
 compiler written in D, I think the language and especially the 
 compiler & toolchain quality itself would benefit from Walter 
 excessively using his   own language. After all, he has to walk around 
 the same traps everybody else does when using D/DMD. I also think D 
 should provide a whole toolchain written in D1, namely frontend, 
 backend, testing, documentation and building (we have the last one 
 already with DSSS, fortunately). Another benefit of this would include 
 the possibility to actually use the D frontend for third party tools, 
 since it's written in D. Of course, we have an open source frontend 
 already, but it's written in C and poorly documented - no offense 
 intended -, thus actually not really usable unless you spend quite 
 some time digging through the source and writing D wrappers for it.

 Frankly said, I would have thought of D1 written in D1 as the next 
 step in  language development, instead of a "forked" experimental D2 
 compiler. But that's just me.

 Kind regards,
 Alex


 
 I think that having a compiler of a language written in itself is 
 certainly nice from the intellectual point of view, but not immediately 
 useful in any sense, and frankly unimportant for most people, even if it 
 gives some real benefits to the language development.


There might not be an immediate impact of glory, but still, my point 
about third party tools still stands. The DMD frontend as it is now is 
not easily usable as such. Thus, it's not only "certainly nice from the 
intellectual point of view", but also from a practical point of view - 
i.e. the view of any developer that might want to interact with the 
semantics of D code that is not compiled with the program.


 Anyway if for you it is so important go and help out
     http://code.google.com/p/dil/
 :)


I know about dil, and I neither have the qualification nor the time to 
work on a compiler. I'm already involved in too many projects around D. ;)

Kind regards,
Alex
Sep 06 2008
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Fawzi Mohamed wrote:

 I think that having a compiler of a language written in itself is 
 certainly nice from the intellectual point of view, but not immediately 
 useful in any sense, and frankly unimportant for most people, even if it 
 gives some real benefits to the language development.


Actually, I was mulling over the idea this afternoon, and I think there 
actually could be some major advantages to having the compiler 
implemented in D.

Depending on the architecture, of course, it might be much easier to 
load the compiler as a library. Then you could do all sorts of neat 
things like compiling and loading code on the fly.

    char[] sourcecode = getSourcecodeFromSomewhere();
    ASTCodeModule myModule = parser.parse(sourcecode);

At this point, with the compiler exposing a well-defined API for all of 
its internal representations, you could add your own hooks to operate on 
AST nodes between those phases.

    foreach (ClassDeclaration clazz; myModule.classes) {
       FunctionDeclaration[] methods = clazz.publicFunctions;
       foreach (auto method; methods) {
          decorateMethodWithTraceLogging(method);
       }
    }

And, if the linker & loader were also written in D, you could take those 
runtime-parsed and dynamically-modified pieces of code, immediately 
lining and loading them right into the application.

    SharedLib library = compiler.toLib(myModule);

    // Maybe write the library to a file
    library.emit(`C:\path\to\my-library.lib`);

    // ...Or execute the code directly
    void delegate() entry = library.entryPoint;
    entry.execute();

The .NET framework has some of this kind of functionality (in 
Reflection.Emit), allowing programmers to build executable code, 
opcode-by-opcode, at runtime.

The resultant code is subject to the same JIT compilation as any other 
.NET code.

A good example of its usage is in the Regex implementation, in the .NET 
standard library. It builds a custom function, with raw GOTO opcodes and 
everything, based on the regex string passed into the constructor at 
runtime. Consequently, the .NET regex engine is very very efficient.

The same kind of thing exists in the Tango regex engine -- you can 
generate and compile D code from a regex -- but only if the regex string 
is known at compile-time.

Furthermore, if the D compiler was written in D, and if it could spawn 
its own subordinate instances of the compiler on the fly, immediately 
loading compiled code into executable memory, think of how that would 
expand the power of CTFE. Any legal function would be callable at 
compile-time just as easily as at runtime.

The opposite would be true too. You'd be able to generate and compile 
templates at runtime, potentially creating whole new Types (which has 
only ever been possible at compile-time). Admittedly, I can't think of 
any actual utility for runtime type-generation, but I'm sure someone 
more clever than me could think of some use for it.

Anyhow, those are the sorts of things that I think would become feasible 
if the D parser, compiler, linker, and loader were all written in D.

Calling the compiler dynamically from user code, or from within the 
compiler itself, could be hugely powerful.

(NOTE: I'm not actually *advocating* any of this. Just musing. There are 
plenty of reasons *not* to write the compiler in D, such as already 
having done ten years of work (more on the backend) to refine the 
existing compiler.)

--benj
Sep 10 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Benji Smith:

 Depending on the architecture, of course, it might be much easier to 
 load the compiler as a library. Then you could do all sorts of neat 
 things like compiling and loading code on the fly.


This is very nice.



 A good example of its usage is in the Regex implementation, in the .NET 
 standard library. It builds a custom function, with raw GOTO opcodes and 
 everything, based on the regex string passed into the constructor at 
 runtime. Consequently, the .NET regex engine is very very efficient.


I don't know how mono Regex are done, but they are quite slow compared to most
of the other ones:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all



 (NOTE: I'm not actually *advocating* any of this. Just musing. There are 
 plenty of reasons *not* to write the compiler in D, such as already 
 having done ten years of work (more on the backend) to refine the 
 existing compiler.)


I think your ideas don't touch the backend, so it can be the normal LLVM. A D
compiler with a D front-end and a LLVM back-end sounds like a nice idea to me.

And the authors of the hopefully-to-be-compiler 'dil' probably think those
ideas aren't that bad :-)

Bye,
bearophile
Sep 10 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
bearophile wrote:

 Benji Smith:

 A good example of its usage is in the Regex implementation, in the .NET 
 standard library. It builds a custom function, with raw GOTO opcodes and 
 everything, based on the regex string passed into the constructor at 
 runtime. Consequently, the .NET regex engine is very very efficient.


 
 I don't know how mono Regex are done, but they are quite slow compared to most
of the other ones:
 http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all


Well I'll be damned. You're right.

I just wrote a few tests, performing identical regex operations in both 




Weird. I wonder why.

--benji
Sep 10 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Benji Smith:


 I just wrote a few tests, performing identical regex operations in both 




If you have a TCL interpreter close to you, I suggest you to try your
benchmarks again, you will see other curious results :-) (If you don't have
TCL, or you don't want to learn how to use it, you can also try Python/Perl
REs, but they are sometimes less efficient than TCL ones).



 Weird. I wonder why.


I don't know. There are several ways to speed up a RE engine, so maybe Java
regex is more refined.

Bye,
bearophile
Sep 10 2008
prev sibling parent reply Sascha Katzner <sorry.no spam.invalid> writes:
Alexander Panek wrote:

 I completely agree. Aside from the sheer prestige of having a D compiler 
 written in D, I think the language and especially the compiler & 
 toolchain quality itself would benefit from Walter excessively using his 
  own language. After all, he has to walk around the same traps everybody 
 else does when using D/DMD. I also think D should provide a whole 
 toolchain written in D1, namely frontend, backend, testing, 
 documentation and building (we have the last one already with DSSS, 
 fortunately). Another benefit of this would include the possibility to 
 actually use the D frontend for third party tools, since it's written in 
 D. Of course, we have an open source frontend already, but it's written 
 in C and poorly documented - no offense intended -, thus actually not 
 really usable unless you spend quite some time digging through the 
 source and writing D wrappers for it.
 
 Frankly said, I would have thought of D1 written in D1 as the next step 
 in  language development, instead of a "forked" experimental D2 
 compiler. But that's just me.


After that we could also finally get rid of the C runtime library on 
this way and reduce the overall size of the compiled applications. These 
are two further important points - at least in my opinion.

In VC I'd love the fact that it is possible to write applications that 
are only a few kb small and also to compile them without including the C 
Runtime library at all. It would be great if that was also possible in D.

LLAP,
Sascha
Sep 07 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sascha Katznerz:

 After that we could also finally get rid of the C runtime library on 
 this way and reduce the overall size of the compiled applications. These 
 are two further important points - at least in my opinion.


How much big is the C runtime compared to the D runtime (GC, etc)?

Bye,
bearophile
Sep 07 2008
parent Alexander Panek <alexander.panek brainsware.org> writes:
bearophile wrote:

 Sascha Katznerz:

 After that we could also finally get rid of the C runtime library on 
 this way and reduce the overall size of the compiled applications. These 
 are two further important points - at least in my opinion.


 
 How much big is the C runtime compared to the D runtime (GC, etc)?


It's small, of course, but it's there, hanging around actually 
unnecessarily since all functionality can be implemented in D, too 
(syscalls, anyone? - there's even a project already doing this to avoid 
having to use the C runtime).

Kind regards,
Alex
Sep 07 2008
prev sibling parent reply "David Wilson" <dw botanicus.net> writes:
2008/9/6 Bruce Adams <tortoise_74 yeah.who.co.uk>:


 Python has a python parser written in python. The main interpreter is
 written in C for portability.
 That is a good reason and the same reason applies for D. Why in this day and
 age C++ isn't considered
 portable by most such project is beyond me.
 I particularly like gcc's approach of bootstraping itself to full
 functionality. Its a shame the insides
 are so gnarly.


FYI, one of the GCC maintainers (Ian Lance Taylor) recently created a
branch of GCC that begins to introduce template usage in the GCC
source itself.

http://www.airs.com/ian/cxx-slides.pdf


David


 Regards,

 Bruce.
Sep 07 2008
parent reply "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Mon, 08 Sep 2008 04:38:34 +0100, David Wilson <dw botanicus.net> wrote:


 2008/9/6 Bruce Adams <tortoise_74 yeah.who.co.uk>:


 Python has a python parser written in python. The main interpreter is
 written in C for portability.
 That is a good reason and the same reason applies for D. Why in this  
 day and
 age C++ isn't considered
 portable by most such project is beyond me.
 I particularly like gcc's approach of bootstraping itself to full
 functionality. Its a shame the insides
 are so gnarly.


 FYI, one of the GCC maintainers (Ian Lance Taylor) recently created a
 branch of GCC that begins to introduce template usage in the GCC
 source itself.

 http://www.airs.com/ian/cxx-slides.pdf


 David


Its been suggested before. I even wanted to do it myself but I never had  
sufficient
time or inclination. I, probably like many others, went for a roll your  
own approach instead
before being distracted. Someone at google might actually have the  
resources to do it.
But come on its 2008. If it was going to happen it should have been years  
ago.
Still relating to this article are a few more links:

http://www.airs.com/blog/archives/187
http://gcc.gnu.org/ml/fortran/2008-06/msg00218.html
http://scaryreasoner.wordpress.com/2008/08/21/so-theyre-going-to-rewrite-gcc-in-c-eh/
http://lwn.net/Articles/286539/

Notice how quickly the language war started.
Now the really interesting question is what progress has been made since  
June 18th?

Anyone have time to check the source tree for bookins?
Sep 08 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Sep 8, 2008 at 4:47 PM, Bruce Adams <tortoise_74 yeah.who.co.uk> wrote:

 On Mon, 08 Sep 2008 04:38:34 +0100, David Wilson <dw botanicus.net> wrote:


 2008/9/6 Bruce Adams <tortoise_74 yeah.who.co.uk>:


 Python has a python parser written in python. The main interpreter is
 written in C for portability.
 That is a good reason and the same reason applies for D. Why in this day
 and
 age C++ isn't considered
 portable by most such project is beyond me.
 I particularly like gcc's approach of bootstraping itself to full
 functionality. Its a shame the insides
 are so gnarly.


 FYI, one of the GCC maintainers (Ian Lance Taylor) recently created a
 branch of GCC that begins to introduce template usage in the GCC
 source itself.

 http://www.airs.com/ian/cxx-slides.pdf


 David


 Its been suggested before. I even wanted to do it myself but I never had
 sufficient
 time or inclination. I, probably like many others, went for a roll your own
 approach instead
 before being distracted. Someone at google might actually have the resources
 to do it.


The funny thing to me is that the difference in code shown in that
presentation doesn't really strike me as much of an improvement.   If
that's the best one can come up with as a justification for moving to
C++, then perhaps it's not really worth the effort.

--bb
Sep 08 2008