August 10, 2015
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



August 10, 2015
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.
August 10, 2015
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.


August 10, 2015
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.

August 10, 2015
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 = execute("shell scripts");
>>
>> I don't think so...
> 
> Its basically as bad, but the execute is faaaarr more useful.

but... you know what? there are shell scripts, and build scripts, and such things, and hey, they can execute other scripts!

August 10, 2015
On Mon, 10 Aug 2015 07:50:27 +0000, 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.

hear, hear.

August 10, 2015
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.
August 10, 2015
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.

August 10, 2015
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.

August 10, 2015
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