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.
