On 7/14/2011 2:40 PM, Andrew Wiley wrote:
>
> It seems to me that a way to fix all this and guarantee CTFE-ability (which seems to be the end goal) would be to add some sort of modifier or annotation to designate that a function is CTFE-able.


Please, please, no! I hate "constexpr" in C++0x. One of the whole point of CTFE is it "just works" on regular D functions.

On Thu, Jul 14, 2011 at 6:19 PM, Walter Bright <walter at digitalmars.com>wrote:

>
>
> On 7/14/2011 2:40 PM, Andrew Wiley wrote:
>
>>
>> It seems to me that a way to fix all this and guarantee CTFE-ability (which seems to be the end goal) would be to add some sort of modifier or annotation to designate that a function is CTFE-able.
>>
>
>
> Please, please, no! I hate "constexpr" in C++0x. One of the whole point of CTFE is it "just works" on regular D functions.


I think that's excellent as well, and to be honest I don't think an annotation is a good solution, but we're going to have to come up with something here because it isn't "just working."

CTFE, traits, and mixins together make D a powerhouse for compile-time code generation, and that's pretty much what's kept me around here :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110714/e0cee1e1/attachment.html>

On Thu, Jul 14, 2011 at 9:30 PM, Andrew Wiley <wiley.andrew.j at gmail.com>wrote:

>
>
> On Thu, Jul 14, 2011 at 6:19 PM, Walter Bright <walter at digitalmars.com>wrote:
>
>>
>>
>> On 7/14/2011 2:40 PM, Andrew Wiley wrote:
>>
>>>
>>> It seems to me that a way to fix all this and guarantee CTFE-ability (which seems to be the end goal) would be to add some sort of modifier or annotation to designate that a function is CTFE-able.
>>>
>>
>>
>> Please, please, no! I hate "constexpr" in C++0x. One of the whole point of CTFE is it "just works" on regular D functions.
>
>
> I think that's excellent as well, and to be honest I don't think an annotation is a good solution, but we're going to have to come up with something here because it isn't "just working."
>
> CTFE, traits, and mixins together make D a powerhouse for compile-time code generation, and that's pretty much what's kept me around here :D
>


Could we just ship both d and di files, and make the frontend able to switch to the .d file when it needs the function source?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110714/a3ccd24d/attachment.html>

In fact, they are both shipped.? In order to use the .d files instead of the .di files change this argument in your dmd.conf file:

-I%@P%/../../src/druntime/import

to this:

-I%@P%/../../src/druntime/src


Note then, you have to be wary not to try and import some of the directories.? Such as rt and gc.


At least this can provide a test of how well CTFE will perform if we *did* switch to .d files.

Here's another idea:

What if .di put in a pragma indicating the original source of the file (auto generated by dmd -h)?? If the original source exists, then CTFE will use it instead of the .di file.

You know, thinking through this, the more I don't really understand why we are doing .di files *except* for object.di (which is hand-generated anyway).

-Steve


>________________________________
>From: Andrew Wiley <wiley.andrew.j at gmail.com>
>To: D's runtime library developers list <d-runtime at puremagic.com>
>Sent: Friday, July 15, 2011 12:31 AM
>Subject: Re: [D-runtime] Why does druntime us .di files instead of .d?
>
>
>On Thu, Jul 14, 2011 at 9:30 PM, Andrew Wiley <wiley.andrew.j at gmail.com> wrote:
>
>
>>
>>
>>On Thu, Jul 14, 2011 at 6:19 PM, Walter Bright <walter at digitalmars.com> wrote:
>>
>>
>>>
>>>On 7/14/2011 2:40 PM, Andrew Wiley wrote:
>>>
>>>
>>>>It seems to me that a way to fix all this and guarantee CTFE-ability (which seems to be the end goal) would be to add some sort of modifier or annotation to designate that a function is CTFE-able.
>>>>
>>>
>>>
Please, please, no! I hate "constexpr" in C++0x. One of the whole point of CTFE is it "just works" on regular D functions.
>>
>>
>>I think that's excellent as well, and to be honest I don't think an annotation is a good solution, but we're going to have to come up with something here because it isn't "just working."
>>
>>
>>CTFE, traits, and mixins together make D a powerhouse for compile-time code generation, and that's pretty much what's kept me around here :D
>
>
>
>
>Could we just ship both d and di files, and make the frontend able to switch to the .d file when it needs the function source??
>
>_______________________________________________
>D-runtime mailing list
>D-runtime at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/d-runtime
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110715/628bd33e/attachment-0001.html>

