• NN (91/91) Apr 16 2006 I love the idea of D language.
• Daniel Keep (58/147) Apr 16 2006 [snip]
• renox (18/20) Apr 17 2006 One thing which could be made postfix is pointers instead of having
• Chris Nicholson-Sauls (27/51) Apr 17 2006 Its an interesting idea, although the latter case is not neccessary, I d...
• renox (21/40) Apr 17 2006 Chris Nicholson-Sauls wrote:
• Jarrett Billingsley (10/13) Apr 17 2006 I find it a lot easier to think of multi-dimensional arrays as if they h...
• David Medlock (6/22) Apr 17 2006 I would say wrap your array for the specific problem you are trying to
• Chris Nicholson-Sauls (13/29) Apr 17 2006 Honestly, to my eyes? The current style. I don't care for the `->` sym...
• renox (23/61) Apr 18 2006 In Pascal it was 'type: array[1,10] of int;' if memory serves which is

NN <NN_member pathlink.com> writes:

I love the idea of D language.
But I think it misses some usefult points.

1.
There is no compile-time reflection.
E.g. one could write:
[d]
class a
{
void f() {}
int i;
}

int a_methods = a.methods.length;
bool has_a_f = a.has_method(f);
int a_variables = a.variables.length;
bool has_a_i = a.has_variable(i);

// Or even
class b
{
void g();
}

type a_f_type = a.f.type;
foreach(auto b_f_type; b.methods)
if(a_f_type == b_f_type)
b.b_f_type(); // call b.g
[/d]

2.
Make all postfix:
[d]
// instead of
typeof(a) x = 1;

// write:
a.type x = 1;

// instead of
int a = cast(int)('a');

// write:
int a = 'a'.cast<int>;
// or if we have static_cast :)
int a = 'a'.static_cast<int>;
[/d]

3.
Extensible Metainformation:
E.g.
[d]
class a
{
meta
{
bool is_a = true;
}
}

meta // For all types
{
bool is_a = false;
}

a x;
int y;

static_assert(x.is_a == true);
static_assert(y.is_a == false);
[/d]

4.
Make built-in types likely to object types.

5.
'auto' keyword problem resolution.
auto x = new a(); // auto type, or auto destructor ?

E.g.:
[d]
auto a x = new a(); // destrutor
var x = new a(); // auto type
auto var x = new a(); // auto type + destructor
[/d]

6.
C syntax for templates.
It's so natural.

7.
More casts.
E.g. 
static_cast
dynamic_cast
reinterpret_cast // make it safe, error if size of arguments is different
pointer_cast


8.
implicit 'new'.
E.g.
[d]
a x(...); // same as , a x = new a(...)
// same as , auto x = new a(...)

int[] q(1, 2, 3, 4, 5); // same as int[] q = new int[](1, 2, 3, 4, 5);
[/d]

9.
Will be continued. :)

Thank you for attention.

Daniel Keep <daniel.keep.lists gmail.com> writes:

NN wrote:
 I love the idea of D language.
 But I think it misses some usefult points.
 
 1.
 There is no compile-time reflection.

[snip]

Yeah, /me wants that too.  You could *probably* fake it using some kind
of preprocessor and TypeInfo_* classes, but that's a bit iffy.

 2.
 Make all postfix:
 [d]
 // instead of
 typeof(a) x = 1;
 
 // write:
 a.type x = 1;

That's fine for single values, but what if you've got an expression?



looks a bit odd.

 // instead of
 int a = cast(int)('a');
 
 // write:
 int a = 'a'.cast<int>;
 // or if we have static_cast :)
 int a = 'a'.static_cast<int>;
 [/d]

I can guarantee that you will never see the syntax `cast<int>`, since
that has the same problem as C++-style templates: they aren't context free.

Also, again, (some complex expression).cast(type) just seems a bit funky.

 
 3.
 Extensible Metainformation:
 E.g.
 [d]
 class a
 {
 meta
 {
 bool is_a = true;
 }
 }
 
 meta // For all types
 {
 bool is_a = false;
 }
 
 a x;
 int y;
 
 static_assert(x.is_a == true);
 static_assert(y.is_a == false);
 [/d]

I'm ... not entirely sure what you're trying to do with this.  It looks
almost like extension methods, except with (basically) wildcard
matching.  Interesting idea, but I can't think of any cases where it'd
be useful.

You could probably emulate it with templates:











 
 4.
 Make built-in types likely to object types.

Your sentence no parse correctly. (huh?)

Do you mean "make built-in types object types"?

 
 5.
 'auto' keyword problem resolution.
 auto x = new a(); // auto type, or auto destructor ?
 
 E.g.:
 [d]
 auto a x = new a(); // destrutor
 var x = new a(); // auto type
 auto var x = new a(); // auto type + destructor
 [/d]

I don't like the name 'var', but I do think Walter should pick a new
keyword for inferred types (maybe 'infer'?).

Actually, from the docs, I get the impression it doesn't HAVE to be
'auto'; any storage class will do.  I still think there should be a
keyword whose only job is to say "normal storage class, figure out the
type for yourself".

 
 6.
 C syntax for templates.
 It's so natural.
 

