Re: new revision ada (exception handling)

Re: new revision ada (exception handling)

[Christoph Karl Walter Grein]

> like the definition of Enumeration_IO.Get assumes that name ends can be
> recognized prior knowing names, though A.10.10(9) does not read it
> explicitly. Considering an enumeration type with images Red and Red1. Would
> it be legal according to A.10.10(9) to read Red; and then raise Data_Error?

If you read the chapter on inputting enumeration literals very carefully, you'll find that you have
 to read a sequence of input characters as long as the sequence is a legal sequence for Ada
identifiers. Only after reading characters has ended, you make a check whether this sequence is a
defined literal.

It is irrelevant how long the expected literals are.

So for instance when reading booleans, "trueanything.x" has to be read until the dot, leaving the dot
 and the x in the input stream. Then you compare trueanything to true and raise Data_Error.
__________________________________________________________________
Zeigen Sie Emotionen mit der WEB.DE Bild-SMS! Das Bild ist gratis,
Sie bezahlen nur den Versand. http://freemail.web.de/?mc=021196

Typing in Ada

[Empit]

From typing point of view, how strong is Ada than C?

or

Which is the most strongly typed language.

Responses appreciated

Re: Typing in Ada

[Peter C. Chapin]

Jeffrey Carter <spam@spam.com> wrote in news:mxJuc.18113$be.10152
@newsread2.news.pas.earthlink.net:

