www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A few questions..

reply 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.
Sep 10 2005
next sibling parent "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.

Sep 10 2005
prev sibling next sibling parent 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
Sep 10 2005
prev sibling next sibling parent reply "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>.
Sep 10 2005
parent 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).
Sep 14 2005
prev sibling next sibling parent 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
Sep 11 2005
prev sibling parent reply 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.
 
 

Sep 11 2005
parent "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.
Sep 12 2005