Topic: [C++0x] Qualifiers, more qualifiers, aspects and annotations, oh my!


Author: skaller@nospam.com.au ("John Max Skaller")
Date: Tue, 16 Nov 2004 19:54:44 GMT
Raw View
On Mon, 25 Oct 2004 18:21:55 +0000, Davide Bolcioni wrote:

> Greetings,
> reading recent papers for the core language, such as n1706, n1703 and
> n1696, a thought occurred to me: all introduce declarative meta
> information about the relevant entities. In the Java camp, the
> syntactic concept of "annotations" has been introduced which seems to
> subsume all of the above nicely, and I was wondering if it could be
> borrowed somehow to provide an unified syntactic approach which frees
> C++ from the "cannot define appropriate keyword" syndrome, but also
> from a deluge of keywords and qualifiers (which to some extent already
> occurs in Java).

I think this is unlikely. I will try to explain why.

I have been dealing with this problem
myself recently in respect of my own language, where, as the
implementor and designer, I have plenty of freedom to actually
try out ideas.

Unfortunately, whilst annotations seem to be almost categorizable,
the useful ones seem to be all slightly different. A simple
and familiar example comes from two existing C++ annotations
which are already in the same syntactic category: 'const'
and 'volatile'. They're part of the type system and behave quite
symmetrically syntactically .. but the semantics aren't quite
symmetric. If you try to add 'restrict' and some other qualifiers
the lack of semantic symmetry soon destroys the utility of the
syntactic categorisation. This is evident in templates .. :)

Another example, again from the type system, is * and &.
Well 'pointer' and 'reference' are almost symmetric
annotations .. but not quite. For example most of the
conversion rules are the same  .. but pointers are deep,
whereas references are not. Again, this is evident in templates..

The real problem with a regular, user defined annotation kind,
is how to define them.

It may seem you can do this for simple cases. For example
for properties of binary operators, we all know
'symmetric' and 'reflexive' and 'transitive'. And with
some logic you can take these as primitives and define
'irreflexive' and 'transitive closure' and some other
terms .. and expect the compiler to understand your
definitions.

Unfortunately significant properties exist, but before
you can define them you need both a formal and conceptual
framework, and worse .. an algorithm for processing
specifications to build into the compiler.

There are some known frameworks with sufficient generality
to be useful, such as category theory, logic, set theory,
etc. However, almost all these systems require quantifiers
to make specifications, and hardly anything is known about
how to calculate with quantifiers. The best available systems
for formal reasoning require an immense amount of tuning
by the programmer to get a result.

So I think we're stuck between a rock and a hard place:
simple annotations are useful, but they can be introduced
directly into standards and implemented by the compiler
writer. Boosting that to the a meta-level to allow the user
to do it, however, more or less requires writing a complete
theorem prover .. they exist, but you need to be a guru
in the area to use one.

The only languages that can do this kind of thing successfully
are languages like Scheme and Forth, which are specified
to be extensible. Even so, writing extensions is not all
that easy, if you go beyond things that are directly supported.

In C++, you can define your own variables and your own
types, and that's about the end of it: templates do allow
you to define sets of types and functions all at once,
but they don't add anything fundamental in terms of
extensibility.

If you use GNU C, you have a regular annotation mechanism
for spelling attributes .. but you still can't define your own.
The bottom line, I think, is that you have to define a language
from the ground up to support any kind of extensibility,
and in C++ that support is only there for variables and types.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: francis@robinton.demon.co.uk (Francis Glassborow)
Date: Tue, 26 Oct 2004 04:00:22 GMT
Raw View
In article <ntvp42-fa2.ln1@interbusiness.it>, Davide Bolcioni
<f5xz2bk02@sneakemail.com> writes
>Greetings,
>reading recent papers for the core language, such as n1706, n1703 and
>n1696, a thought occurred to me: all introduce declarative meta
>information about the relevant entities. In the Java camp, the
>syntactic concept of "annotations" has been introduced which seems to
>subsume all of the above nicely, and I was wondering if it could be
>borrowed somehow to provide an unified syntactic approach which frees
>C++ from the "cannot define appropriate keyword" syndrome, but also
>from a deluge of keywords and qualifiers (which to some extent already
>occurs in Java).

Thank you for your thoughts. As an author of one of the papers I value
suggestions as to where we might look for prior art and ideas about
syntax. I and the authors of the other papers will be doing more work on
the proposals during the next few months. However one item we do have to
address is the use of function pointers. These do not exist in Java but
in C++ they not only exist but so does passing functions by reference. I
think that means that we need to come up with very different solutions
to those of Java. However we would certainly appreciate any pointers to
prior art.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]