> procedure Strongly_Typed is
>     type I1 is new Integer;
>     type I2 is new Integer;
>     type I3 is range -100 .. 100;
[snip]
> 
> int main () { /* I cannot call this Strongly_Typed */
>     typedef int   I1;
>     typedef int   I2;
>     typedef short I3;

This isn't an entirely fair comparison because in C, typedef doesn't 
introduce a new type it simply creates a new name for an existing type. In 
Ada, it would be more similar to using a subtype, perhaps. Something like

     subtype I1 is Integer;

In any event to create a new type in C you need to introduce a structure. In 
fact, different structures do have different types:

typedef struct {
  int x;
} A;

typedef struct {
  int x;
} B;

int main()
{
  A a;
  B b;

  a = b;  // Error. A and B are different types.

  ...

I'm not sure if there is a formal definition of strong typing or not. I've 
always thought that it had to do with the property of every expression and 
variable having a well defined type. If so, that is as true of C as it is of 
Ada (in some ways its even more true of C because in C literal numbers have 
specific types... there is no "universal integer" type used, for example, for 
integer literals). The real difference is that C does a bunch of automatic 
type conversions and, furthermore, normally performs these conversions 
without checking if the converted value will fit into the target type. I'm 
not sure that's a strong typing issue, however.

Peter

Re: Typing in Ada

[Jeffrey Carter]

Peter C. Chapin wrote:

> This isn't an entirely fair comparison because in C, typedef doesn't 
> introduce a new type it simply creates a new name for an existing type. In 
> Ada, it would be more similar to using a subtype, perhaps. Something like

The number of ways in which a language allows errors to be detected at 
compilation time because of erroneous type mixing is the essence of 
strong typing. Ada is more strongly typed than Pascal because of its 
ability to define new numeric types (among other things). The ability to 
define new numeric types is a way that Ada allows the compiler to detect 
errors that C lacks. Thus, the example is a perfectly good example of 
Ada being more strongly typed than C, and a fair comparison of the 
strength of typing in the 2 languages.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31

Re: Typing in Ada

[Peter C. Chapin]

Jeffrey Carter <spam@spam.com> wrote in
news:Q4avc.18446$Tn6.11146@newsread1.news.pas.earthlink.net: 

>> This isn't an entirely fair comparison because in C, typedef doesn't 
>> introduce a new type it simply creates a new name for an existing type.
>> In Ada, it would be more similar to using a subtype, perhaps. Something
>> like 
> 
> The ability to 
> define new numeric types is a way that Ada allows the compiler to detect
> errors that C lacks. Thus, the example is a perfectly good example of 
> Ada being more strongly typed than C, and a fair comparison of the 
> strength of typing in the 2 languages.

I guess my point was that in C typedef does not even attempt to define a 
new type so comparing it to Ada's 'type' declaration seems unfair. For 
example if you replace the type declarations in the OP's example with 
unconstrained subtype declarations, the OP's Ada program compiles with no 
complaints just like the the example C program using typedef does.

Now in C there *is* a mechanism for creating new types... it's just that 
typedef isn't it. Thus it would be more appropriate to compare an Ada 
program that introduces a new type that is a numeric range to a C program 
that implements numeric ranges as structs. There is no doubt that the Ada 
way of creating ranged types is easier and cleaner than any kind of 
"equivalent" solution in plain C might be. On the other hand, I'm sure C++ 
could do a much better job of emulating the Ada solution by using 
templates and overloaded operators.

In any case, the OP's example didn't seem like a good example of how Ada 
is more strongly typed than C. It is certainly true that Ada does not do 
automatic type conversions the way C does, but the OP's example doesn't 
illustrate that point. In contrast, when I think about a weakly typed 
language I think about languages like AWK, the shell scripting languages, 
or perhaps Perl... where the type of a variable shifts around depending on 
how it is used. For example:

#!/bin/bash
COUNT=1
echo "COUNT is now $COUNT"   # Treat COUNT as a string
COUNT=$(($COUNT + 1))        # Treat COUNT as a number
echo "COUNT is now $COUNT"

Peter

Re: Typing in Ada

[Marin David Condic]

You may be right about structs, but making the argument that because C 
can introduce a new type that it is therefore a strongly typed language 
doesn't seem to follow. Ada won't let you assign a character to an 
integer. C will. While a typedef example may not be 100% equivalent to 
an Ada type, that doesn't cause C to be strongly typed - which was the 
original point.

I'd also observe that just because there is a secret handshake that will 
get C to complain about type compatibility doesn't mean much. Following 
that logic, an assembler program can be made to complain about type 
compatibility (at least at runtime) if you want to do enough work. The 
problem is that typedef doesn't do what one who is acustomed to Ada 
would think it should: "type" - "def" - Define a type.

MDC


Peter C. Chapin wrote:
> 
> I guess my point was that in C typedef does not even attempt to define a 
> new type so comparing it to Ada's 'type' declaration seems unfair. For 
> example if you replace the type declarations in the OP's example with 
> unconstrained subtype declarations, the OP's Ada program compiles with no 
> complaints just like the the example C program using typedef does.
> 
> Now in C there *is* a mechanism for creating new types... it's just that 
> typedef isn't it. Thus it would be more appropriate to compare an Ada 
> program that introduces a new type that is a numeric range to a C program 
> that implements numeric ranges as structs. There is no doubt that the Ada 
> way of creating ranged types is easier and cleaner than any kind of 
> "equivalent" solution in plain C might be. On the other hand, I'm sure C++ 
> could do a much better job of emulating the Ada solution by using 
> templates and overloaded operators.
> 
> In any case, the OP's example didn't seem like a good example of how Ada 
> is more strongly typed than C. It is certainly true that Ada does not do 
> automatic type conversions the way C does, but the OP's example doesn't 
> illustrate that point. In contrast, when I think about a weakly typed 
> language I think about languages like AWK, the shell scripting languages, 
> or perhaps Perl... where the type of a variable shifts around depending on 
> how it is used. For example:
> 
> #!/bin/bash
> COUNT=1
> echo "COUNT is now $COUNT"   # Treat COUNT as a string
> COUNT=$(($COUNT + 1))        # Treat COUNT as a number
> echo "COUNT is now $COUNT"
> 
> Peter


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: Typing in Ada

[Dave Thompson]

On Wed, 02 Jun 2004 11:38:04 GMT, Marin David Condic
<nobody@noplace.com> wrote:
<snip>
> I'd also observe that just because there is a secret handshake that will 
> get C to complain about type compatibility doesn't mean much. Following 
> that logic, an assembler program can be made to complain about type 
> compatibility (at least at runtime) if you want to do enough work. The 
> problem is that typedef doesn't do what one who is acustomed to Ada 
> would think it should: "type" - "def" - Define a type.
> 
One of the regulars on comp.lang.c, Chris Torek, likes to suggest that
the 'struct' keyword -- which unlike 'typedef' does create a distinct
type as far as the C compiler is concerned -- should be read as an
acronym "STRange spelling for User Constructed Type". :-)

- David.Thompson1 at worldnet.att.net

Re: Typing in Ada

[James Rogers]

Dave Thompson <david.thompson1@worldnet.att.net> wrote in
news:gn12d0pk7e6hhmhr6k87hcj4olebou5hel@4ax.com: 

> One of the regulars on comp.lang.c, Chris Torek, likes to suggest that
> the 'struct' keyword -- which unlike 'typedef' does create a distinct
> type as far as the C compiler is concerned -- should be read as an
> acronym "STRange spelling for User Constructed Type". :-)

