Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 14:13:18 UTC, Patrick Schluter wrote: For the same reason it is in C. If the ambition for D is to be a system language then it should avoid introducing artificial abstractions and work with the machine it runs on, not against. The C model isn't much like x86 at all. You can do operations on 8 bit and 16 bit registers on x86, but C doesn't reflect that reality. I usually defend D's behavior of "blame C". Compatibility is useful for us and conservative programmers like familiarity, but I can't defend C's rules on the merits. They aren't like the processor and they aren't even that useful.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Sat, Apr 29, 2017 at 11:24:36AM +, Patrick Schluter via Digitalmars-d-announce wrote: > On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote: > > The latest WAT I found in D is this one, see if you can figure it > > out: > > > > char ch; > > wchar wch; > > dchar dch; > > > > pragma(msg, typeof(true ? ch : ch));// char - OK > > pragma(msg, typeof(true ? ch : wch)); // int - WAT? > > pragma(msg, typeof(true ? wch : wch)); // wchar - OK > > pragma(msg, typeof(true ? wch : dch)); // uint - WAT? > > pragma(msg, typeof(true ? dch : dch)); // dchar - OK > > > > How an alternation between two character types ends up being int is > > beyond me, but even more inscrutible is why ch : wch produces int > > but wch : dch produces uint. > > That's the C integer promotion rule, nothing suprising here. > > C99 says "if an int can represent all values of the original type, the > value is converted to an int; otherwise, it is converted to an > unsigned int." > > While quite often surprising for people coming from other languages, I > think that Walter's persistence in following the basic C rule is a > good thing. Maybe the documentation should cite more prominently from > the C standard on that point. While it is quite obvious, I noticed > that a lot of people do not know how it works. The problem is that while C integer promotion works well for C, it doesn't for D so much. Perhaps it worked well in the beginning days of D, when D was much closer to C, but today's D has significantly diverged from C in many respects, including making a clear(?) distinction between character types vs. integer types (e.g., char != ubyte). There has been a regression (at least) caused by the above adherence to C integer promotion rules: https://issues.dlang.org/show_bug.cgi?id=17358 There has also been bugs / problems related to overloading between int and char types of the same width (the wrong overload gets chosen). The problem is that because D makes it a point that char and ubyte are different (ditto for wchar / ushort, dchar / uint), people have come to expect that they should be consistently treated differently. But then we run into anachronisms like C integer promotion rules that basically disregard the distinction between integer and character types. So now you have this schizophrenic situation where part of the language (a good chunk of Phobos, for example, and some parts of the compiler/language -- e.g., char.init != ubyte.init) considers them as two different things, but other parts of the language (e.g. here) disregard their distinction. That this inconsistency should lead to bugs should be no surprise. The question now is, are we going to *fix* this situation at its root, or are we going to merely patch over it half-heartedly in the name of not OMG potentially breaking wrong codez! -- and thereby perpetuate this bug-prone situation? I sure hope it's not the latter. T -- The richest man is not he who has the most, but he who needs the least.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 14:13:18 UTC, Patrick Schluter wrote: That's not a simple assumption, it's acknowledgment that a C program runs on real hardware not a virtual machine like Java or C#. Modern X86s are basically virtual machines... The instruction set is decoded and executed on a completely different machine than the original X86. This is no longer true of course, as "registers" are "SIMD sized". SIMD and GP are not related and one will never replace the other. SIMD is generally for floating point, when it is used for integer, it is not for the usual integer semantics and requires special handling in any case. Huh? No, at least on X86 the register is only bits. You can mask floats with ints. So I am pretty sure it will lead to suboptimal code in some instances. Can also be said if it had another semantic. Not sure what you mean here. If every byte is recast to 32bit then you have to prove that it ends up with the same result when computed as 8bit. In C it is cast to the register size (16bit, 32bit or 64bit), because C was designed for 40 years old CPUs where you had a fixed word size (register size). D has locked int to 32 bit, so the register argument no longer makes sense. For the same reason it is in C. If the ambition for D is to be a system language then it should avoid introducing artificial abstractions and work with the machine it runs on, not against. But the C environment no longer works well with the machine it runs on. It is archaic and doesn't really reflect the underlying hardware well. It may seem like it does, but that's only because hardware vendors target C-generated code...
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 11:48:46 UTC, Ola Fosheim Grøstad wrote: On Saturday, 29 April 2017 at 11:24:36 UTC, Patrick Schluter wrote: C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." Well, C is making the simple assumption that registers are int-sized... That's not a simple assumption, it's acknowledgment that a C program runs on real hardware not a virtual machine like Java or C#. This is no longer true of course, as "registers" are "SIMD sized". SIMD and GP are not related and one will never replace the other. SIMD is generally for floating point, when it is used for integer, it is not for the usual integer semantics and requires special handling in any case. So I am pretty sure it will lead to suboptimal code in some instances. Can also be said if it had another semantic. While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing. Why is it a good thing? For the same reason it is in C. If the ambition for D is to be a system language then it should avoid introducing artificial abstractions and work with the machine it runs on, not against.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 11:24:36 UTC, Patrick Schluter wrote: C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." Well, C is making the simple assumption that registers are int-sized... This is no longer true of course, as "registers" are "SIMD sized". So I am pretty sure it will lead to suboptimal code in some instances. While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing. Why is it a good thing?
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Friday, 28 April 2017 at 22:11:30 UTC, H. S. Teoh wrote: The latest WAT I found in D is this one, see if you can figure it out: char ch; wchar wch; dchar dch; pragma(msg, typeof(true ? ch : ch));// char - OK pragma(msg, typeof(true ? ch : wch)); // int - WAT? pragma(msg, typeof(true ? wch : wch)); // wchar - OK pragma(msg, typeof(true ? wch : dch)); // uint - WAT? pragma(msg, typeof(true ? dch : dch)); // dchar - OK How an alternation between two character types ends up being int is beyond me, but even more inscrutible is why ch : wch produces int but wch : dch produces uint. That's the C integer promotion rule, nothing suprising here. C99 says "if an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int." While quite often surprising for people coming from other languages, I think that Walter's persistence in following the basic C rule is a good thing. Maybe the documentation should cite more prominently from the C standard on that point. While it is quite obvious, I noticed that a lot of people do not know how it works.
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 29 April 2017 at 03:44:50 UTC, Nick Sabalausky (Abscissa) wrote: On 04/28/2017 06:11 PM, H. S. Teoh via Digitalmars-d-announce wrote: https://bartoszmilewski.com/2013/09/19/edward-chands/ That is *awesome*! Although, I always saw Eddie Scissors as more of a retelling of Frankenstein. It is rather inaccurate. E.g.: «Imperative languages offer no protection against data races — maybe with the exception of D.» Sounds mostly like a sales pitch for Haskell over C++, glossing over the main reason for why the highest performance parallell algorithms are risky: the actual hardware design. If you don't want that highest speed then you most certainly can protect against data races for many problems in other languages, including C++. This won't change until the hardware changes. Oh well, it kinda has, with GPU programming.
