www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - access CTFE variables at compile time.

reply "JS" <js.mdnq gmail.com> writes:
It seems possible that we can print CTFE variables at compile 
time by using string mixes as the code below demonstrates.

The problem is that we can not pass a variable to a template to 
create a print routine in the first place. e.g., we can't do 
mixin a!(s) if s is a string since s can't be read, supposedly, 
at compile time.

We can't even do mixin("mixin a!(\""~s~"\");") though to get 
around this.

The following code at least proves that CTFE variables can be 
read at compile time and the limitation is with the internal 
implementation.

(this is easy to see, because on one hand we can't print s but on 
the other we can... hence the limitation with pragma is an 
artificial one.)

import std.stdio, std.cstream, std.conv;

mixin template a()
{
	template b()
	{
		static string c()
		{
			
			string s = "a"; s ~= "b";
			string x = "pragma(msg, \""~s~"\");";
			// pragma(msg, s) // fails
			return x;
		}
		enum b = c();
	}
	mixin(b!());
}

int main(string[] argv)
{
	mixin a!(); // can't pass a string to a in any way because of 
artificial  ctfe limitation
	din.getc();
	return 0;
}
Jul 09 2013
next sibling parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 9 July 2013 at 22:49:38 UTC, JS wrote:
 It seems possible that we can print CTFE variables at compile 
 time by using string mixes as the code below demonstrates.

 The problem is that we can not pass a variable to a template to 
 create a print routine in the first place. e.g., we can't do 
 mixin a!(s) if s is a string since s can't be read, supposedly, 
 at compile time.

I think there's been mention a couple times of a ctfeWrite function that can print values at compile-time, but so far nobody's implemented it.
Jul 09 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Meta:

 I think there's been mention a couple times of a ctfeWrite 
 function that can print values at compile-time, but so far 
 nobody's implemented it.

That's not true. This is the ER: http://d.puremagic.com/issues/show_bug.cgi?id=3952 And the patch: https://github.com/D-Programming-Language/dmd/pull/237 A significant problem with GitHub is that it's managed mostly as as a LIFO (last in first out), it means the last added patches get exposure, are discussed, and they often get added to the code. But if they are not merged in few weeks, they get out of radar and they get forgotten, and they rot for years. This is a significant problem for D development that so far doesn't have a solution. I don't remember Andrei or Walter every discussing about this problem or proposing solutions... Bye, bearophile
Jul 09 2013
prev sibling next sibling parent "JS" <js.mdnq gmail.com> writes:
On Wednesday, 10 July 2013 at 01:10:37 UTC, Meta wrote:
 On Tuesday, 9 July 2013 at 22:49:38 UTC, JS wrote:
 It seems possible that we can print CTFE variables at compile 
 time by using string mixes as the code below demonstrates.

 The problem is that we can not pass a variable to a template 
 to create a print routine in the first place. e.g., we can't 
 do mixin a!(s) if s is a string since s can't be read, 
 supposedly, at compile time.

I think there's been mention a couple times of a ctfeWrite function that can print values at compile-time, but so far nobody's implemented it.

I've heard of this too and even tried __ctfeWrite and it worked!! Well, at least no compile time error... just didn't print anything. I believe the error "variable can't be read at compile time" is due to the fact that the compiler doesn't have access to/isn't aware of the frame pointers(the stack) of the functions. This means that "local" variables can't be used in compile time, before ctfe, constructs because there is no way to get at the data. This seems like a limitation of the system and not some innate reason why it should fail...
Jul 09 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, July 10, 2013 06:24:02 JS wrote:
 On Wednesday, 10 July 2013 at 01:10:37 UTC, Meta wrote:
 On Tuesday, 9 July 2013 at 22:49:38 UTC, JS wrote:
 It seems possible that we can print CTFE variables at compile
 time by using string mixes as the code below demonstrates.
 
 The problem is that we can not pass a variable to a template
 to create a print routine in the first place. e.g., we can't
 do mixin a!(s) if s is a string since s can't be read,
 supposedly, at compile time.

I think there's been mention a couple times of a ctfeWrite function that can print values at compile-time, but so far nobody's implemented it.

I've heard of this too and even tried __ctfeWrite and it worked!! Well, at least no compile time error... just didn't print anything. I believe the error "variable can't be read at compile time" is due to the fact that the compiler doesn't have access to/isn't aware of the frame pointers(the stack) of the functions. This means that "local" variables can't be used in compile time, before ctfe, constructs because there is no way to get at the data. This seems like a limitation of the system and not some innate reason why it should fail...

Making it work would be like trying to make an if function as a static if. It would muddle things considerably and as such is a very bad idea IMHO. Right now, there is a very clean distinction between what's done at compile time and what's done at runtime as well as between CTFE and templated code. Allowing what you're trying to do would ruin that. - Jonathan M Davis
Jul 09 2013
prev sibling next sibling parent "Don" <turnyourkidsintocash nospam.com> writes:
On Wednesday, 10 July 2013 at 01:23:20 UTC, bearophile wrote:
 Meta:

 I think there's been mention a couple times of a ctfeWrite 
 function that can print values at compile-time, but so far 
 nobody's implemented it.

That's not true. This is the ER: http://d.puremagic.com/issues/show_bug.cgi?id=3952 And the patch: https://github.com/D-Programming-Language/dmd/pull/237

 A significant problem with GitHub is that it's managed mostly 
 as as a LIFO (last in first out), it means the last added 
 patches get exposure, are discussed, and they often get added 
 to the code. But if they are not merged in few weeks, they get 
 out of radar and they get forgotten, and they rot for years. 
 This is a significant problem for D development that so far 
 doesn't have a solution. I don't remember Andrei or Walter 
 every discussing about this problem or proposing solutions...

Although that's a problem, it's not at all what's happened here. That patch would not have worked, essentially because it mixes values-inside-CTFE with literals-outside-CTFE. It worked in simple cases, but not in general. That's not a simple problem with the patch that could have been fixed at the time.
Jul 10 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Don:

 Although that's a problem, it's not at all what's happened here.

Right. I presume that several of the patches that are waiting for some time have some significant problems. Bye, bearophile
Jul 10 2013