Re: We do not use C++ exceptions at Google
on Tue Feb 17 2009, Damien Kick <dkixk-AT-earthlink.net> wrote:
David Abrahams wrote:
on Sun Feb 01 2009, Damien Kick <dkixk-AT-earthlink.net> wrote:
David Abrahams wrote:
I agree that this is an extremely important idea in general, and for
C/C++ programmers in particular (see Stepanov on Regular Types).
However, most other languages I've encountered either have no value
semantics (Python, Java, Lisp, **) or inconsistent value semantics (D).
Isn't it strange that such a fundamental principle is inaccessible to
programmers in those languages?
Of course, one might wonder if value semantics really are such a
fundamental principal if there are so many successful languages which
completely lack value semantics.
That question sure made me think.
I think value semantics important because of its relationship to the
underlying machine model and to equational reasoning. In other words,
it's a combination that has to do with understandability *and*
efficiency, and not everyone cares about efficiency at this level. You
can provide an experience of pure value semantics if everything is
immutable, but then some important operations become too expensive. If
you want to allow mutability, your choices are to either expose the use
of references in the implementation (now mutating X changes the value of
Y) or to introduce real copy semantics.
Hmm, I'm not satisfied yet. Trying to put my finger on a good way to
say it (not enough sleep last night). Let me try again. Programming is
about mathematical structures. IMO it's important to be able to write
b = a
assert(a == b)
a += c
assert(a != b)
where a, b, and c are numeric types, whether built-in or user-defined,
and no matter how complicated their internal data structure.
Well, closer, but still not satisfied. I'll have to start thinking
about this more deeply. Thanks for the impetus.
But it's interesting to me to note that Common Lisp doesn't have a
copy-object on purpose <http://www.nhplace.com/kent/PS/EQUAL.html> and
that Kent Pitman, the project editor of the Common Lisp standard,
considers the main point of departure to be related to issues of
typing.
<blockquote>
In a language with strong static typing, the intentional type of the
object would be evident at compile time, and the same representational
type could be used for multiple intentional types. The main problem with
this approach is that it gives up dynamic typing, which Lisp users have
come to expect and enjoy.
If static type information is optional, it is difficult for language
designers to reliably express how operators behave in the hybrid
environment that results.
</blockquote>
To me that sounds like a failure to recognize the schematic type
requirements (i.e. concepts) present in the dynamically-typed code.
It's very reminiscent of this thread:
http://markmail.org/message/mvcq2wegwb2bzkpj
Of course, C++ does define a default copy construtor for every type,
but C++ programmers have to worry about deep copy vs shallow copy,
whether or not to introduce some kind of "virtual T* clone() const"
operation, and the problems introduced by the interaction of
pass-by-value and public inheritance, i.e. slicing. This all makes me
wonder if perhaps the more fundamental concept is object identity and
that the decisions to make regarding copying, assignment, and tests
for equality depend on the interactions of decisions made regarding
other more fundamental concepts in the design space of the language,
e.g. static vs dynamic typing.
Perhaps, but I don't think so. You can (and should) define the
semantics of "operators" on types, even when the type identity can only
be known at runtime.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]