October 17, 2021

On Sunday, 17 October 2021 at 04:17:38 UTC, jfondren wrote:

>

https://www.youtube.com/watch?v=d2VRuZo2pdA

About 50% of it is inadvertent praise for D. The rest is ARC and C++ interop.

Speaker here, thanks for watching and for your thoughts. In retrospect I should have mentioned D (and Zig as well), my reason for not doing so was (1) to keep it focused on Nim since that was the subject of the talk and (2) I don't know enough about D to field questions about how they differ and when you might want to choose one over the other so I wanted to avoid that situation.

For what it's worth I did a broader talk on static introspection which does feature D as well so you might be interested in checking that out.

October 17, 2021

On Sunday, 17 October 2021 at 16:50:39 UTC, Deech wrote:

>

On Sunday, 17 October 2021 at 04:17:38 UTC, jfondren wrote:

>

https://www.youtube.com/watch?v=d2VRuZo2pdA

About 50% of it is inadvertent praise for D. The rest is ARC and C++ interop.

Speaker here, thanks for watching and for your thoughts. In retrospect I should have mentioned D (and Zig as well), my reason for not doing so was (1) to keep it focused on Nim since that was the subject of the talk and (2) I don't know enough about D to field questions about how they differ and when you might want to choose one over the other so I wanted to avoid that situation.

For what it's worth I did a broader talk on static introspection which does feature D as well so you might be interested in checking that out.

Nice to see you here! Didn't think anyone cared about D anymore 🍀

Nice presentation btw. I use Nim occasionally. I got productive pretty quick with it

October 17, 2021
On 10/17/2021 3:03 AM, Ola Fosheim Grøstad wrote:
> On Sunday, 17 October 2021 at 08:20:24 UTC, Imperatorn wrote:
>> And still, in 2021 using C++20, compile time features are severely crippled.
> 
> How so? Anyway, what Walter said was not accurate. Languages are usually defined in a way where compile-time optimizations are optional and an implementation detail. Compile time evaluation of functions is nothing new, and a common optimization.

You're confusing data flow analysis and function inlining with ctfe. I know how data flow optimizers work, I was the first to implement one for DOS compilers in the 80s.

C and C++ compilers have enjoyed the best optimizers in the industry for decades. But not one of them could compile:

  int square(int x) { return x * x; }

  const int s = square(2);

Being able to do such NEVER occurred to anyone in the business. It's one of those ridiculously obvious things that nobody thought of for decades. It's so obvious people today cannot even conceive of not thinking of it.

I developed compilers with optimizers for 20 years before it occurred to me. Implementing it around 2007, it was like a bomb went off in the D community. (Don Clugston was the first to recognize what it could do.) From there it spread to C++ and pretty much every other compiled language.
October 17, 2021
On Sunday, 17 October 2021 at 19:18:25 UTC, Walter Bright wrote:
> On 10/17/2021 3:03 AM, Ola Fosheim Grøstad wrote:
>> [...]
>
> You're confusing data flow analysis and function inlining with ctfe. I know how data flow optimizers work, I was the first to implement one for DOS compilers in the 80s.
>
> [...]

https://gcc.godbolt.org/z/jr5W6rY1W

If I read you correctly, gcc circa '06 could do what you describe. Or do you mean in windows land?
October 17, 2021
On Sunday, 17 October 2021 at 14:16:51 UTC, russhy wrote:
> On Sunday, 17 October 2021 at 11:04:26 UTC, Paulo Pinto wrote:
>> On Sunday, 17 October 2021 at 08:15:26 UTC, Walter Bright wrote:
>>> On 10/16/2021 11:05 PM, Paulo Pinto wrote:
>>>> On Sunday, 17 October 2021 at 04:17:38 UTC, jfondren wrote:
>>>>> https://www.youtube.com/watch?v=d2VRuZo2pdA
>>>>>
>>>>> About 50% of it is inadvertent praise for D. The rest is ARC and C++ interop.
>>>> 
>>>> If you mean compile time evaluation, D wasn't the first with such features and it is quite far from what Common Lisp is capable of.
>>>
>>> Lisp is fundamentally different. It started out as an interpreter and later added native code generation. There never really was a difference between compile time and runtime for Lisp.
>>>
>>> Nobody even thought of compile time function evaluation for C and C++ until D did it.
>>>
>>> Nobody.
>>>
>>> As evidence, when people discovered that C++ templates could be used to evaluate things at compile time, everyone was completely agog over it. I never heard *anyone* suggest that maybe ordinary functions could do this, too.
>>>
>>> Now everyone does it. Even C is considering adding it.
>>
>> Maybe you should have read more SIGPLAN papers then, there are several examples of those capabilities.
>>
>> Always screaming D did it before C and C++ is not going to increase D's userbase, specially since they get the feature without leaving their ecosystem.
>>
>> Maybe instead of complaining about who did it first, the community should focus on fixing all lose ends.
>
> you are the one that started with:
>
> "X did it first"
>
> then you complain when people correct you, and then you say it's useless to focus on "who did it first"
>
> come on!

Was I corrected, really?

The very first compiler for Lisp was created in 1960 for the IBM 704.

Common Lisp was just one example among others, here are a few more.

- Dylan, released to the public in 1995

