www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Writing/Creating files at compile-time

reply "JDemler" <jakob.demler stud-mail.uni-wuerzburg.de> writes:
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.
Aug 09 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 09 2015
next sibling parent reply "cym13" <cpicard openmailbox.org> writes:
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.
Aug 09 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Aug 09 2015
next sibling parent reply "jmh530" <john.michael.hall gmail.com> writes:
On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
 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.
Could you provide an example of your point about being careful with D's imports? I'm not sure I've had this problem. I'm happy to admit I like D's imports, especially compared with C++. Is your ideal alternative something like C's processor or something else?
Aug 09 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 10/08/2015 2:38 a.m., jmh530 wrote:
 On Sunday, 9 August 2015 at 14:00:55 UTC, Rikki Cattermole wrote:
 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.
Could you provide an example of your point about being careful with D's imports? I'm not sure I've had this problem.
1. The biggest issue is actually a bug. With subdirectories not working on Windows. Yes, bug but a BIG problem. 2. They promote using them all over the place, when in reality with CTFE you shouldn't. You should be very careful when you initiate these sort of things. E.g. Do it in one are of the program so you don't have to grep to find where they are declared. But alas, most of it is just intuition. I don't think it'll play well if you do anything crazy. But hey I'm the only one that does that sort of thing so no worries there ;) On that note, when I began working on Developing with compile time in mind[0], string imports didn't exist. So I should really add a bit about that.
 I'm happy to admit I like D's imports, especially compared with C++. Is
 your ideal alternative something like C's processor or something else?
Bin2D[1] is my preferred processor. Note, I'm the author. Pros: - Typically these resources are long lived, so files that contain the contents are just as viable - Can work for any asset files - Can take in directories and even sub directories - Can export once program started - Usable at runtime and compile time Cons: - Larger input files ~2-3 larger - Required to run as a preprocessor over input files [0] https://leanpub.com/ctfe [1] https://github.com/rikkimax/Bin2D
Aug 09 2015
parent "jmh530" <john.michael.hall gmail.com> writes:
On Sunday, 9 August 2015 at 14:50:21 UTC, Rikki Cattermole wrote:
 Bin2D[1] is my preferred processor. Note, I'm the author.
I'll take a look. Thanks.
Aug 09 2015
prev sibling parent reply "JDemler" <jakob.demler stud-mail.uni-wuerzburg.de> writes:
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).
Aug 09 2015
next sibling parent "Etienne" <etcimon gmail.com> writes:
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 :)
Aug 09 2015
prev sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Aug 09 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/9/15 9:57 AM, cym13 wrote:
 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.
Where is the definition of the other one? -- Andrei
Aug 09 2015
prev sibling parent reply "JDemler" <jakob.demler stud-mail.uni-wuerzburg.de> writes:
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 next step is a DIP on which further discussion is based? I would be willing to provide one.
Aug 09 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Aug 09 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 09 Aug 2015 09:07:49 +0000, JDemler wrote:

 We can read files at compile-time:
=20
    enum file =3D import(fileName);
=20
 But we cannot write to a file or create files at compile time.
=20
 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.
=20
 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=20 listings! and stat()! and unlink()! and wow, how can we live without http=20 downloader?! and... this road has no end, and the problem already has a solution:=20 preprocessing step. nothing stops you from writing your preprocessors in=20 D and run 'em as a part of your build script.=
Aug 09 2015
next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
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.
Aug 09 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Aug 09 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote:

 I think you mean dlopen, dlsym and dlclose. Not full file system access
 geez.
and root privs requirement. just to complement it all.
 We are already getting so close to have a full blown CTFE implementation
 that it isn't funny.
i'm starting to think that CTFE was a big mistake. while it's ok in=20 languages like Forth and Scheme, it seems to suits c-like languages bad.=20 people feels something wrong with it, but can't exactly see what is=20 wrong. and the only way to fix it is to drop it.=
Aug 10 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 10/08/2015 9:48 p.m., ketmar wrote:
 On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote:

 I think you mean dlopen, dlsym and dlclose. Not full file system access
 geez.
and root privs requirement. just to complement it all.
 We are already getting so close to have a full blown CTFE implementation
 that it isn't funny.
i'm starting to think that CTFE was a big mistake. while it's ok in languages like Forth and Scheme, it seems to suits c-like languages bad. people feels something wrong with it, but can't exactly see what is wrong. and the only way to fix it is to drop it.
Nah, I like CTFE a lot. It's just that.. ugh we can have a full implementation that isn't the issue. It's just that we won't be committing to it. So we should understand and not try to expand upon it.
Aug 10 2015
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 10-Aug-2015 13:22, Rikki Cattermole wrote:
 On 10/08/2015 9:48 p.m., ketmar wrote:
 On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote:

 I think you mean dlopen, dlsym and dlclose. Not full file system access
 geez.
and root privs requirement. just to complement it all.
 We are already getting so close to have a full blown CTFE implementation
 that it isn't funny.
