Re: Jonathan Blow demo #2
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
Re: Jonathan Blow demo #2
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
Re: Jonathan Blow demo #2
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
Re: Jonathan Blow demo #2
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;
Re: Jonathan Blow demo #2
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
Re: Jonathan Blow demo #2
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
Re: Jonathan Blow demo #2
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.
Re: Jonathan Blow demo #2
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?
Re: Jonathan Blow demo #2
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++.
Re: Jonathan Blow demo #2
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 ...
Re: Jonathan Blow demo #2
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
Re: Jonathan Blow demo #2
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
Re: Jonathan Blow demo #2
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 :)
Re: Jonathan Blow demo #2
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.
Re: Jonathan Blow demo #2
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 :-)
Jonathan Blow demo #2
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
Re: Jonathan Blow demo #2
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.
Re: Jonathan Blow demo #2
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/qilkslpfwvkbqlrad...@forum.dlang.org
Bye,
bearophile
Re: Jonathan Blow demo #2
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/qilkslpfwvkbqlrad...@forum.dlang.org
Bye,
bearophile
Re: Jonathan Blow demo #2
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/qilkslpfwvkbqlrad...@forum.dlang.org I don't see support for the notion of a ushort index.
Re: Jonathan Blow demo #2
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);
}
}
