On Sunday, 9 August 2015 at 21:48:13 UTC, JDemler wrote:
> On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
>> On 10/08/2015 1:57 a.m., cym13 wrote:
>>> On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
>>>> On 8/9/15 5:07 AM, JDemler wrote:
>>>>> [...]
>>>>
>>>> I think this is an interesting pursuit that closes the circle on a
>>>> number of issues, such as debuggability and compilation speed of mixin
>>>> code. -- Andrei
>>>
>>> The moment this is added to D, we will have two complete languages in
>>> one: an interpreted one at compile-time and another at runtime.
>>>
>>> While I find this interesting, I wonder wether this is  a good idea or not.
>>
>> I'm actually at the point where I believe the addition of string import was a bad one. No. I prefer preprocessing into a D file first.
>> It irks me, you have to be pretty careful with them, but at least a preprocessed file you know _exactly_ where all files need to be for CT.
>
> Consider vibe.d's diet templates: They are compiled into d code using information of the types provided by the user.
> Without string imports at compile-time that would either result in a two-step compile process or would rely on run-time type information. Both is nothing I would like to use.
>
> Imagine the .dt files could be compiled into .dt.d files and then imported at compile-time. The development process would be much easier (debugging and examining the source files becomes trivial) and the usage would be more transparent (I see what my .dt file gets compiled into) and would have faster compile times (as Andrei mentioned).

You cam already do this I believe. You only need to write the string to a file instead of putting it through mixin. You import the module corresponding to the compiled diet template if it exists, or create it if it doesn't (at runtime). This means you get 2 runtimes though... But you also need a way to delete the .d file automatically once the .dt is changed. In the end, this is totally less convenient than writing a custom precompiler but whatever :)

On Sun, 09 Aug 2015 09:07:49 +0000, JDemler wrote:

> We can read files at compile-time:
> 
>    enum file = import(fileName);
> 
> But we cannot write to a file or create files at compile time.
> 
> Generating code at compile-time and mixing it in is fun but has a few
> flaws.
> It isn't debuggable, the generated code cannot be directly inspected (we
> have to use pragma(msg, )) and it is not possible to manually tweak it.
> 
> If we could generate source files (.d) at compile time and then import them using mixins or something else, these problems can be dealt with.

next will be full filesystem access, 'cause hey, we need directory listings! and stat()! and unlink()! and wow, how can we live without http downloader?! and...

this road has no end, and the problem already has a solution: preprocessing step. nothing stops you from writing your preprocessors in D and run 'em as a part of your build script.

On Monday, 10 August 2015 at 01:57:40 UTC, ketmar wrote:
> next will be full filesystem access, 'cause hey, we need directory listings! and stat()! and unlink()! and wow, how can we live without http downloader?! and...
>
> this road has no end, and the problem already has a solution: preprocessing step. nothing stops you from writing your preprocessors in D and run 'em as a part of your build script.

Directory listing of the string mixin directory would actually be super nice.

On 8/9/15 5:39 PM, JDemler wrote:
> The next step is a DIP on which further discussion is based?
> I would be willing to provide one.

Great. I assume it's understood it's a difficult undertaking. Looking forward to more on the topic. -- Andrei

On 10/08/2015 1:57 p.m., ketmar wrote:
> On Sun, 09 Aug 2015 09:07:49 +0000, JDemler wrote:
>
>> We can read files at compile-time:
>>
>>     enum file = import(fileName);
>>
>> But we cannot write to a file or create files at compile time.
>>
>> Generating code at compile-time and mixing it in is fun but has a few
>> flaws.
>> It isn't debuggable, the generated code cannot be directly inspected (we
>> have to use pragma(msg, )) and it is not possible to manually tweak it.
>>
>> If we could generate source files (.d) at compile time and then import
>> them using mixins or something else, these problems can be dealt with.
>
> next will be full filesystem access, 'cause hey, we need directory
> listings! and stat()! and unlink()! and wow, how can we live without http
> downloader?! and...

I think you mean dlopen, dlsym and dlclose. Not full file system access geez.

> this road has no end, and the problem already has a solution:
> preprocessing step. nothing stops you from writing your preprocessors in
> D and run 'em as a part of your build script.

We are already getting so close to have a full blown CTFE implementation that it isn't funny.

