Long - sorry...

One of the issues that people have long had with C/++ has been the necessity of building and maintaining, by hand, both header and code files for libraries.

With that in mind, I've just started work (with a jump start from dmdfe - thanks Ben Hinkle!) to 'finish' the symbol-file generation that is already built-in to the reference compiler and about (say) 90% completed.

The big difference is that the 'symbols' this version will emit will be in the form of a compiler portable 'header' format, if you will (*).

The reasons for doing this is simple: Make D more appealing to 3rd party library developers by getting rid of manually supporting two versions of code for closed-source libraries, and to make the 'symbol file' idea portable between D compilers and useful to other tools that understand the D language (**).

The ultimate goal would be to include this functionality in the language spec. and, therefore, the compiler itself once it is adequately tested and IF it proves to be useful, and of course if Walter agrees to it.

The questions are:

- How important is this? For example, to get 3rd party lib. developers
interested in developing libs. for D?
- How useful will this be?
- How important is it to specify as a part of the language and as a job for the
compiler instead of a stand-alone tool (bare in mind that this tool HAS to stay
in sync. with a conforming compiler because it is generating code)?
- What priority should this have over, say, including a doc. generator in the
compiler itself (assuming limited resources and the desire to avoid compiler
bloat)?

The reason for the last question is that I was a bit dismayed that the recent thread on documentation, while very important, seems by the tone of things to have been given priority over some other functionality like this (that actually needs a compiler to be done well because it is, after all, emitting code and not documentation).

Thanks,

- Dave

(*) Basically what I have planned is that it will emit everything in the original source file except function bodies, compiler conditionals, code rightfully omitted by compiler conditionals, invariant and unittest blocks. It will all be in a form that will be understood by any verion-level compliant D compiler (and perhaps "pretty printed" as well). I haven't decided on emitting template code yet, at least for the first version.

(**) I could care less if you want to distribute your source code or not, my motivation is for the good of the D language. D shouldn't carry on this part of the C lineage.

> - How important is this? For example, to get 3rd party lib. developers
> interested in developing libs. for D?
> - How useful will this be?
> - How important is it to specify as a part of the language and as a job
for the
> compiler instead of a stand-alone tool (bare in mind that this tool HAS to
stay
> in sync. with a conforming compiler because it is generating code)?
> - What priority should this have over, say, including a doc. generator in
the
> compiler itself (assuming limited resources and the desire to avoid
compiler
> bloat)?

- Really important
- Super useful
- Definetly would want it built-in to the compiler, maintaing such a tool
would suck
- Don't know on that one , I imagine both would be important.

Charlie


"Dave" <Dave_member@pathlink.com> wrote in message news:dfvhj9$m50$1@digitaldaemon.com...
>
> Long - sorry...
>
> One of the issues that people have long had with C/++ has been the
necessity of
> building and maintaining, by hand, both header and code files for
libraries.
>
> With that in mind, I've just started work (with a jump start from dmdfe -
thanks
> Ben Hinkle!) to 'finish' the symbol-file generation that is already
built-in to
> the reference compiler and about (say) 90% completed.
>
> The big difference is that the 'symbols' this version will emit will be in
the
> form of a compiler portable 'header' format, if you will (*).
>
> The reasons for doing this is simple: Make D more appealing to 3rd party
library
> developers by getting rid of manually supporting two versions of code for closed-source libraries, and to make the 'symbol file' idea portable
between D
> compilers and useful to other tools that understand the D language (**).
>
> The ultimate goal would be to include this functionality in the language
spec.
> and, therefore, the compiler itself once it is adequately tested and IF it proves to be useful, and of course if Walter agrees to it.
>
> The questions are:
>
> - How important is this? For example, to get 3rd party lib. developers
> interested in developing libs. for D?
> - How useful will this be?
> - How important is it to specify as a part of the language and as a job
for the
> compiler instead of a stand-alone tool (bare in mind that this tool HAS to
stay
> in sync. with a conforming compiler because it is generating code)?
> - What priority should this have over, say, including a doc. generator in
the
> compiler itself (assuming limited resources and the desire to avoid
compiler
> bloat)?
>
> The reason for the last question is that I was a bit dismayed that the
recent
> thread on documentation, while very important, seems by the tone of things
to
> have been given priority over some other functionality like this (that
actually
> needs a compiler to be done well because it is, after all, emitting code
and not
> documentation).
>
> Thanks,
>
> - Dave
>
> (*) Basically what I have planned is that it will emit everything in the original source file except function bodies, compiler conditionals, code rightfully omitted by compiler conditionals, invariant and unittest
blocks. It
> will all be in a form that will be understood by any verion-level
compliant D
> compiler (and perhaps "pretty printed" as well). I haven't decided on
emitting
> template code yet, at least for the first version.
>
> (**) I could care less if you want to distribute your source code or not,
my
> motivation is for the good of the D language. D shouldn't carry on this
part of
> the C lineage.
>
>

On Sat, 10 Sep 2005 21:01:29 +0000 (UTC), Dave wrote:

> I've just started work ...that will emit (symbols) in the
> form of a compiler portable 'header' format

