www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Jonathan Blow demo #2

reply "bearophile" <bearophileHUGS lycos.com> writes:
Jonathan Blow, Programming Language Demo #2:

https://www.youtube.com/watch?v=-UPFH0eWHEI

https://www.reddit.com/r/programming/comments/2oyg5e/jonathan_blow_dec_10_programming_language_demo_2/

------------------

He shows a way to not initialize a struct that has specified 
values. In D it could be:

struct Vec { float x = 1, y = 5, z = 9; }

auto v = new Vec(void);
auto av = new Vec[10] = void;
auto av2 = new Vec[10] = Vec(0, 0, 0);

------------------

He suggests a way to optionally specify the type of array 
indexes. In a D-like syntax it could be:

enum N = 10;
float[N : ushort] a1;
float[: ushort] a2;

My point of having this in D is to optionally increase strictness 
of the array indexes, to avoid some bugs when you handle many 
arrays.

------------------

He suggests something like a  noinline attribute.

Bye,
bearophile
Dec 11 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/11/2014 8:57 AM, bearophile wrote:
 He shows a way to not initialize a struct that has specified values. In D it
 could be:

 struct Vec { float x = 1, y = 5, z = 9; }

 auto v = new Vec(void);
 auto av = new Vec[10] = void;
 auto av2 = new Vec[10] = Vec(0, 0, 0);
D already does this. It's been said before, Jonathan is reinventing D, piece by piece :-)
 He suggests a way to optionally specify the type of array indexes. In a D-like
 syntax it could be:

 enum N = 10;
 float[N : ushort] a1;
 float[: ushort] a2;
I don't see any point to this.
 My point of having this in D is to optionally increase strictness of the array
 indexes, to avoid some bugs when you handle many arrays.
Doesn't make sense to me.
 He suggests something like a  noinline attribute.
It'll go into D in some form. It's an old suggestion.
Dec 11 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 struct Vec { float x = 1, y = 5, z = 9; }

 auto v = new Vec(void);
 auto av = new Vec[10] = void;
 auto av2 = new Vec[10] = Vec(0, 0, 0);
D already does this.
D doesn't do that, not even one of those three :-) I'm willing to open one or two ERs later on those things. At best in Phobos we have a workaround for the second of those three ideas: auto av = minimallyInitializedArray(Vec, 10);
 He suggests a way to optionally specify the type of array 
 indexes. In a D-like
 syntax it could be:

 enum N = 10;
 float[N : ushort] a1;
 float[: ushort] a2;
I don't see any point to this.
 My point of having this in D is to optionally increase 
 strictness of the array
 indexes, to avoid some bugs when you handle many arrays.
