Notes IV

[downs]

bearophile wrote:
> 
> 3) In my D code I keep writing "length" all the time (currently I can find 458 "length" words inside my d libs). It's a long word, $ inside the scope of [] helps reducing the typing, but I often enough write "lenght", so I think still a default attribute named "len" (as in Python) may be better than "length". The attribute "dup" too is an abbreviation, probably of "duplicate", so abbreviations seem acceptable in such context.
> 

Agreed. That abbreviation would be useful.
> 
> 4) Regarding the array/string concatenation the D docs say:
>> Many languages overload the + operator to mean concatenation. This confusingly leads to, does:
> "10" + 3
> produce the number 13 or the string "103" as the result? It isn't obvious, and the language designers wind up carefully writing rules to disambiguate it - rules that get incorrectly implemented, overlooked, forgotten, and ignored. It's much better to have + mean addition, and a separate operator to be array concatenation.<
> 
> I don't agree with that. Maybe that comment is true for Perl, where the wild casting is automatic, or it's true for Java, that automatically converts values to strings if you add them to a strings, but other languages are quite strict, like Python, that allows you only to "sum" two strings or to sum two numbers:
>>>> "10" + "3"
> '103'
>>>> 10 + 3
> 13
>>>> "10" + 3
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: cannot concatenate 'str' and 'int' objects
>>>> 10 + "3"
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for +: 'int' and 'str'
> Thanks to such strong (but dynamic) typing in Python I've never had problems in using "+" to join strings, and if you look in the Python newsgroup you will find surprisingly little complaints from people doing errors because of such overloading of "+". So I think "+" and "+=" are fine to join strings/arrays if you use them in a strong typed way, beside being more standard, because various languages use "+" for that purpose. (And string join is a very common operation, and to input "~" it forces to use the numerical keyboard to input it if you don't use an English keyboard). 
> 

Strongly disagreed. Addition simply isn't the same as concatenation, and using the same operator for both will cause confusion.

Besides, Walter is planning to eventually add array operations, i.e. [2, 3, 4] + [1, 1, 5] -> [3, 4, 9] which would be impossible if + already meant "concatenate".

> 
> 
> 5) AST macros: I think they add power to the language, and I think I'll enjoy using them. It will increase the appeal & sexiness of the language for some people. But they have downsides too, and not just derived from how much/how little hygienic they are. In Lisp macros are very useful, but a common compliant is that "with macros every programmer reinvents his/her language, making difficult understand and modify the code written by others". So I suggest to be careful in adding macros to D... Unfortunately I don't have a better suggestion to give. Note that macros that are present inside the STD lib avoid that problem, because they are standard, everyone uses them, and most people don't need to understand how the insides of the std lib works (as the source of the C++ STL, or of Blitz++, etc). 
> 
Programmers will create miniature languages anyway. Since this is unavoidable, I think it's best to just give them the tools to do it as easily and succinctly as possible, since trying to prevent it will only make the inevitable DSL's look uglier. :)

> 
> 6a) Often most of the time necessary to write programs is used to debug the code. So I encourage D to try to adopt syntax and other constructs that help avoid bugs in the first place. Many bugs can be avoided adding certain runtime cheeks that the compiler can remove when the code is compiled in release mode.

This is already done in some places (array bounds checking).

> 6b) It may be useful to create an online repository of bugs present in D code written by all people (ranked by their experience?), that may allow us to know what parts of D syntax lead to more bugs in people code, so we can fix the language to avoid some of them :-) For example I'd like to know if the error in the foreach() caused by "," and ";" of point (1) is common to other D programmers, or if (unlikely) it's just a problem of mine.

I think what you want goes more in the direction of a Wishlist with vote features. Such a thing already exists, although I don't know the URL.

> 8) I think string functions of Phobos are quite usable and powerful enough, but I think they are a bit too many/much complex. So I think it's better to reduce their number/complexity a bit. I think it's very positive when about 90% of the string functions can fit in a brain and they can be used from memory, leaving the necessity to read the Phobos docs only in the few cases where you need some subtler/less common string function. Such high memory recall rate is common among Python programmers (while Delphi has tons of very fast string functions (often written in assembly) and I have never succeed learning a large percentage of them), and it allows you to speed up you programming a lot. If you put lot of string functions in a lib, with complex usage, you obtain a more powerful string library, but then you have to look the manuals often, and the coding becomes slow. That's why I suggested that the "chomp"/"chop" names are too much similar and easy to confound.

Disagreed. Code space isn't limited; I see no reason to leave out functions that might be useful. Maybe create a better sorting for the documentation, though (grep+count over some large code base for importance?)

> 
> 
> 
> 9) AA literals need lot of improvement:
[snip]

Agreed. The current syntax is needlessly verbose.

> 
> 10b) In C# "yield" too seem to have a nice syntax:
> http://en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java

There exist several implementations of StackThreads for D (Tango's fibers, scrapple.tools' StackThreads, Mikola Lysenko's first StackThreads package (http://assertfalse.com/projects.shtml )).
Example using scrapple.tools:

auto GetEven = stackthread = (int delegate() read, void delegate(int) yield) {
  while (true) { auto n = read(); if (n % 2 == 0) yield(n); }
};
writefln(GetEven([2, 3, 4, 5, 6]));

> 13a) random functions in Phobos of DMD 2.x: a random function has contrasting requirements, because you need them in very different situations. I think such requirements can be satisfied with using two different random functions:
> - One very fast RND function, with very simple and short syntax, useful for little programs or where you need to compute lot of randoms, like in a little game. It may use the Kiss algorithm used by Tango.
> - One slower RND generator, it has to be very good, and thread safe. So this can use the Mersenne Twister, be a class and use a longer dotted syntax.

Vote [+] for Mersenne Twister in the standard library.

> 13b) In my d libs I have added some very useful functions like choice(sequence), randInt(a,b), randRange, shuffle(sequence), etc. I think they are almost necessary, and very easy to implement.

I'm not sure whether such things should be in the standard library.
Very tentatively in favor.

> 
> 
> 14) Reals [...] I don't like the compiler to fake them silently for me).
I do. :)

> 18c) This is another silly bug, but I presume it's not common enough to justify compiler changes:
> void main() {
>   void foo(int x) { printf("%d\n", x); }
>   foo((1, 2)); // prints 2
> }
This is not a bug; the comma expression evaluates, then discards all but the last expression.
It's only in D for C compatibility, which is stupid if you think about it.
Also, the existing usage of the comma expression makes it harder to implement more powerful native tuples.
IMNSHO, the comma expression should be deprecated. :)

> 
> Bye,
> bearophile

 --downs