On 2012-11-27 12:28, Gor Gyolchanyan wrote:
> Basically the most important thing I miss is mutable compile-time
> variables. That's it. Everything else can be worked around.

This compiles just fine and prints "10" at compile time:

int foo ()
{
    int i = 0;
    for (; i < 10; i++) {}
    return i;
}

enum i = foo();
pragma(msg, i);

-- 
/Jacob Carlborg

It has to be in a single function. Suppose you have a variety of modules each of which has a variety of types. And you need to compose a compile-time string which involves all those types and you need to mix that string in at some point. You can't do that.


On Tue, Nov 27, 2012 at 4:33 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-27 12:28, Gor Gyolchanyan wrote:
>
>> Basically the most important thing I miss is mutable compile-time variables. That's it. Everything else can be worked around.
>>
>
> This compiles just fine and prints "10" at compile time:
>
> int foo ()
> {
>     int i = 0;
>     for (; i < 10; i++) {}
>     return i;
> }
>
> enum i = foo();
> pragma(msg, i);
>
> --
> /Jacob Carlborg
>



-- 
Bye,
Gor Gyolchanyan.

On 27 November 2012 14:36, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>wrote:

> It has to be in a single function. Suppose you have a variety of modules each of which has a variety of types. And you need to compose a compile-time string which involves all those types and you need to mix that string in at some point. You can't do that.


...what? Wanna supply some sort of context?
I've spent a lot of time generating a lot of mixin code, and while it can
be a proper pain in the arse, you can do some pretty powerful stuff. I
haven't run into many limitations.

Can you implement this use case?
Have classes mix in something,, which will register them in a single place,
which can later suppl the registered classes as a type tuple.


On Tue, Nov 27, 2012 at 7:06 PM, Manu <turkeyman@gmail.com> wrote:

> On 27 November 2012 14:36, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>wrote:
>
>> It has to be in a single function. Suppose you have a variety of modules each of which has a variety of types. And you need to compose a compile-time string which involves all those types and you need to mix that string in at some point. You can't do that.
>
>
> ...what? Wanna supply some sort of context?
> I've spent a lot of time generating a lot of mixin code, and while it can
> be a proper pain in the arse, you can do some pretty powerful stuff. I
> haven't run into many limitations.
>



-- 
Bye,
Gor Gyolchanyan.

On 27 November 2012 17:49, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com>wrote:

> Can you implement this use case?
> Have classes mix in something,, which will register them in a single
> place, which can later suppl the registered classes as a type tuple.
>

I don't do it as a type tuple, why do you need that?
I do it as a runtime registry.

I have 'mixin RegisterModule;' at the top of every module. RegisterModule looks kinda like:

mixin template RegisterModule()
{
  // produces a module constructor that collects all the things you're
interested in and registers them with a central repository.
  shared static this()
  {
    foreach(m; __traits(allMembers, mixin(moduleName!FindModules))
    {
      // work out if you're interested in 'm'
      static if(isInterested!(mixin(m)))
      {
        // register the thing you're interested in with some global registry
        RegisterThing(&mixin(m));
      }
    }
  }
}

Then I can query the registry at runtime.

If you insist it be a type tuple, you'd need to import everything into the
one location where you intend to do this work, and recursively
scan allMembers of all the imported modules. You could probably produce a
tuple that way, but the catch being that the location that generates the
tuple needs to import everything that could ever appear in the tuple.
I suspect this could only be done with a recursive template, since I don't
think foreach over allMembers can append to a tuple...

On Tuesday, 27 November 2012 at 15:49:45 UTC, Gor Gyolchanyan wrote:
> Can you implement this use case?
> Have classes mix in something,, which will register them in a single place,
> which can later suppl the registered classes as a type tuple.

This is fundamentally impossible in the D module system if the "single place" S does not import the modules where the types are defined. Even if you could append strings to a "compile-time global" in S, this still wouldn't help you in any way because if you tried to mix in the string in S, you'd get nothing but a slew of undefined symbol errors.

Maybe you can describe your use case a bit? I'm optimistic that there is a solution which is not radically incompatible with the design of D.

David

I can't recall the exact use case which drove me to this topic at the moment. I'll definitely post it as soon as I remember. D's CTFE, mixins and templates almost make up a full language for compile-time. This allows generating the source code from within source code. The problem is that it's impossible to perform compile-time actions on a combination of modules in different compiler runs. different directly unrelated modules could contribute to the code generation process if mutable compile-time variables were available.


On Tue, Nov 27, 2012 at 8:59 PM, David Nadlinger <see@klickverbot.at> wrote:

> On Tuesday, 27 November 2012 at 15:49:45 UTC, Gor Gyolchanyan wrote:
>
>> Can you implement this use case?
>> Have classes mix in something,, which will register them in a single
>> place,
>> which can later suppl the registered classes as a type tuple.
>>
>
> This is fundamentally impossible in the D module system if the "single place" S does not import the modules where the types are defined. Even if you could append strings to a "compile-time global" in S, this still wouldn't help you in any way because if you tried to mix in the string in S, you'd get nothing but a slew of undefined symbol errors.
>
> Maybe you can describe your use case a bit? I'm optimistic that there is a solution which is not radically incompatible with the design of D.
>
> David
>



-- 
Bye,
Gor Gyolchanyan.

On Tuesday, 27 November 2012 at 18:57:09 UTC, Gor Gyolchanyan wrote:
> different directly unrelated modules could
> contribute to the code generation process […]

And one of the main design goals of the D module system is precisely that »different directly unrelated modules« don't affect each other. ;)

David

I understand, that this was the way D was designed initially. But the directly unrelated modules are both involved in the process willfully by using some mixins. They know what they're doing. They're not _completely_ unrelated.


On Tue, Nov 27, 2012 at 10:58 PM, David Nadlinger <see@klickverbot.at>wrote:

> On Tuesday, 27 November 2012 at 18:57:09 UTC, Gor Gyolchanyan wrote:
>
>> different directly unrelated modules could
>> contribute to the code generation process […]
>>
>
> And one of the main design goals of the D module system is precisely that »different directly unrelated modules« don't affect each other. ;)
>
> David
>



-- 
Bye,
Gor Gyolchanyan.

On 11/27/12 19:56, Gor Gyolchanyan wrote:
> The problem is that it's impossible to perform compile-time actions on a combination of modules in different compiler runs. different directly unrelated modules could contribute to the code generation process if mutable compile-time variables were available.

No.

Unless you want to effectively use a two-stage build process - at which point
it no longer really is "CTFE". IOW, what you're asking for is basically semi-
persistent backing store for compile-time objects. When you /really/ need that
kind of functionality, splitting out the "code generator" is fine.
D's design allows for much smarter compilers than the ones currently available,
the way module dependencies work is essential for that.

What you seem to want to do can be done, as already explained in this thread, at runtime, or as an additional custom build stage (mark the required types/ objects using UDA's (or otherwise), compile the project, run your custom tool that scans for the markers and generates code, compile that and then link it all together). There really is no alternative, other than automating this by introducing new "special" kind of modules, that are built during the final link phase. (Well, theoretically you could also invent ugly hacks where just some ops on certain magic data types work, but...).

artur