Yes, a C struct is the means for creating a user defined type.
It is similar to an Ada record, without all the representation
control or the possibility of discriminants. 

One important difference between Ada records and C structs is
in the creation of incomplete types. A C compiler allows the
creation of incomplete types under the assumption that the
type will be completed through the linking process, while an
Ada compiler must have all types completed at compile time.

Jim Rogers

Re: Typing in Ada

[Hyman Rosen]

James Rogers wrote:
> One important difference between Ada records and C structs is
> in the creation of incomplete types. A C compiler allows the
> creation of incomplete types under the assumption that the
> type will be completed through the linking process, while an
> Ada compiler must have all types completed at compile time.

No, incomplete types in C have nothing to do with linking.
Incomplete types are there for the same reason as in any
other language, so that mutually recursive types may be
declared. Eg.,
     struct A;
     struct B { struct A *my_A; int x; };
     struct A { struct B *my_B; int y; };
For this mutual recursion to be possible, C and C++ must
then identify the places where incomplete types may be used,
such as in declarations of pointers to them, or as function
parameters - basically those places where knowing the innards
of the type is unnecessary.

It is true in C or C++ that if you never have a context in
which you need the complete type, you need not supply it,
even at link time.

Re: Typing in Ada

[James Rogers]

Hyman Rosen <hyrosen@mail.com> wrote in 
news:1087475285.166449@master.nyc.kbcfp.com:

> No, incomplete types in C have nothing to do with linking.
> Incomplete types are there for the same reason as in any
> other language, so that mutually recursive types may be
> declared. Eg.,
>      struct A;
>      struct B { struct A *my_A; int x; };
>      struct A { struct B *my_B; int y; };
> For this mutual recursion to be possible, C and C++ must
> then identify the places where incomplete types may be used,
> such as in declarations of pointers to them, or as function
> parameters - basically those places where knowing the innards
> of the type is unnecessary.
> 
> It is true in C or C++ that if you never have a context in
> which you need the complete type, you need not supply it,
> even at link time.

Perhaps I misspoke. I did not mean that C reserves incomplete
types for link time. I meant to say that the compiler does not
require completion of incomplete types. This effect allows a
C program to define an incomplete type in the global area of
one file and complete the type in another file. The compiler
never knows of the completion, while the linker might.

I agree that the most common use of incomplete types is the
same in C as in Ada; for recursive or self-referential types.
One common example is a singly linked list, where one of the
node data elements is a reference or pointer to the next node.

A common Ada implementation approach is:

package Single_List is
   type List is private
   procedure add(Item : in Item_Type; To : in out List);
   procedure get(Item : out Item_Type; From : in out List);
   function Is_Empty(The_List : List) return Boolean;
private
   type Node;
   type List is Access Node;
   Type Node is record
     Element : Item_Type;
     Next    : List := Null;
   end record;
end Single_List;

The Ada difference is that all incomplete types must be
completed in the same compilation unit.

Jim Rogers

Re: Typing in Ada

[Nick Roberts]

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns950BB3B4DBFE6jimmaureenrogers@204.127.36.1...

> ...
> The Ada difference is that all incomplete types must be
> completed in the same compilation unit.

In fact, this restriction is likely be lifted (in a very restricted way ;-)
in the new revision of the Ada language. It has proved to be too
inconvenient.

Whether implementations will join up the dots at (traditional) link time, or
at some pre-linking stage instead, is yet to be seen. I think the latter is
more likely.

-- 
Nick Roberts

Re: new revision ada

[Brian May]

>>>>> "Nick" == Nick Roberts <nick.roberts@acm.org> writes:

    Nick> In fact, this restriction is likely be lifted (in a very
    Nick> restricted way ;-) in the new revision of the Ada
    Nick> language. It has proved to be too inconvenient.

Are the details of this new revision of Ada published anywhere?

Personally I have very happy with Ada95 the way it is, the only
exception being exception handling which tends to look restrictive now
compared with, say Java exceptions (as functions declare what
exceptions they can raise, and can pass more information in the
exception instead of just a string).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: new revision ada

[Georg Bauhaus]

Brian May <bam@snoopy.apana.org.au> wrote:
: 
: Personally I have very happy with Ada95 the way it is, the only
: exception being exception handling which tends to look restrictive now
: compared with, say Java exceptions (as functions declare what
: exceptions they can raise, and can pass more information in the
: exception instead of just a string).

