• Dave <Dave_member pathlink.com> Sep 10 2005
• "Charles" <noone nowhere.com> Sep 10 2005
• Derek Parnell <derek psych.ward> Sep 10 2005
• "Walter Bright" <newshound digitalmars.com> Sep 10 2005
• Dave <Dave_member pathlink.com> Sep 14 2005
• Chris Sauls <ibisbasenji gmail.com> Sep 11 2005
• J Thomas <jtd514 ameritech.net> Sep 11 2005
• "Walter Bright" <newshound digitalmars.com> Sep 12 2005

Dave <Dave_member pathlink.com> writes:

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.

"Charles" <noone nowhere.com> writes:

 - 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


 compiler instead of a stand-alone tool (bare in mind that this tool HAS to


 in sync. with a conforming compiler because it is generating code)?
 - What priority should this have over, say, including a doc. generator in


 compiler itself (assuming limited resources and the desire to avoid


 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


 building and maintaining, by hand, both header and code files for


 With that in mind, I've just started work (with a jump start from dmdfe -


 Ben Hinkle!) to 'finish' the symbol-file generation that is already


 the reference compiler and about (say) 90% completed.

 The big difference is that the 'symbols' this version will emit will be in


 form of a compiler portable 'header' format, if you will (*).

 The reasons for doing this is simple: Make D more appealing to 3rd party


 developers by getting rid of manually supporting two versions of code for
 closed-source libraries, and to make the 'symbol file' idea portable


 compilers and useful to other tools that understand the D language (**).

 The ultimate goal would be to include this functionality in the language


 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


 compiler instead of a stand-alone tool (bare in mind that this tool HAS to


 in sync. with a conforming compiler because it is generating code)?
 - What priority should this have over, say, including a doc. generator in


 compiler itself (assuming limited resources and the desire to avoid


 bloat)?

 The reason for the last question is that I was a bit dismayed that the


 thread on documentation, while very important, seems by the tone of things


 have been given priority over some other functionality like this (that


 needs a compiler to be done well because it is, after all, emitting code


 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


 will all be in a form that will be understood by any verion-level


 compiler (and perhaps "pretty printed" as well). I haven't decided on


 template code yet, at least for the first version.

 (**) I could care less if you want to distribute your source code or not,


 motivation is for the good of the D language. D shouldn't carry on this


 the C lineage.

Derek Parnell <derek psych.ward> writes:

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

"Walter Bright" <newshound digitalmars.com> writes:

"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,


 motivation is for the good of the D language. D shouldn't carry on this


 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>.

Dave <Dave_member pathlink.com> writes:

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,


 motivation is for the good of the D language. D shouldn't carry on this


 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).

Chris Sauls <ibisbasenji gmail.com> writes:

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

J Thomas <jtd514 ameritech.net> writes:

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.
 
 

"Walter Bright" <newshound digitalmars.com> writes:

"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.