...

> 
> The questions are:
> 
> - How important is this? For example, to get 3rd party lib. developers interested in developing libs. for D?

Very.

> - How useful will this be?

Extremely.

> - How important is it to specify as a part of the language and as a job for the compiler instead of a stand-alone tool (bare in mind that this tool HAS to stay in sync. with a conforming compiler because it is generating code)?

Essential.

> - What priority should this have over, say, including a doc. generator in the compiler itself (assuming limited resources and the desire to avoid compiler bloat)?

Much Higher.

-- 
Derek Parnell
Melbourne, Australia
11/09/2005 9:40:40 AM

"Dave" <Dave_member@pathlink.com> wrote in message news:dfvhj9$m50$1@digitaldaemon.com...
> (**) I could care less if you want to distribute your source code or not,
my
> motivation is for the good of the D language. D shouldn't carry on this
part of
> the C lineage.

It's useful even if you do distribute source code. Look at gc.d and object.d, for example. There's just no good reason to have to reparse the whole garbage collector and its support code for every compilation <g>.

I vaguely recall Walter saying he's interested in getting the compiler to do this (presumably activated by a switch like -h/-headers) and I also think I remember Derek saying he'd like to get Build to do it, as well...  Maybe you ought to coordinate with one or both of them on this?  I'd /love/ to see this feature a reality!  Its on my personal wish-list.

-- Chris Sauls

Yes D very much needs reflection and emitting.

can I get a copy of that source by chance? maybe this could be added to
something like dflect....

Walter, can we get an official statement regarding reflection? is this
feature going to be added to the language and if so what is its priority
and possible timeframe.

Dave wrote:
> Long - sorry...
> 
> One of the issues that people have long had with C/++ has been the necessity of
> building and maintaining, by hand, both header and code files for libraries.
> 
> With that in mind, I've just started work (with a jump start from dmdfe - thanks
> Ben Hinkle!) to 'finish' the symbol-file generation that is already built-in to
> the reference compiler and about (say) 90% completed.
> 
> The big difference is that the 'symbols' this version will emit will be in the
> form of a compiler portable 'header' format, if you will (*).
> 
> The reasons for doing this is simple: Make D more appealing to 3rd party library
> developers by getting rid of manually supporting two versions of code for
> closed-source libraries, and to make the 'symbol file' idea portable between D
> compilers and useful to other tools that understand the D language (**).
> 
> The ultimate goal would be to include this functionality in the language spec.
> and, therefore, the compiler itself once it is adequately tested and IF it
> proves to be useful, and of course if Walter agrees to it.
> 
> The questions are:
> 
> - How important is this? For example, to get 3rd party lib. developers
> interested in developing libs. for D?
> - How useful will this be?
> - How important is it to specify as a part of the language and as a job for the
> compiler instead of a stand-alone tool (bare in mind that this tool HAS to stay
> in sync. with a conforming compiler because it is generating code)?
> - What priority should this have over, say, including a doc. generator in the
> compiler itself (assuming limited resources and the desire to avoid compiler
> bloat)?
> 
> The reason for the last question is that I was a bit dismayed that the recent
> thread on documentation, while very important, seems by the tone of things to
> have been given priority over some other functionality like this (that actually
> needs a compiler to be done well because it is, after all, emitting code and not
> documentation).
> 
> Thanks,
> 
> - Dave
> 
> (*) Basically what I have planned is that it will emit everything in the
> original source file except function bodies, compiler conditionals, code
> rightfully omitted by compiler conditionals, invariant and unittest blocks. It
> will all be in a form that will be understood by any verion-level compliant D
> compiler (and perhaps "pretty printed" as well). I haven't decided on emitting
> template code yet, at least for the first version.
> 
> (**) I could care less if you want to distribute your source code or not, my
> motivation is for the good of the D language. D shouldn't carry on this part of
> the C lineage.
> 
> 

"J Thomas" <jtd514@ameritech.net> wrote in message news:dg13ke$2bff$1@digitaldaemon.com...
> Walter, can we get an official statement regarding reflection? is this feature going to be added to the language and if so what is its priority and possible timeframe.

It isn't what reflection is commonly understood as. I must say I've underestimated the desire to have such a tool.

In article <dg06lg$1mk8$2@digitaldaemon.com>, Walter Bright says...
>
>
>"Dave" <Dave_member@pathlink.com> wrote in message news:dfvhj9$m50$1@digitaldaemon.com...
>> (**) I could care less if you want to distribute your source code or not,
>my
>> motivation is for the good of the D language. D shouldn't carry on this
>part of
>> the C lineage.
>
>It's useful even if you do distribute source code. Look at gc.d and object.d, for example. There's just no good reason to have to reparse the whole garbage collector and its support code for every compilation <g>.
>

Another great reason - probably end up just as important as the other reasons once all is said and done, I think, because of the better build speed.

And also to encourage people to develop RAD tools for D (two of the reasons I think that demand for C++ RAD tools never caught on - a bear to manage and automatically maintain 2 sets of files in the RAD IDE, and build time).