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