bearophile wrote:
Andrei Alexandrescu:
Well I think a language can only have so many built-in types. We
can't go on forever.
Too many built-ins become confusing (see Fortress), but D is quite
far from that point (see Python, that has more than D and they are
just fine and easy to use and remember. I'd also like to add a set
literal to the D syntax, semantically implemented in the std
library).
Would the special set syntax look a ton better than
set(1, 2, 5, 6)
set("ab", "c")
?
On the other hand Scala language shows that a good language allows
you to remove things from the language/syntax and implement them as
libraries (Scala moves in the libs several things that are built-in
in D). So it's a dynamic balance, things go, things come. But note
that collection "literals" of Scala are worse than Python ones.
---------------
Sergey Gromov:
Comma expression is not ambiguous. It's a comma expression.
Renaming it into a tuple constructor expression does not add any
ambiguity. Parentheses here are only required to separate the comma
expression from an assignment expression which otherwise would
become a part of comma expression.<
Python has tuples, but their syntax has some holes I have never fully
loved. See: Empty tuple: ()
Tuple with 1 item: 1, Or (1,)
Tuple with two items: 1, 2 Or: (1, 2)
They also support smarter forms of unpacking (Python 2.6): def
foo((x, y)): Now if you pass foo a pair (a 2-list, 2-tuple, 2-string,
2-lazy iterable, 2-array, 2-set, 2-dict, etc) you have available and
assigned x and y inside foo.
In the following syntax (Python 3.0+), c becomes assigned with all
the items following the second one: a, b, *c = baz
In the end I don't like the use of () to denote tuples (well, in
Python most of the times it's the comma that denotes a tuple, only
empty tuples needs () ). So better to use different ways to denote
them.
Bye, bearophile
I guess I can't bring myself to dislike tuple(1, 2) in D.
Andrei
