ANN: Ada source code decorator

ANN: Ada source code decorator

[Georg Bauhaus]

ASnip reads snippets of Ada source text, correct or incorrect, and
produces output suitable for printing, viewing, or including in web
pages (also in the Ada WiKiBook).

   * HTML     - use your own style sheets, or the ones provided
   * Text     - for regression testing, really
   * TeX      - via Knuth's WEB macros (Try lgrind with LaTeX)
   * WiKiBook - adds markup used for the Ada Wikibook,
                automatically links tokens to the Ada reference
  (* RTF      - time permitting)
  (* XML      - time permitting, using Simon Wright's ASIS based GIs.)

http://home.arcor.de/bauhaus/Tools/ASnip/

Enjoy,
 Georg

Re: ANN: Ada source code decorator

[Simon Wright]

Georg Bauhaus <bauhaus@futureapps.de> writes:

>   (* XML      - time permitting, using Simon Wright's ASIS based GIs.)

Although that work was useful, a lot more needs to be done on it to
make it anywhere near complete. It would be a lot easier if ASIS (the
standard) was open-source.

If there is to be an ASIS 2005 I hope the representation will be as an
XML schema and not an API; the API makes using ASIS so very clumsy
compared to the various XML processing technologies available
now. Well, that's the way it seems from here!

Re: ANN: Ada source code decorator

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Georg Bauhaus <bauhaus@futureapps.de> writes:
>
>>   (* XML      - time permitting, using Simon Wright's ASIS based GIs.)
>
> Although that work was useful, a lot more needs to be done on it to
> make it anywhere near complete. It would be a lot easier if ASIS (the
> standard) was open-source.

The ASIS _standard_ is open-source; it consists of Ada specs giving the API.

The GNAT implementation is also open-source.

So what is missing?

> If there is to be an ASIS 2005 

There is; the ARG is starting work on it.

> I hope the representation will be as an XML schema and not an API;

I don't see how that is remotely possible. The whole point of ASIS is
to access the knowledge the compiler has about the source. Thus the
compiler has to provide functions to access that knowledge.

I can see building an XML processor in which some of the XML tags
cause ASIS API calls. But that is a layer on top of the ASIS API, not
a replacement for the ASIS API.

> the API makes using ASIS so very clumsy compared to the various XML
> processing technologies available now. Well, that's the way it seems
> from here!

Can you give a concrete example of how an ASIS-XML would work?

-- 
-- Stephe

Re: ANN: Ada source code decorator

[Jeffrey R. Carter]

Stephen Leake wrote:
> 
> I don't see how that is remotely possible. The whole point of ASIS is
> to access the knowledge the compiler has about the source. Thus the
> compiler has to provide functions to access that knowledge.

The point of ASIS is to provide a standard way to access information 
about the source that the compiler has saved. The format of this 
information is not specified. I suspect Wright is hoping an Ada-0X 
version of ASIS will specify the format, using XML.

-- 
Jeff Carter
"Sons of a silly person."
Monty Python & the Holy Grail
02

Re: ANN: Ada source code decorator

[Georg Bauhaus]

Jeffrey R. Carter wrote:
> Stephen Leake wrote:
>>
>> I don't see how that is remotely possible. The whole point of ASIS is
>> to access the knowledge the compiler has about the source. Thus the
>> compiler has to provide functions to access that knowledge.

The compiler could provide a representation of its knowledge of the
source that uses XML. For example, internal trees (or graphs), where
the nodes carry information not only about names, etc, but also
about representations. Trees, or groves, are an ideal candidate for
XML based representation because an XML document instance is a tree
or graph, and XML based tools are made for working on these.

In fact, ASIS and XML use almost the same wording, e.g. element
trees.

> The point of ASIS is to provide a standard way to access information 
> about the source that the compiler has saved. The format of this 
> information is not specified. I suspect Wright is hoping an Ada-0X 
> version of ASIS will specify the format, using XML.

If ASIS were to provide a set of XML element definitions,
these could be used to write transformations to and from XMI,
easing the use of Ada with some OOD tools.
Getting a sorted index of all tagged types in a program will then
be very easy with XML tools: just declare the corresponding XPath
choice and employ XSL's sort and key functions. Done.

Which leads me to a question: Is there a set of "ASIS items" that
you use frequently? Items that could be useful when represented
using XML, even when the Ada information contained therein is limited?


-- Georg 

Re: ANN: Ada source code decorator

[Stephen Leake]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> Stephen Leake wrote:
>> I don't see how that is remotely possible. The whole point of ASIS is
>> to access the knowledge the compiler has about the source. Thus the
>> compiler has to provide functions to access that knowledge.
>
> The point of ASIS is to provide a standard way to access information
> about the source that the compiler has saved. The format of this
> information is not specified. I suspect Wright is hoping an Ada-0X
> version of ASIS will specify the format, using XML.

Ok, now I see; that does make sense.

I don't think that will happen as part of the ASIS 05 effort; there
are not many people working on it, and they don't see that as their
mission. They are working on extending the ASIS 95 API to cover the
new Ada 2005 features, and possibly fixing any problems with the
current API.

I believe the original decision to specify an API, rather than a
format, was to allow each compiler vendor to use a format that was
similar to their already-existing internal compiler structures, thus
making it easier for each compiler vendor to support ASIS. I suspect
that argument still holds. But it might be reasonable to add an
optional standard XML format.

If enough people want it to happen, they should get together and
produce a working example of such a standard format, then lobby to get
it approved as a secondary standard.

Note that vendors will only support such a format if they see money in
it. So people who want it must be able to say they will pay a
reasonable fee for it, and that there are still others who will also
pay such a fee. Or they need to fund the entire development themselves.


I have not used XML processors, so I can't comment on whether they are
"less clunky" than using the ASIS API. But I can see that having a
standard XML representation of the Ada source would make it easier for
people who are familiar with XML to build useful tools. And since
there are certainly more people familiar with XML than with ASIS, that
would be a good thing for Ada.

-- 
-- Stephe

Re: ANN: Ada source code decorator

[Manuel Collado]

Stephen Leake escribi�:
> "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:
> 
>> Stephen Leake wrote:
>>> I don't see how that is remotely possible. The whole point of ASIS is
>>> to access the knowledge the compiler has about the source. Thus the
>>> compiler has to provide functions to access that knowledge.
>> The point of ASIS is to provide a standard way to access information
>> about the source that the compiler has saved. The format of this
>> information is not specified. I suspect Wright is hoping an Ada-0X
>> version of ASIS will specify the format, using XML.
> 
> Ok, now I see; that does make sense.
> ...
> I have not used XML processors, so I can't comment on whether they are
> "less clunky" than using the ASIS API. But I can see that having a
> standard XML representation of the Ada source would make it easier for
> people who are familiar with XML to build useful tools. And since
> there are certainly more people familiar with XML than with ASIS, that
> would be a good thing for Ada.

That's my case. I would love an ASIS export utility that provides the full 
ASIS-accesible information about a single compilation unit as a single XML 
document.

-- 
Manuel Collado

Re: ANN: Ada source code decorator

[Martin Krischik]

Manuel Collado wrote:

> That's my case. I would love an ASIS export utility that provides the full
> ASIS-accesible information about a single compilation unit as a single XML
> document.

And I would like that format to be XMI [1]. What good woul be any XML
format when there are tools which can read it.

Martin

[1] http://en.wikipedia.org/wiki/XMI

Re: ANN: Ada source code decorator

[Georg Bauhaus]

On Thu, 2006-05-25 at 22:54 -0700, Martin Krischik wrote:
> Manuel Collado wrote:
> 
> > That's my case. I would love an ASIS export utility that provides the full
> > ASIS-accesible information about a single compilation unit as a single XML
> > document.
> 
> And I would like that format to be XMI [1]. What good woul be any XML
> format when there are tools which can read it.

An XML format modeled around Ada information, not XMI, would be
good because XSL transformations can transform them into XMI,
and vice versa.

If ASIS definitions can only refer to ISO standard languages, then this
transformation could use DSSSL, the ISO precursor to XSL.

Re: ANN: Ada source code decorator

[Simon Wright]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> Manuel Collado wrote:
>
>> That's my case. I would love an ASIS export utility that provides
>> the full ASIS-accesible information about a single compilation unit
>> as a single XML document.
>
> And I would like that format to be XMI [1]. What good woul be any
> XML format when there are tools which can read it.
>
> Martin
>
> [1] http://en.wikipedia.org/wiki/XMI

I'm not at all sure that XMI is capable of representing _all_ of an
Ada program without extensions. And you would certainly have to make
some mapping decisions.

In the reverse direction, given a UML model, are you going to map a
Class to a package? to a tagged type? Either would be valid ... (and
would have its own difficulties).

Re: ANN: Ada source code decorator

[Martin Krischik]

Simon Wright wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> writes:
> 
>> Manuel Collado wrote:
>>
>>> That's my case. I would love an ASIS export utility that provides
>>> the full ASIS-accesible information about a single compilation unit
>>> as a single XML document.
>>
>> And I would like that format to be XMI [1]. What good woul be any
>> XML format when there are tools which can read it.
>>
>> Martin
>>
>> [1] http://en.wikipedia.org/wiki/XMI
> 
> I'm not at all sure that XMI is capable of representing _all_ of an
> Ada program without extensions. And you would certainly have to make
> some mapping decisions.
> 
> In the reverse direction, given a UML model, are you going to map a
> Class to a package? to a tagged type? Either would be valid ... (and
> would have its own difficulties).

UML has both Classes and Packages. If I was to make an UML <-> Ada mapping
then packages are mapped to Packages and type/subtype is mapped to Classes.

Unadorned Classes would become tagged types while adorned Classes could
become any other Ada type. Like (use an unproportional font for what
follows):

   +-------------------+
   | <<range>> Integer |
   +-------------------+
            ^
            |
            | <<subtype>>
            |
+-------------------------+
| <<range>> Day           |
+-------------------------+
| First : Integer := 1    |
| Last  : Integer := 31   |
+-------------------------+

Would become:

subtype Day is Integer range 1 .. 31;

and 

+---------------+
| <<range>> Day |
+---------------+
| First := 1    |
| Last  := 31   |
| Size  := 8    |
+---------------+

Would become:

type Day is new range 1 .. 31;
For Day'Size use 8;

I think that this a full natural way of mapping Ada <-> UML - After all
'First and 'Last are called Attributes on both sides. And if you continue
the way of stereotypes then you can map all Ada feature to UML.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: ANN: Ada source code decorator

[Georg Bauhaus]

Martin Krischik wrote:

> I think that this a full natural way of mapping Ada <-> UML - After all
> 'First and 'Last are called Attributes on both sides. And if you continue
> the way of stereotypes then you can map all Ada feature to UML.

Is there a way to represent an access to a nested function?


Georg 

Re: ANN: Ada source code decorator

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik wrote:
> 
>> I think that this a full natural way of mapping Ada <-> UML - After all
>> 'First and 'Last are called Attributes on both sides. And if you continue
>> the way of stereotypes then you can map all Ada feature to UML.
> 
> Is there a way to represent an access to a nested function?

You probably need two representations.

1) Often overlooked is UML support for free functions and procedures. The
only place I saw them actually used it the Rational Ada <-> Rational Rose
mapping.

2) You would need a Class of  stereotype <<access>> and the procedure as
target type.

But then I don't know any UML tool that handles functions or procedure
pointer natively.

Having said that: You did reveal the real weakness for UML: UML is mostly
about the interfaces and not internals.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: ANN: Ada source code decorator

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> I think that this a full natural way of mapping Ada <-> UML - After
> all 'First and 'Last are called Attributes on both sides. And if you
> continue the way of stereotypes then you can map all Ada feature to
> UML.

Hmm, yes -- I see your point, though it's certainly not the route I
took with http://coldframe.sf.net/. The difference is because I was
coming from a Shlaer/Mellor OOA viewpoint, and also I'd much rather
have a model that accurately reflects the problem domain
(platform-independent model, PIM) and that tools can translate into
code (possibly via a platform-specific model, PSM).

I certainly haven't achieved that with ColdFrame, which is a framework
generator, and has a lot of vaguely Ada-like stereotypes to support
code generation; for example, <<atomic>>. Well, really that could have
a meaning in a translator to C, but it's hardly part of the
application's subject matter[1], and doesn't make it any easier to
discuss with a client whether you are solving the right problem!

So I'm uncomfortable with the idea of having many stereotypes to allow
you to specify every detail of Ada in a model. Why not just write the
Ada? The model needs to be an abstraction. People may remember Raymond
Buhr's book "System design with Ada", which had a diagrammatic
convention for every aspect of Ada 83 and which I can't imagine helped
anyone develop real software.

XMI which could accurately reflect full Ada would have to be extended;
I know UML can be extended using profiles (ie, stereotypes, tagged
values and the associated semantics), one would suppose that XMI
reflects this.

[1] Of course, if you _have_ to say <<atomic>> it's possible that the
subject matter in hand may be one where it _is_ appropriate to discuss
this sort of thing. It seems to tend to the 'implementation detail',
though.

Re: ANN: Ada source code decorator

[Martin Dowie]

Simon Wright wrote:
> In the reverse direction, given a UML model, are you going to map a
> Class to a package? to a tagged type? Either would be valid ... (and
> would have its own difficulties).

I've never understood this view point - a UML class is (to me) clearly 
an Ada publicly tagged type. If you are using UML classes you are 
explicitly "OO".

If you don't want OO then you can always add functions/procedures to 
packages (or at least you can in some UML tools ;-).

Cheers
-- Martin

Re: ANN: Ada source code decorator

[Simon Wright]

Stephen Leake <stephen_leake@acm.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>>
>>>   (* XML      - time permitting, using Simon Wright's ASIS based GIs.)
>>
>> Although that work was useful, a lot more needs to be done on it to
>> make it anywhere near complete. It would be a lot easier if ASIS
>> (the standard) was open-source.
>
> The ASIS _standard_ is open-source; it consists of Ada specs giving
> the API.
>
> The GNAT implementation is also open-source.
>
> So what is missing?

Something to make it clear what the actual structure is. I found it
very hard indeed to understand what the API was trying to tell me; for
example, a qualified name a.b.c is stored in something like

  (a (b (c)))

which you can understand a compiler using, rather than

  <name>
      <component>a</component>
      <component>b</component>
      <component>c</component>
   </name>

and asis2xml would _definitely_ produce the latter (I forget whether
it actually does at this stage).

Re: ANN: Ada source code decorator

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@acm.org> writes:
>
>> Simon Wright <simon@pushface.org> writes:
>>
>>> Georg Bauhaus <bauhaus@futureapps.de> writes:
>>>
>>>>   (* XML      - time permitting, using Simon Wright's ASIS based GIs.)
>>>
>>> Although that work was useful, a lot more needs to be done on it to
>>> make it anywhere near complete. It would be a lot easier if ASIS
>>> (the standard) was open-source.
>>
>> The ASIS _standard_ is open-source; it consists of Ada specs giving
>> the API.
>>
>> The GNAT implementation is also open-source.
>>
>> So what is missing?
>
> Something to make it clear what the actual structure is. I found it
> very hard indeed to understand what the API was trying to tell me; 

Perhaps there needs to be more user-friendly documentation of the ASIS
structure. 

> for example, a qualified name a.b.c is stored in something like
>
>   (a (b (c)))
>
> which you can understand a compiler using, 

Well, yes; ASIS is designed to represent the information a compiler
knows. So it helps to be able to think like a compiler :).

> rather than
>
>   <name>
>       <component>a</component>
>       <component>b</component>
>       <component>c</component>
>    </name>

Well, this has nothing to do with being "open source".

You are arguing that the particular structure defined in the ASIS spec
is not one you would use for your particular application. 

That is certainly your choice. Everyone else will also have a
particular choice; probably different. I suspect the choice of
structure depends heavily on the algorithm you want to implement.

So it will be very difficult to get agreement on a _standard_ XML
representation of Ada source code. But it's probably worth trying. 

> and asis2xml would _definitely_ produce the latter (I forget whether
> it actually does at this stage).

http://www.pushface.org/asis2xml/ says the structure output by
asis2xml follows that of ASIS, so I'd be surprised if it did what you
describe above. 

I would argue that an XML structure that is as close as possible to
the ASIS structure would be the best one to standardize.

When you (Simon Wright), as the author of asis2xml, decided to change
the representation of a qualified name as above, what criteria were
you using to determine the "right" structure?

How would that transformation handle expressions like

    Array_1 (i).Function_Pointer_2 (x, y, z).Component

?

When using ASIS to implement a non-trivial source processing
algorithm, the first step is to transform the ASIS-defined structure
into one that is better for your algorithm; that's what auto_text_io
does (my ASIS tool). Even if you start from an ASIS-equivalent XML
representation, that will still be true.

-- 
-- Stephe

Re: ANN: Ada source code decorator

[Simon Wright]

Stephen Leake <stephen_leake@acm.org> writes:

> Simon Wright <simon@pushface.org> writes:
>
>> Stephen Leake <stephen_leake@acm.org> writes:

>>> The ASIS _standard_ is open-source; it consists of Ada specs giving
>>> the API.
>>>
>>> The GNAT implementation is also open-source.
>>>
>>> So what is missing?
>>
>> Something to make it clear what the actual structure is. I found it
>> very hard indeed to understand what the API was trying to tell me; 
>
> Perhaps there needs to be more user-friendly documentation of the ASIS
> structure. 

Yes. You have to understand what an API is _about_.

>> for example, a qualified name a.b.c is stored in something like
>>
>>   (a (b (c)))
>>
>> which you can understand a compiler using, 
>
> Well, yes; ASIS is designed to represent the information a compiler
> knows. So it helps to be able to think like a compiler :).
>
>> rather than
>>
>>   <name>
>>       <component>a</component>
>>       <component>b</component>
>>       <component>c</component>
>>    </name>
>
> Well, this has nothing to do with being "open source".
>
> You are arguing that the particular structure defined in the ASIS spec
> is not one you would use for your particular application. 
>
> That is certainly your choice. Everyone else will also have a
> particular choice; probably different. I suspect the choice of
> structure depends heavily on the algorithm you want to implement.

It would be completely unnatural in XML to represent the concept of a
name with components as a nested structure. For a start, the XPath
expressions involved will be unmanageable.

> So it will be very difficult to get agreement on a _standard_ XML
> representation of Ada source code. But it's probably worth trying. 

Indeed.

>> and asis2xml would _definitely_ produce the latter (I forget
>> whether it actually does at this stage).
>
> http://www.pushface.org/asis2xml/ says the structure output by
> asis2xml follows that of ASIS, so I'd be surprised if it did what you
> describe above. 

Well, it does what seemed like a good idea at the time :-) -- ie, what
worked.

