Francis Glassborow ha scritto:
> 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.

Assuming a not yet well defined notion of "annotation" which behaves more
or less as described in the original posting and obeys standard class
inheritance, suppose we had the following hierarchy of annotations

   namespace std {
     class [annotation] no_qualifier;
     class [annotation] function_qualifier: public no_qualifier;
     ...
     class [annotation] nothrow: public function_qualifier;
     class [annotation] pure: public function_qualifier;
   }

All of the above would be "intrinsic" annotations, e.g. the compiler
knows that 'nothrow' is about exceptions and that 'function_qualifier'
applies to function calls.

The rule might look like this: if the type of the calling function has
an annotation Q derived from std::function_qualifier, calling a function
whose type has not the Q annotation, or an annotation derived from Q, is
an error and requires a diagnostic. This makes std::function_qualifier
an annotation for the type of annotated objects, functions in this
example; I guess not all annotations would similarly affect types.

Why user definable annotations ? Consider multithreading: if we had
an application with different thread *types* e.g. an input thread, a
watchdog thread and unspecified worker threads, we could define

   namespace threaded_app {
     using std::annotation,
           std::function_qualifier,
           std::instance_qualifier; // see below

     class [annotation] thread_guard: function_qualifier,

                                      accessible_qualifier;
     class [annotation] input_thread: thread_guard ;
     class [annotation] watchdog_thread: thread_guard;

     explicit [input_thread] int input_state;
     explicit [input_thread, watchdog_thread] int shared_state;

     explicit [input_thread] void input_thread_function();
     explicit [watchdog_thread] void watchdog_thread_function();
   }

Now, the rule (just made on the spot) says that if an instance is
annotated with Q derived from std::accessible_qualifier (it would
be an annotation affecting all instances of a type if applied to a
type, affecting single instance if applied to instances) then if it
is accessed by a function not annotated with Q or a descendant of
Q an error is reported. So, the function implementing the watchdog
thread cannot directly or indirectly access "input_state", except
possibly by circumventing the compiler.

In a sense, it might be possible to look at C++ annotations as if they
were mixin classes with the following properties:
- a subset, easily extended over revisions of the standard unlike
   keywords in the core language, would be known and acted upon by
   the compiler;
- applicable to non-class types, unlike mixins;
- reusing notions familiar to C++ programmers, such as inheritance;
- not impacting the size of instances (better: defined to avoid
   impacting the size of instances unless explicitly requested by
   the programmer, which might happen with Aspect Oriented stuff).

Just my $0.02

Davide Bolcioni
--
There is no place like /home.

---
[ 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                       ]

Francis Glassborow wrote:
> 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.
>

I haven't completely understood the proposal, but at a first sight it
seems to me that annotations vaguely resembles the way /stereotypes/ are
used in UML. That's a very clever and powerful way of extending a
language and I believe it's worth looking into it.

Alberto

---
[ 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                       ]