On Jul 13, 2011, at 4:01 PM, Jonathan M Davis wrote:

> On 2011-07-13 15:41, Walter Bright wrote:
>> On 7/13/2011 3:19 PM, Jonathan M Davis wrote:
>>> Given its heavy use of templates, I'm not sure how much that'll buy us in terms of compilation speed, and since it's all open source, I don't know why it would matter about hiding implementation details.
>> 
>> Consider the garbage collector. Should every compilation have to recompile that, too?
> 
> Since it doesn't take very long to compile, I really don't care much personally, and I think that it's just simpler to only deal with .d files. However, I'm not against the use of .di files if it speeds up compilation and doesn't have any major drawbacks. My primary concern at the moment (and why I brought it up in the first place) is that it seems to be affecting CTFE. For instance, this program
> 
> ====
> import std.stdio;
> import std.string;
> 
> enum a = strip(" hello world");
> 
> void main() {}
> ====
> 
> currently fails to compile, giving these errors:
> 
> ====
> /home/jmdavis/dmd2/linux/bin/../../src/phobos/std/string.d(1468): Error:
> _aApplycd2 cannot be interpreted at compile time, because it has no available
> source code

This function is in src/rt, which isn't publicly visible code (much like the GC).  Is there a similar example involving a module in core.*?

On Fri, 15 Jul 2011 00:40:19 +0300, Andrew Wiley <wiley.andrew.j at gmail.com> wrote:

> It seems to me that a way to fix all this and guarantee CTFE-ability (which seems to be the end goal) would be to add some sort of modifier or annotation to designate that a function is CTFE-able.

We've actually discussed this idea with Andrei on the #d IRC channel. I would suggest a more generic attribute like @exportsource which preserves the body of a function in cases where it would be stripped otherwise (including .di generation). It wouldn't need to be required, unless the user wants to use CTFE with .di files.

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net

On 13 July 2011 23:58, Walter Bright <walter at digitalmars.com> wrote:
>
>
> On 7/13/2011 2:21 PM, Jonathan M Davis wrote:
>>
>> On 2011-07-13 13:36, Walter Bright wrote:
>>>
>>> .di files are used when they are generated from .d files.
>>
>> Yes. I get that. But why are .di files generated in the first place?
>
> To 1. hide implementation details and 2. speed up compilation.
>
>> ?Phobos just uses .d files.
>
> It'll eventually migrate to .di files.

That will indeed prevent the use of CTFE.
I'm not sure how to get around that. The basic problem is that CTFE
requires a semantically-analyzed function, in order to be able to run
it. If the source is provided, then you've entirely lost the benefits
of .di files. If it's not provided, you can't do CTFE.

There are a couple of intermediate options:
Then there's the option of adding the ability to run external
functions from CTFE. A huge amount of work to implement (among other
things, you need to dynamically link to a .obj file, and you have
problems with initialization and gc use).
A deeper problem is cross-compilation: the target CPU may not the same
as the one the compiler is running on. (In fact, that's already the
case with the 64-bit compiler).
Really, you would need to specifically compile a separate version of
each function, for use by CTFE.
If you provide the function in an intermediate form, you add a host of
complications (reminds me a bit of 'export' in C++, maybe not as bad).

Sounds like a D3 feature to me.

On Wed, Jul 20, 2011 at 4:06 PM, Don Clugston <dclugston at googlemail.com>wrote:

> On 13 July 2011 23:58, Walter Bright <walter at digitalmars.com> wrote:
> >
> >
> > On 7/13/2011 2:21 PM, Jonathan M Davis wrote:
> >>
> >> On 2011-07-13 13:36, Walter Bright wrote:
> >>>
> >>> .di files are used when they are generated from .d files.
> >>
> >> Yes. I get that. But why are .di files generated in the first place?
> >
> > To 1. hide implementation details and 2. speed up compilation.
> >
> >>  Phobos just uses .d files.
> >
> > It'll eventually migrate to .di files.
>
> That will indeed prevent the use of CTFE.
> I'm not sure how to get around that. The basic problem is that CTFE
> requires a semantically-analyzed function, in order to be able to run
> it. If the source is provided, then you've entirely lost the benefits
> of .di files. If it's not provided, you can't do CTFE.
>
> There are a couple of intermediate options:
> Then there's the option of adding the ability to run external
> functions from CTFE. A huge amount of work to implement (among other
> things, you need to dynamically link to a .obj file, and you have
> problems with initialization and gc use).
> A deeper problem is cross-compilation: the target CPU may not the same
> as the one the compiler is running on. (In fact, that's already the
> case with the 64-bit compiler).
> Really, you would need to specifically compile a separate version of
> each function, for use by CTFE.
> If you provide the function in an intermediate form, you add a host of
> complications (reminds me a bit of 'export' in C++, maybe not as bad).
>
> Sounds like a D3 feature to me.
>