> I would argue that an XML structure that is as close as possible to
> the ASIS structure would be the best one to standardize.
>
> When you (Simon Wright), as the author of asis2xml, decided to change
> the representation of a qualified name as above, what criteria were
> you using to determine the "right" structure?
>
> How would that transformation handle expressions like
>
>     Array_1 (i).Function_Pointer_2 (x, y, z).Component

It would probably be fairly close. But the argument list would be
mapped to an XML sequence, I'm sure.

> When using ASIS to implement a non-trivial source processing
> algorithm, the first step is to transform the ASIS-defined structure
> into one that is better for your algorithm; that's what auto_text_io
> does (my ASIS tool). Even if you start from an ASIS-equivalent XML
> representation, that will still be true.

Yes.

For info, the output from

   generic
   package Basis is
      type Base is abstract tagged private;
      procedure Op (B : Base) is abstract;
   private
      type Base is abstract tagged record
         V : Boolean;
      end record;
   end Basis;

was

   <asis>
   <generic_package_declaration>
   <defining_identifier>Basis</defining_identifier>
   <private_type_declaration kind="abstract_private_trait">
   <defining_identifier>Base</defining_identifier>
   <tagged_private_type_definition kind="abstract_private_trait">
   </tagged_private_type_definition>
   </private_type_declaration>
   <procedure_declaration kind="abstract_trait">
   <defining_identifier>Op</defining_identifier>
   <parameter_specification kind="ordinary_trait"
   mode="default_in_mode">
   <defining_identifier>B</defining_identifier>
   <identifier>Base</identifier>
   </parameter_specification>
   </procedure_declaration>
   <ordinary_type_declaration>
   <defining_identifier>Base</defining_identifier>
   <type_definition>
   <tagged_record_type_definition kind="abstract_trait">
   </tagged_record_type_definition>
   <record_definition>
   <component_declaration>
   <defining_identifier>V</defining_identifier>
   <component_definition kind="ordinary_trait" size="8">
   <subtype_indication>
   <identifier>Boolean</identifier>
   </subtype_indication>
   </component_definition>
   </component_declaration>
   </record_definition>
   </type_definition>
   </ordinary_type_declaration>
   </generic_package_declaration>
   </asis>

