 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Steven T. Hatton Guest
|
Posted: Mon Jul 11, 2005 7:02 am Post subject: Can C++ be derived from first principles? |
|
|
In a discussion elsewhere I mentioned that the amount of forward reference
found in ISO/IEC 14882:2003(E) was surprising to me. Take for example the
introductory note in §5:
1 [Note: Clause 5 defines the syntax, order of evaluation, and meaning of
expressions. An expression is a
sequence of operators and operands that specifies a computation. An
expression can result in a value and
can cause side effects.
2 Operators can be overloaded, that is, given meaning when applied to
expressions of class type (clause 9) or
enumeration type (7.2). Uses of overloaded operators are transformed into
function calls as described in
13.5. Overloaded operators obey the rules for syntax specified in clause 5,
but the requirements of operand
type, lvalue, and evaluation order are replaced by the rules for function
call. Relations between operators,
such as ++a meaning a+=1, are not guaranteed for overloaded operators
(13.5), and are not guaranteed for
operands of type bool. ?end note]
Obviously the Standard is sufficiently clear to implement a usable compiler
(although rumor has it, none fully implement the specification). To some
extent this is a purely academic question. Has anybody attempted to
"derive" C++ from "first principles"? That is, to present a definition of
the language beginning with a few foundational definitions, and developing
each language construct on the basis of previously introduced concepts.
--
Regards,
Steven
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
wkaras@yahoo.com Guest
|
Posted: Tue Jul 12, 2005 12:46 am Post subject: Re: Can C++ be derived from first principles? |
|
|
Steven T. Hatton wrote:
| Quote: | In a discussion elsewhere I mentioned that the amount of forward reference
found in ISO/IEC 14882:2003(E) was surprising to me. Take for example the
introductory note in §5:
1 [Note: Clause 5 defines the syntax, order of evaluation, and meaning of
expressions. An expression is a
sequence of operators and operands that specifies a computation. An
expression can result in a value and
can cause side effects.
2 Operators can be overloaded, that is, given meaning when applied to
expressions of class type (clause 9) or
enumeration type (7.2). Uses of overloaded operators are transformed into
function calls as described in
13.5. Overloaded operators obey the rules for syntax specified in clause 5,
but the requirements of operand
type, lvalue, and evaluation order are replaced by the rules for function
call. Relations between operators,
such as ++a meaning a+=1, are not guaranteed for overloaded operators
(13.5), and are not guaranteed for
operands of type bool. ?end note]
Obviously the Standard is sufficiently clear to implement a usable compiler
(although rumor has it, none fully implement the specification). To some
extent this is a purely academic question. Has anybody attempted to
"derive" C++ from "first principles"? That is, to present a definition of
the language beginning with a few foundational definitions, and developing
each language construct on the basis of previously introduced concepts.
|
Can you say more about what doing this would perhaps reveal about the
language? Are you saying you'd like to see a definition of C++ that
would be structured like Euclid's writings on Geometry?
I think that a big part of why C++ is more usable than Ada, Java, etc.
is that it has a (relatively) small set of basic, powerful "tools"
(pointers, templates, virtual functions, macros, etc.), and minimal
restrictions on how these tools can be combined. But if, like Euclid
going for the minimal set of axioms, we tried to go for the
minimal set of tools in C++, it would likely lead to mistakes. For
example, references at first glance might look like a redundant form
of pointers. But the syntax of references often allow templates
(or macros) to be written than can be efficient with both big objects
(using references to them) and small objects (pasing them by value).
I think there are probably alot of forward references in the Standard
that aren't strictly necessary. But removing them would probaly make
the Standard less rather than more usable. And the "cicularity" in
some sense is a reflection of reality. Even Euclid was aware that it's
somewhat arbitrary what you declare to be the axiom and what therefore
is the proven principle. Everything is defined by its relationships
to other things.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
kanze@gabi-soft.fr Guest
|
Posted: Tue Jul 12, 2005 10:11 am Post subject: Re: Can C++ be derived from first principles? |
|
|
Steven T. Hatton wrote:
| Quote: | In a discussion elsewhere I mentioned that the amount of
forward reference found in ISO/IEC 14882:2003(E) was
surprising to me. Take for example the introductory note in
§5:
1 [Note: Clause 5 defines the syntax, order of evaluation, and meaning of
expressions. An expression is a
sequence of operators and operands that specifies a computation. An
expression can result in a value and
can cause side effects.
2 Operators can be overloaded, that is, given meaning when applied to
expressions of class type (clause 9) or
enumeration type (7.2). Uses of overloaded operators are transformed into
function calls as described in
13.5. Overloaded operators obey the rules for syntax specified in clause 5,
but the requirements of operand
type, lvalue, and evaluation order are replaced by the rules for function
call. Relations between operators,
such as ++a meaning a+=1, are not guaranteed for overloaded operators
(13.5), and are not guaranteed for
operands of type bool. ?end note]
Obviously the Standard is sufficiently clear to implement a
usable compiler (although rumor has it, none fully implement
the specification).
|
Almost by definition. A C++ compiler is complicated enough that
I doubt it possible to write one without any errors. And of
course, any errors can make the compiler non conforming.
Modulo errors, I think that the latest versions of both Comeau
and the Intel compiler implement the entire language.
| Quote: | To some extent this is a purely academic question. Has
anybody attempted to "derive" C++ from "first principles"?
That is, to present a definition of the language beginning
with a few foundational definitions, and developing each
language construct on the basis of previously introduced
concepts.
|
In a certain sense, that's what the standard does. Sections 1
through 16 define the first principles, and sections 17 through
27 define the rest of the language in terms of those first
principles.
One could, of course, argue that this set of first principles is
a little bit larger than one might like. At least for a set of
first principles. :-)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
tony_in_da_uk@yahoo.co.uk Guest
|
Posted: Tue Jul 12, 2005 1:33 pm Post subject: Re: Can C++ be derived from first principles? |
|
|
Google for "BNF C++" (e.g. [url]http://www.nongnu.org/hcb/)[/url]. The Standard
might be able to be expressed around such a grammar, but I'm not sure
it would add much value. ADA's Language Reference Manual usefully
contains such a grammar. Additionally, you could search the C++ FAQ
lite for lex/yacc. If you become interested in such things, check out
the boost Spirit library, which is a mind-blowingly powerful and
easy-to-use text parser. When I checked about a year ago, I think
people had written a C++ lexer compatible with Spirit (but not a full
grammar parser). Think there was a C parser. Cheers, Tony
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Steven T. Hatton Guest
|
Posted: Tue Jul 12, 2005 4:18 pm Post subject: Re: Can C++ be derived from first principles? |
|
|
[email]tony_in_da_uk (AT) yahoo (DOT) co.uk[/email] wrote:
| Quote: | Google for "BNF C++" (e.g. [url]http://www.nongnu.org/hcb/)[/url]. The Standard
might be able to be expressed around such a grammar, but I'm not sure
it would add much value. ADA's Language Reference Manual usefully
contains such a grammar. Additionally, you could search the C++ FAQ
lite for lex/yacc. If you become interested in such things, check out
the boost Spirit library, which is a mind-blowingly powerful and
easy-to-use text parser. When I checked about a year ago, I think
people had written a C++ lexer compatible with Spirit (but not a full
grammar parser). Think there was a C parser. Cheers, Tony
|
That's not really what I meant, although I'm not exactly sure what I really
meant. There /is/ a grammar for C++ in Annex A of ISO/IEC 14882:200
(E). The grammer is not a complete language definition. AAMOF, I believe
there may be some ambiguities which must be resolved by means outside of
the BNF metalanguage. What I was intending was more along the lines of
Euclidian exposition. That is, stating a set of axioms (definitions), and
deriving every C++ language construct on the basis of these axioms. No
language construct would be introduced prior to its definition in terms of
previously defined more primitive constructs.
For example, in this idealized language definition there would be no
discussion of member function prior to the definition of /class/, and
thence member functions. Member function could, however, be defined in
terms of a previously defined function construct.
--
Regards,
Steven
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
tony_in_da_uk@yahoo.co.uk Guest
|
Posted: Tue Jul 12, 2005 10:39 pm Post subject: Re: Can C++ be derived from first principles? |
|
|
| Quote: | For example, in this idealized language definition there would be no
discussion of member function prior to the definition of /class/, and
thence member functions. Member function could, however, be defined in
terms of a previously defined function construct.
|
Hi Steven. Isn't that the way the BNF-ish grammars tend to work? You
either define things top-down, or bottom-up. True, some might allow
both directions, but I think that's generally discouraged. What you're
asking for is the latter, which is actually required by some parsers.
Any motivation or conception behind your enquiry? Regards, Tony
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
johnchx2@yahoo.com Guest
|
Posted: Tue Jul 12, 2005 10:40 pm Post subject: Re: Can C++ be derived from first principles? |
|
|
Steven T. Hatton wrote:
| Quote: | What I was intending was more along the lines of
Euclidian exposition. That is, stating a set of axioms (definitions), and
deriving every C++ language construct on the basis of these axioms.
|
I believe the answer to this is "no."
There are some languages (I think Haskell and ML, for example) that are
defined in terms of a very small and rigorously defined core calculus,
with each additional feature layered on top as "syntactic sugar," such
that every construct in the language can be translated into the core
calculus.
I think it's fair to describe the design of C++ as "pragmatic" rather
than "formal" -- fair in the sense that I believe that the designer of
the language (as well as most of the participants in the
standardization process) would neither disagree with the description
nor regard it as a criticism.
If formality interests you, you might be intrigued by this:
http://www.coyotos.org/docs/bitc-spec/bitc-spec.html
....which is an effort to design a language with formal properties like
ML, but which is suitable to systems programming.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Andrei Alexandrescu (See Guest
|
Posted: Wed Jul 13, 2005 10:32 am Post subject: Re: Can C++ be derived from first principles? |
|
|
Steven T. Hatton wrote:
| Quote: | That's not really what I meant, although I'm not exactly sure what I really
meant. There /is/ a grammar for C++ in Annex A of ISO/IEC 14882:200
(E). The grammer is not a complete language definition. AAMOF, I believe
there may be some ambiguities which must be resolved by means outside of
the BNF metalanguage. What I was intending was more along the lines of
Euclidian exposition. That is, stating a set of axioms (definitions), and
deriving every C++ language construct on the basis of these axioms. No
language construct would be introduced prior to its definition in terms of
previously defined more primitive constructs.
For example, in this idealized language definition there would be no
discussion of member function prior to the definition of /class/, and
thence member functions. Member function could, however, be defined in
terms of a previously defined function construct.
|
You're not really looking for a Euclidean definition. The usual tools
used in language semantics are either operational semantics or
denotational semantics. (The grammar doesn't tell anything about the
semantics.)
Other languages do have such a formal specification. Usually the
formalism only focuses on a "core" language - an essential subset of it
that defines its properties. Of all languages used in the industry, Java
is the only one that has a formal specification - google for
"Featherweight Java".
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
wkaras@yahoo.com Guest
|
Posted: Wed Jul 13, 2005 10:35 am Post subject: Re: Can C++ be derived from first principles? |
|
|
Steven T. Hatton wrote:
| Quote: | tony_in_da_uk (AT) yahoo (DOT) co.uk wrote:
Google for "BNF C++" (e.g. [url]http://www.nongnu.org/hcb/)[/url]. The Standard
might be able to be expressed around such a grammar, but I'm not sure
it would add much value. ADA's Language Reference Manual usefully
contains such a grammar. Additionally, you could search the C++ FAQ
lite for lex/yacc. If you become interested in such things, check out
the boost Spirit library, which is a mind-blowingly powerful and
easy-to-use text parser. When I checked about a year ago, I think
people had written a C++ lexer compatible with Spirit (but not a full
grammar parser). Think there was a C parser. Cheers, Tony
That's not really what I meant, although I'm not exactly sure what I really
meant. There /is/ a grammar for C++ in Annex A of ISO/IEC 14882:200
(E). The grammer is not a complete language definition. AAMOF, I believe
there may be some ambiguities which must be resolved by means outside of
the BNF metalanguage. What I was intending was more along the lines of
Euclidian exposition. That is, stating a set of axioms (definitions), and
deriving every C++ language construct on the basis of these axioms. No
language construct would be introduced prior to its definition in terms of
previously defined more primitive constructs.
For example, in this idealized language definition there would be no
discussion of member function prior to the definition of /class/, and
thence member functions. Member function could, however, be defined in
terms of a previously defined function construct.
|
It's really just an illusion that Euclid's specification of geometry
is non-circular. Euclid's axioms only deal with a very small number
of types of entities (points, lines, etc.). These types are "defined"
first, but would the definitions be meaningful to someone who was
blind and immobile from birth? But this doesn't bother the rest of
us -- our shared perceptions of the world make us feel we know what a
point or line is, and to accept that the axioms are correct. It's
more correct say that the axioms are what define the basic types
of entities. A dot on Euclid's infinite flat sheet of paper or
an ordered pair of real numbers can both be points, because they both
(when combined with an appriopriate type of "line" entity) obey the
axioms of of a Euclidean plane geometry. Some may say that's because
a point in space *is* a tuple of real numbers, but that seems like
a metaphysical backpatch to me. A specification like the C++
Standard deals with alot more types of entities, and they aren't
generally types of entities that everyone has shared experience
with in everyday life. Euclid's proofs would be more analogous
to C++ programs, where the entities, defined by the axioms,
combine and interact in meaningful ways.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Steven T. Hatton Guest
|
Posted: Wed Jul 13, 2005 10:43 am Post subject: Re: Can C++ be derived from first principles? |
|
|
[email]tony_in_da_uk (AT) yahoo (DOT) co.uk[/email] wrote:
| Quote: | For example, in this idealized language definition there would be no
discussion of member function prior to the definition of /class/, and
thence member functions. Member function could, however, be defined in
terms of a previously defined function construct.
Hi Steven. Isn't that the way the BNF-ish grammars tend to work? You
either define things top-down, or bottom-up. True, some might allow
both directions, but I think that's generally discouraged. What you're
asking for is the latter, which is actually required by some parsers.
Any motivation or conception behind your enquiry? Regards, Tony
|
It is the way grammars work, but I don't believe the grammar will tell you
all that is needed in order to implement the language. Parsers only turn
the sourcecode into something the compiler can digest. I do believe what I
am suggesting would very closely follow the structure of the grammar in
Annex A.
To some extent the Standard does follow that outline. It starts out in
clause 1 providing some fromal definition (some of which do seem to rely on
prior knowledge of subsequent material). Then it goes into clause 2 with a
reasonably orderly development of the basic lexicon of the language, which
I believe discusses all grammar elements prior to §A.3. Then in clause 3
we encounter the following which I have in the (original?) Danish:
Et slidigt gravben vridrede
i brumringen på tidvis plent,
og lappingen var vaklig, og
det borte gro°fgrin grent.
»Min so°n, pas godt på Jabberwock!
Han river, og hans tand er hvas.
Pas på den onde jubjub-fugl
og gribbekloens krads.«[*]
.....
Then clause 4 provides us with a necessary account of the the conversion
rules which no-one is likely to be able to fully recall, but even here we
encounter some discussion of pointers to member functions, which, in the
Euclidian development would not be discussed until after classes are
introduced and defined. Nonetheless, the subsequent text does more or less
follow the grammar.
As for motivation? Primarily I simply believe that any programming language
could in principle be expressed in such a mathematically rigorous manner.
I also have the sense that if it were accomplished it would shed
considerable light onto the language and how it could be used, taught, and
implemented more effectively. Even if the exercise were not a complete
success, I suspect it would still be productive to compare a partially
completed formal model with the existing specification.
I've also, in the past, proposed an "anthropological" study of C++. That
is, to try to define the language by studying its useage in the same way
linguists study natural languages. That, I believe is far less likely to
happen.
[*]For the humor impaired: this is a joke!
--
Regards,
Steven
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Steven T. Hatton Guest
|
Posted: Wed Jul 13, 2005 4:18 pm Post subject: Re: Can C++ be derived from first principles? |
|
|
[email]wkaras (AT) yahoo (DOT) com[/email] wrote:
| Quote: | Steven T. Hatton wrote:
[email]tony_in_da_uk (AT) yahoo (DOT) co.uk[/email] wrote:
Google for "BNF C++" (e.g. [url]http://www.nongnu.org/hcb/)[/url]. The Standard
might be able to be expressed around such a grammar, but I'm not sure
it would add much value. ADA's Language Reference Manual usefully
contains such a grammar. Additionally, you could search the C++ FAQ
lite for lex/yacc. If you become interested in such things, check out
the boost Spirit library, which is a mind-blowingly powerful and
easy-to-use text parser. When I checked about a year ago, I think
people had written a C++ lexer compatible with Spirit (but not a full
grammar parser). Think there was a C parser. Cheers, Tony
That's not really what I meant, although I'm not exactly sure what I
really
meant. There /is/ a grammar for C++ in Annex A of ISO/IEC 14882:200
(E). The grammer is not a complete language definition. AAMOF, I
believe there may be some ambiguities which must be resolved by means
outside of
the BNF metalanguage. What I was intending was more along the lines of
Euclidian exposition. That is, stating a set of axioms (definitions),
and
deriving every C++ language construct on the basis of these axioms. No
language construct would be introduced prior to its definition in terms
of previously defined more primitive constructs.
For example, in this idealized language definition there would be no
discussion of member function prior to the definition of /class/, and
thence member functions. Member function could, however, be defined in
terms of a previously defined function construct.
It's really just an illusion that Euclid's specification of geometry
is non-circular. Euclid's axioms only deal with a very small number
of types of entities (points, lines, etc.). These types are "defined"
first, but would the definitions be meaningful to someone who was
blind and immobile from birth? But this doesn't bother the rest of
us -- our shared perceptions of the world make us feel we know what a
point or line is, and to accept that the axioms are correct. It's
more correct say that the axioms are what define the basic types
of entities. A dot on Euclid's infinite flat sheet of paper or
an ordered pair of real numbers can both be points, because they both
(when combined with an appriopriate type of "line" entity) obey the
axioms of of a Euclidean plane geometry. Some may say that's because
a point in space *is* a tuple of real numbers, but that seems like
a metaphysical backpatch to me. A specification like the C++
Standard deals with alot more types of entities, and they aren't
generally types of entities that everyone has shared experience
with in everyday life. Euclid's proofs would be more analogous
to C++ programs, where the entities, defined by the axioms,
combine and interact in meaningful ways.
|
In his most advanced work, _The_Meaning_of_Relativity_, Albert Einstein
wrote on page 2:
"The only justification for our concepts and system of concepts is that
they represent the complex of our experiences; beyond this they have
no legitimacy. I am convinced that the philosophers have had a harmful
effect upon the progress of scientific thinking in removing certain
fundamental concepts from the domain of empiricism, where they are
under our control, to the intangible heights of the a priori. For even
if it should appear that the universe of ideas cannot be deduced from
experience by logical means, but is, in a sense, a creation of the
human mind, without which no science is possible, nevertheless this
universe of ideas is just as little independent of the nature of our
experiences as clothes are of the form of the human body. This is
particularly true of our concepts of time and space, which physicists
have been obliged by the facts to bring down from the Olympus of the a
priori in order to adjust them in a serviceable condition."
Now, taking your argument that the algebraic geometric space of Descartes
is isomorphic to Euclidian space, consider that using purely symbolic means
one can show that the Taylor series expansion of e^(xi)=cos(x) + i sin(x),
and from that we can derive the value of pi which is unique to Euclidian
geometry. It is therefore possible to argue that Einstein was not
completely correct in his assessment of the a priori nature of Euclidian
space. Furthermore, there are interpretations of the general theory of
relativity which do not require that "reality" is non-Euclidian. There is
also an observable means of determining the velocity vector of absolute
rest with respect to the observable Universe as a whole. But this is a C++
newsgroup, and we are not here to talk about the axiomatics of
quantum-geometrodynamics.
Geometric derivation is a cornerstone of Western Philosophy and does not
simply mean what is expressed in _The_Elements_ of Euclid. It is a means
of developing any logical construct on the basis of first principles.
Since the advent of non-Euclidian geometry, this field has been expanded to
what is sometimes called "axiomatics" which is the exercise of positing, at
will, first principles upon which logical constructs are erected. This is
distinct from from traditional geometric reasoning in so much as there is
no assumption a priori required of the stated axioms. These axioms are the
primitive foundation of the construct built upon them. It is this sense
that Dr. Stroustrup intended when he suggested that the C++ Standard
Library should provide a set of primitive building blocks for programmers.
It is not clear to me that there are innumerable foundational ideas upon
which C++ is built. That is quite distinct from saying that I could
readily enumerate these. Nonetheless, I suspect there /are/ some people who
have the skills to make a meaningful study of C++ in terms of logic and
linguistics.
--
Regards,
Steven
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Steven T. Hatton Guest
|
Posted: Thu Jul 14, 2005 5:32 pm Post subject: Re: Can C++ be derived from first principles? |
|
|
[email]johnchx2 (AT) yahoo (DOT) com[/email] wrote:
| Quote: | Steven T. Hatton wrote:
What I was intending was more along the lines of
Euclidian exposition. That is, stating a set of axioms (definitions),
and deriving every C++ language construct on the basis of these axioms.
I believe the answer to this is "no."
There are some languages (I think Haskell and ML, for example) that are
defined in terms of a very small and rigorously defined core calculus,
with each additional feature layered on top as "syntactic sugar," such
that every construct in the language can be translated into the core
calculus.
I think it's fair to describe the design of C++ as "pragmatic" rather
than "formal" -- fair in the sense that I believe that the designer of
the language (as well as most of the participants in the
standardization process) would neither disagree with the description
nor regard it as a criticism.
|
I believe it /was/ designed pragmatically. Nonetheless, part of that
pragmatism included holding onto some semblance of formal structure. It
may well be the case that the existing presentation /is/ more orderly than
I perceive it to be. If rather than insisting that 'member function' not
be discussed at all prior to the section fully defining 'class', we allow
for the introduction of a syntactic construct called 'member function'
based on prior lexical and syntactic definition, we may be able to still
use 'member function' where it appears in the development without loss of
formality. This would be something like a forward declaration.
My intuition tells me that C++ /has/ to be more structured than it appears
(to me) to be. There are probably steps of reasoning which were evident to
the language designer(s) at the time of codification which were not
preserved in the codification. (See comments on D&E below.)
Another direction from which to approach my objective might be the repeated
exercise of choosing any given statement in a (presumed) valid program and
attempt to trace the genessis of its definition back to the relevant
discussion in the Standard. From there, attempt to identify the
prerequisite ideas upon which the concept is based.
Part of the difficulty with the exercise I have proposed appears to be that
C++ was created in the real world of physical machines, and subsequently
abstracted. C++ therefore rests upon an abstract virtual machine similar
to the JVM, but with the exception that it is a pure abstraction. The C++
AVM, if you will, was also created in a somewhat ad hock manner. That is,
individual components were introduced as needed to break the dependency
between the physical implementation instance, and the purely conceptual
language definition.
There are multiple dimensions to the conceptual space inwhich the C++
language definition exists. I can't say I have a carefully selected
taxonomy of these. I can merely offer a few candidate examples. There is
the grammatical axis along which which the parser operates. There is the
(implicit) runtime memory layout. There is the source code file structure
which is mapped onto the translation unit axis. There is the sequential
runtime execution axis. The variability of physical implementation
platform also seems relevant here.
This may all seem to demonstrate the ultimate futility in attempting the
proposed exercise. To some extent it depends on what the objective is.
Beyond satisfying my innate desire for conceptual clarity, I do have
pragmatic ends. C++ is difficult to learn. And even when learned in the
sense of being able to write and read production code, it remains difficult
to understand in many ways. Some people have a great capacity for learning
prescriptive rules and following them faithfully. Others of us rely more
heavily on understanding as a guide to making our choices. Ultimately, the
prescriptive rules should rest upon formal understanding.
I believe, at its core, C++ is not as complex as it appears to be. There
is, I believe, a fundamental core which, when understood, will lead
logically and naturally to an understanding of the more difficult aspects
of the language. Perhaps reading D&E as well as Lippman's _Inside the C++
Object Model_ will help me identify this fundamental core. Unfortunately,
the copy of D&E I have on order seems to have taken a detour to Tibet in
its journey across the county inwhich I live.
I find these things interesting, but they do not address my immediate
objectives in proposing the derivation of C++ from first principles. That
objective being a better understanding of C++.
AFAIK, languages such as ML are typically recursive in nature, and do not
provide the flexibility (perhaps performance is a better word) of
procedurally based languages such as C++. This may be part of the
distinction between C++ and Java. I would say Java leans more toward being
a functional language than does C++.
I actually believe C++ is a far more coherent language than it appears to
be. It has one great flaw: '#'. When I contemplate what constitutes a
typical translation unit, I have the sense there is a clear path of
dependency which can be traced through it, and which only involves a very
small fraction of what is actually loaded into memory as the translation
unit. One library I recently began working with has a perverse number of
#include interdependencies. I suspect that is quite typical for many
"mature" C++ libraries.
I perceive that to presage an upper limit on the scaleability of C++. This
may seem out of context in the current discussion, but I don't believe it
is. I believe a core understanding of C++ in the fromal sense will lead to
a better understanding of how complex structures are built upon it, and
will therefore lead to a more coherent means of organizing and accessing
the components necessary for a given situation without involving an untold
number of irrelevant components which just happen to be in the #include
path.
--
Regards,
Steven
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
johnchx2@yahoo.com Guest
|
Posted: Fri Jul 15, 2005 11:01 am Post subject: Re: Can C++ be derived from first principles? |
|
|
Steven T. Hatton wrote:
| Quote: | This may all seem to demonstrate the ultimate futility in attempting the
proposed exercise. To some extent it depends on what the objective is.
Beyond satisfying my innate desire for conceptual clarity, I do have
pragmatic ends. C++ is difficult to learn. And even when learned in the
sense of being able to write and read production code, it remains difficult
to understand in many ways. Some people have a great capacity for learning
prescriptive rules and following them faithfully. Others of us rely more
heavily on understanding as a guide to making our choices. Ultimately, the
prescriptive rules should rest upon formal understanding.
|
A great deal depends on what you're prepared to accept as a "formal
understanding."
Let's talk about a specific example. One "prescriptive rule" in C++ is
that you may not initialize a reference to a non-const type with an
rvalue (i.e. you can't bind a non-const reference to a temporary)
(8.5.3/5).
| Quote: | From what formal understanding can this prescriptive rule be deduced?
|
The *historical* reason for the rule is pretty well known: in the
presence of implicit conversions, especially between numeric types,
allowing non-const references to temporaries turned out to be
error-prone in practice.
Over the years, a couple of folk-beliefs have sprung up about the
"reason" for the rule. One is that it makes no sense to want to modify
the state of a temporary object, since the object is "just going to go
away." This is simply incorrect -- there are lots of good reasons why
this might be a useful thing to do. (For example, we might want to
initialize an auto_ptr with an auto_ptr returned from a function. The
whole auto_ptr_ref apparatus was invented just to circumvent this
rule.)
The other folk-belief (mostly among C++ beginners) is that a temporary
object is somehow "implicitly const." Of course, this is also not so.
It is, for example, perfectly legal to call non-const member functions
on a temporary object of class type.
The point, I suppose, is that C++ does contain wrinkles which really
are just pragmatic kludges. Of course, it's possible to treat every
such kludge as an "axiom" in its own right, but that would tend to
defeat the purpose, if I understand the purpose correctly.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Steven T. Hatton Guest
|
Posted: Fri Jul 15, 2005 3:05 pm Post subject: Re: Can C++ be derived from first principles? |
|
|
[email]johnchx2 (AT) yahoo (DOT) com[/email] wrote:
| Quote: | Steven T. Hatton wrote:
This may all seem to demonstrate the ultimate futility in attempting the
proposed exercise. To some extent it depends on what the objective is.
Beyond satisfying my innate desire for conceptual clarity, I do have
pragmatic ends. C++ is difficult to learn. And even when learned in the
sense of being able to write and read production code, it remains
difficult
to understand in many ways. Some people have a great capacity for
learning
prescriptive rules and following them faithfully. Others of us rely more
heavily on understanding as a guide to making our choices. Ultimately,
the prescriptive rules should rest upon formal understanding.
A great deal depends on what you're prepared to accept as a "formal
understanding."
Let's talk about a specific example. One "prescriptive rule" in C++ is
that you may not initialize a reference to a non-const type with an
rvalue (i.e. you can't bind a non-const reference to a temporary)
(8.5.3/5).
|
That's not really what I meant by "prescriptive rule". That is what I would
call an "explicit rule", or "design decision". By "prescriptive rule", I
mean what typically falls under the heading of "style guidelines", or "best
practices".
| Quote: | From what formal understanding can this prescriptive rule be deduced?
The *historical* reason for the rule is pretty well known: in the
presence of implicit conversions, especially between numeric types,
allowing non-const references to temporaries turned out to be
error-prone in practice.
|
That would be relevant commentary explaining the motivation behind the
choice, but the "first principles" involved are the formal definition of
"rvalue", "initialize a reference", "non-const type", etc.
| Quote: | The point, I suppose, is that C++ does contain wrinkles which really
are just pragmatic kludges. Of course, it's possible to treat every
such kludge as an "axiom" in its own right, but that would tend to
defeat the purpose, if I understand the purpose correctly.
|
What I mean by 'deriving from first principles' is that any such explicit
design decision should be stated in terms of well defined precursors. I
don't mean that the entire language structure follows from a set of
fundamental axioms which determine every aspect of the C++ grammar. I mean
that there are fundamental principles which determine the meaning of design
decisions. This is similar to the way the laws of physics are used in
architectural engineering.
Quite often, we can study the physics of ancient designs and discover a
profound expression of insight into the underlying physics expressed in the
structure. Nonetheless, we tend to believe the designers didn't
"understand physics". Take for examples the efficiency of the Roman arch,
or its generalization, the dome, the flying buttress of the Gothic
cathedrals, the hydrodynamics of a Viking longship, etc. In all these
cases, there are certain aspects of the design which were completely
dependent upon the whim of the designer. But once certain design choices
were made, other aspects deterministically followed.
--
Regards,
Steven
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
johnchx2@yahoo.com Guest
|
Posted: Sat Jul 16, 2005 10:16 am Post subject: Re: Can C++ be derived from first principles? |
|
|
Steven T. Hatton wrote:
| Quote: | What I mean by 'deriving from first principles' is that any such explicit
design decision should be stated in terms of well defined precursors.
|
I think that many people would find that definition surprising. It's
one thing to say that a proposition can be formulated in terms of
previously defined terms. It's quite another to say that the
proposition *derives* from those terms.
| Quote: | the "first principles" involved are the formal definition of
"rvalue", "initialize a reference", "non-const type", etc.
|
Those are the terms used, but their formal definitions in no way
*imply* the rule in question.
It sounds like you are primarily interested in a sequence of exposition
that might make the language -- or at least the terminology used to
define the language -- easier to understand. Which seems like a
perfectly legitimate thing to be interested in. But it's quite
different from derivation.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|