View mode: basic / threaded / horizontal-split · Log in · Help
October 01, 2012
Re: It seems pure ain't so pure after all
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 anything
> like that to the language at this point. Adding much of 
> _anything_ to the
> language is generally considered expensive.

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 
language was still back on the drawing board and nothing had been 
written down yet".
October 01, 2012
Re: It seems pure ain't so pure after all
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
> language was still back on the drawing board and nothing had been
> written down yet".

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 
language now.

If we were really back at the drawing board, there are plenty of other things 
which would change, some of which could completely change how some things work 
and possibly invalidate a feature which might seem reasonable now but wouldn't 
work with the other changes (which probably isn't the case here, but still, 
discussing what could have been doesn't really buy us anything IMHO).

- Jonathan M Davis
October 01, 2012
Re: It seems pure ain't so pure after all
On Mon, Oct 1, 2012 at 4:19 PM, Tommi <tommitissari@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
>> going to have to drive a very hard bargain to talk Walter into adding
>> anything
>> like that to the language at this point. Adding much of _anything_ to the
>> language is generally considered expensive.
>>
>
> 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 language was still back on the drawing board
> and nothing had been written down yet".
>

That is a close to useless exercise (or domain problem). Problems to solve
are only interested in a specific domain. In other words the problem as you
have defined it will have a different solution in D, C++, Java, vaporware
language, etc.

To some degree it reminds me of the slew of TCP replacement protocols that
academia has designed and implemented that will probably never see the day
of light. Don't get me wrong it is educational to read them and
implementable in private networks but it is highly probably that the
Internet will never see them.

Thanks,
-Jose
October 01, 2012
Re: It seems pure ain't so pure after all
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;
}
struct Bar {
    int x, y;
}
void main() {
    auto f1 = new Foo(1, 2);
    auto f2 = new Foo(1);
    auto b1 = new Bar(10, 20);
    auto b2 = new Bar(10);
}

Bye,
bearophile
October 01, 2012
Re: It seems pure ain't so pure after all
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'd get simpler syntax at the cost of just one lousy new keyword. It's
> a once in a life time deal! Any takers?

I understand the motivation. We will not consider such a feature for the 
time being.

Andrei
October 02, 2012
Re: It seems pure ain't so pure after all
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
> language now.
>
> If we were really back at the drawing board, there are plenty 
> of other things
> which would change, some of which could completely change how 
> some things work
> and possibly invalidate a feature which might seem reasonable 
> now but wouldn't
> work with the other changes (which probably isn't the case 
> here, but still,
> discussing what could have been doesn't really buy us anything 
> IMHO).
>
> - Jonathan M Davis

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. Call the specification D++ 
and maybe some day someone will pick it up and try to implement 
it.
October 02, 2012
Re: It seems pure ain't so pure after all
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 doing 
now. Discussing features for a possible D3 is of some relevance, because it 
could eventually affect the language (but is also kind of pointless in that it 
won't matter for years yet). Discussing features simply because they might 
have been nice but we don't intend to ever add them is utterly pointless IMHO.

Aside from D, discussing your dream language is all well and good, but it's 
not really going to help D if the discussion isn't aimed at improving D as it 
is now.

> Call the specification D++
> and maybe some day someone will pick it up and try to implement
> it.

Um. That would actually be bad from our point of view. We don't want to 
fragment the community. D will evolve, and we may even eventually end up with 
D3, and someone may very well create a D++ someday, but it's not really in our 
best interest to promote the creation of such a language (especially not now). 
We want D to succeed, and it's going to have to do that pretty much as it is 
now.

At some point, you have to make what you have work and get it to gain traction 
in the programming community as it is, or what you have is of little practical 
value. Forever tweaking it won't get you there even if the tweaks create what 
is theoretically a better language.

So, feel free to air your ideas, but if they're not of practical value towards
improving D right now, many of us aren't going to pay much attention to them.

- Jonathan M Davis
October 02, 2012
Re: It seems pure ain't so pure after all
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 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.

Note that it is also impossible in the general case for the compiler to 
guarantee that a specific function is CTFE'able for all arguments that 
are also CTFE'able.
October 02, 2012
Re: It seems pure ain't so pure after all
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 IO at compile-time (there's a special pragma for 
that). This is merely an outgrowth of a compiler optimization 
technique.

Now, back on topic:
I agree with Jonathan - in general the compiler can't evaluate 
_all_ functions at-compile time due these limitations of CTFE and 
adding a compiler flag will make compilation times far worse than 
c++. Adding a function attribute adds marginal benefit over 
simply assigning to a static/enum variable.
October 02, 2012
Re: It seems pure ain't so pure after all
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");
>      readln();
> }

You don't need the if (__ctfe) to show this behaviour. Nor do you even 
need CTFE at all (though it would be a bit less obvious). You could 
demonstrate it in C++ too.

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 machine calculates them. I believe that GCC, for example, uses 
very much higher precision (hundreds of bits) at compile time.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home