which probably makes more sense to you than to me. I can get some of
it, of course, but -- for example -- what other sorts of traits are
there and what do they actually mean?

Re: ANN: Ada source code decorator

[Stephen Leake]

Simon Wright <simon@pushface.org> writes:

> Stephen Leake <stephen_leake@acm.org> writes:
>
>> Simon Wright <simon@pushface.org> writes:
>>
>>> Stephen Leake <stephen_leake@acm.org> writes:
>
>> You are arguing that the particular structure defined in the ASIS spec
>> is not one you would use for your particular application. 
>>
>> That is certainly your choice. Everyone else will also have a
>> particular choice; probably different. I suspect the choice of
>> structure depends heavily on the algorithm you want to implement.
>
> It would be completely unnatural in XML to represent the concept of a
> name with components as a nested structure. For a start, the XPath
> expressions involved will be unmanageable.

Hmm. Taken purely at face value, that tells me that XML is not a
suitable representation for Ada :).

But if there are a few standard transformations from the ASIS
structure to the XML structure, that would be ok.

> For info, the output from
>
>    generic
>    package Basis is
>       type Base is abstract tagged private;
>       procedure Op (B : Base) is abstract;
>    private
>       type Base is abstract tagged record
>          V : Boolean;
>       end record;
>    end Basis;
>
> was
>
>    <asis>
>    <generic_package_declaration>
>    <defining_identifier>Basis</defining_identifier>
>    <private_type_declaration kind="abstract_private_trait">
>    <defining_identifier>Base</defining_identifier>
>    <tagged_private_type_definition kind="abstract_private_trait">
>    </tagged_private_type_definition>
>    </private_type_declaration>
>    <procedure_declaration kind="abstract_trait">
>    <defining_identifier>Op</defining_identifier>
>    <parameter_specification kind="ordinary_trait"
>    mode="default_in_mode">
>    <defining_identifier>B</defining_identifier>
>    <identifier>Base</identifier>
>    </parameter_specification>
>    </procedure_declaration>
>    <ordinary_type_declaration>
>    <defining_identifier>Base</defining_identifier>
>    <type_definition>
>    <tagged_record_type_definition kind="abstract_trait">
>    </tagged_record_type_definition>
>    <record_definition>
>    <component_declaration>
>    <defining_identifier>V</defining_identifier>
>    <component_definition kind="ordinary_trait" size="8">
>    <subtype_indication>
>    <identifier>Boolean</identifier>
>    </subtype_indication>
>    </component_definition>
>    </component_declaration>
>    </record_definition>
>    </type_definition>
>    </ordinary_type_declaration>
>    </generic_package_declaration>
>    </asis>
>
> which probably makes more sense to you than to me. 

