On 4/30/22 15:26, Timon Gehr wrote:
> On 30.04.22 23:59, Ali Çehreli wrote:
>>
>>  > downright hostile. You really deserved much better than that.
>>
>> Not everybody has the tactfulness to accept the ideas of non-academics.
>
> Unfortunately that often goes both ways. :/
>
> Also, Andrei has a PhD.

I did not mean otherwise. With "academic" I meant (copying from the internet) "a member (such as a professor) of an institution of learning (such as a university)".

Ali

On 4/30/2022 10:17 PM, Ola Fosheim Grøstad wrote:
> My point was that it did propose CTFE,

Nope. It proposed more syntax for something else. I wasn't sure what, as the examples and text apparently needed the verbal part of the presentation to make sense. I don't know what "metacode injection" is or what it has to do with CTFE.


> and the presentation states that they had a prototype compiler extension for it, back in 2003.

It says "partially implemented", not a prototype. It also seems to have nothing in common with Bjarne's proposal 4 years later.


> D also makes some unsound assumptions by assuming that the hardware you compile on is giving the same answer as the hardware you execute on That can give
> surprising results, bugs that are nigh impossible to pinpoint, because you don't get them on your development machine. Are you really sure you want that?

Are you sure D's CTFE does that? (CTFE doesn't allow unsafe code, for example.) Are you sure C++'s does not? D is much more portable between systems than C++ is, in particular things like the sizes of types.


> Thankfully consteval gives you full control over what happens when.

That's the C++ rationale for consteval. But D allows 100% control over whether CTFE is run or not. consteval is completely unnecessary. It's simple - CTFE is run if otherwise the compiler would give an error message that it cannot resolve an expression at compile time. For example,

void test()
{
    enum e = foo(); // runs foo() at compile time
    auto f = foo(); // runs foo() at run time
}

------

CTFE is conceptually a no-brainer. Run a function at compile time. That's it. Neither Daveed's nor Bjarne's proposals do that. Zero new syntax is necessary.

On Sunday, 1 May 2022 at 02:18:37 UTC, Ali Çehreli wrote:
> > The tooling problems that result from
> > `static if` are real.
>
> Oh! I must have missed their point.