i'm starting to think that CTFE was a big mistake. while it's ok in languages like Forth and Scheme, it seems to suits c-like languages bad. people feels something wrong with it, but can't exactly see what is wrong. and the only way to fix it is to drop it.
Nah, I like CTFE a lot. It's just that.. ugh we can have a full implementation that isn't the issue. It's just that we won't be committing to it. So we should understand and not try to expand upon it.
Rather the only problem with CTFE is that it should to be within factor of x10 slower then real-time version not x1000 times slower. -- Dmitry Olshansky
Aug 10 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 10/08/2015 10:31 p.m., Dmitry Olshansky wrote:
 On 10-Aug-2015 13:22, Rikki Cattermole wrote:
 On 10/08/2015 9:48 p.m., ketmar wrote:
 On Mon, 10 Aug 2015 16:08:43 +1200, Rikki Cattermole wrote:

 I think you mean dlopen, dlsym and dlclose. Not full file system access
 geez.
and root privs requirement. just to complement it all.
 We are already getting so close to have a full blown CTFE
 implementation
 that it isn't funny.
i'm starting to think that CTFE was a big mistake. while it's ok in languages like Forth and Scheme, it seems to suits c-like languages bad. people feels something wrong with it, but can't exactly see what is wrong. and the only way to fix it is to drop it.
Nah, I like CTFE a lot. It's just that.. ugh we can have a full implementation that isn't the issue. It's just that we won't be committing to it. So we should understand and not try to expand upon it.
Rather the only problem with CTFE is that it should to be within factor of x10 slower then real-time version not x1000 times slower.
Meh, thats a problem with the implementation. Not so much with the feature set or rather the desired feature set.
Aug 10 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 10 Aug 2015 22:22:49 +1200, Rikki Cattermole wrote:

 Nah, I like CTFE a lot.
if it will ever be augmented with AST macros... yes. until then, people=20 will try to bolt extensions on it again and again, and i have a feeling=20 that CTFE engine will become another abomination that makes D weirder,=20 yet cannot be dropped due to "it's already used in too much D code".=
Aug 10 2015
prev sibling next sibling parent reply "ChangLong" <changlon gmail.com> writes:
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");
Aug 09 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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...
Aug 10 2015
parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Monday, 10 August 2015 at 07:02:44 UTC, Iain Buclaw wrote:
 On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
 what will bing D more awesomeness is a ctfe execute.

 enum file = execute("shell scripts");
I don't think so...
Its basically as bad, but the execute is faaaarr more useful.
Aug 10 2015
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 10 Aug 2015 08:33:49 +0000, Tofu Ninja wrote:

 On Monday, 10 August 2015 at 07:02:44 UTC, Iain Buclaw wrote:
 On 10 August 2015 at 07:54, ChangLong via Digitalmars-d
 what will bing D more awesomeness is a ctfe execute.

 enum file =3D execute("shell scripts");
I don't think so...
=20 Its basically as bad, but the execute is faaaarr more useful.
but... you know what? there are shell scripts, and build scripts, and=20 such things, and hey, they can execute other scripts!=
Aug 10 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
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.
Aug 10 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
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.
Aug 10 2015
next sibling parent reply "lobo" <swamplobo gmail.com> writes:
On Monday, 10 August 2015 at 07:50:29 UTC, Ola Fosheim Grøstad 
wrote:
 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.
While I agree with you I am curious; where would the compiler place its artefacts and why can't "export" write to the same place? The way I see it files created by export would be transient anyway, generated each time you compile. bye, lobo
Aug 10 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 10 August 2015 at 08:03:47 UTC, lobo wrote:
 While I agree with you I am curious; where would the compiler 
 place its artefacts and why can't "export" write to the same 
 place?
I think that is an implementation detail and not a language-issue.
 The way I see it files created by export would be transient 
 anyway, generated each time you compile.
Yes, or cached, but it should not be a file. You might want the ability to build resources (e.g. for Apple ios/osx bundles), but then you would need compiler support for those resource bundles. E.g. create a bundle as a "database" and then populate it programatically. If you go down the route of generating files you probably also would also need to build in "make" like dependency resolution so that the resources are built in the correct order... Another point: if "export" is needed to generate D-files then one would be better off adding AST-macros instead and generate the AST for whole modules in-memory. Saving the AST to disk for inspection would be a compiler-pragma.
Aug 10 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 10 August 2015 at 10:59, via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Monday, 10 August 2015 at 08:03:47 UTC, lobo wrote:
 While I agree with you I am curious; where would the compiler place its
 artefacts and why can't "export" write to the same place?
I think that is an implementation detail and not a language-issue.
 The way I see it files created by export would be transient anyway,
 generated each time you compile.
Yes, or cached, but it should not be a file. You might want the ability to build resources (e.g. for Apple ios/osx bundles), but then you would need compiler support for those resource bundles. E.g. create a bundle as a "database" and then populate it programatically. If you go down the route of generating files you probably also would also need to build in "make" like dependency resolution so that the resources are built in the correct order... Another point: if "export" is needed to generate D-files then one would be better off adding AST-macros instead and generate the AST for whole modules in-memory. Saving the AST to disk for inspection would be a compiler-pragma.
Who said anything about D-files? import() accepts any arbitrary text that you may want to embed in a program.
Aug 10 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 10 August 2015 at 09:55:51 UTC, Iain Buclaw wrote:
 Who said anything about D-files?  import() accepts any 
 arbitrary text that you may want to embed in a program.
And that is not a problem if it is reading a static file from the source-bundle, conceptually it just means you have split your source code into multiple files.
Aug 10 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 10 Aug 2015 07:50:27 +0000, Ola Fosheim Gr=C3=B8stad wrote:

 Ugh=E2=80=A6 please don't add more ugly features that has to be ripped ou=
t to
 bring the language to a sane state.
hear, hear.=
Aug 10 2015