Doesn't make sense to me.
I explained the topic here (note this not exactly the same thing discussed by Jonathan Blow: http://forum.dlang.org/thread/qilkslpfwvkbqlradhit forum.dlang.org Bye, bearophile
Dec 11 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 struct Vec { float x = 1, y = 5, z = 9; }

 auto v = new Vec(void);
 auto av = new Vec[10] = void;
 auto av2 = new Vec[10] = Vec(0, 0, 0);
D already does this.
D doesn't do that, not even one of those three :-) I'm willing to open one or two ERs later on those things. At best in Phobos we have a workaround for the second of those three ideas: auto av = minimallyInitializedArray(Vec, 10);
 He suggests a way to optionally specify the type of array 
 indexes. In a D-like
 syntax it could be:

 enum N = 10;
 float[N : ushort] a1;
 float[: ushort] a2;
I don't see any point to this.
 My point of having this in D is to optionally increase 
 strictness of the array
 indexes, to avoid some bugs when you handle many arrays.
Doesn't make sense to me.
I explained the topic here (note this not exactly the same thing discussed by Jonathan Blow: http://forum.dlang.org/thread/qilkslpfwvkbqlradhit forum.dlang.org Bye, bearophile
Dec 11 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/11/2014 1:49 PM, bearophile wrote:
 Walter Bright:

 struct Vec { float x = 1, y = 5, z = 9; }

 auto v = new Vec(void);
 auto av = new Vec[10] = void;
 auto av2 = new Vec[10] = Vec(0, 0, 0);
D already does this.
D doesn't do that, not even one of those three :-)
I beg to differ: struct Vec { float x = 1, y = 5, z = 9; } void main() { { Vec v; assert(v.x == 1 && v.y == 5 && v.z == 9); } { auto v = new Vec(); assert(v.x == 1 && v.y == 5 && v.z == 9); } { auto v = cast(Vec*)malloc(Vec.sizeof * 10)[0..10]; } { auto v = new Vec[10]; v[] = Vec(0,0,0); assert(v[1].x == 0 && v[1].y == 0 && v[1].z == 0); } }
Dec 11 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 On 12/11/2014 1:49 PM, bearophile wrote:
 Walter Bright:

 struct Vec { float x = 1, y = 5, z = 9; }

 auto v = new Vec(void);
 auto av = new Vec[10] = void;
 auto av2 = new Vec[10] = Vec(0, 0, 0);
D already does this.
D doesn't do that, not even one of those three :-)
I beg to differ: struct Vec { float x = 1, y = 5, z = 9; } void main() { { Vec v; assert(v.x == 1 && v.y == 5 && v.z == 9); }
This is not relevant in this discussion.
   {
     auto v = new Vec();
     assert(v.x == 1 && v.y == 5 && v.z == 9);
   }
This misses the point. This code: struct Vec { float x = 1, y = 5, z = 9; } auto v = new Vec(void); Means having defined a struct with explicitly statically defined fields, and then allocate one of it on the heap without initializing its fields. It's equivalent to: auto v = cast(Vec*)malloc(Vec.sizeof); Also written like this if you have written a little function (missing in Phobos) that makes your code more DRY and hides the cast in a probably trusted function: auto v = cMalloc!Vec; Similar code can be written if you want to use the GC heap.
   {
     auto v = cast(Vec*)malloc(Vec.sizeof * 10)[0..10];
   }
This is right, but in D it's often better to use std.array.uninitializedArray to do that.
   {
     auto v = new Vec[10];
     v[] = Vec(0,0,0);
     assert(v[1].x == 0 && v[1].y == 0 && v[1].z == 0);
   }
 }
This causes double initialization of the array, and I can't be sure the optimizer removes the first one (dmd doesn't remove it, and until now ldc2 doesn't remove it). To solve this problem with Phobos code it can be added another std.array function like: auto av2 = initializedArray!(Vec[])(10, Vec(0, 0, 0)); Beside constants, initializedArray also should accept a pure function that takes as input the index (this request is in Bugzilla). So all three patterns can be realized using functions, so there's no need to change the D language to do all three things. But are some of those patterns common enough to deserve to be supported by the language? Bye, bearophile
Dec 12 2014
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/12/2014 10:54 AM, bearophile wrote:
 This code:
 struct Vec { float x = 1, y = 5, z = 9; }
 auto v = new Vec(void);

 Means having defined a struct with explicitly statically defined fields,
 and then allocate one of it on the heap without initializing its fields.
 It's equivalent to:

 auto v = cast(Vec*)malloc(Vec.sizeof);
D is a language with C-like syntax and static typing. It pragmatically combines efficiency, control, and modeling power, with ~~~>safety<~~ and programmer productivity. Unsafe stuff shouldn't be simple to type and why would you need language support for a 1-liner? ref T uninitializedAlloc(T)() system pure nothrow { return *cast(T*)GC.malloc(T.sizeof); } The only argument I can see is the asymmetry to Vec v = void;
Dec 12 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Martin Nowak:

OK, I think that it will be enough to add a Phobos function like 
this (what's the right Phobos module to put it?) (why isn't this 
 trusted?) (why isn't this returning a T*?):


 ref T uninitializedAlloc(T)()  system pure nothrow
 {
     return *cast(T*)GC.malloc(T.sizeof);
 }
Plus these one of two Phobos functions: https://d.puremagic.com/issues/show_bug.cgi?id=8280 (But the request about optionally strongly typed array indexes is still active). Bye, bearophile
Dec 12 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 OK, I think that it will be enough to add a Phobos function 
 like this (what's the right Phobos module to put it?) (why 
 isn't this  trusted?) (why isn't this returning a T*?):


 ref T uninitializedAlloc(T)()  system pure nothrow
 {
    return *cast(T*)GC.malloc(T.sizeof);
 }
https://issues.dlang.org/show_bug.cgi?id=13859 Bye, bearophile
Dec 12 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/12/14 2:47 AM, bearophile wrote:
 OK, I think that it will be enough to add a Phobos function like this
 (what's the right Phobos module to put it?) (why isn't this  trusted?)
 (why isn't this returning a T*?):


 ref T uninitializedAlloc(T)()  system pure nothrow
 {
    return *cast(T*)GC.malloc(T.sizeof);
 }
https://issues.dlang.org/show_bug.cgi?id=13859 Bye, bearophile
There should be a minimallyInitializedAlloc, too. -- Andrei
Dec 22 2014
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/12/2014 11:42 AM, bearophile wrote:
 Martin Nowak:

 OK, I think that it will be enough to add a Phobos function like this
 (what's the right Phobos module to put it?)
Did you just volunteer to make a pull :)? As usual, having a problem to find the right place myself. Would put it close to uninitializedFill which lives in std.algorithm, yuck. BTW, if anyone knows where initOnce should go, I'd be glad to hear. https://github.com/D-Programming-Language/phobos/pull/2664#issuecomment-66242464
 (why isn't this  trusted?)
Can't be trusted because it returns a heap allocated struct that might contain uninitialized pointers. You could be more precise and make an overload for plain value types.
 (why isn't this returning a T*?):


 ref T uninitializedAlloc(T)()  system pure nothrow
 {
     return *cast(T*)GC.malloc(T.sizeof);
 }
Yeah, that should return a pointer.
Dec 12 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/11/2014 1:49 PM, bearophile wrote:
 He suggests a way to optionally specify the type of array indexes. In a D-like
 syntax it could be:

 enum N = 10;
 float[N : ushort] a1;
 float[: ushort] a2;
I don't see any point to this.
 My point of having this in D is to optionally increase strictness of the array
 indexes, to avoid some bugs when you handle many arrays.
Doesn't make sense to me.
I explained the topic here (note this not exactly the same thing discussed by Jonathan Blow: http://forum.dlang.org/thread/qilkslpfwvkbqlradhit forum.dlang.org
I don't see support for the notion of a ushort index.
Dec 11 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I don't see support for the notion of a ushort index.
A ushort index is not useful, I agree. That's why I have said my proposal is a little different from Jonathan Blow idea. My point was to optionally define built-in arrays with a strongly typed indexing (where the strongly typed index can be defined with a better version of Typedef!()), as I've tried to explain in that post. If you have questions please ask and I'll try to explain again (at worst Monday). Bye, bearophile
Dec 12 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/12/2014 1:58 AM, bearophile wrote:
 My point was to optionally define built-in arrays with a strongly typed
indexing
 (where the strongly typed index can be defined with a better version of
 Typedef!()), as I've tried to explain in that post.
All you have to do is define your own array type as a struct wrapper around an array, then overload the [] operator. No need for new language features.
Dec 12 2014
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/11/2014 10:34 PM, Walter Bright wrote:
 D already does this. It's been said before, Jonathan is reinventing D,
 piece by piece :-)
What does that mean, it's been said? Didn't anyone actually try to tell him about D?
Dec 12 2014
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 12 December 2014 at 11:58:04 UTC, Martin Nowak wrote:
 On 12/11/2014 10:34 PM, Walter Bright wrote:
 D already does this. It's been said before, Jonathan is 
 reinventing D,
 piece by piece :-)
What does that mean, it's been said? Didn't anyone actually try to tell him about D?
Actually he dismisses D in his first video for being too much like C++.
Dec 12 2014
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 12/12/2014 01:15 PM, Tobias Pankrath wrote:
 Actually he dismisses D in his first video for being too much
 like C++.
What do you usually do when learning a new programming language? Right, write a small program. Apparently he ruled out all 3 candidates by looking at the front page of their website, so clearly this guy wants to write his own "personal perfect" programming language, be it for fun or for fame. I think every good C++ programmer ends up in this situation at some point and using an existing language will always feel like a compromise. And who wouldn't have thought of writing a better D ;). Anyhow, he seems to be a somewhat smart guy and we could really make use of one that has enough time to write a compiler. Maybe we could talk him into giving D a more in-depth look. He might have missed the pragmatic in "It pragmatically combines efficiency, control, and modeling power, with safety and programmer productivity.". https://www.youtube.com/watch?v=TH9VCN6UkyQ#t=1626 But to understand how much more productive D is in comparison to C++, he'd have to actually code something. -Martin
Dec 12 2014
prev sibling next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Friday, 12 December 2014 at 11:58:04 UTC, Martin Nowak wrote:
 On 12/11/2014 10:34 PM, Walter Bright wrote:
 D already does this. It's been said before, Jonathan is 
 reinventing D,
 piece by piece :-)
What does that mean, it's been said?
He means he said it before: :) http://forum.dlang.org/post/m33eun$1ki4$1 digitalmars.com
Dec 12 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Friday, 12 December 2014 at 11:58:04 UTC, Martin Nowak wrote:
 On 12/11/2014 10:34 PM, Walter Bright wrote:
 D already does this. It's been said before, Jonathan is 
 reinventing D,
 piece by piece :-)
What does that mean, it's been said? Didn't anyone actually try to tell him about D?
I did in a quite long e-mail. Here is his answer:
 I agree that D is a much better language than C++ but I don't 
 believe it is quite the right thing. I am going to keep doing 
 talks, and the further talks will go into more language 
 specifics, and I think you'll see that eventually it shapes up 
 into a pretty different language.
 That said, I do think D has a lot of value, and if the world 
 switched over to D from C++ tonight, I think everyone would be 
 a lot better off.
 I am well aware of how much work it is to make a new language 
 and get it adopted. It is a big job for sure! But, part of my 
 goal is to rally the big game development community to do that 
 big job.
I feel like he is a very capable programmer that simply want to do his thing, like many of us do :)
Dec 12 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/12/2014 3:57 AM, Martin Nowak wrote:
 On 12/11/2014 10:34 PM, Walter Bright wrote:
 D already does this. It's been said before, Jonathan is reinventing D,
 piece by piece :-)