I cannot tell if you're sarcastic or not but the major point of contention is the scoping involved, `static if` doesn't introduce a new scope (and that's a feature) whereas C++'s `if constexpr` does introduce a scope. This really does make quite a difference for tooling.

On Saturday, 30 April 2022 at 17:25:27 UTC, Walter Bright wrote:

>
> I'm open to a reference to one that does have it, that predates D's CTFE.

I think Paulo Pinto has given you enough hard evidence. However, I was responding to the other of your claims, which is - nobody asked for CTFE. I doubt it because the factorial implemented with templates is the first thing a new-born C++ programmer sees, and her first words are "Template metaprogramming is an abomination. Why can't we just evaluate functions at compile time?".

>
>
>> And even today, the feature is only marginally useful because of the countless forward reference bugs. I recently filed one more (https://issues.dlang.org/show_bug.cgi?id=22981), which is not a CTFE bug per se but was encountered in another futile attempt to generate code with CTFE in a reasonable manner.
>
> I'm sorry about the problems you encountered, but as you say they are forward reference issues, not about CTFE.

I also said that CTFE is not so useful in the presence of forward reference bugs.

> You couldn't get that code to work in C++, either, because C++ does not allow forward references at all.

Yes, that is one of the reasons why we want to use D and not C++. When it doesn't work, the reason goes away.

>
> Thanks for submitting a well-done bug report on it.

D will prevail!

On Saturday, 30 April 2022 at 17:39:04 UTC, Walter Bright wrote:
> On 4/30/2022 1:32 AM, Paulo Pinto wrote:
>> Switching gears to ranges, we have Smalltalk-80 collections as one possible example,
>> 
>> https://www.researchgate.net/publication/2409926_Interfaces_and_Specifications_for_the_Smalltalk-80_Collection_Classes
>
> C++ went the iterator approach. Ranges in C++ occurred only after D did them.
>
> Also, Lisp started out as an interpreted language. Native compilation came much later.
>
> I'm interested in an example of a language that started out as a natively compiled language, and then added interpretation.
>
> I know back in the 80's there were some C interpreters, but they were not combined with a native compiler. Nobody thought to put the chocolate and the peanut butter together.
>
> No version of Fortran I ever used had CTFE.

First Lisp compiler was in 1960's....

On Saturday, 30 April 2022 at 17:14:24 UTC, Walter Bright wrote:
> On 4/30/2022 1:02 AM, Paulo Pinto wrote:
>> As if all those people doing CS research in programming languages needed D's existence to notice what is know in academia for decades.
>
> Bjarne Stroustrup has a PhD in CS. Why didn't C++ have it? Why does every iteration of C++ make CTFE work more like D's?
>
> Why didn't any of the other mainstream native compiled languages have it? Fortran? Ada? Pascal? Modula 2? (The latter two by CS academic researcher Niklaus Wirth.)
>
> CTFE is a *huge* win. Why was this well-known thing languishing in complete obscurity?

C++ doesn't pretend to have invented features that have preceded it by decades, other than what they might have taken away from D.

Other programming languages had other design goals, which is not the same as clamming to have invented something.

On 5/1/2022 12:26 AM, Ola Fosheim Grøstad wrote:
> In C++ you use stdint which gives you 3 options for each bit width: exact, at least or fast...
> Then you bind these in meaningful ways for you application using alias, unfortunately C++ does not provide nominal binding, but D doesn't offer that either so...

I.e. if you write portable code it is portable. But that wasn't your complaint - which was about getting portability wrong. C++ offers many more options for that.

>>> Thankfully consteval gives you full control over what happens when.
>>
>> That's the C++ rationale for consteval. But D allows 100% control over whether CTFE is run or not. consteval is completely unnecessary. It's simple - CTFE is run if otherwise the compiler would give an error message that it cannot resolve an expression at compile time.
> 
> Th difference is that I have functions that I only want to run at compile time or runtime, in D you have to test it in the body, in C++ you are forced to think about it.

I haven't made it clear. There is no ambiguity in D about when a function is run at compile time or run time. None. Zero. It is entirely unnecessary to add a keyword for that.

If you want to run a function at compile time, you don't have to test it. Just run it at compile time. We've had CTFE in D for 15 years now. None of your objections to it have caused a problem that has come to my attention. CTFE is used heavily in D.

The beauty of CTFE is it is so simple that Daveed and Bjarne missed it. You can see that in their proposals.


>> CTFE is conceptually a no-brainer. Run a function at compile time. That's it.
> 
> I agree that the concept is trivial, which is why it is surprising that people think other languages haven't considered this option.

Many times obvious things are obvious only in retrospect, and we get so comfortable with them we can no longer imagine otherwise.

I implemented modules in 10 lines of code for C. It seems so obvious - why didn't I do it 40 years ago? I can't explain it. Why did it take C++ 35 years to come up with modules?

Why didn't I invent Visicalc? It seems so obvious now. Ditto for all the FAANG zillionaires.

I kick myself about Autotune. It's so obvious even the inventor didn't think of it. His wife, a singer, casually mentioned to him that it would be nice to have a device that fixed her pitch.

A friend of mine who worked at a major company in the 90's would interview candidates. A question he'd ask was "what features would you add to this cellphone if you could?" Not one of them came up with anything other than things like "better voice quality". Nobody thought of using it as a radio, a music player, a book reader, a note taker, a voice recorder, a camera, and on and on. NOBODY!

On 5/1/2022 12:13 AM, Max Samukha wrote:
> On Saturday, 30 April 2022 at 17:25:27 UTC, Walter Bright wrote:
> 
>>
>> I'm open to a reference to one that does have it, that predates D's CTFE.
> 
> I think Paulo Pinto has given you enough hard evidence.

Of interpreters that later generated native code. Not the other way around.

> However, I was responding to the other of your claims, which is - nobody asked for CTFE. I doubt it because the factorial implemented with templates is the first thing a new-born C++ programmer sees, and her first words are "Template metaprogramming is an abomination. Why can't we just evaluate functions at compile time?".

You would think they would have, as many said it was an abomination. But they never said the next.

There were many, many articles about using C++ templates as a Turing complete programming language. Find one that said "why can't we ..."

Find one and I'll buy you a beer at DConf!