On 10/08/2015 9:48 a.m., JDemler wrote:
> On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
>> On 10/08/2015 1:57 a.m., cym13 wrote:
>>> On Sunday, 9 August 2015 at 13:51:21 UTC, Andrei Alexandrescu wrote:
>>>> On 8/9/15 5:07 AM, JDemler wrote:
>>>>> We can read files at compile-time:
>>>>>
>>>>>    enum file = import(fileName);
>>>>>
>>>>> But we cannot write to a file or create files at compile time.
>>>>>
>>>>> Generating code at compile-time and mixing it in is fun but has a few
>>>>> flaws.
>>>>> It isn't debuggable, the generated code cannot be directly
>>>>> inspected (we
>>>>> have to use pragma(msg, )) and it is not possible to manually tweak
>>>>> it.
>>>>>
>>>>> If we could generate source files (.d) at compile time and then import
>>>>> them using mixins or something else, these problems can be dealt with.
>>>>
>>>> I think this is an interesting pursuit that closes the circle on a
>>>> number of issues, such as debuggability and compilation speed of mixin
>>>> code. -- Andrei
>>>
>>> The moment this is added to D, we will have two complete languages in
>>> one: an interpreted one at compile-time and another at runtime.
>>>
>>> While I find this interesting, I wonder wether this is  a good idea
>>> or not.
>>
>> I'm actually at the point where I believe the addition of string
>> import was a bad one. No. I prefer preprocessing into a D file first.
>> It irks me, you have to be pretty careful with them, but at least a
>> preprocessed file you know _exactly_ where all files need to be for CT.
>
> Consider vibe.d's diet templates: They are compiled into d code using
> information of the types provided by the user.
> Without string imports at compile-time that would either result in a
> two-step compile process or would rely on run-time type information.
> Both is nothing I would like to use.
>
> Imagine the .dt files could be compiled into .dt.d files and then
> imported at compile-time. The development process would be much easier
> (debugging and examining the source files becomes trivial) and the usage
> would be more transparent (I see what my .dt file gets compiled into)
> and would have faster compile times (as Andrei mentioned).

Yeah this is the main use case. I just like being devils advocate a bit too much atm.

On Sunday, 9 August 2015 at 09:07:51 UTC, JDemler wrote:
> We can read files at compile-time:
>
>   enum file = import(fileName);
>
> But we cannot write to a file or create files at compile time.
>
> Generating code at compile-time and mixing it in is fun but has a few flaws.
> It isn't debuggable, the generated code cannot be directly inspected (we have to use pragma(msg, )) and it is not possible to manually tweak it.
>
> If we could generate source files (.d) at compile time and then import them using mixins or something else, these problems can be dealt with.

what will bing D more awesomeness is a ctfe execute.

enum file = execute("shell scripts");

On 10 August 2015 at 07:54, ChangLong via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 9 August 2015 at 09:07:51 UTC, JDemler wrote:
>>
>> We can read files at compile-time:
>>
>>   enum file = import(fileName);
>>
>> But we cannot write to a file or create files at compile time.
>>
>> Generating code at compile-time and mixing it in is fun but has a few
>> flaws.
>> It isn't debuggable, the generated code cannot be directly inspected (we
>> have to use pragma(msg, )) and it is not possible to manually tweak it.
>>
>> If we could generate source files (.d) at compile time and then import them using mixins or something else, these problems can be dealt with.
>
>
> what will bing D more awesomeness is a ctfe execute.
>
> enum file = execute("shell scripts");

I don't think so...

On 9 August 2015 at 11:07, JDemler via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> We can read files at compile-time:
>
>   enum file = import(fileName);
>
> But we cannot write to a file or create files at compile time.
>

So, something like:

enum contents = someCTFEStringFunction();
export(fileName, contents);

Iain.

On Monday, 10 August 2015 at 07:05:40 UTC, Iain Buclaw wrote:
> On 9 August 2015 at 11:07, JDemler via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> We can read files at compile-time:
>>
>>   enum file = import(fileName);
>>
>> But we cannot write to a file or create files at compile time.
>>
>
> So, something like:
>
> enum contents = someCTFEStringFunction();
> export(fileName, contents);

Ugh… please don't add more ugly features that has to be ripped out to bring the language to a sane state.

A compiler should be able to compile all programs on a read only filesystem. If the language requires a filesystem to compile then I consider the language broken and in need of redesign.