Questions about syntax decisions

2010-05-19 Thread F. Almeida
Dear all,

I once took a curious look at D in the past (circa 2004), and also
read the DM newsgroups at the time that Stroustrup frequently posted
here.

Now, in 2010, I've been giving D 2.0 a second chance and I'm happy
with it. Strings, dynamic arrays and hash tables couldn't be easier
to use and the option of metaprogramming presents way more
possibilities than C++.

However, I have a few questions about syntax.

1) Operator overloading

First of all, I find the operator overloading weird. This is because
I'm used to C++'s syntax operator+ and operator+=, for example,
instead of opAdd and opAddAssign. While I understand that it
gives plenty of room and freedom for introducing new operators in
the future, it nonetheless feels less natural, at the lack of a
better word. C++ has a reserved keyword operator for this, why not
using a modified syntax to this end in D? Why not using, for
example, operator(+), operator(+=), or operator(cast(real))?
This would be consistent with the simplified function template
syntax, and make operator declarations easier to read (I find that
reading the symbol itself is more intuitive when reading the source
code).

2) Operators that change context when unary or binary

I noticed that for example, ~this denotes a class destructor
(thank you for including GC AND making it optional, btw), meaning
that the ~ operator is a negation when used as a unary operator.
However, it becomes a binary concatenation operator when used with
arrays/strings, which is completely unrelated to the other use.

The same applies to templates: ! is a logical negation operator
when used as an unary operator, but it denotes a template when
introduced in a function declaration, for example.

This can be confusing for people learning the language, especially
if it's a first or second programming language. There are a number
of symbols that are not used at all and could just as easily be
used. Why not use @? The fact that D does not use the C macro
preprocessor means that # is available, for example.

Thank you for taking the time to read my questions.

Regards,
F. Almeida


Re: Questions about syntax decisions

2010-05-19 Thread Simen kjaeraas

F. Almeida cpp.tutor...@gmail.com wrote:


I have a few questions about syntax.

1) Operator overloading

First of all, I find the operator overloading weird. This is because
I'm used to C++'s syntax operator+ and operator+=, for example,
instead of opAdd and opAddAssign. While I understand that it
gives plenty of room and freedom for introducing new operators in
the future, it nonetheless feels less natural, at the lack of a
better word. C++ has a reserved keyword operator for this, why not
using a modified syntax to this end in D? Why not using, for
example, operator(+), operator(+=), or operator(cast(real))?
This would be consistent with the simplified function template
syntax, and make operator declarations easier to read (I find that
reading the symbol itself is more intuitive when reading the source
code).


The reason for the naming of operator overloads in D was to prevent
stupid overloading. That is, while the + operator might mean
concatenation, addition, and possibly other things, opAdd does not
have this ambiguity. The hope was, programmers would be discouraged
from overloading + to mean anything other than addition.

Now, opAdd and its ilk are scheduled for deprecation. The newest
operator overloading scheme is much more C++-like, only easier to
implement for a mass of related operators:
http://digitalmars.com/d/2.0/operatoroverloading.html

As you can see, the new syntax is a template system, with the
actual operator as a string parameter. This lets you use string
mixins to cover more bases with one less code.


2) Operators that change context when unary or binary

I noticed that for example, ~this denotes a class destructor
(thank you for including GC AND making it optional, btw), meaning
that the ~ operator is a negation when used as a unary operator.
However, it becomes a binary concatenation operator when used with
arrays/strings, which is completely unrelated to the other use.

The same applies to templates: ! is a logical negation operator
when used as an unary operator, but it denotes a template when
introduced in a function declaration, for example.

This can be confusing for people learning the language, especially
if it's a first or second programming language. There are a number
of symbols that are not used at all and could just as easily be
used. Why not use @? The fact that D does not use the C macro
preprocessor means that # is available, for example.


These character were chosen because not that many are available, and
because they had no binary counterpart. A negate B makes no sense.
Of the remaining character (!...@#), # is taken by compiler special
token sequences (set line number, amongst others). That leaves ~, !
and @, and frankly, A ~ B looks a lot more like concatenation to me
than does A @ B or A ! B.

As for template instantiation, we have mostly the same choices, only
not the character chosen for concatenation. Again, a choice had to
be made, and at least to me, @ implies a connection that does not
make sense, while ! does not.


This all said, there have been discussions of adding other symbols
for operator overloading, most commonly ×, for cross product.
Needless to say, this character is not easily accessible on most
keyboards, and its addition to the language has therefore not
happened.

In this vein, I gave this example two years ago:

int a = Ø; //empty set, same as = void
int[] b = [1,2,3,4,5,6];
a = readInt();

if (a ∈ b) { // Element of - in
  float c = 2.1;
  float d =  readInt();
  writefln(c ≈ ⌈d⌉ ); // Approximately equal, ceil

  myClass c = getInstance();
  if (∃c) { // c exists, i.e. !is null
writefln(√(c.foo));
  }

  ∀element∈b { // New foreach syntax!
element *= ¼;
  }
}

I hope we don't get to see this any time soon.

--
Simen


Re: Questions about syntax decisions

2010-05-19 Thread F. Almeida
I see. The templated implementation is a big improvement. If the
intention was to prevent people to turn + into concatenation for
example, I'm afraid anybody really keen on doing so would still overload
opAdd.
As a side note, C++0x is going to add a new suffix operator to C++. This
operator would be useful in its own right. Are there any plans to add a
new opSuffix!(s) operator in D?


Re: Questions about syntax decisions

2010-05-19 Thread bearophile
F. Almeida:

 Now, in 2010, I've been giving D 2.0 a second chance and I'm happy
 with it. Strings, dynamic arrays and hash tables couldn't be easier
 to use and the option of metaprogramming presents way more
 possibilities than C++.

And there's a bit of possibility still to have AST macros in D3 (but recently 
they have got less probable).


 This can be confusing for people learning the language, especially
 if it's a first or second programming language.

I have not had problems with it, and people in D.learn seem to not complain 
about it. Currently there are far worse problems in D2 syntax.


 There are a number
 of symbols that are not used at all and could just as easily be
 used. Why not use @? The fact that D does not use the C macro
 preprocessor means that # is available, for example.

@ is now used for properties (currently there is the @property).

# is used only minimally. D tries to not add syntax that is valid C syntax with 
a different semantics.


 If the intention was to prevent people to turn +
 into concatenation for example, I'm afraid anybody really
 keen on doing so would still overload opAdd.

There was opCat plus language conventions. If programmers ignore them both, 
then they are stupid programmers. A language can't be designed to avoid really 
stupid errors like that, it's a wasted energy.


 As a side note, C++0x is going to add a new suffix operator to C++. This
 operator would be useful in its own right. Are there any plans to add a
 new opSuffix!(s) operator in D?

Quite probably it will not become part of D, I think Andrei doesn't like that. 
D has Foo!xxx(...) syntax.

Bye,
bearophile


Re: Questions about syntax decisions

2010-05-19 Thread Bill Baxter
On Wed, May 19, 2010 at 3:55 AM, bearophile bearophileh...@lycos.com wrote:

 As a side note, C++0x is going to add a new suffix operator to C++. This
 operator would be useful in its own right. Are there any plans to add a
 new opSuffix!(s) operator in D?

 Quite probably it will not become part of D, I think Andrei doesn't like 
 that. D has Foo!xxx(...) syntax.

It would also be chaos in D, since D lacks fine-grained control over namespaces.

D's module==namespace model means that every module has to be designed
with the idea that every publicly visible entity is likely to end up
in the global namespace.  That doesn't really play together nicely
with the notion of defining a bunch of what are essentially
single-letter functions.

--bb