www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Jonathan Blow demo #2

reply "bearophile" <bearophileHUGS lycos.com> writes:


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:



 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