If you want to handle an exceptional situation with something
more "powerful" than an exception handler, then you might actually
be referring to a different notion of exception.
If it is more like backtracing, why not use a programming construct
that (I think) is closer in spirit to backtracing?  If the exception
is not what is traditionally called an exception but rather a special
program state that is special rather than exceptional in the Ada(?)
sense, an exception handler might be at the wrong level of
abstraction. Just the same name for two different things.

Ada has facilities to implement "trying-out programming". If one
(logical) thread of control fails, and it is important to
collect information about why it failed and in what program
state, than save the relevant pieces of the program state
using the executable statements of a local exception
handler for example.
You can store the information somewhere for lookup, and
use Ada's exceptions, or task communication, or plain
returned values to inform the caller of the failure or
success. The caller can use this information to retrieve
what has been stored for lookup.

Re: new revision ada

[James Rogers]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in 
news:cb927q$332$1@a1-hrz.uni-duisburg.de:

> Ada has facilities to implement "trying-out programming". If one
> (logical) thread of control fails, and it is important to
> collect information about why it failed and in what program
> state, than save the relevant pieces of the program state
> using the executable statements of a local exception
> handler for example.
> You can store the information somewhere for lookup, and
> use Ada's exceptions, or task communication, or plain
> returned values to inform the caller of the failure or
> success. The caller can use this information to retrieve
> what has been stored for lookup.

Your solution detaches the information from the notification.
This detachment causes problems, which are compounded by
concurrency. If two exceptions are raised in a program and
their state information is stored in some buffer such as
a protected object, how will a handler determine which state
belongs to which exception occurrence?

The state information must be directly associated with the
exception occurrence. In Java this is done be creating an
exception object. References to that object are passed
up through the call stack until the exception is handled.
I believe the same concept is used in C++ exceptions.

Ada has a somewhat different view of exceptions. All exceptions
are the same type, and are identified by name. Ada 95 added the
ability to define exception information in a limited length
string. That string is intimately associated with an exception
occurrence. I am proposing that we provide a second kind of
exception information using a variable-width string that
encodes data in XML. XML is capable of encoding any kind of
data including very complex data structures. This new form
of exception information will allow complex exception state
data to be reliably communicated with an exception 
occurrence.

Jim Rogers

Re: new revision ada

[Martin Krischik]

James Rogers wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in
> news:cb927q$332$1@a1-hrz.uni-duisburg.de:
> 
>> Ada has facilities to implement "trying-out programming". If one
>> (logical) thread of control fails, and it is important to
>> collect information about why it failed and in what program
>> state, than save the relevant pieces of the program state
>> using the executable statements of a local exception
>> handler for example.
>> You can store the information somewhere for lookup, and
>> use Ada's exceptions, or task communication, or plain
>> returned values to inform the caller of the failure or
>> success. The caller can use this information to retrieve
>> what has been stored for lookup.
> 
> Your solution detaches the information from the notification.
> This detachment causes problems, which are compounded by
> concurrency. If two exceptions are raised in a program and
> their state information is stored in some buffer such as
> a protected object, how will a handler determine which state
> belongs to which exception occurrence?

Store them in an booch component map indexed by thread id. I do that in
AdaCL.Trace.

> The state information must be directly associated with the
> exception occurrence. In Java this is done be creating an
> exception object. References to that object are passed
> up through the call stack until the exception is handled.

Posible only becase Java throws pointers only.

> I believe the same concept is used in C++ exceptions.

With the usual amount of pitfalls which acomplished every C++ feature - yes.

> Ada has a somewhat different view of exceptions. All exceptions
> are the same type, and are identified by name. Ada 95 added the
> ability to define exception information in a limited length
> string. That string is intimately associated with an exception
> occurrence. I am proposing that we provide a second kind of
> exception information using a variable-width string that
> encodes data in XML. XML is capable of encoding any kind of
> data including very complex data structures. This new form
> of exception information will allow complex exception state
> data to be reliably communicated with an exception
> occurrence.

Again: why XML when Ada has a perfectly usable system to stream out data.
i.E. 'Input and 'Output. Annex E is allready based on it so it could be
used for extended exceptions as well.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: new revision ada (exception handling)

[Nick Roberts]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1774424.VSnnNmZCKX@linux1.krischik.com...

