digitalmars.D - access CTFE variables at compile time.
- JS (38/38) Jul 09 2013 It seems possible that we can print CTFE variables at compile
- Meta (4/10) Jul 09 2013 I think there's been mention a couple times of a ctfeWrite
- bearophile (15/18) Jul 09 2013 That's not true. This is the ER:
- Don (6/22) Jul 10 2013 Although that's a problem, it's not at all what's happened here.
- bearophile (5/6) Jul 10 2013 Right. I presume that several of the patches that are waiting for
- JS (12/23) Jul 09 2013 I've heard of this too and even tried __ctfeWrite and it worked!!
- Jonathan M Davis (7/34) Jul 09 2013 Making it work would be like trying to make an if function as a static i...
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
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
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
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/237A 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
"bearophile" <bearophileHUGS lycos.com> 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
On Wednesday, 10 July 2013 at 01:10:37 UTC, Meta wrote:On Tuesday, 9 July 2013 at 22:49:38 UTC, JS wrote: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...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
On Wednesday, July 10, 2013 06:24:02 JS wrote:On Wednesday, 10 July 2013 at 01:10:37 UTC, Meta wrote: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 DavisOn Tuesday, 9 July 2013 at 22:49:38 UTC, JS wrote: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...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