I've been searching through the documentation trying to find out if D has any facilities for separate compilation. If so, where should I look? If not, are there any plans for this in future D compilers?

Not that I'm criticizing D. I'm just struck by some of the similarities with Ada that I'm finding. D feels like Ada-lite(which is a good thing IMHO). Heck, all I need is a formal Partition Communication System, and a formalized Interfaces root library(from which to derive Interfaces.C, Interfaces.Java, Interfaces.etc, ...) and I can switch to D for all but the most demanding applications.

I've just downloaded GDC. I'll starting hacking on it and see what else would work. In the meantime, any documentation pointers?

Freejack

On Sun, 28 Aug 2005 13:23:28 -0400, Freejack wrote:

> I've been searching through the documentation trying to find out if D has any facilities for separate compilation.

Please excuse my ignorance, but what does the term "separate compilation" mean? Does it mean compiling source code only to the object file stage and then performing a separate linking phase later on?


-- 
Derek Parnell
Melbourne, Australia
29/08/2005 7:30:50 AM

On Mon, 29 Aug 2005 07:32:17 +1000, Derek Parnell wrote:

> On Sun, 28 Aug 2005 13:23:28 -0400, Freejack wrote:
> 
>> I've been searching through the documentation trying to find out if D has any facilities for separate compilation.
> 
> Please excuse my ignorance, but what does the term "separate compilation" mean? Does it mean compiling source code only to the object file stage and then performing a separate linking phase later on?

A psuedo example...

file application.d
class bar {
function foo(ItemX :in Sometype, ItemY : in Sometype, Result : out
Sometype) is separate;
}
file foox86.d
function foo(ItemX : in Sometype, ItemY : in Sometype, Result : out
Sometype)
{
	/* Write x86 Optimized foo code here */
}

file foosparc.d /* Same as above, but for sparc arch */
file fooppc.d
file foolinux.d
file foobsd.d
file foowinNT.d
etc....

The internals of foo are absolutely invisible to the user. The compiler can select(or be told) which file to use. Also...

file foox86_ver1.d
file foox86_ver2.d
file foosparc_ver1.d

All the user needs is the Interface specification. They don't even need the actual code if all their doing is checking the contract.

Ideally, a group could create their own formal generic contract and have every implementation automatically checked by the compiler statically at compile time. This can span from a few files, up to thousands.

As this is done before the compiler even gets to generating object code. So the linker doesn't even come into play.

Questions?

Freejack

On Sun, 28 Aug 2005 14:22:23 -0400, Freejack wrote:

> On Mon, 29 Aug 2005 07:32:17 +1000, Derek Parnell wrote:
> 
>> On Sun, 28 Aug 2005 13:23:28 -0400, Freejack wrote:
>> 
>>> I've been searching through the documentation trying to find out if D has any facilities for separate compilation.
>> 
>> Please excuse my ignorance, but what does the term "separate compilation" mean? Does it mean compiling source code only to the object file stage and then performing a separate linking phase later on?
> 
> A psuedo example...
> 
> file application.d
> class bar {
> function foo(ItemX :in Sometype, ItemY : in Sometype, Result : out
> Sometype) is separate;
> }
> file foox86.d
> function foo(ItemX : in Sometype, ItemY : in Sometype, Result : out
> Sometype)
> {
> 	/* Write x86 Optimized foo code here */
> }
> 
> file foosparc.d /* Same as above, but for sparc arch */
> file fooppc.d
> file foolinux.d
> file foobsd.d
> file foowinNT.d
> etc....
> 
> The internals of foo are absolutely invisible to the user. The compiler can select(or be told) which file to use. Also...
> 
> file foox86_ver1.d
> file foox86_ver2.d
> file foosparc_ver1.d
> 
> All the user needs is the Interface specification. They don't even need the actual code if all their doing is checking the contract.
> 
> Ideally, a group could create their own formal generic contract and have every implementation automatically checked by the compiler statically at compile time. This can span from a few files, up to thousands.
> 
> As this is done before the compiler even gets to generating object code. So the linker doesn't even come into play.
> 
> Questions?

Funny you should ask ...

It looks as if you are wanting to declare a class in one file, but have details of its implementation in one or more other files, which are selected by the author of the application as needed.

-- 
Derek Parnell
Melbourne, Australia
29/08/2005 8:21:17 AM

On Mon, 29 Aug 2005 08:24:26 +1000, Derek Parnell wrote:
> 
> Funny you should ask ...
> 
> It looks as if you are wanting to declare a class in one file, but have details of its implementation in one or more other files, which are selected by the author of the application as needed.

It's not just limited to classes.
You could also do...

function bar(<parameters>){
	function foo(<parameters>) is separate;
}

Or if one wants to be extremely explicit, something like...

	for function foo in unittest bar use foox86;
	/*Although this is pseudo-code, it is a logical
	directive suitable for a compiler.*/

Or something like...

	file Somearchtype.d
	Represent Sometype as{
		field1 : Machine_word;
		field2 : Integer_32;
		field3 : Address_16;
		/* Blah blah blah. */
	}

	type RGB is packed[Machine_word] of Boolean...
	/* etc... */

file application_Direct_Render.d
	Sometype Screen = <Initial parameters>
	RGB Colors;

file extension_OGL.d
	for screen use Somearchtype.Sometype.


And so on an so forth. The idea being that the Abstract declarations and the actual implementations are totally isolated into separate files. And the implementations are only visible within the "scope" that includes them.

See what I'm saying?

Freejack

In article <1xuf34283pitc.fegoyen4wbu1$.dlg@40tude.net>, Derek Parnell says...
>
>It looks as if you are wanting to declare a class in one file, but have details of its implementation in one or more other files, which are selected by the author of the application as needed.

This is what the version statement is for.  But what the OP wants works just fine with DMD--just provide a stripped header module and link against a set of pre-compiled objects.  Look at object.d for an example.


Sean