There seems to be a lot missing. Remember that I have never used XML
in an application, but my impression was that it's supposed to be a
self-documenting format. So, for example, I would expect the various
identifiers to be labeled more specifically; "variable_identifier",
"type_identifier". Or have names that match the ASIS query that
returned them.

I guess if there was an XML grammar to go along with this, that would
specify that information.

> I can get some of it, of course, but -- for example -- what other
> sorts of traits are there and what do they actually mean?

That does require a better ASIS manual.

This looks like a good start on an XML tool for Ada; I'll keep it in
mind if I ever start using XML :).

-- 
-- Stephe

Re: ANN: Ada source code decorator

[Simon Wright]

Stephen Leake <stephen_leake@acm.org> writes:

> There seems to be a lot missing. Remember that I have never used XML
> in an application, but my impression was that it's supposed to be a
> self-documenting format.

About as much as Ada is ..

>                          So, for example, I would expect the various
> identifiers to be labeled more specifically; "variable_identifier",
> "type_identifier". Or have names that match the ASIS query that
> returned them.

The scheme I adopted was to use the ASIS enumeration names as far as
possible: a snippet of the code is

      case Asis.Elements.Element_Kind (Element) is

         when A_Defining_Name =>           -- Asis.Declarations
            State.Current :=
            DOM.Core.Nodes.Append_Child
            (State.Current,
             DOM.Core.Documents.Create_Element
               (State.Document,
                To_Tag_Name
                       (Defining_Name_Kinds'Image
                          (Asis.Elements.Defining_Name_Kind (Element)))));
            Tmp :=
              DOM.Core.Nodes.Append_Child
              (State.Current,
               DOM.Core.Documents.Create_Text_Node
                 (State.Document,
                  +Asis.Declarations.Defining_Name_Image (Element)));

where To_Tag_Name strips a leading A_ or An_. So if -- for example, I
don't know if this is exactly right -- my output contained
<defining_identifier>Basis</defining_identifier> that would be because
I got an element of Element_Kind = A_Defining_Name with
Defining_Name_Kind = A_Defining_Identifier. Perhaps I should have said
eg

  <defining_name.defining_identifier>?

or, probably better,

  <defining_name kind="defining_identifier">?