> > Your solution detaches the information from the notification.
> > This detachment causes problems, which are compounded by
> > concurrency. If two exceptions are raised in a program and
> > their state information is stored in some buffer such as
> > a protected object, how will a handler determine which state
> > belongs to which exception occurrence?
>
> Store them in an booch component map indexed by thread id.
> I do that in AdaCL.Trace.

I am intrigued by this technique. It is of importance to me, since I am
currently thinking about how to implement exception handling according to
the current CORBA Ada binding.

There seem to be two problems with the solution you suggest:

(1) Nested exception occurrances. If an exception is raised and handled
within an exception handler, the parameters of the outer occurrance will be
overwritten by those of the inner one. A solution would be for every handler
(that uses parameters) to copy off the parameters before doing anything else
(that could raise and handle an exception). However, this solution causes
extra work, and is not neat; it seems bug-prone to me.

(2) Memory management. The memory used up by the parameters of an exception
will not be reclaimed at an appropriate time (for example, when there is no
longer any possibility of the associated exception being handled). This is
only a memory leakage problem, and may be considered of low significance,
but I don't like it.

In addition, the use of a map structure seems a bit heavyweight.

I'd appreciate your comments.

> Again: why XML when Ada has a perfectly usable system to
> stream out data. i.E. 'Input and 'Output. Annex E is already
> based on it so it could be used for extended exceptions as
> well.

I think a possible answer to this question is that XML is human-readable (or
at least it is pure text), whereas Ada streams are (essentially) binary. I
think the point of providing (only) string data for parametising exceptions
in Ada 95 was to ensure that those parameters could simply be
printed/displayed (by diagnostic software). XML encoded parameters could
also be simply printed out, as well as being interpreted and used by
knowledgeable software.

However, I would not personally advocate this approach. The use of XML seems
extremely heavyweight to me. I think a better idea would be to allow
parameters to be added to an exception occurrance in the machine's internal
format (possibly as a value of a type derived from an abstract root tagged
type), in addition to an appropriate human-readable message being added to
the occurrance's message. This way, diagnostic software can simply print the
message, and knowledgable software can interpret the parameters directly.
There would be no need for any endcoding or decoding software. Surely having
to add an XML generator and parser to a piece of (embedded) software just to
support exception handling would be overkill?

-- 
Nick Roberts

Re: new revision ada (exception handling)

[Pascal Obry]

"Nick Roberts" <nick.roberts@acm.org> writes:

> I think a possible answer to this question is that XML is human-readable (or
> at least it is pure text), whereas Ada streams are (essentially) binary. I
> think the point of providing (only) string data for parametising exceptions
> in Ada 95 was to ensure that those parameters could simply be
> printed/displayed (by diagnostic software). XML encoded parameters could
> also be simply printed out, as well as being interpreted and used by
> knowledgeable software.

There is mixed issues here. The stream does not need to be human readable as
the information is passed between partition, this is really a computer issue
and the most compact representation is better. Now to display the exception
information I agree that we need to kind of human representation.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: new revision ada (exception handling)

[Martin Krischik]

Pascal Obry wrote:

> 
> "Nick Roberts" <nick.roberts@acm.org> writes:
> 
>> I think a possible answer to this question is that XML is human-readable
>> (or at least it is pure text), whereas Ada streams are (essentially)
>> binary. I think the point of providing (only) string data for
>> parametising exceptions in Ada 95 was to ensure that those parameters
>> could simply be printed/displayed (by diagnostic software). XML encoded
>> parameters could also be simply printed out, as well as being interpreted
>> and used by knowledgeable software.
> 
> There is mixed issues here. The stream does not need to be human readable
> as the information is passed between partition, this is really a computer
> issue and the most compact representation is better. Now to display the
> exception information I agree that we need to kind of human
> representation.

In this respect I allways missed the

for My_Type'Image use ...;

feature.

We can say:

for My_Type'Output use ...;

so why not?

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: new revision ada (exception handling)

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:3596451.WJTNXepdF3@linux1.krischik.com...
> In this respect I allways missed the
>
> for My_Type'Image use ...;
>
> feature.

