Ted Williams schrieb:

> OK...what if the compiler, based on a switch, would generate a pre-compiled
> "module" file from the source file it is compiling.  Whenever a module is
> referenced via import, first this pre-comled file would be searched for and
> used if found, otherwise the corresponding source file would be imported as
> is now.

If i recall correctly, Walter's original plan involved caching an intermediate representation for modules in a binary format, which would as a side effect allow to do the same you propose. However, the parser has turned out so fast, that this feature lost most of its technical motivation and has been put off. Maybe Walter would implement something like that in the first commercial D compiler.

Naturally, if you liked you could take the source and implement the feature. However, this doesn't mean that the implementation would be accepted by the distributions, and there's another aspect: the implementation would be public, so as soon as D gains more users, tools will start to appear which would regain major parts of the source code from thís representation. From some point of popularity, roughly the same would happen even with format being closed. Besides, when you do a binary-only distribution, you can make it for a limited number of compilers and operating systems, thus some people won't be able to use it. So i see some people sell their libraries with source.

digc compiler driver (a neat tool by itself: see undig at dsource) can do stripped versions ("headers") of libraries.

-eye

Ilya Minkov wrote:
> Ted Williams schrieb:
> 
>> OK...what if the compiler, based on a switch, would generate a pre-compiled
>> "module" file from the source file it is compiling.  Whenever a module is
>> referenced via import, first this pre-comled file would be searched for and
>> used if found, otherwise the corresponding source file would be imported as
>> is now.
> 
> 
> If i recall correctly, Walter's original plan involved caching an intermediate representation for modules in a binary format, which would as a side effect allow to do the same you propose. However, the parser has turned out so fast, that this feature lost most of its technical motivation and has been put off. Maybe Walter would implement something like that in the first commercial D compiler.
> 
> Naturally, if you liked you could take the source and implement the feature. However, this doesn't mean that the implementation would be accepted by the distributions, and there's another aspect: the implementation would be public, so as soon as D gains more users, tools will start to appear which would regain major parts of the source code from thís representation. From some point of popularity, roughly the same would happen even with format being closed. Besides, when you do a binary-only distribution, you can make it for a limited number of compilers and operating systems, thus some people won't be able to use it. So i see some people sell their libraries with source.
> 
> digc compiler driver (a neat tool by itself: see undig at dsource) can do stripped versions ("headers") of libraries.
> 
> -eye

Some of dig has accumulated some dust since Burton Radons stopped working on it. The strip.d module is one of those parts. I've just made some improvements to it, but I'm sure it'll still malfunction on some bits of valid D code.

See also: http://www.dsource.org/forums/viewtopic.php?t=196

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

"Ted Williams" <ted.wil.no.spam@verizon.net> wrote in message news:ca01jj$7vg$1@digitaldaemon.com...
> OK...what if the compiler, based on a switch, would generate a
pre-compiled
> "module" file from the source file it is compiling.  Whenever a module is referenced via import, first this pre-comled file would be searched for
and
> used if found, otherwise the corresponding source file would be imported
as
> is now.
>
> So, to compile a library module I might have:
>
>     dmd -c -genimport myModule.d        Generates object and import file
> myModule.imp for myModule.d
>
> Then, when the libary is shipped, only the .imp files are sent with it.
>
> Probably there is a better solution, but this is my stab at it.

That's really no different from a 'strip' utility.

"Ted Williams" <ted.wil.no.spam@verizon.net> wrote in message news:c9vv4i$4ao$1@digitaldaemon.com...
> This sounds an aweful lot like header files, which I thought import was supposed to eliminiate the need for.  I have a solution in mind if you'd like to hear it.

Import does eliminate the need for it, unless you want to hide the source.

In article <c9vn3c$2qod$1@digitaldaemon.com>, Walter says...
>
>
>"Ted Williams" <ted.wil.no.spam@verizon.net> wrote in message news:c9uopb$1hkl$1@digitaldaemon.com...
>> So what you are saying is that I will have to maintain two of everything? One version with the full source to compile the library and one "stripped" version with just declarations?
>
>Yes, just like in C++. However, it would be fairly easy to write a D tool to take the source and 'strip' it.
>
>
Effiel does it this way, it has "short"
Putting both the interface and the implementation in a single file doesn't mean
those separate concepts go away