No header files?

[Yigal Chripun]

On 23/10/2009 12:37, Walter Bright wrote:
> Yigal Chripun wrote:
>> that's a different use case. *If* full sources are available than I
>> could just compile everything myself.
>> What we're talking about is commercial companies that do not provide
>> full sources. In Java this is trivial - just provide jar(s), in .Net
>> it's trivial - just provide assemblies. in D you need to provide both
>> a library file *and* di header files.
>
> I just don't see how having another file is any sort of burden. People
> have been doing it for a very long time.
>
the disadvantages of this were mentioned several times in this thread. 
People have also used horses for transportation for a very long time and 
yet they got replaced by cars and planes.

>
>> I was suggesting to convert *both* obj files and lib files to llvm
>> bit-code. such library files will still contain the metadata.
>
> I understand, but it's a lot of code to write to eliminate a file - and
> with other downsides like not being human readable.

it's mostly integration glue code but it would be much easier to do in a 
compiler that already uses LLVM as its backend like LDC. I also agree 
with other people that said that in the long term they (and I) would 
like to see the reference implementation (DMD) based on LLVM. There are 
all those benchmarks by bearophile and others that show weak spots in 
DMD compared to LLVM.
As a D user I'd like to get all the performance benefits from a modern 
otimizing back-end without the need for you to spend your precious time 
on reinventing the wheel in the DMD backend. If the reference 
implementation relies on LLVM we get all the optimizations for free and 
you'll have more time to concentrate on the D language itself.
>
>
>> what I ultimately want is to have something similar in concept to .net
>> asseblies/java Jars but with native code (no VM involved). LLVM
>> provides the infrastructure to do exactly this: the compiler generates
>> platform neutral D-assemblies (in llvm bitcode) that can be used on
>> any architecture/OS/llvm-compiler. This would also allow us to use
>> libraries written in other languages when there's an appropriate llvm
>> compiler for them (Ruby, scheme, python, etc).
>
> Right now, you can hook D up to any language that supports a C
> interface. It's not necessary to convince them to use LLVM, too.
>
No need to convince anyone - many such projects are already on their way 
pypy for python, rubinious for ruby, something for scheme, clang for 
c/c++/objective-c/objective-c++, etc..

the current way requires to write/maintain bindings and what if a 
specific project doesn't provide a C API?
in .NET you can use assemblies generated from any .NET language in your 
project. For example, you can write a C# application that uses an 
assembly generated from a F# lib. I guess in a way, I'm suggesting to 
use LLVM as an open .net like platform with native complation in mind 
instead of VM and managed code.

>
>> Another issue that's not mentioned here is shared libraries and D.
>> there's no one simple way to have D shared libraries, and especially
>> on windows (90% market share...) dlls are *not* a solution at all.
>> there are 3rd party tools like DDL but I'd like to see *one* solution
>> that works on all platforms and directly supported by D. major D
>> libraries need to be shared libs - the runtime, the stdlib, the GUI
>> libs, etc..
>
> Shared libraries are inherently not portable from system to system.

only if you consider dlls and so. Java jars are portable. so do .net 
assemblies.