We considered it briefly, but there are a number of problems with such a
feature. (One example is that Text_IO.Enumeration_IO depends on 'Image. How
will it know what syntax to read for a user-defined image.) Anyway, we
dropped the idea. (You should be able to find that discussion in the meeting
minutes, although I can't tell you in which meeting we discussed it.)

              Randy Brukardt
              ARG Editor

Re: new revision ada (exception handling)

[Martin Krischik]

Randy Brukardt wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:3596451.WJTNXepdF3@linux1.krischik.com...
>> In this respect I allways missed the
>>
>> for My_Type'Image use ...;
>>
>> feature.
> 
> We considered it briefly, but there are a number of problems with such a
> feature. (One example is that Text_IO.Enumeration_IO depends on 'Image.
> How will it know what syntax to read for a user-defined image.) Anyway, we
> dropped the idea.

At least for the first question I know the answer. It is the same as for
'Output:

for My_Type'Value use ...;

If you provide 'Output and want to read the data afterwards you have to
provide an 'Input which fits the bill.

So it would be the same for the 'Image / 'Value pair. 

> (You should be able to find that discussion in the
> meeting minutes, although I can't tell you in which meeting we discussed
> it.)

To difficult to find anything in there.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: new revision ada (exception handling)

[Randy Brukardt]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1602287.U74iaLRb4H@linux1.krischik.com...
> Randy Brukardt wrote:
...
> > We considered it briefly, but there are a number of problems with such a
> > feature. (One example is that Text_IO.Enumeration_IO depends on 'Image.
> > How will it know what syntax to read for a user-defined image.) Anyway,
we
> > dropped the idea.
>
> At least for the first question I know the answer. It is the same as for
> 'Output:

No, that's *not* the question. (That's another question, which also needs to
be answered.)

The issue is that Enumeration_IO.Get needs to know the syntax of a
enumeration literal in order to know when to stop reading. For instance, if
a file has:

Red;Green Blue

and you do a Get, the next character to be read is ';', and "Red" will be
passed to 'Image.

But if you allow a user-defined 'Image, you don't know what to read in order
to pass it to 'Image. Perhaps the semicolon is part of the literal, perhaps
it is not. Perhaps the case matters to the literal, and perhaps not. So
where does reading stop? (And remember, whatever is done has to be
compatible with existing code and files.)

If you just say that the syntax is still that of an identifier, then what
you can do with a user-defined 'Image is very limited. "Real-Time" and "62B"
would not be legitimate uses of 'Image, and the errors that would occur when
trying to read them would be very mysterious to programmers.

                               Randy.

Re: new revision ada (exception handling)

[Dmitry A. Kazakov]

On Thu, 24 Jun 2004 16:13:58 -0500, Randy Brukardt wrote:

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1602287.U74iaLRb4H@linux1.krischik.com...
>> Randy Brukardt wrote:
> ...
>>> We considered it briefly, but there are a number of problems with such a
>>> feature. (One example is that Text_IO.Enumeration_IO depends on 'Image.
>>> How will it know what syntax to read for a user-defined image.) Anyway,
> we
>>> dropped the idea.
>>
>> At least for the first question I know the answer. It is the same as for
>> 'Output:
> 
> No, that's *not* the question. (That's another question, which also needs to
> be answered.)
> 
> The issue is that Enumeration_IO.Get needs to know the syntax of a
> enumeration literal in order to know when to stop reading. For instance, if
> a file has:
> 
> Red;Green Blue
> 
> and you do a Get, the next character to be read is ';', and "Red" will be
> passed to 'Image.
> 
> But if you allow a user-defined 'Image, you don't know what to read in order
> to pass it to 'Image. Perhaps the semicolon is part of the literal, perhaps
> it is not. Perhaps the case matters to the literal, and perhaps not. So
> where does reading stop? (And remember, whatever is done has to be
> compatible with existing code and files.)

One can build a table of all possible values of 'Image and use the table to
match the input. In this case there is no need to know where a name stops,
one only needs to have all names in the table different. However it looks
like the definition of Enumeration_IO.Get assumes that name ends can be
recognized prior knowing names, though A.10.10(9) does not read it
explicitly. Considering an enumeration type with images Red and Red1. Would
it be legal according to A.10.10(9) to read Red; and then raise Data_Error?

But of course the real source of the problems is that there is no S'Class
for enumeration types. Otherwise one could just deduce 'Input from 'Image
and use it Get.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Re: new revision ada (exception handling)

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:s1spuprxstn0$.11739hjwai5o4$.dlg@40tude.net...
...
> One can build a table of all possible values of 'Image and use the table
to
> match the input. In this case there is no need to know where a name stops,
> one only needs to have all names in the table different.

You could do something like that, but:

-- There's no way to do that with the 'Image and 'Value attributes; (it
should be possible to write the bodies of standard packages in Ada) - that's
especially important when they are user-defined, as we were discussing; and
-- It would be very incompatible with the current definition (which
Christophe explained nicely).

                 Randy.