Am Tue, 02 Oct 2012 09:38:56 +0200
schrieb Don Clugston :
> 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
> how the mac
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 c
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 along
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 perform
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 gu
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 do
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 th
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.
You'
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;
}
stru
On Mon, Oct 1, 2012 at 4:19 PM, Tommi 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
>> going to hav
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
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 anyt
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 t
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
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 o
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 t
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() {
> >>
> >> wri
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 wou
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
On Mon, 01 Oct 2012 16:23:17 -0400, Tommi 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 fun = _funimpl(s);
}
//
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 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
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.
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...)
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 a
On Mon, 01 Oct 2012 16:10:48 -0400, Tommi 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 will fail, because they're d
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 quickl
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 u
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 operato
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. If
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 _ctf
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 understa
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 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, bu
On Mon, 01 Oct 2012 01:40:37 -0400, 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
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] fu
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 potential
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 won't
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 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
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, o
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
> > implementa
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, 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 i
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
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
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 target
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 re
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* pur
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 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 alo
51 matches
Mail list logo
