Two unrelated things found recently on Reddit:

In Java 8 they have added type annotations:
http://www.mscharhag.com/2014/02/java-8-type-annotations.html


This shows how a C-like language lacks some essential parts to use well the CPUs (both x86 and to ARM) to implement range integrals or multi-word integrals efficiently without using asm:
http://accu.org/index.php/journals/1849

Bye,
bearophile

On Sunday, 9 February 2014 at 15:38:24 UTC, bearophile wrote:
> Two unrelated things found recently on Reddit:
>
> In Java 8 they have added type annotations:
> http://www.mscharhag.com/2014/02/java-8-type-annotations.html

Wow, they are totally coping! :P Jokes aside, now I wonder: what language introduced type anotation first?

On Sunday, 9 February 2014 at 16:23:50 UTC, Francesco Cattoglio wrote:
> Wow, they are totally coping! :P Jokes aside, now I wonder: what language introduced type anotation first?

Probably some CASE tool 20-30 years ago or so.

Am 09.02.2014 17:23, schrieb Francesco Cattoglio:
> On Sunday, 9 February 2014 at 15:38:24 UTC, bearophile wrote:
>> Two unrelated things found recently on Reddit:
>>
>> In Java 8 they have added type annotations:
>> http://www.mscharhag.com/2014/02/java-8-type-annotations.html
>
> Wow, they are totally coping! :P Jokes aside, now I wonder: what
> language introduced type anotation first?

.NET did it before Java.

Along the way Python got them too.

Common Lisp and Dylan had them before the former.

--
Paulo

Am 09.02.2014 16:38, schrieb bearophile:
> Two unrelated things found recently on Reddit:
>
> In Java 8 they have added type annotations:
> http://www.mscharhag.com/2014/02/java-8-type-annotations.html
>
>
> This shows how a C-like language lacks some essential parts to use well
> the CPUs (both x86 and to ARM) to implement range integrals or
> multi-word integrals efficiently without using asm:
> http://accu.org/index.php/journals/1849
>
> Bye,
> bearophile

I tend to have some fun pointing out on online forums like HN, that despite common belief, it is 100% ANSI/ISO compliant to have C and C++ compilers that don't expose inline assembly, cpu intrisics and that those languages no longer map directly to modern CPUs architectures like they did in the 70's.

--
Paulo

Francesco Cattoglio:

> Wow, they are totally coping! :P

What's interesting is not just that Java has type annotations, but the details of this feature. That article show many details.

Bye,
bearophile

On Sunday, 9 February 2014 at 17:55:50 UTC, bearophile wrote:
> Francesco Cattoglio:
>
>> Wow, they are totally coping! :P
>
> What's interesting is not just that Java has type annotations, but the details of this feature. That article show many details.
>
> Bye,
> bearophile

I don't think he mentioned it in the first article, but are these annotations checked at runtime or compile time? For example, @NonNegative.

On 02/09/2014 07:25 PM, Meta wrote:
> On Sunday, 9 February 2014 at 17:55:50 UTC, bearophile wrote:
>> Francesco Cattoglio:
>>
>>> Wow, they are totally coping! :P
>>
>> What's interesting is not just that Java has type annotations, but the
>> details of this feature. That article show many details.
>>
>> Bye,
>> bearophile
>
> I don't think he mentioned it in the first article, but are these
> annotations checked at runtime or compile time? For example, @NonNegative.

Java does not assign any interesting semantics to those annotations. They however can be used together with tools/compiler plugins. Eg. one could use tools that recognize @NonNegative in order to add runtime checks or apply static analysis, or some combination of the two.

On 2/9/2014 7:38 AM, bearophile wrote:
> This shows how a C-like language lacks some essential parts to use well the CPUs
> (both x86 and to ARM) to implement range integrals or multi-word integrals
> efficiently without using asm:
> http://accu.org/index.php/journals/1849

Much like how ROR and ROL is efficiently handled in compilers by having the compiler recognize the equivalent expression, I think the best way to handle these issues is by having the compiler recognize the multi-precision expressions, and rewrite it internally into the optimal asm.

Walter Bright:

> Much like how ROR and ROL is efficiently handled in compilers by having the compiler recognize the equivalent expression, I think the best way to handle these issues is by having the compiler recognize the multi-precision expressions, and rewrite it internally into the optimal asm.

See:
https://d.puremagic.com/issues/show_bug.cgi?id=6829

My opinions:
- It's a fragile pattern recognition. In D.learn and elsewhere I have seen people write the rot/rol in a way that DMD is not able to recognize.
- It's not portable, because there is no guarantee that other present or future compilers will perform that optimization. See that issue 6829 thread for problems with LLVM.
- Generally it's nice to have a language that offers higher level operations to the programmer, making coding simpler. But in this case calling a function as rol/ror is very easy for the programmer, it is not a burden at all. Replacing it with a pattern to be written carefully is not a gain for the programmer. And it helps the person that later reads the code at a bit higher level (and currently Phobos doesn't have such ror/rol functions, so they need to be written in user code).

Here I have suggested something different:
https://d.puremagic.com/issues/show_bug.cgi?id=9850

Bye,
bearophile