- PL/I included a macro subset, released in 1964

- Template Haskell, initially prototyped in 2002

- <bigwig> language research project at BRICS in 2002

- Luca Cardelli work on extensible languages at DEC Olivetti/HP

It is useless for the community to whine who did it first, because it won't increase its audience.




October 17, 2021
On Sunday, 17 October 2021 at 08:15:26 UTC, Walter Bright wrote:
> Lisp is fundamentally different. It started out as an interpreter and later added native code generation. There never really was a difference between compile time and runtime for Lisp.

Lisp has pretty much always been compiled.  EG. maclisp (a very early, very influential lisp, started off in the 60s or 70s).  And there were papers in the 80s comparing lisp's numerical performance to fortran's.
October 17, 2021
On 10/17/2021 2:11 PM, max haughton wrote:
> On Sunday, 17 October 2021 at 19:18:25 UTC, Walter Bright wrote:
>> On 10/17/2021 3:03 AM, Ola Fosheim Grøstad wrote:
>>> [...]
>>
>> You're confusing data flow analysis and function inlining with ctfe. I know how data flow optimizers work, I was the first to implement one for DOS compilers in the 80s.
>>
>> [...]
> 
> https://gcc.godbolt.org/z/jr5W6rY1W
> 
> If I read you correctly, gcc circa '06 could do what you describe. Or do you mean in windows land?

------------------------
mercury> cat test.c
int square(int x) { return x * x; }

const int c = square(2);

mercury> cc test.c -O3
test.c:3:1: error: initializer element is not constant
 const int c = square(2);
 ^
mercury> cc test.c --version
cc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-------------------------

Your example is fundamentally different:

-------------------------
int square(int x) { return x * x; }

int main()
{
    const int s = square(2);  <== not a constant-expression
    return s;


}
----------------
October 17, 2021
On Sunday, 17 October 2021 at 22:53:29 UTC, Walter Bright wrote:
> On 10/17/2021 2:11 PM, max haughton wrote:
>> On Sunday, 17 October 2021 at 19:18:25 UTC, Walter Bright wrote:
>>> [...]
>> 
>> https://gcc.godbolt.org/z/jr5W6rY1W
>> 
>> If I read you correctly, gcc circa '06 could do what you describe. Or do you mean in windows land?
>
> ------------------------
> mercury> cat test.c
> int square(int x) { return x * x; }
>
> const int c = square(2);
>
> mercury> cc test.c -O3
> test.c:3:1: error: initializer element is not constant
>  const int c = square(2);
>  ^
> mercury> cc test.c --version
> cc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> -------------------------
>
> Your example is fundamentally different:
>
> -------------------------
> int square(int x) { return x * x; }
>
> int main()
> {
>     const int s = square(2);  <== not a constant-expression
>     return s;
>
>
> }
> ----------------

I see. I thought you meant the constant-folding power rather than initializing something static.

"The manner and timing of static initialization" is listed as unspecified behaviour in the C11 standard, it's curious why this restriction persists.
October 17, 2021

On Sunday, 17 October 2021 at 21:17:43 UTC, Paulo Pinto wrote:

>

The very first compiler for Lisp was created in 1960 for the IBM 704.

Common Lisp was just one example among others, here are a few more.

  • Dylan, released to the public in 1995

AKA, Common Lisp.

>
  • Template Haskell, initially prototyped in 2002

I don't know of your other examples, but Common Lisp and Template Haskell are in the category with C++ templates of "this could be technically abused towards compile time evaluation (which still isn't ctfe) if someone wanted to, but people generally didn't because it didn't occur to them".

I gave an example of a trivial macro earlier. It's from https://letoverlambda.com/lol-orig.lisp , where it's preceded by

(defun sleep-units% (value unit)
  (sleep
    (* value
       (case unit
         ((s) 1)
         ((m) 60)
         ((h) 3600)
         ((d) 86400)
         ((ms) 1/1000)
         ((us) 1/1000000)))))

A normal function. Which was not simply used at compile-time; instead, a macro version was written so that the same calculation could occur at compile-time. And this is what people'd tend to do in Common Lisp. The function actually could be used at compile-time but the EVAL-WHEN syntax to do that is so heavy, nobody would bother without ctfe having occurred to them.

An example of a language where people genuinely did write normal functions and then freely execute them at compile-time is Forth, and there the community mostly bemoaned that poor optimizers made it necessary to use even for constant-folding:

: rotchar ( c -- c' )
  dup  [char] a [ char m 1+ ] literal within 13 and
  over [char] A [ char M 1+ ] literal within 13 and +
  over [char] n [ char z 1+ ] literal within -13 and +
  over [char] N [ char Z 1+ ] literal within -13 and + + ;

WITHIN checks a half-open range, so it's getting passed 'a' and 'z'+1, with compile-time calculation of the latter happening due to [ ... ] literal

When a better optimizer is available you'd just write 'a' 'z' 1+ within

>

It is useless for the community to whine who did it first, because it won't increase its audience.

This is a really strange axe to grind.

October 17, 2021
On 10/17/2021 4:06 PM, max haughton wrote:
> I see. I thought you meant the constant-folding power rather than initializing something static.

More precisely, I mean anything that is specified as a `constant-expression` in the C Standard.