C doesn't have templates.  I'm going to assume you meant "C++ syntax".
In which case, again, ain't going to happen (see `cast<int>`).

 7.
 More casts.
 E.g. 
 static_cast
 dynamic_cast
 reinterpret_cast // make it safe, error if size of arguments is different
 pointer_cast
 

One of the biggest problems I had with C++ was all the casts.  I spent a
considerable amount of time pouring over C++ books, and I never did work
out what the hell those things do.

For my money, the cast we have is fine for the moment.  The only thing I
can think of that would be nice is some kind of decoupled conversion
like so:







So that something like `T y = cast(T)x` would become `opCast(y,x)`.

But maybe that's just me. ^_^

 
 8.
 implicit 'new'.
 E.g.
 [d]
 a x(...); // same as , a x = new a(...)
 // same as , auto x = new a(...)
 
 int[] q(1, 2, 3, 4, 5); // same as int[] q = new int[](1, 2, 3, 4, 5);
 [/d]

Actually, what I'd *really* like to see is implicit 'new', but in the
Python sense:




The rationale behind that is that classes and object factories are
suddenly interchangeable.

 
 9.
 Will be continued. :)

Dun, dun dunnnnnn...

 
 Thank you for attention.
 
 

	-- Daniel

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/

renox <renosky free.fr> writes:

NN wrote:
[cut]
 2.
 Make all postfix:

One thing which could be made postfix is pointers instead of having
*p=5; using p =5; would be better: no need to use parenthesis to 
distinguish between *(f()) and (*f)(), it becomes f()  and f () .

And no need to have the C shortcut pst->field, it just becomes pst .field

Having postfix pointer dereferencing is better IMHO, what I'm not sure 
is if postfix is better for getting the address of an object, that is 
replacing p = &x ; by p = x.get_address; here I'm not sure that there is 
a real advantage.



I would add one point: replace C like type declaration (which sucks a 
lot) by Pascal like type declaration.
Pacal like type declaration still sucked because it was too verbose: C 
terseness with Pascal like variable declaration would be ideal IMHO.

Something looking like: x:  [10]->int; (the variable x is a pointer to 
an array of 10 int) but I've not yet thought enough about it.

Regards,
Renox

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

renox wrote:
 NN wrote:
 [cut]
 
 2.
 Make all postfix:

 
 
 One thing which could be made postfix is pointers instead of having
 *p=5; using p =5; would be better: no need to use parenthesis to 
 distinguish between *(f()) and (*f)(), it becomes f()  and f () .

Its an interesting idea, although the latter case is not neccessary, I don't
believe, even 
if one uses a C-style function pointer.  D automagically dereferences for
member accesses 
and function/delegate invocations.

 And no need to have the C shortcut pst->field, it just becomes pst .field

We don't have this, already.  With pointers, you just use the dot (.) operator.
 Also, the 
most common occurance of pointers with fields -- class instances -- does not
apply to D, 
because class variables are references.  So...









 Having postfix pointer dereferencing is better IMHO, what I'm not sure 
 is if postfix is better for getting the address of an object, that is 
 replacing p = &x ; by p = x.get_address; here I'm not sure that there is 
 a real advantage.

I think the address operator should be left alone.  Besides, it reads well as
"address-of" 
in this position.

 I would add one point: replace C like type declaration (which sucks a 
 lot) by Pascal like type declaration.
 Pacal like type declaration still sucked because it was too verbose: C 
 terseness with Pascal like variable declaration would be ideal IMHO.
 
 Something looking like: x:  [10]->int; (the variable x is a pointer to 
 an array of 10 int) but I've not yet thought enough about it.

// your idea: x:  [10]->int;
// currently: int[10]* x;

Knowing that in D types are read right-to-left in declerations, I really don't
think we 
need this big of a change.  Especially since we do have the 'function' keyword
for doing 
function pointers.







 Regards,
 Renox

-- Chris Nicholson-Sauls

renox <renosky free.fr> writes:

Chris Nicholson-Sauls wrote:
[cut interesting remark showing that automagic pointer dereferencing 
reduce the interest of postfix pointer derefencing]
 // your idea: x:  [10]->int;
 // currently: int[10]* x;
 
 Knowing that in D types are read right-to-left in declarations,

I know that and for me, this is an unpleasant pitfall of D, especially 
for array declaration:
int[Y][X] t; and then t[x][y] = ...

t: [X]->[Y]->int; and then t[x][y] = ...

Honnestly which reads better?

I know that D used to be (is still?) compatible with C declaration, but 
if helps for the array declaration (int t[X][Y];) but, this is a mess 
when there are pointers..

 I really 
 don't think we need this big of a change.  Especially since we do have 
 the 'function' keyword for doing function pointers.

I do agree that this is a big change and don't expect to see it in D, 
and in fact I'm so used to C's declaration that personnaly it's not a 
problem, but I do remember clearly that I had a hard time learning them 
while beginning C and I expect D beginners to have the same problem.. 
which is a pity.

