Am Tue, 02 Oct 2012 09:38:56 +0200
schrieb Don Clugston d...@nospam.com:
Any code that behaves differently when compiled with -O, will do this as
well. Constant folding of floating point numbers does the same thing, if
the numbers are represented in the compiler in a different precision to
On Tuesday, 2 October 2012 at 01:00:25 UTC, Walter Bright wrote:
Since all you need to do to guarantee compile time evaluation
is use it in a context that requires CTFE, which are exactly
the cases where you'd care that it was CTFE'd, I just don't see
much utility here.
I suppose the most
On Monday, 1 October 2012 at 22:47:48 UTC, Timon Gehr wrote:
A D compiler is also a D interpreter. I wouldn't even bother
with D if this wasn't the case.
A D compiler _contains_ a limited interpreter for constant
expression evaluation. This has limitations such as not being
able to
On 01/10/12 07:40, Tommi wrote:
import std.stdio;
int pow2(int val) pure
{
if (__ctfe)
return 6;
else
return val * val;
}
void main()
{
assert(pow2(3) == 9);
static assert(pow2(3) == 6);
writeln(9 = 6 ... I knew it! '6' was faking it all
On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen
wrote:
As far as purity goes, pow2 *is* pure. ...
According to http://en.wikipedia.org/wiki/Pure_function it's not:
The [pure] function always evaluates the same result value given
the same argument value(s)
On Monday, October 01, 2012 07:43:59 Alex Rønne Petersen wrote:
This is a corner case.
__ctfe is there to allow special-cased CTFE code when absolutely
necessary. By necessity, this separates a function into two worlds:
compile time and run time.
As far as purity goes, pow2 *is* pure. It
On Monday, October 01, 2012 07:58:39 Tommi wrote:
On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen
wrote:
As far as purity goes, pow2 *is* pure. ...
According to http://en.wikipedia.org/wiki/Pure_function it's not:
The [pure] function always evaluates the same result
On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
It would be kind of like complaining that a pure function
returns different
values on Linux and Windows due to a version statement or
static if. It's just
that in the thing that varies is compile time vs runtime not
the
On 9/30/2012 11:09 PM, Tommi wrote:
On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
It would be kind of like complaining that a pure function returns different
values on Linux and Windows due to a version statement or static if. It's
just
that in the thing that varies is
On Monday, October 01, 2012 08:09:38 Tommi wrote:
On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
It would be kind of like complaining that a pure function
returns different
values on Linux and Windows due to a version statement or
static if. It's just
that in the
On Monday, 1 October 2012 at 06:13:51 UTC, Brad Roberts wrote:
So, Tommi, do you have a suggestion or proposal to make or are
you just trying to point and snicker? There's a
multitude of ways that bad programmers can write bad code.
I can't provide a solution until we've agreed that there
On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote:
A function which uses __ctfe should probably do essentially the
same thing at
both runtime and compile time, but it _has_ __ctfe, because the
runtime
implementation won't work at compile time, and it's up to the
programmer to
On Monday, October 01, 2012 08:25:39 Tommi wrote:
On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote:
A function which uses __ctfe should probably do essentially the
same thing at
both runtime and compile time, but it _has_ __ctfe, because the
runtime
implementation won't
On Sunday, September 30, 2012 23:38:43 Jonathan M Davis wrote:
On Monday, October 01, 2012 08:25:39 Tommi wrote:
Thus we're in a situation where pure means pure only by
convention, not because it's enforced by the compiler. It's like
const in c++ then, it's const only by convention, only
On 10/1/12 2:19 AM, Tommi wrote:
On Monday, 1 October 2012 at 06:13:51 UTC, Brad Roberts wrote:
So, Tommi, do you have a suggestion or proposal to make or are you
just trying to point and snicker? There's a
multitude of ways that bad programmers can write bad code.
I can't provide a solution
I'll have to consider all functions potentially schizophrenic
then. They might do one thing at compile-time and another at
run-time.
I was going to make a feature request to add a compiler flag for
making more functions execute at compile-time than those which
the compiler *has* to. But this
On Monday, October 01, 2012 09:46:43 Tommi wrote:
I'll have to consider all functions potentially schizophrenic
then. They might do one thing at compile-time and another at
run-time.
That's only the case if they're buggy, so that's pretty much the same as
considering all functions potentially
On Monday, 1 October 2012 at 06:25:19 UTC, Tommi wrote:
On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis
wrote:
A function which uses __ctfe should probably do essentially
the same thing at
both runtime and compile time, but it _has_ __ctfe, because
the runtime
implementation
Le 01/10/2012 08:07, Jonathan M Davis a écrit :
On Monday, October 01, 2012 07:58:39 Tommi wrote:
On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen
wrote:
As far as purity goes, pow2 *is* pure. ...
According to http://en.wikipedia.org/wiki/Pure_function it's not:
The [pure]
On Mon, 01 Oct 2012 01:40:37 -0400, Tommi tommitiss...@hotmail.com wrote:
import std.stdio;
int pow2(int val) pure
{
if (__ctfe)
return 6;
else
return val * val;
}
void main()
{
assert(pow2(3) == 9);
static assert(pow2(3) == 6);
writeln(9 = 6
On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote:
And you _can't_ determine ahead of time which functions can be
safely executed at compile time either, because that's an
instance of the halting problem.
I don't understand (I did read what halting problem means just
now, but
On Monday, 1 October 2012 at 08:00:47 UTC, Jakob Ovrum wrote:
The only real problem here is that you wrote a function called
pow2 that effectively returns 6 unconditionally. I doubt your
math professor would be particularly impressed. If you had used
__ctfe properly, it would return the same
On Monday, 1 October 2012 at 17:46:00 UTC, Tommi wrote:
On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis
wrote:
And you _can't_ determine ahead of time which functions can be
safely executed at compile time either, because that's an
instance of the halting problem.
I don't
On Monday, 1 October 2012 at 06:09:18 UTC, Tommi wrote:
Actually... let's not even worry about the definition of the
word 'pure'. Let's just ask ourselves: do we really want to
live in a world where people can write code like that:
Yes, yes we do, because if we didn't there wouldn't be a
On Monday, 1 October 2012 at 17:53:35 UTC, Tommi wrote:
On Monday, 1 October 2012 at 08:00:47 UTC, Jakob Ovrum wrote:
The only real problem here is that you wrote a function called
pow2 that effectively returns 6 unconditionally. I doubt your
math professor would be particularly impressed.
On Monday, October 01, 2012 19:46:16 Tommi wrote:
On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote:
And you _can't_ determine ahead of time which functions can be
safely executed at compile time either, because that's an
instance of the halting problem.
I don't
On Monday, October 01, 2012 19:53:53 Tommi wrote:
I solemnly swear not to use __ctfe improperly. But my problem
with it is, that there *exists* the possibility of improper use
of __ctfe.
I could just as easily name a function pow2 and make it return the square
root. I could overload operator
On Monday, 1 October 2012 at 18:36:23 UTC, Jonathan M Davis wrote:
CTFE was specifically designed with the idea that you would not
need to mark functions as CTFEable. You can call _any_ functio
at compile time. Some will fail, because they're doing things
that CTFE won't allow, but that's
On Mon, 01 Oct 2012 16:10:48 -0400, Tommi tommitiss...@hotmail.com wrote:
On Monday, 1 October 2012 at 18:36:23 UTC, Jonathan M Davis wrote:
CTFE was specifically designed with the idea that you would not need to
mark functions as CTFEable. You can call _any_ functio
at compile time. Some
On Monday, 1 October 2012 at 20:16:09 UTC, Steven Schveighoffer
wrote:
We already have that, use templates:
private auto _funimpl(string s) {
/* what was previously in fun(string) */
}
template fun(string s)
{
enum fun = _funimpl(s);
}
// usage:
fun!(times); // always executes _funimpl at
private auto _funimpl(string s) {
/* what was previously in fun(string) */
}
template fun(string s)
{
enum fun = _funimpl(s);
}
// usage:
fun!(times); // always executes _funimpl at compile time
-Steve
You could even use this template:
template ct(alias f)
{
template ct(params...)
It's a lot less work to add one attribute to your function once,
than to write something extra every time you call that function.
On Monday, 1 October 2012 at 20:30:26 UTC, Tommi wrote:
It's a lot less work to add one attribute to your function
once, than to write something extra every time you call that
function.
string exclaim(string v)() {
return v ~ !;
}
void main() {
writeln(exclaim!(howdy));
}
Graham
On Monday, 1 October 2012 at 20:33:29 UTC, Graham Fawcett wrote:
string exclaim(string v)() {
return v ~ !;
}
void main() {
writeln(exclaim!(howdy));
}
It doesn't scale well to have to write both compile-time and
run-time versions of your functions.
On Mon, 01 Oct 2012 16:23:17 -0400, Tommi tommitiss...@hotmail.com wrote:
On Monday, 1 October 2012 at 20:16:09 UTC, Steven Schveighoffer wrote:
We already have that, use templates:
private auto _funimpl(string s) {
/* what was previously in fun(string) */
}
template fun(string s)
{
enum
On Monday, 1 October 2012 at 20:41:53 UTC, Tommi wrote:
On Monday, 1 October 2012 at 20:33:29 UTC, Graham Fawcett wrote:
string exclaim(string v)() {
return v ~ !;
}
void main() {
writeln(exclaim!(howdy));
}
It doesn't scale well to have to write both compile-time and
run-time versions of
On Monday, 1 October 2012 at 21:15:40 UTC, Graham Fawcett wrote:
And how is your proposed @force_ctfe attribute going to solve
this issue? If you're forcing CTFE, by definition you don't
have runtime support.
Maybe the name @force_ctfe is misleading. But, like I said: the
attribute @asdf
On Monday, October 01, 2012 23:15:55 Graham Fawcett wrote:
On Monday, 1 October 2012 at 20:41:53 UTC, Tommi wrote:
On Monday, 1 October 2012 at 20:33:29 UTC, Graham Fawcett wrote:
string exclaim(string v)() {
return v ~ !;
}
void main() {
writeln(exclaim!(howdy));
}
On Monday, 1 October 2012 at 21:29:33 UTC, Tommi wrote:
Maybe the name @force_ctfe is misleading. But, like I said:
the attribute @asdf would make it so that the function is
guaranteed to execute at compile-time when its arguments are
compile-time constants.
Oh, wait. Now I understand why
On Monday, 1 October 2012 at 21:35:16 UTC, Jonathan M Davis wrote:
The question is whether it's worth adding such an attribute to
the language, and clearly, most of us think that explicitly
using enum suffices whereas Tommi wants such a function
attribute.
You'd get simpler syntax at the cost
On Monday, October 01, 2012 23:55:11 Tommi wrote:
On Monday, 1 October 2012 at 21:35:16 UTC, Jonathan M Davis wrote:
The question is whether it's worth adding such an attribute to
the language, and clearly, most of us think that explicitly
using enum suffices whereas Tommi wants such a
On 10/01/2012 08:02 PM, foobar wrote:
On Monday, 1 October 2012 at 17:46:00 UTC, Tommi wrote:
On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote:
And you _can't_ determine ahead of time which functions can be safely
executed at compile time either, because that's an
instance of
On Monday, 1 October 2012 at 22:23:51 UTC, Jonathan M Davis wrote:
Keywords are considered to be incredibly expensive. Being able
to use a name
starting with @ rather than a keyword does reduce the cost, but
you're still
going to have to drive a very hard bargain to talk Walter into
adding
On Tuesday, October 02, 2012 01:19:51 Tommi wrote:
I'm not sure if you meant the same, but I meant the word cost
of a feature as the amount the feature complicates the
language. Also, I'm only asking people to buy this feature in
the sense of: what would you say about this feature if the
On Mon, Oct 1, 2012 at 4:19 PM, Tommi tommitiss...@hotmail.com wrote:
On Monday, 1 October 2012 at 22:23:51 UTC, Jonathan M Davis wrote:
Keywords are considered to be incredibly expensive. Being able to use a
name
starting with @ rather than a keyword does reduce the cost, but you're
still
Jonathan M Davis:
Adding much of _anything_ to the
language is generally considered expensive.
Sometimes you add from a language removing something, like
allowing handy code like this, removing such limitations and
making the language more regular/uniform:
class Foo {
int x, y;
}
On 10/1/12 5:55 PM, Tommi wrote:
On Monday, 1 October 2012 at 21:35:16 UTC, Jonathan M Davis wrote:
The question is whether it's worth adding such an attribute to
the language, and clearly, most of us think that explicitly
using enum suffices whereas Tommi wants such a function
attribute.
On Monday, 1 October 2012 at 23:31:21 UTC, Jonathan M Davis wrote:
No offense, but a feature proposal is pretty pointless if it's
a this would
have been nice had we had thought of it when we could have
easily added it. A
feature proposal is only relevant if it's really an attempt to
change the
On Tuesday, October 02, 2012 02:19:21 Tommi wrote:
I don't think you should stop trying to write the best language
specification you can just because you're past the point of it
being implementable by this language.
Discussing changes to D2 is of relevance, because that affects what we're
On 10/1/2012 1:10 PM, Tommi wrote:
I meant that all functions would still be
implicitly CTFEable by default, but an attribute like force_ctfe would
make it so that the function is guaranteed to execute at compile-time
when its arguments are compile-time constants.
Since all you need to do to
import std.stdio;
int pow2(int val) pure
{
if (__ctfe)
return 6;
else
return val * val;
}
void main()
{
assert(pow2(3) == 9);
static assert(pow2(3) == 6);
writeln(9 = 6 ... I knew it! '6' was faking it all along);
readln();
}
On 01-10-2012 07:40, Tommi wrote:
import std.stdio;
int pow2(int val) pure
{
if (__ctfe)
return 6;
else
return val * val;
}
void main()
{
assert(pow2(3) == 9);
static assert(pow2(3) == 6);
writeln(9 = 6 ... I knew it! '6' was faking it all
52 matches
Mail list logo
