On 1/7/12 12:48 PM, Walter Bright wrote:
On 1/7/2012 8:10 AM, Don wrote:
Moving AAs from a built-in to a library type has been an unmitigated
disaster
from the implementation side. And it has so far brought us *nothing*
in return.
Not "hardly anything", but *NOTHING*. I don't even have any idea of
what good
could possibly come from it. Note that you CANNOT have multiple
implementations
on a given platform, or you'll get linker errors! So I think there is
more pain
to come from it.
It seems to have been motivated by religious reasons and nothing more.
Why should anyone believe the same argument again?
Having a pluggable interface so the implementation can be changed is all
right, as long as the binary API does not change.
If the binary API changes, then of course, two different libraries
cannot be linked together. I strongly oppose any changes which would
lead to a balkanization of D libraries.
In my opinion this statement is thoroughly wrong and backwards. I also
think it reflects a misunderstanding of what my stance is. Allow me to
clarify how I see the situation.
Currently built-in hash table use generates special-cased calls to
non-template functions implemented surreptitiously in druntime. The
underlying theory, also sustained by the statement quoted above, is that
we are interested in supporting linking together object files and
libraries BUILT WITH DISTINCT MAJOR RELEASES OF DRUNTIME.
There is zero interest for that. ZERO. No language even attempts to do
so. Runtimes that are not compatible with their previous versions are
common, frequent, and well understood as an issue.
In an ideal world, built-in hash tables should work in a very simple
manner. The compiler lowers all special hashtable syntax - in a manner
that's MINIMAL, SIMPLE, and CLEAR - into D code that resolves to use of
object.di (not some random user-defined library!). From then on,
druntime code takes over. It could choose to use templates, dynamic type
info, whatever. It's NOT the concern of the compiler. The compiler has
NO BUSINESS taking library code and hardwiring it in for no good reason.
This setup allows static and dynamic linking of libraries, as long as
the runtimes they were built with are compatible. This is expected, by
design, and a good thing.
(Consider the disaster C++ has had forever with everyone inventing their
own string type. That insured zero interoperability between C++
libraries, a situation that persists even for 10 years after C++ finally
acquired a standard string library.)
It is exactly this kind of canned statement and prejudice that we must
avoid. It unfairly singles out C++ when there also exist incompatible
libraries in C, Java, Python, you name it.
Also, the last time the claim that everywhere invented their own string
type could have been credibly aired was around 2004.
What's built inside the compiler is like axioms in math, and what's
library is like theorems supported by the axioms. A good language, just
like a good mathematical system, has few axioms and many theorems. That
means the system is coherent and expressive. Hardwiring stuff in the
language definition is almost always a failure of the expressive power
of the language. Sometimes it's fine to just admit it and hardwire
inside the compiler e.g. the prior knowledge that "+" on int does modulo
addition. But most always it's NOT, and definitely not in the context of
a complex data structure like a hash table. I also think that adding a
hecatomb of built-in types and functions has smells, though to a good
extent I concede to the necessity of it.
We should start from what the user wants to accomplish. Then figure how
to express that within the language. And only lastly, when needed,
change the language to mandate lowering constructs to the MINIMUM EXTENT
POSSIBLE into constructs that can be handled within the existing
language. This approach has been immensely successful virtually whenever
we applied it: foreach for ranges (though there's work left to do
there), operator overloading, and too little with hashes. Lately I see a
sort of getting lazy and skipping the second pass entirely. Need
something? Yeah, what the hell, we'll put it in the language.
I am a bit worried about the increasing radicalization of the discussion
here, but recent statements come in frontal collision with my core
principles, which I think stand on solid evidential ground. I am
appealing for building consensus and staying principled instead of
reaching for the cheap solution. If we do the latter, it's quite likely
we'll regret it later.
Andrei