Oh well, at least hopefully the out-of-bound exception will show them 
the mistake quicky (far from sure of course as it depends on the value 
used), but it is still a pitfall.

Regards,
renox

 





 
 Regards,
 Renox

 
 
 -- Chris Nicholson-Sauls

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"renox" <renosky free.fr> wrote in message 
news:e20n8n$cia$1 digitaldaemon.com...
 I know that and for me, this is an unpleasant pitfall of D, especially for 
 array declaration:
 int[Y][X] t; and then t[x][y] = ...

I find it a lot easier to think of multi-dimensional arrays as if they had 
parentheses to show binding of types, like so:

(int[Y])[X] t;

That is, t is an array of size [X] of (arrays of size[Y] of int).  That is, 
when you use one level of [] operators,

t[4]

You get an int[Y].  Then you use another set to strip off the [Y] to get at 
the actual int values. 

David Medlock <noone nowhere.com> writes:

renox wrote:
 Chris Nicholson-Sauls wrote:
 [cut interesting remark showing that automagic pointer dereferencing 
 reduce the interest of postfix pointer derefencing]
 // your idea: x:  [10]->int;
 // currently: int[10]* x;

 Knowing that in D types are read right-to-left in declarations,

 
 I know that and for me, this is an unpleasant pitfall of D, especially 
 for array declaration:
 int[Y][X] t; and then t[x][y] = ...
 
 t: [X]->[Y]->int; and then t[x][y] = ...
 
 Honnestly which reads better?
 

I would say wrap your array for the specific problem you are trying to 
solve, then override the opIndex/opIndexAssign  methods:

t[ X, Y ] = ....

Reads much better.

-DavidM

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

renox wrote:
 Chris Nicholson-Sauls wrote:
 [cut interesting remark showing that automagic pointer dereferencing 
 reduce the interest of postfix pointer derefencing]
 
 // your idea: x:  [10]->int;
 // currently: int[10]* x;

 Knowing that in D types are read right-to-left in declarations,

 
 I know that and for me, this is an unpleasant pitfall of D, especially 
 for array declaration:
 int[Y][X] t; and then t[x][y] = ...
 
 t: [X]->[Y]->int; and then t[x][y] = ...
 
 Honnestly which reads better?

Honestly, to my eyes?  The current style.  I don't care for the `->` symbol
needed in the 
proposed syntax, and I'm just too used (in D) to scanning down columns of
variables and 
glancing (right to left) to check types.  Probably if it had been otherwise
from earlier 
on, my habits would be different, while as it is...  Although I do admit to
liking a 
left-to-right style in general, I just don't see a way to do it in D.  For what
its worth, 
a purely hypothetical pet language of me and a couple buddies (codename Lux)
has used this 
for years:






-- Chris Nicholson-Sauls

renox <renosky free.fr> writes:

Chris Nicholson-Sauls wrote:

 renox wrote:
 
 Chris Nicholson-Sauls wrote:
 [cut interesting remark showing that automagic pointer dereferencing 
 reduce the interest of postfix pointer derefencing]

 // your idea: x:  [10]->int;
 // currently: int[10]* x;

 Knowing that in D types are read right-to-left in declarations,


 I know that and for me, this is an unpleasant pitfall of D, especially 
 for array declaration:
 int[Y][X] t; and then t[x][y] = ...

 t: [X]->[Y]->int; and then t[x][y] = ...

 Honnestly which reads better?

 
 
 Honestly, to my eyes?  The current style.  I don't care for the `->` 
 symbol needed in the proposed syntax,

In Pascal it was 'type: array[1,10] of int;' if memory serves which is 
definitely too verbose. I like '->' that's what Scala use: it looks like 
math.. But this is just a matter of taste.

 and I'm just too used (in D) to 
 scanning down columns of variables and glancing (right to left) to check 
 types. 

That's the problem once you got used to a syntax, you don't even see its 
  problem anymore, as I'm not using D and that in C/C++ the array 
declaration has the correct order, the inverse array declaration/usage 
of D still 'hurt my eyes'.

 Probably if it had been otherwise from earlier on, my habits 
 would be different, while as it is...  Although I do admit to liking a 
 left-to-right style in general, I just don't see a way to do it in D.  
 For what its worth, a purely hypothetical pet language of me and a 
 couple buddies (codename Lux) has used this for years:
 





Interesting, I like it. It's compact and it's clever to use & instead of  *.
The terseness may make it a bit hard to read for beginners, but it's nice.

I prefer 'variable: type' than the other way round because as in Limbo 
you can do this nice regular syntax:

my_var : int; // declares my_var with type int and initialise it with 
default value of type int (0).
my_var : int = 5; // declares my_var with type int and initialise it with 5
my_var := 5; // declares my_var with type inferred from 5 (int), and 
initialise it with 5
my_var = 6; // assign 6 to my_var, my_var must already be declared with 
a compatible type.

To avoid people abusing of ':=', the language just have to forbid double 
declaration of variable in the same function.

Regards,
Renaud.

 
 -- Chris Nicholson-Sauls