What does that mean, it's been said? Didn't anyone actually try to tell him about D?
I've emailed him about it. He is having a great time designing his own language, though, and of course I can understand that :-)
Dec 12 2014
prev sibling parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 11 December 2014 at 16:57:35 UTC, bearophile wrote:
 Jonathan Blow, Programming Language Demo #2:

 https://www.youtube.com/watch?v=-UPFH0eWHEI

 https://www.reddit.com/r/programming/comments/2oyg5e/jonathan_blow_dec_10_programming_language_demo_2/

 ------------------

 He shows a way to not initialize a struct that has specified 
 values. In D it could be:

 struct Vec { float x = 1, y = 5, z = 9; }

 auto v = new Vec(void);
 auto av = new Vec[10] = void;
 auto av2 = new Vec[10] = Vec(0, 0, 0);

 ------------------

 He suggests a way to optionally specify the type of array 
 indexes. In a D-like syntax it could be:

 enum N = 10;
 float[N : ushort] a1;
 float[: ushort] a2;

 My point of having this in D is to optionally increase 
 strictness of the array indexes, to avoid some bugs when you 
 handle many arrays.

 ------------------

 He suggests something like a  noinline attribute.

 Bye,
 bearophile
It would be nice, if you gave a real world example and explained why you need this feature and whether the problem is general enough to turn it into a feature of the language. I sometimes think "Wouldn't it be nice to have feature X now!" only to find out it is already there. This, or I realize the code is flawed somewhere else and I can sort it out by fixing the flawed code. I'm sometimes tempted to demand a feature, but then I realize that the problem is so specific that it would be ridiculous to demand a language feature for a problem that is specific only to my problem. It reminds me of laws. At the beginning laws cover general cases (theft, fraud whatever), then people demand a specific law for theft after 5 o'clock in winter when the moon is full as opposed to theft in summer when the sky is blue. And there was this guy who got robbed in autumn ...
Dec 12 2014