We should not be expected to rewrite all C libraries in D. In my opinion, this is a vast understatement. We should plan to use C libraries from non-C languages for a long time.

Doing so can be difficult, primarily because you need to write your language's equivalent to the C header files.

I believe solutions to "shipping D libraries" should take the future of D as a popular language into consideration.

I believe you could secure a place in history by allowing compiled code to work together more easily, especially with respect to statically linked libraries. C style DLL/SO can work for this, but static linking is often desirable and dynamic libraries are often an annoyance.

We are being given an opportunity to address a problem.

If we address it thoughtfully, it could have a big impact.

Given this opportunity, I think those concerned with writing programs to extract API from lib files and other machinations should most definitely consider writing a language-neutral "declaration file" to replace C header files and their ilk.

Create something, document it and implement it for D. Dis- associate it from D, like GTK is disassociated from the GIMP.

From then on, developers writing re-usable compiled code could provide this declaration. People would contribute the same declaration for old libraries and the world is a happier place.

Languages would use this file as needed, instead of import modules and header files. Automatic creation of the file(s) should be well within reach as would automatic inclusion/use.

If we started writing D libraries that other languages could use by way of this interface, I think we'd be on to something.

The implementation details are probably not important yet, but I imagine you would forget OO (for now) and stay away from XML.

-- 
 kai
 tags: OMF, COFF, ELF, coff2omf, .lib, .a, SWIG, DLL, SO, COM

kai wrote:
> We should not be expected to rewrite all C libraries in D.
> In my opinion, this is a vast understatement. We should plan
> to use C libraries from non-C languages for a long time.
> 
> Doing so can be difficult, primarily because you need to
> write your language's equivalent to the C header files.
> 
> I believe solutions to "shipping D libraries" should take
> the future of D as a popular language into consideration.
> 
> I believe you could secure a place in history by allowing
> compiled code to work together more easily, especially with
> respect to statically linked libraries. C style DLL/SO can
> work for this, but static linking is often desirable and
> dynamic libraries are often an annoyance.
> 
> We are being given an opportunity to address a problem.
> 
> If we address it thoughtfully, it could have a big impact.
> 
> Given this opportunity, I think those concerned with writing
> programs to extract API from lib files and other machinations
> should most definitely consider writing a language-neutral
> "declaration file" to replace C header files and their ilk.
> 
> Create something, document it and implement it for D. Dis-
> associate it from D, like GTK is disassociated from the GIMP.
> 
> From then on, developers writing re-usable compiled code could
> provide this declaration. People would contribute the same
> declaration for old libraries and the world is a happier place.
> 
> Languages would use this file as needed, instead of import
> modules and header files. Automatic creation of the file(s)
> should be well within reach as would automatic inclusion/use.
> 
> If we started writing D libraries that other languages could
> use by way of this interface, I think we'd be on to something.
> 
> The implementation details are probably not important yet, but
> I imagine you would forget OO (for now) and stay away from XML.
> 

I think all we need is a parser for c/c++, which I've heard is very difficult to write! Although it can probably be easier if we're only dealing with header files, specially C header files (no C++).

I like the idea of language-neutral headers, but who are we to turn it into a de-facto standard? How can we do that?

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:dr8pef$2o7f$2@digitaldaemon.com...
> I think all we need is a parser for c/c++, which I've heard is very difficult to write!

I already have one. The difficulty is spending to the time to write the converter.

Walter Bright wrote:
> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:dr8pef$2o7f$2@digitaldaemon.com...
> 
>>I think all we need is a parser for c/c++, which I've heard is very difficult to write!
> 
> 
> I already have one. The difficulty is spending to the time to write the converter. 
> 
> 
How much of the relevant code/interface would you be willing to expose? Enough to let someone else wright a program to filter and extract the pertinent info?

BCS wrote:
> Walter Bright wrote:
> 
>> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:dr8pef$2o7f$2@digitaldaemon.com...
>>
>>> I think all we need is a parser for c/c++, which I've heard is very difficult to write!
>>
>>
>>
>> I already have one. The difficulty is spending to the time to write the converter.
>>
> How much of the relevant code/interface would you be willing to expose? Enough to let someone else wright a program to filter and extract the pertinent info?

How about gcc? It's Open Source, after all.