• bearophile <bearophileHUGS lycos.com> Aug 08 2010
• BCS <none anon.com> Aug 08 2010
• Mafi <mafi example.org> Aug 08 2010
• bearophile <bearophileHUGS lycos.com> Aug 08 2010

bearophile <bearophileHUGS lycos.com> writes:

BCS:

 All the issues you address up to where you propose ctputs are bugs in DMD, 
 not pragma(msg,...) as for ctputs as a /replacement/ see my replay to the 
 bug.


Thank you for this answer and the answer in bugzilla. I explain the problems I
find while I program in D, and sometimes I try to give a starting point for a
solution, but usually it's not hard to find solutions better than the ones I
suggest.

I have written an answer in Bugzilla, I don't know if it's enough.


 you will not convince me that what it currently does is less than /very
useful/. 


You are right :-)


 My minimum requirements for a pragma(msgm...) replacement would be that it 
 take any expression that results in an immutable(char[]) and, at compile 
 time (and only compile time) during the semantic pass (while the code is 
 processed, not evaluated) output the string.


I'd like to ctputs() to act as std.c.stdio.puts() if the function is run at run
time.

  
 The major cases where your ctputs fails on this are inside a function that 
 can be evaluated via CTFE:
 - If placed in a RT loop it could be evaluated to many times.
 - If placed in a code path that isn't hit via CTFE, it never outputs anything.
 - If the function gets run at RT, then you need to add a guard to prevent 
 it from generating output at RT.


This is by design.

But I understand your point, ctputs seems designed for a purpose different than
pragma(msg), it doesn't seem a replacement. ctputs is meant as a way to print
strings from function if you call the function both at runtime or compile time
with CTFE. pragma(msg) is meant to show a message at compile time. So
pragma(msg) needs to be debugged and then kept.

I probably have update the bug report, and I'd like to split it in a
pragma(msg) bug report (essentially to make it test its input argument better),
plus an enhancement request for a ctputs() probably in std.intrinsic :-)

Bye and thank you,
bearophile

BCS <none anon.com> writes:

Hello bearophile,

 BCS:
 
 All the issues you address up to where you propose ctputs are bugs in
 DMD, not pragma(msg,...) as for ctputs as a /replacement/ see my
 replay to the bug.
 


 problems I find while I program in D, and sometimes I try to give a
 starting point for a solution, but usually it's not hard to find
 solutions better than the ones I suggest.
 
 I have written an answer in Bugzilla, I don't know if it's enough.
 
 you will not convince me that what it currently does is less than
 /very useful/.
 


 
 My minimum requirements for a pragma(msgm...) replacement would be
 that it take any expression that results in an immutable(char[]) and,
 at compile time (and only compile time) during the semantic pass
 (while the code is processed, not evaluated) output the string.
 


 run at run time.
 
 The major cases where your ctputs fails on this are inside a function
 that
 can be evaluated via CTFE:
 - If placed in a RT loop it could be evaluated to many times.
 - If placed in a code path that isn't hit via CTFE, it never outputs
 anything.
 - If the function gets run at RT, then you need to add a guard to
 prevent
 it from generating output at RT.




Understood, and I see it's value. I'm not going to argue for not having
ctputs() 
but I want (need?) a way to have the other option. I don't think these can 
be combined (but I could be wrong).  Just as a point to consider; it might 
be reasonable to implement ctputs in terms of a combination of a compile 
time only puts and a runtime only puts. Either the runtime/compile time version 
or the compile time only version can be derived from the other but deriving 
the former seems cleaner than deriving the latter.

 
 But I understand your point, ctputs seems designed for a purpose
 different than pragma(msg), it doesn't seem a replacement. ctputs is
 meant as a way to print strings from function if you call the function
 both at runtime or compile time with CTFE. pragma(msg) is meant to
 show a message at compile time. So pragma(msg) needs to be debugged
 and then kept.


Good. We agree.

 
 I probably have update the bug report, and I'd like to split it in a
 pragma(msg) bug report (essentially to make it test its input argument
 better), plus an enhancement request for a ctputs() probably in
 std.intrinsic :-)


Souinds like a good way to go.

-- 
... <IXOYE><

Mafi <mafi example.org> writes:

Am 08.08.2010 17:41, schrieb bearophile:
 BCS:

 All the issues you address up to where you propose ctputs are bugs in DMD,
 not pragma(msg,...) as for ctputs as a /replacement/ see my replay to the
 bug.


 Thank you for this answer and the answer in bugzilla. I explain the problems I
find while I program in D, and sometimes I try to give a starting point for a
solution, but usually it's not hard to find solutions better than the ones I
suggest.

 I have written an answer in Bugzilla, I don't know if it's enough.


 you will not convince me that what it currently does is less than /very
useful/.


 You are right :-)


 My minimum requirements for a pragma(msgm...) replacement would be that it
 take any expression that results in an immutable(char[]) and, at compile
 time (and only compile time) during the semantic pass (while the code is
 processed, not evaluated) output the string.


 I'd like to ctputs() to act as std.c.stdio.puts() if the function is run at
run time.


 The major cases where your ctputs fails on this are inside a function that
 can be evaluated via CTFE:
 - If placed in a RT loop it could be evaluated to many times.
 - If placed in a code path that isn't hit via CTFE, it never outputs anything.
 - If the function gets run at RT, then you need to add a guard to prevent
 it from generating output at RT.


 This is by design.

 But I understand your point, ctputs seems designed for a purpose different
than pragma(msg), it doesn't seem a replacement. ctputs is meant as a way to
print strings from function if you call the function both at runtime or compile
time with CTFE. pragma(msg) is meant to show a message at compile time. So
pragma(msg) needs to be debugged and then kept.


I see the need for ctputs-like construct but I don't like the name. What 
about simply making puts magically ctfe-able. The runtime behavior is 
clearly defined and the compiler has to to simply catch calls to the 
real puts when ctfe-ing and replace it with it's implemantation.
What do you, bearophile and others, think?

 I probably have update the bug report, and I'd like to split it in a
pragma(msg) bug report (essentially to make it test its input argument better),
plus an enhancement request for a ctputs() probably in std.intrinsic :-)

bearophile <bearophileHUGS lycos.com> writes:

Mafi:
 I see the need for ctputs-like construct but I don't like the name. What 
 about simply making puts magically ctfe-able. The runtime behavior is 
 clearly defined and the compiler has to to simply catch calls to the 
 real puts when ctfe-ing and replace it with it's implemantation.
 What do you, bearophile and others, think?


If that can be done, then I am OK with that too.

Bye,
bearophile