I realize I'm not someone that has worked in this area, but how feasible would it be to just ship both d and di files and allow the frontend to only parse the d file only when such a semantic analysis is needed? It would increase the download size, but it seems like it would maintain the compile speeds di gets you without losing CTFE. On the other hand, it could be a lot of frontend work, depending on how much file information the frontend currently maintains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d-runtime/attachments/20110720/0ff1bb0b/attachment.html>

On 2011-07-20 16:06, Don Clugston wrote:
> On 13 July 2011 23:58, Walter Bright <walter at digitalmars.com> wrote:
> > On 7/13/2011 2:21 PM, Jonathan M Davis wrote:
> >> On 2011-07-13 13:36, Walter Bright wrote:
> >>> .di files are used when they are generated from .d files.
> >> 
> >> Yes. I get that. But why are .di files generated in the first place?
> > 
> > To 1. hide implementation details and 2. speed up compilation.
> > 
> >> Phobos just uses .d files.
> > 
> > It'll eventually migrate to .di files.
> 
> That will indeed prevent the use of CTFE.
> I'm not sure how to get around that. The basic problem is that CTFE
> requires a semantically-analyzed function, in order to be able to run
> it. If the source is provided, then you've entirely lost the benefits
> of .di files. If it's not provided, you can't do CTFE.
> 
> There are a couple of intermediate options:
> Then there's the option of adding the ability to run external
> functions from CTFE. A huge amount of work to implement (among other
> things, you need to dynamically link to a .obj file, and you have
> problems with initialization and gc use).
> A deeper problem is cross-compilation: the target CPU may not the same
> as the one the compiler is running on. (In fact, that's already the
> case with the 64-bit compiler).
> Really, you would need to specifically compile a separate version of
> each function, for use by CTFE.
> If you provide the function in an intermediate form, you add a host of
> complications (reminds me a bit of 'export' in C++, maybe not as bad).
> 
> Sounds like a D3 feature to me.

That may be, but many consider CTFE to be a big enough feature that disallowing it in the standard library (which would happen if we switched it all to .di files) would be unacceptable. So, while there may be a better solution which we could implement later, the question of how to handle it now remains.

- Jonathan M Davis

On 21 July 2011 01:55, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On 2011-07-20 16:06, Don Clugston wrote:
>> On 13 July 2011 23:58, Walter Bright <walter at digitalmars.com> wrote:
>> > On 7/13/2011 2:21 PM, Jonathan M Davis wrote:
>> >> On 2011-07-13 13:36, Walter Bright wrote:
>> >>> .di files are used when they are generated from .d files.
>> >>
>> >> Yes. I get that. But why are .di files generated in the first place?
>> >
>> > To 1. hide implementation details and 2. speed up compilation.
>> >
>> >> Phobos just uses .d files.
>> >
>> > It'll eventually migrate to .di files.
>>
>> That will indeed prevent the use of CTFE.
>> I'm not sure how to get around that. The basic problem is that CTFE
>> requires a semantically-analyzed function, in order to be able to run
>> it. If the source is provided, then you've entirely lost the benefits
>> of .di files. If it's not provided, you can't do CTFE.
>>
>> There are a couple of intermediate options:
>> Then there's the option of adding the ability to run external
>> functions from CTFE. A huge amount of work to implement (among other
>> things, you need to dynamically link to a .obj file, and you have
>> problems with initialization and gc use).
>> A deeper problem is cross-compilation: the target CPU may not the same
>> as the one the compiler is running on. (In fact, that's already the
>> case with the 64-bit compiler).
>> Really, you would need to specifically compile a separate version of
>> each function, for use by CTFE.
>> If you provide the function in an intermediate form, you add a host of
>> complications (reminds me a bit of 'export' in C++, maybe not as bad).
>>
>> Sounds like a D3 feature to me.
>
> That may be, but many consider CTFE to be a big enough feature that disallowing it in the standard library (which would happen if we switched it all to .di files) would be unacceptable. So, while there may be a better solution which we could implement later, the question of how to handle it now remains.

I mean shipping Phobos only as .di files sounds like a D3 feature for this reason.