Linux World

Linux World

[Richard D Riehle]

I am wondering if there will be anyone from
the Ada community at the Linux conference in 
San Jose, California this week.  

I will be there on Wednesday only and willing to
meet with any other Ada enthusiasts who might attend.

Richard Riehle
richard@adaworks.com

Re: Linux World

[fraser]

Richard Riehle wrote:

>I am wondering if there will be anyone from
>the Ada community at the Linux conference in 
>San Jose, California this week.  

>I will be there on Wednesday only and willing to
>meet with any other Ada enthusiasts who might attend.

I'd really like to go, pending time constraints.  If you see a guy wearing
black with a shaved head asking innocent C-philes how to display the
string representation of an enumeration constant, that's me. :)

Fraser.

Printing Enum Variable Re: Linux World

[David Starner]

fraser@synopsys.synopsys.com.com wrote:
> I'd really like to go, pending time constraints.  If you see a guy wearing
> black with a shaved head asking innocent C-philes how to display the
> string representation of an enumeration constant, that's me. :)

/* This code is off the top of my head, and has not been tested. */
#include <stdio.h>
enum Bob {Red_Apple, Green_Apple, Orange};

char * PrintBob(enum Bob Mike) {
	switch (Mike) {
		case Red_Apple: return "Red apple";
		case Green_Apple: return "Green apple";
		case Orange: return "Orange";
	};
};

int main() {puts (PrintBob(Apple));}

Note this has certain advantages over Ada's default method - it lets you
print a good string, instead of the mangled string that went into the
code (which, in my experiance, Ada further mangles by making it all
upper case), and it lets you internationalize the code easily. 

IMO, printing enumerator literals, as is, is a quick and dirty hack that
should be used only if you're the only user. It's not C's fault for
leaving it out; it would be inappropriate with C's model of enumerated
variables, IMO. (How should you print a value that doesn't have an
associated name, for instance?)

-- 
David Starner - OSU student - dstarner98@aasaa.ofe.org
If you want a real optimist, look up Ray Bradbury. Guy's nuts. 
He actually likes people. -David Brin

Re: Printing Enum Variable Re: Linux World

[David Starner]

robert_dewar@my-dejanews.com wrote:
> True, but complaining about C for lack of enumeration
> *types* is a legitimate complaint. The named constants
> provided by C are an inadequate substitute. Enumeration
> types are an important abstraction, and their absence
> from C is a significant missing capability.
> 
> Calling something an enum does not make it an enumeration
> type!

Well, pulling out an old Pascal textbook, I don't see anything that
Pascal offers enumeration types that C doesn't. Ada being a rather type
strong language, it doesn't suprise me that you can do more things with
enumeration types in it than in Pascal or C. I would hesitate to claim
that Pascal or C don't provide enumeration types just because they don't
offer all the dials and knobs that Ada does. 

-- 
David Starner - OSU student - dstarner98@aasaa.ofe.org
If you want a real optimist, look up Ray Bradbury. Guy's nuts. 
He actually likes people. -David Brin

Re: Printing Enum Variable Re: Linux World (Correction)

[Hans Marqvardsen]

Magnus Larsson wrote:
> My only problem is the
> latin-1 characters in DOS, but I guess that's no fault of Ada. ;-)
> 
> /Magnus
> 


Sorry for an error in my previous reply.
(you have to press the key � to get a Pound_Sign)

In any case I have uploaded the Package Console.io
to David Bottons Ada Treasury.

Console.io.put puts any Latin_1 character correctly to the Console
screen.
Console.io.get gets any Latin_1 character correctly from the console
keyboard.

Re: Printing Enum Variable Re: Linux World

[Hans Marqvardsen]

Magnus Larsson wrote:
>  My only problem is the
> latin-1 characters in DOS, but I guess that's no fault of Ada. ;-)
> 
> /Magnus

Guess you mean "The OEM characters in DOS".

I have always found it amazing that the validation suites does not care
if IO from the keyboard or to the screen distorts 
about half of the available graphic characters.
  
EG Put('�') to see a Pound_Sign, on the screen.
American Chauvinism !)

Re: Printing Enum Variable Re: Linux World

[Larry Kilgallen]

In article <36DCAC1F.430E2C5E@aasaa.ofe.org>, David Starner <dstarner98@aasaa.ofe.org> writes:

> IMO, printing enumerator literals, as is, is a quick and dirty hack that
> should be used only if you're the only user. It's not C's fault for
> leaving it out; it would be inappropriate with C's model of enumerated
> variables, IMO. (How should you print a value that doesn't have an
> associated name, for instance?)

I think that is part of the point -- that C allows values without an
associated name.

Larry Kilgallen

Re: Printing Enum Variable Re: Linux World

[fraser]

I nearly cried when dstarner98@aasaa.ofe.org said:

[ printing enumerations in C example deleted ...]

The point being, of course, that in Ada I write:
  
   Bob'Image (X)

which still works even if I add an apricot.  Which solution do you prefer?

Fraser.

Re: Printing Enum Variable Re: Linux World

[Fraser Wilson]

I nearly cried when dstarner98@aasaa.ofe.org said:

>Note this has certain advantages over Ada's default method - it lets you
>print a good string, instead of the mangled string that went into the
>code (which, in my experiance, Ada further mangles by making it all
>upper case), and it lets you internationalize the code easily. 

Well, I have to disagree on this.  Printing a string representation of
a literal is not something that goes out to the User (bless his heart).
It's for my information, and the all caps, direct representation of the
name is exactly what I need.

I understand gdb can do something similar, but debuggers are a poor
substitute for understanding the code.

If you add an extra element to the enumeration, will the compiler
warn you about the switch statement?  What if the strings were stored
in an array?

>IMO, printing enumerator literals, as is, is a quick and dirty hack that
>should be used only if you're the only user.

Again, it's for my eyes only.  And I wouldn't call it a quick'n'dirty hack.
It's a useful technique.

> (How should you print a value that doesn't have an
>associated name, for instance?)

I'd completely forgotten you could do that in C.  So an enum is basically
a shorthand to avoid writing lots of #defines?  Doesn't that somewhat miss
the point.

Oh, dear, the topic tree is straining ...

Fraser.

Re: Printing Enum Variable Re: Linux World

[Nick Roberts]

All of which spectacularly misses the point.  Now ask a C-phile to construct
an entire air traffic control system in C.  That's the point.

Nick Roberts

Re: Printing Enum Variable Re: Linux World

[David Starner]

fraser@synopsys.ha.com wrote:
> 
> I nearly cried when dstarner98@aasaa.ofe.org said:
> 
> [ printing enumerations in C example deleted ...]
> 
> The point being, of course, that in Ada I write:
> 
>    Bob'Image (X)
> 
> which still works even if I add an apricot.  Which solution do you prefer?

Mine. For my example printed out "Red apple" as opposed to "RED_APPLE",
and could be quickly internationalized. The only way to internationalize
Bob'Image (X) is to rip it out and replace all examples with something
like the code you cut. I don't think direct outputing of enumerations is
right except as a quick and dirty hack - the name mangling require by C
or Ada (no spaces, no hypens, etc.) combined with the i18n problems make
it inappropriate. 

I never meant this as an attack on Ada. It just that complaining about C
for lack of enumeration strings is as appropriate as complaining about
Ada for lack of a "?:" operator. It's not that big a deal. 
-- 
David Starner - OSU student - dstarner98@aasaa.ofe.org
If you want a real optimist, look up Ray Bradbury. Guy's nuts. 
He actually likes people. -David Brin

Re: Printing Enum Variable Re: Linux World

[David Starner]

Nick Roberts wrote:
> 
> All of which spectacularly misses the point.  Now ask a C-phile to construct
> an entire air traffic control system in C.  That's the point.
> 
> Nick Roberts

Bingo. He may try, but . . .
-- 
David Starner - OSU student - dstarner98@aasaa.ofe.org
If you want a real optimist, look up Ray Bradbury. Guy's nuts. 
He actually likes people. -David Brin

Re: Printing Enum Variable Re: Linux World

[David Starner]

Fraser Wilson wrote:
> Well, I have to disagree on this.  Printing a string representation of
> a literal is not something that goes out to the User (bless his heart).
> It's for my information, and the all caps, direct representation of the
> name is exactly what I need.

Actually, it rather annoyed me to find it in all caps. I typed into the
program with initial caps for a reason. If it's not something that goes
out to a user, why worry about it? For most my enumeration printing in
C, a couple nested "?:" did the trick. 
> 
> I understand gdb can do something similar, but debuggers are a poor
> substitute for understanding the code.
How does this help you understand the code? 
> 
> If you add an extra element to the enumeration, will the compiler
> warn you about the switch statement?  What if the strings were stored
> in an array?
Yes, if you added a default case at the end of the switch statement. The
array is a totally different issue - a valid point to complain about.
> 
> >IMO, printing enumerator literals, as is, is a quick and dirty hack that
> >should be used only if you're the only user.
> 
> Again, it's for my eyes only.  And I wouldn't call it a quick'n'dirty hack.
> It's a useful technique.
If it is just something I toss into a program and don't care how it
looks or runs, just that it does, that's what I call a quick'n'dirty
hack. YMMV
> 
> > (How should you print a value that doesn't have an
> >associated name, for instance?)
> 
> I'd completely forgotten you could do that in C.  So an enum is basically
> a shorthand to avoid writing lots of #defines?  Doesn't that somewhat miss
> the point.

No, it just means that a C enum is not quite the same abstraction as an
Ada enum. 
-- 
David Starner - OSU student - dstarner98@aasaa.ofe.org
If you want a real optimist, look up Ray Bradbury. Guy's nuts. 
He actually likes people. -David Brin

Re: Printing Enum Variable Re: Linux World

[fraser]

I nearly cried when dstarner98@aasaa.ofe.org said:

>I never meant this as an attack on Ada. It just that complaining about C
>for lack of enumeration strings is as appropriate as complaining about
>Ada for lack of a "?:" operator. It's not that big a deal. 

Believe me, I'd have to kill myself if I got narky whenever someone
said that a feature in Ada is not necessarily positive.  But you're
still wrong :)

I see the enumeration string thing itself as being minor.  However,
consider what being able to provide that feature means: enumerations
are actual, real live types just as, say, integers are.  Having an Image
attribute is a big flag that says an enumeration is something more than
just a convenience; it says that the language supports it, nutures it,
and holds it when it cries.

I think that your comment about a similar operation in C being inconsistent
with the semantics of an enum in that language is telling: it shows that
they're not really there.  They're just window dressing.

Attributes indicate a lot about the type system.  For an array object X,
being able to write X'Range, X'First, X'Last etc. tells you that Ada
has a lot of support for what arrays actually are.  The fact that these
things are not available in C (not even X'First in the general case [1])
tells you how C feels about the construct.  It doesn't have arrays, it
has chunks of memory that you can allocate in a single declaration.
Big whoop.

This is, of course, completely informal.  But a programming language is
more than just a reference manual, it's a style as well.

Oh, and sorry for the purpleness of the above.

Fraser.

[1] there's a C idiom that goes char a[100]; char *b = a-1; which gives
you an array b from 1 to 100.  Sure, it violates the standard, but name
a compiler that rejects and I'll give you twelve zorkmids.

Re: Printing Enum Variable Re: Linux World

[Samuel T. Harris]

David Starner wrote:
> 
> fraser@synopsys.ha.com wrote:
> >
> > I nearly cried when dstarner98@aasaa.ofe.org said:
> >
> > [ printing enumerations in C example deleted ...]
> >
> > The point being, of course, that in Ada I write:
> >
> >    Bob'Image (X)
> >
> > which still works even if I add an apricot.  Which solution do you prefer?

When I don't like the case of 'image, I use enumeration_io which
provides control over case. When I don't like the other stuff,
then I use a constant array indexed by the enumeration type
with component type of access to string. Who needs a case or switch
statement?
Oh, and the compiler complains when I add an apricot but forget
to add the additional component to my constant array initialization
aggregate. Oh yeah, I almost forgot about those nasty Ada reserved
words colliding with my intended vocabulary. In that case, I
instantiate my own word_io package which deals with the arbitrary
prefixes I had to use for x_all (the most common collision in
my experience). It not only duplicates the functionality of
enumeration_io, but also provides the width, image, and value
functions which correspond to the attributes so my resulting
code looks reasonably similar to what I wanted in the first place.

> 
> Mine. For my example printed out "Red apple" as opposed to "RED_APPLE",
> and could be quickly internationalized. The only way to internationalize
> Bob'Image (X) is to rip it out and replace all examples with something
> like the code you cut. I don't think direct outputing of enumerations is
> right except as a quick and dirty hack - the name mangling require by C
> or Ada (no spaces, no hypens, etc.) combined with the i18n problems make
> it inappropriate.

> 
> I never meant this as an attack on Ada. It just that complaining about C
> for lack of enumeration strings is as appropriate as complaining about
> Ada for lack of a "?:" operator. It's not that big a deal.
> --
> David Starner - OSU student - dstarner98@aasaa.ofe.org
> If you want a real optimist, look up Ray Bradbury. Guy's nuts.
> He actually likes people. -David Brin

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Scientific and Technical Systems
"If you can make it, We can fake it!"

Re: Printing Enum Variable Re: Linux World

[Richard D Riehle]

In article <36DDA9BA.E005E578@aasaa.ofe.org>,
	David Starner <dstarner98@aasaa.ofe.org> wrote:

>Actually, it rather annoyed me to find it in all caps. I typed into the
>program with initial caps for a reason. If it's not something that goes
>out to a user, why worry about it? 

 There is a parameter for Put in Enumeration_IO which allows 
 either upper case of lower case in the output.  The default
 is upper case.  It is trivial to select lower case.

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com

Re: Printing Enum Variable Re: Linux World

[Richard D Riehle]

>Actually, it rather annoyed me to find it in all caps. I typed into the
>program with initial caps for a reason. If it's not something that goes
>out to a user, why worry about it? 

 A follow-up to my earlier post about Put in Enumeration_IO.  I
 notice you are concerned about this problem with the 'Image
 attribute.  The following code should handle this problem
 quite nicely,

  with Ada.Characters.Handling;
  with Ada.Text_IO;
  use  Ada;
  use  Characters;
  procedure Test_Handling is
  begin
    Ada.Text_IO.Put(Handling.To_Lower(Boolean'Image(True)));
  end Test_Handling;

For some odd reason, people are still not getting used to the idea
of using the Character and String packages pre-defined in Annex A.
A lot of problems are solved easily using these services.

Richard Riehle
richard@adaworks.com
http://www.adaworks.com

Re: Printing Enum Variable Re: Linux World

[Samuel Mize]

David Starner <dstarner98@aasaa.ofe.org> wrote:
> robert_dewar@my-dejanews.com wrote:
>> True, but complaining about C for lack of enumeration
>> *types* is a legitimate complaint. The named constants
>> provided by C are an inadequate substitute. Enumeration
>> types are an important abstraction, and their absence
>> from C is a significant missing capability.
>> 
>> Calling something an enum does not make it an enumeration
>> type!

In another message, you say:
> No, it just means that a C enum is not quite the same abstraction as an
> Ada enum.

Both are true.  You don't contradict Robert, but you missed his point.

His point depends critically on understanding the concept of "type."
This concept is fundamental to programming languages.

A type is a set of legal values, and operations on those values.

To say that a language provides the "enum" concept as a type, that
language must ensure that a variable of that type will hold only those
values, and it must provide the standard operations (like 'Last and
'First) for an enumeration.  If it doesn't do this for you, it doesn't
support the type as an entity of the language.

In Ada, an enumeration is truly a type.

In C (IIRC), an "enum" is just a bunch of names for numbers.

So what?  I mean, what's the difference, what's the advantage?

Well, an example may make it clear.  I don't recall the C syntax, so
I'll speak here in general terms.  In C, you can have an enumeration
"color" of:

  RED = 0
  WHITE = 1
  BLUE = 2

and an enumeration "animal" of:

  DOG = 0
  CAT = 1
  FERRET = 2
  GODZILLA = 3

If you have an integer variable Pet, which you intend to be of type
"animal", there's nothing stopping you from writing:

  Pet = BLUE;
  /* should have written Pet_Color = BLUE; */

You can even write:

  Pet = 33;
  /* whoops, double-tapped the key */

Those are errors, and that kind of error occurs much more often than
you would expect; especially when you're dealing with a large program
with dozens of enumerations, all relating to (for instance) a
windowing GUI system.

Another example: a call to a windowing function that expects a window ID,
an enumerated color (really, an integer), and a bitmap that covers some
list of attributes (again, really an integer).  In C, you might not
notice that you reversed these two parameters, and there's no way the
compiler can tell you:

  /* one of these must be right, the other wrong */
  SetWindow (W1, color, attribs);
  SetWindow (W1, attribs, color);

  /* which one is the color?  did the programmer get it right? */
  SetWindow (W1, 0x3F, 0xA7); 

Pascal and Ada will catch the reversal of parameters on line 2 (or is
it line 1?  How do you know?)

They will also keep you from manually typing in arbitrary integers.
This annoys many C people, but again this is a common source of error in
code that is maintained for more than one version.  Even if the coder
put the parameters in the right order, the codes may change.  But the
typed-in integers remain the same, forgotten in some seldom-used nook of
the code until a user stumbles over it, causing a system crash.

That's what "strong typing" is all about.  It doesn't mean you should
hit the keys more forcefully :-), it means that the type system built
into the language knows a lot about what you're trying to do (if you
use the type system to tell it), and it can help you write clearer
code and avoid making mistakes.


Elsewhere in this thread someone asked:
> If you add an extra element to the enumeration, will the compiler
> warn you about the switch statement?

and you replied:
> Yes, if you added a default case at the end of the switch statement.

Well, no.  The compiler doesn't care in either case.  If you have a
default case in your switch statement, you can detect at RUN TIME
that you missed the new element.  Or, as happens too often, the end
user detects it, because the new element didn't get into the regression
test suite at EVERY SINGLE POINT it was needed.

In Ada, the compiler will stop you and make you code up that alternative,
before you even start testing.

Or not, if you used a "when others" alternative to provide a default
behavior.  This is less safe than explicitly listing all alternatives,
but it can be a convenience, and it's safe if you're sure that the
possible alternatives won't change (for instance, a case based on type
type character).  You use this -- if you're savvy -- knowing that you
have lost part of the protection that a case statement usually provides.


> Well, pulling out an old Pascal textbook, I don't see anything that
> Pascal offers enumeration types that C doesn't.

I hope you see now that the difference what C lets you do, often
erroneously.  You can do anything with an enumeration that you can do
with any other integer.  An enumeration value is just an integer, and
an enumeration variable can hold any integer.

Pascal and Ada assume you meant it when you said this type was an
enumeration, and they detect typos and mental errors in enumeration usage.

> I would hesitate to claim
> that Pascal or C don't provide enumeration types just because they don't
> offer all the dials and knobs that Ada does. 

Pascal offers enumeration types.

C offers the concept of enumeration, but in a much weaker form, and it's
not a true type (limited set of values + operations).


> David Starner - OSU student - dstarner98@aasaa.ofe.org

I hope you don't feel we're beating on you here.  Keep asking questions,
keep learning, God bless.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

In article <36DD54D2.141B@ddre.dk>,
  hm@ddre.dk_nospam wrote:
> I have always found it amazing that the validation suites
> does not care if IO from the keyboard or to the screen
> distorts about half of the available graphic characters.
>
> EG Put('�') to see a Pound_Sign, on the screen.
> American Chauvinism !)


If you have found this amazing, it is because you do not
understand the situation.

The RM has *nothing* at all to say about what characters
look like in the external world. Absolutely NOTHING. A
validated compiler has no requirements at all in this area.

A compiler which used B as the representation of letter-A
and A as the representation of letter-B in the external
world would be annoying and silly, and undoubtedly rejected
by the marketplace, but not necessarily invalid if the
internal codes were correctly represented.

This is a VERY common misconception (that external
characters must correspond to some preconceived conception
of them).

To see just how wrong this is, consider that a compiler can
be fully conformant with the 10646-based requirements for
wide characters, without the ability to output or input a
character in anything like its Han form.

So if the validation process DID complain about the sort
of thing you mention, it would mean that the validation
process was seriously broken.

Of course when you are acquiring a compiler and an
operating system, you must make sure that external handling
of character data meets your requirements.

By the way, in practice this is 100% an operating system
issue, and not at all a compiler issue. The compiler will
handle Latin-1 input and output, and how it got there is
not the compiler's business.

GNAT does support many other character sets, including
multiple PC code pages, and other Latin-n sets, but such
support is in fact a language extension, nothing at all to
do with the RM requirements.


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[fraser]

I nearly cried when dstarner98@aasaa.ofe.org said:

>Actually, it rather annoyed me to find it in all caps. I typed into the
>program with initial caps for a reason.

It's easy to change (generically even).

>> I understand gdb can do something similar, but debuggers are a poor
>> substitute for understanding the code.

>How does this help you understand the code? 

Not enumeration strings in particular, but debuggers in general.  I always
found that most of the 'a-ha' moments while using a debugger were related
coming to a sudden understanding of what the code was trying to do.

If you eliminate the debugger, then you're forced to start with this
understanding.  I think that's profitable.  If I let myself run to gdb
every time something goes wrong, then I'll be forever patching symptoms
instead of causes, and it will probably take longer to sort things
out anyway.

My debugging tools are a trace, Emacs and a nice stout.  Actually, the stout
is optional, but hey, the first one doesn't hurt.  Saying no to the second
hurts a _lot_ though.

First, look the code.  If that doesn't help, follow the trace.  If it still
doesn't help, drink the stout and repeat.

>Yes, if you added a default case at the end of the switch statement. The
>array is a totally different issue - a valid point to complain about.

That's a run-time diagnostic, isn't it?

>If it is just something I toss into a program and don't care how it
>looks or runs, just that it does, that's what I call a quick'n'dirty
>hack. YMMV

I care deeply how it looks -- I want it to look like an enumeration literal.
And it's not just tossed in, it's carefully placed to extract the maximum
information about the state of the process.

Well, in an ideal world, anyway.

>No, it just means that a C enum is not quite the same abstraction as an
>Ada enum. 

It looks like it's not an abstraction at all, just a different way of
denoting an int.  Then again, most things in C are different ways of
denoting an int :)

Fraser.

Re: Printing Enum Variable Re: Linux World

[Samuel Mize]

There's another point about C-style "enum"s not being a true type.
IIRC, the compiler can't easily handle multiple "enum"s with the same
identifier in them.  Is my recollection correct?

How would you code this in C:

    
  with text_io; use text_io;
  procedure a is
    type US_Bunting_Color is (Red, White, Blue);
    type Mardi_Gras_Color is (Purple, Green, Black, White);

    put_line (integer'image (US_Bunting_Color'Pos (Bunting)));
    put_line (integer'image (Mardi_Gras_Color'Pos (Ribbon)));
  end a;
    --
    -- outputs:
    -- 1
    -- 3

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: Printing Enum Variable Re: Linux World

[Hans Marqvardsen]

robert_dewar@my-dejanews.com wrote:
> 
> In article <36DD54D2.141B@ddre.dk>,
>   hm@ddre.dk_nospam wrote:
> > I have always found it amazing that the validation suites
> > does not care if IO from the keyboard or to the screen
> > distorts about half of the available graphic characters.
> >
> > EG Put('�') to see a Pound_Sign, on the screen.
> > American Chauvinism !)
> 
> If you have found this amazing, it is because you do not
> understand the situation.
> 
> The RM has *nothing* at all to say about what characters
> look like in the external world. Absolutely NOTHING. A
> validated compiler has no requirements at all in this area.
> 

What really amazes me is that even though good people has spent good
time
designing a validation procedure where specific compilers are
validated for specific operating systems, 
then one of these good people claims that 

1. this procedure may validate combinations that in his own words
behave annoying and silly and undoubtedly would be rejected by the 
marketplace.

2. the validation process would seriously broken, if it were to 
consider these problems.


By the way,  David Bottons Ada treasury has a package Console_io 
       http://www.botton.com/ada/reuse/alphcon.html
that hopefully handles  console-mode IO "correctly".

"correctly" meaning 
press any key, get the corresponding character
put any character, see the corresponding graphic image.

Re: Printing Enum Variable Re: Linux World

[Hans Marqvardsen]

robert_dewar@my-dejanews.com wrote:

> This is a VERY common misconception (that external
> characters must correspond to some preconceived conception
> of them).
> 
> 

When Robert Dewar says so, I must accept that it is so.
(But maybe the Ada-community would be better served if not)

Regarding similar common (mis?)conceptions, is it true
that the current validation still allows a compiler 
to put arbitrary limits on compilable program size? 
(such as to disallow any program bigger than 1 character)
or to take forever to compile?

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

In article <36DDA9BA.E005E578@aasaa.ofe.org>,
  David Starner <dstarner98@aasaa.ofe.org> wrote:
> Actually, it rather annoyed me to find it in all caps. I
> typed into the program with initial caps for a reason. If
> it's not something that goes out to a user, why worry
> about it?

Surely you do not expect it to come out the way it is
spelled in the program? That would be a horrible idea,
since it would mean that there was no longer case
insensitivity for identifiers.

So it obviously has to be normalized, and it is hard to
see any choice except all caps!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

In article <36DDA761.7B4E8099@aasaa.ofe.org>,
  David Starner <dstarner98@aasaa.ofe.org> wrote:
> I never meant this as an attack on Ada. It just that
> complaining about C for lack of enumeration strings is as
> appropriate as complaining about Ada for lack of a "?:"
> operator. It's not that big a deal.

True, but complaining about C for lack of enumeration
*types* is a legitimate complaint. The named constants
provided by C are an inadequate substitute. Enumeration
types are an important abstraction, and their absence
from C is a significant missing capability.

Calling something an enum does not make it an enumeration
type!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Magnus Larsson]

I think the Reading of an Enum is really the trick in Ada, and find
these type of constructs really useful. Note that you could declare the
State type in your "language package" which is precicely what I've used
it for. Here you don't have care about any caps. My only problem is the
latin-1 characters in DOS, but I guess that's no fault of Ada. ;-)

/Magnus

   function State
        (Data       : String)
         return Natural
   is
      type State is (Brake, Start, Resume, Reset); 
   begin
      return State'Pos (State'Value (Data));
   exception
      when others => -- Of course i should only trap the "right"
exception,
                     -- but I can't remember which one it was
         return Some_Error_Code;
   end State;


David Starner wrote:
> 
> Fraser Wilson wrote:
> > Well, I have to disagree on this.  Printing a string representation of
> > a literal is not something that goes out to the User (bless his heart).
> > It's for my information, and the all caps, direct representation of the
> > name is exactly what I need.
> 
> Actually, it rather annoyed me to find it in all caps. I typed into the
> program with initial caps for a reason. If it's not something that goes
> out to a user, why worry about it? For most my enumeration printing in
> C, a couple nested "?:" did the trick.
> >
> > I understand gdb can do something similar, but debuggers are a poor
> > substitute for understanding the code.
> How does this help you understand the code?
> >
> > If you add an extra element to the enumeration, will the compiler
> > warn you about the switch statement?  What if the strings were stored
> > in an array?
> Yes, if you added a default case at the end of the switch statement. The
> array is a totally different issue - a valid point to complain about.
> >
> > >IMO, printing enumerator literals, as is, is a quick and dirty hack that
> > >should be used only if you're the only user.
> >
> > Again, it's for my eyes only.  And I wouldn't call it a quick'n'dirty hack.
> > It's a useful technique.
> If it is just something I toss into a program and don't care how it
> looks or runs, just that it does, that's what I call a quick'n'dirty
> hack. YMMV
> >
> > > (How should you print a value that doesn't have an
> > >associated name, for instance?)
> >
> > I'd completely forgotten you could do that in C.  So an enum is basically
> > a shorthand to avoid writing lots of #defines?  Doesn't that somewhat miss
> > the point.
> 
> No, it just means that a C enum is not quite the same abstraction as an
> Ada enum.
> --
> David Starner - OSU student - dstarner98@aasaa.ofe.org
> If you want a real optimist, look up Ray Bradbury. Guy's nuts.
> He actually likes people. -David Brin

-- 
________________________________
 .|,    | Jobb: 08 - 750 74 30
 -o---- | Mob : 0708 - 13 57 94
omicron | Hem : 08 - 545 600 76

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

In article <36DE0007.5236CEA2@aasaa.ofe.org>,
  David Starner <dstarner98@aasaa.ofe.org> wrote:
> Well, pulling out an old Pascal textbook, I don't see
> anything that Pascal offers enumeration types that C
> doesn't.

Read the text book more carefully, it is what pascal does
NOT allow you to do that is the key to seeing enumerations
as a different abstraction.

In C, enums are just int's with a special way of defining
values, they are not a separate type.

The situation is similar to char. I think it is a mistake
that C does not have a character type. This of course can
be discussed, but no one can argue that C *does* have
a character type (calling one of the int types char, and
allowing int literals to have the form of characters does
NOT make a character type!)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[dennison]

In article <36DDA761.7B4E8099@aasaa.ofe.org>,
  David Starner <dstarner98@aasaa.ofe.org> wrote:
> fraser@synopsys.ha.com wrote:
> >
> > I nearly cried when dstarner98@aasaa.ofe.org said:
> >
> > [ printing enumerations in C example deleted ...]
> >
> > The point being, of course, that in Ada I write:
> >
> >    Bob'Image (X)
> >
> > which still works even if I add an apricot.  Which solution do you prefer?
>
> Mine. For my example printed out "Red apple" as opposed to "RED_APPLE",
> and could be quickly internationalized. The only way to internationalize
> Bob'Image (X) is to rip it out and replace all examples with something
> like the code you cut. I don't think direct outputing of enumerations is
> right except as a quick and dirty hack - the name mangling require by C
> or Ada (no spaces, no hypens, etc.) combined with the i18n problems make
> it inappropriate.

Actually, I use 'Image and 'Value a *lot*. Perhaps it isn't the best feature
in the world for production user interfaces, but it has saved me *months* of
time over my career in generating test drivers. It is also quite helpful for
configuration files, where users aren't as finiky about the interface.

I don't think the argument that it is of no value hold any water at all. In
the above applications a C developer would probably end up using integers due
to the pain of having to type out 40 or so strings, and calling the i/o
routine then strncmp and interpreting the results, etc. My enumeration value
interface is much clearer, and thus less error prone. In an application like
a config file, that's a big win.

And of course if I need your "any string and internationalization"
functionality, I can do just what C coders are forced to do for everything.
:-)

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Ehud Lamm]

On Thu, 4 Mar 1999 robert_dewar@my-dejanews.com wrote:

>  Enumeration
> types are an important abstraction, and their absence
> from C is a significant missing capability.
> 
> Calling something an enum does not make it an enumeration
> type!
> 

Time and again I am amazed how this simple festure ofthe language stumps
people. I see exercises which show understanding of important and
difficult concepts like genericity - but fail to exploit enumeration type
where appropriate. This should really end up on my idiom list. 

Just as the ultimate simple exmaple, for lurkers who are studying the
language, consider that when you have a situation where you know exactly
the class of possible values enumeration types allow you to (1) name them
and (2) implicitly assume that the value is valid, without having to check
it each time it is used. Example:
If I have a function that receives a coind value, which must be a quarter
or a cent, I can coide it like this:
type coin is (quarter,cent)
...
case Coin_val is
when quarter =>
when cent =>
end case

where as a lower level of abstractenss and more work is needed when you
define coin to a integer type:
case Coin_val is
when 1 =>
when 25=>
when others => raise Coin_Error;
end case

(This is a nice situation, because many people want to declare an integer
subtype with two, non-consecutive values).

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
http://www2.cybercities.com/e/ehud

Re: Printing Enum Variable Re: Linux World

[Ehud Lamm]

> > Mine. For my example printed out "Red apple" as opposed to "RED_APPLE",

A little example of using generics, producing a menu, and pretry printing:

with ada.text_io; use ada.text_io;
with ada.integer_text_io; use ada.integer_text_io;
with Ada.Characters.Handling;

--generic
--   type Menu_Choice is (<>);
procedure Get_Menu_Choice (Choice:out Menu_Choice)  is
   Input:Integer range 0..Menu_Choice'Pos(Menu_Choice'Last);
   Done :Boolean;
   

   function Pretty(S:String) return String is
      -- This code is independent of 'image behaviuor.
      -- just deals with _ and capitalizes first letter in "words"
      Aux    :String(1..S'Length):=(others=>' ');
      Capital:Boolean:=True;
   begin
      for i in S'range loop
         if S(i)='_' then
               Aux(i):=' ';
               Capital:=True;
         elsif Capital then
               Aux(i):=Ada.Characters.Handling.To_Upper(S(i));
               Capital:=False;
         else
               Aux(i):=Ada.Characters.Handling.To_lower(S(i));
         end if;
      end loop;
      return Aux;
   end;

begin  -- Get_Menu
   for Choice in Menu_Choice loop
      put_line(Integer'Image(Menu_Choice'Pos(Choice)) & ' ' & 
               Pretty(Menu_Choice'image(Choice)));
   end loop;
   loop
      begin
         get(Input);
         Done:=True;
      exception
         when others =>
            put_line("minimal error message");
            Skip_Line;
            Done:=False;
      end;
      exit when Done;
    end loop;
    Choice:=Menu_Choice'val(Input);
end;

And a simple driver:

with get_menu_choice;
with ada.text_Io;
use ada.text_io;
procedure try_menu_choice is
   type menu is (First_Option,Second_Option_For_You);
   procedure Get_My_Menu_Choice is new Get_Menu_Choice(Menu_Choice=>Menu);
   
   package EIO is new Enumeration_Io(Menu);
   use EIO;
   C:menu;
begin
   get_My_Menu_Choice(C);
   put(C);
   
end;

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
http://www2.cybercities.com/e/ehud

Re: Printing Enum Variable Re: Linux World

[Nick Roberts]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 226 bytes --]

Hans Marqvardsen wrote in message <36DD54D2.141B@ddre.dk>...
[...]
|EG Put('�') to see a Pound_Sign, on the screen.
|American Chauvinism !)

No, IBM chauvinism (and haste, but that's whole nother story).

Nick Roberts

Re: Printing Enum Variable Re: Linux World

[Nick Roberts]

fraser@sinopsis.com wrote in message <7bmua7$qg9$1@remarQ.com>...
[...]
|Not enumeration strings in particular, but debuggers in general.  I always
|found that most of the 'a-ha' moments while using a debugger were related
|coming to a sudden understanding of what the code was trying to do.
|
|If you eliminate the debugger, then you're forced to start with this
|understanding.  I think that's profitable.  If I let myself run to gdb
|every time something goes wrong, then I'll be forever patching symptoms
|instead of causes, and it will probably take longer to sort things
|out anyway.


I've had contact with a lot of different programmers, and I find that some
rely heavily on debuggers, and some eschew them (as I do myself most of the
time), but, and this is the big but, BUT, both groups seem to do as well as
each other in terms of debugging speed and accuracy.  Conclusion: provide a
good debugger; provide other debugging support (e.g. assertion, stack
traceback, exception diagnosis, a pop-up eror message message facility,
etc.); leave it to the user to choose.

|My debugging tools are a trace, Emacs and a nice stout.  Actually, the
stout
|is optional, but hey, the first one doesn't hurt.  Saying no to the second
|hurts a _lot_ though.


I think most programmers will agree, you need quite a high pain threshold to
make a living out of programming computers.  (Masochistic tendencies help
:-)

|First, look the code.  If that doesn't help, follow the trace.  If it still
|doesn't help, drink the stout and repeat.

This is (nearly) always my style.  It's incredibale how you can stare at a
small piece of code, sometimes literally for hours, and only _then_ see the
'obvious' error.  But even I would attest that a really good debugger (and
most, admittedly, are pretty crap) can be most enlightening sometimes
(sometimes, note).

-------------------------------------
Nick Roberts
-------------------------------------

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

In article <36E0085A.C1667CA5@Botton.com>,
  David Botton <David@Botton.com> wrote:
> The author, Hans Marqvardsen, you were responding to just
> happened to mention my name, since he has an article on
> CONIO on my site. I wouldn't get involved with a thread
> like this unless I was dragged in!

Sorry for the misattribution!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Nick Roberts]

Richard D Riehle wrote in message <7bpevu$frn@dfw-ixnews12.ix.netcom.com>...
[...]
| Enumeration types also carry the potential for abuse.  I recall
| a programmer who had a package specification with an enumeration
| type where the set of values spanned three pages of source code.


I think it's interesting to note that the (notional) declaration of the
Character type (RM95 A.1) is pretty big, and a declaration of Wide_Character
would span more than three pages!  I suppose it's also interesting to note
that these types can't be declared by a normal Ada declaration (the control
characters are unrepresentable).

| If enumeration types are to be on the idiom list, they should be
| accompanied by a set of guidelines.  One of the problems we are
| trying to solve with object-oriented programming and child library
| units is the extension of existing code without performing "open
| heart surgery" on it.  Heavy use of enumeration types can result in
| cracking open existing code to perform such extensions.
|
| Some of the guidelines I follow, and counsel my clients to follow,
| 1) only use enumeration types when there is a well-known limit to the
| set of values.  2) Use them when there is a clear requirement for an
| ordered set, 3) Use them for identifying types that have a small
| set of values (e.g., Location is (Front, Back);).


The canonical example -- I suppose -- being the type Boolean.

| There is a point of view in the OOP community that says that enumeration
| types are an artifact of an obsolete style of programming.  That is,
| an enumeration type, because it is not extensible and cannot be
| further specialized, is antithetical to OOP.  Although I find this
| viewpoint a little too narrow for my taste, one could make a very
| good case to support it in many situations.


In Ada, tagged types -- possibly empty -- can be used like extensible
enumeration types (which is presumably partly why the original idea of
extensible enumeration types was rejected).  The syntax is, perhaps,
slightly clumsy for this use, sometimes.

Compare:

   type Traffic_Light_State is (Red, Amber, Green, Red_And_Amber);

   Traffic_May_Pass: array (Traffic_Light_State) of Boolean :=
      (Red | Red_And_Amber => False, Amber | Green => True);

If you wanted to added a new state (blinking amber, say), you would have
difficulty in two ways: firstly, you can't extend the enumerated type
without performing 'open heart surgery' on the code; secondly, the question
of whether traffic may pass may need to be qualified (by whether there is a
pedestrian crossing the road), so that you can't just extend the array, you
have to make some more extensive changes to the program's logic.  Now
consider:

   type Traffic_Light_State is abstract tagged ...;

   function Traffic_May_Pass (State: in Traffic_Light_State) return Boolean
is abstract;

then:

   type Red_Light_State is new Traffic_Light_State with ...;

   function Traffic_May_Pass (State: in Red_Light_State) return Boolean;

where the function body would presumably just return False, and so on for
the other states.  Now, a new state can be added easily, and it may be
possible to add logic in the body of the Traffic_May_Pass function to decide
whether a pedestrian is crossing the road or not before giving traffic
permission to pass.

However, it remains difficult to code, in an easily extensible way, which
state comes first or last (as in the attributes First and Last), or to
iterate over them (as in the attributes Pred and Succ), since extensibility
means there is no clear 'last' element, and no clear 'next' for each one.

Like most good ideas, this idea is ludicrous when taken to the extreme.
Would it make sense to implement Boolean as a tagged type?  Or Character, or
Wide_Character?  (Perhaps it _would_ make sense for Wide_Character or a
similar type, but I'm dubious.)

-------------------------------------
Nick Roberts
-------------------------------------

Re: Printing Enum Variable Re: Linux World

[fraser]

paene lacrimavi postquam "Nick Roberts" <Nick.Roberts@dial.pipex.com> scribavit

>I've had contact with a lot of different programmers, and I find that some
>rely heavily on debuggers, and some eschew them (as I do myself most of the
>time), but, and this is the big but, BUT, both groups seem to do as well as
>each other in terms of debugging speed and accuracy.

Good point; I should have said, "Oh, this is how I work, YMMV."

OTOH, doesn't every programmer have the perfect style?  Just ask them.  :)

Fraser.
(change i to y for my email address)

Re: Printing Enum Variable Re: Linux World

[Larry Kilgallen]

In article <36DE53BC.1AE0@ddre.dk>, Hans Marqvardsen <hm@ddre.dk> writes:

> What really amazes me is that even though good people has spent good
> time
> designing a validation procedure where specific compilers are
> validated for specific operating systems, 
> then one of these good people claims that 
> 
> 1. this procedure may validate combinations that in his own words
> behave annoying and silly and undoubtedly would be rejected by the 
> marketplace.
> 
> 2. the validation process would seriously broken, if it were to 
> consider these problems.

I am not amazed in the least.  The purpose of validation should be to
address those issues that are not well handled by informal methods.
For the proposed example of a compiler that limited program size to
1 line, that would be quickly rejected by the first would-be customer
(and likely would not run the validation suite either, but I digress).

It would be a waste of money to formally validate that a compiler
handled something that users will quickly judge for themselves anyway,
such as whether the display of the "Ada Inside" logo was of the proper
size :-).

Larry Kilgallen

Re: Printing Enum Variable Re: Linux World

[dewar]

In article <36DE58B5.49B@ddre.dk>,
  hm@ddre.dk_nospam wrote:
> When Robert Dewar says so, I must accept that it is so.
> (But maybe the Ada-community would be better served if
> not)

I disagree, any attempt to prescribe the form of external
characters provided by the operating system would be hugely
messy and of no value to users of Ada.

Remember that if you want an Ada 95 compiler that "does
the right thing" in a PC environment for example, you are
actually asking for a non-standard non-conforming Ada
compiler which recognizes PC encodings rather than the
standard Latin-1 encodings.

Note that for most purposes, it does not matter at all
what the external relationships are (you put characters
into your program, and they come out "right"). There are
some exceptions, e.g. identifier encoding, which is why
GNAT provides specific (non-standard) localization options
for additional character sets:

 Latin-2
 Latin-3
 Latin-4
 IBM PC Code page 437 (typical US default)
 IBM PC Code page 850 (Latin-1 style)
 No Upper Half

and also supports multiple encodings for wide characters:

 Hex coding
 Upper-half coding
 Shift JIS
 EUC
 Brackets coding
 UTF-8 coding

If you have problems with code sets, most likely the
problem is one of operating system configuration, rather
than the compiler. The only obligation of a compiler are
the following:

  1) To accept sources with some reasonable representation
     of all required characters (there is NO requirement to
     accept Latin-1 ISO encoded sources, and you would not
     want their to be such a requirement, since it may make
     no sense in some environments, e.g. an IBM mainframe
     compiler can reasonably use extended EBCDIC for
     sources.

  2) To process internal string data according to Latin-1
     interpretation (means little most of the time, since
     these are just character codes, but has meaning in
     connection with the standard string handling packages)

  3) Similar requirements for wide characters

Now if you want to worry about how these characters will
*look* on some external medium, such as an OS window or
a printer, don't look to the compiler! It has no control
over the fonts you select, the printers you buy, the
operating systems options you select etc. If the wrong
characters are coming out, talk to your OS vendor, not
your compiler vendor (well of course the compiler vendor
may well be able to help with useful advice, certainly we
would, but the problem is not in the compiler and is
certainly not a validation issue). Any attempt to make
this a validation issue misunderstands what validation
is all about. Validation is about conformance, NOT about
usability in a given environment. Validation is just one
of many ways of evaluating a compiler for suitability to
a given task.

> Regarding similar common (mis?)conceptions, is it true
> that the current validation still allows a compiler
> to put arbitrary limits on compilable program size?
> (such as to disallow any program bigger than 1 character)
> or to take forever to compile?

Validation has never allowed this, what on earth would make
you think otherwise?

Read AI-325 for Ada 83, or Ada 95 RM

      6  Contain no variations except those explicitly
         permitted by this International Standard, or those
         that are impossible or impractical to avoid given
         the implementation's execution environment.

This has always been intepreted by the validation process
to mean that if a test is rejected for capacity arguments,
the capacity arguments must be pragmatically reasonable. I
cannot recall many instances where this was appealed to,
and certainly none when it was unreasonably appealed to
with examples of the kind you cite.

Robert Dewar
Ada Core Technologies


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[dewar]

In article <36DE53BC.1AE0@ddre.dk>,
  hm@ddre.dk_nospam wrote:
> robert_dewar@my-dejanews.com wrote:
> What really amazes me is that even though good people has
> spent good time designing a validation procedure where
> specific compilers are validated for specific operating
> systems, then one of these good people claims that
>
> 1. this procedure may validate combinations that in his
> own words behave annoying and silly and undoubtedly would
> be rejected by the marketplace.
>
> 2. the validation process would seriously broken, if it
> were to consider these problems.

If this amazes you, it is simply because you have
fundamental misunderstandings of what validation is
all about.

From one point of view it is amazing to *me* that people
still have these kinds of misconceptions, but on the other
hand we always have new people who have not been around,
and for whom we rerun old discussions :-) :-)

Validation has NOTHING to say about whether implementations
are usable. Remember that the first validation was of
Ada/Ed which was obviously unusable for anything even
vaguely serious (David, this was probably before your time,
but Ada/Ed was an executable specification that ran perhaps
6-7 decimal orders of magnitude slower than a production
compiler).

Validation merely measures one thing, whether your
implementation understands the semantic and syntactic
issues in the language definition, as tested reasonably
thoroughly, but of course not fully (no test is complete)
by the validation suite.

If you use a validated compiler, then you know the
implementors understand the language well, which is a good
thing, and you are perhaps less likely to find the kind
of bugs that involve two different compilers making subtly
different interpretations (e.g. a program that is legal
on one compiler and illegal on another). Note I say less
likely, not impossible!

Lots of people have lots of different ideas about what
make an Ada 95 compiler usable, here are some examples,
some from our customers, some from CLA:

  1) performance must be same as compiler xxx
  2) COM files must be buildable on NT :-)
  3) rep clauses recognized by compiler xxx must work
  4) garbage collection is required
  5) UTF-8 encoding for wide character is required
  6) 256 priority levels are required
  7) floating-point overflow checking is required
  8) full IEEE semantics for floating-point are required
  9) Latin-1 characters must come out "right" on my screen
 10) C++ interfacing must work
 11) -n32 mode must be supported on SGI
 12) loop unrolling must be controllable by a pragma
 13) tight packing is required for component size of 42
 14) clearer error msg is required for xxx
 15) every error msg should have an RM reference
 16) 64-bit integer support is required on all machines
 17) 64-bit integer support required with no run-time

OK, that's enough typing, I have to get back to work, I
could easily add another several hundred entries to the
list.

The point is that NONE of the above issues are even vaguely
validation issues.

Over time, people have kept making the mistake of assuming
that validation ensures usability. In real life it does not
even ensure 100% conformance, let alone usability. It is
generally the only objective test we have for conformance,
so it is common to at least consider it to be a test for
conformance, but to get confused with a test for usability
or marketability is a definite error!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Robert A Duff]

Samuel Mize <smize@imagin.net> writes:

> To say that a language provides the "enum" concept as a type, that
> language must ensure that a variable of that type will hold only those
> values, and it must provide the standard operations (like 'Last and
> 'First) for an enumeration.  If it doesn't do this for you, it doesn't
> support the type as an entity of the language.

Pascal does not provide anything like 'First and 'Last.
But I would still say that Pascal supports enumeration types.

> Or not, if you used a "when others" alternative to provide a default
> behavior.  This is less safe than explicitly listing all alternatives,
> but it can be a convenience, and it's safe if you're sure that the
> possible alternatives won't change (for instance, a case based on type
> type character).  You use this -- if you're savvy -- knowing that you
> have lost part of the protection that a case statement usually provides.

You don't have to be sure the set of alternatives won't change.  You
just have to be sure that "others" will still be correct when they *do*
change.  In other words, think of "when others =>" as meaning "all other
values, including the ones that somebody might add to the program in the
future", rather than, "all other values that exist in this program
today".

Also, type Character *does* change.  It changed from Ada 83 to Ada 95,
for example.  This broke some code I was porting to Ada 95, and I was
thankful that all of the problems were detected at compile time,
primarily because of the full-coverage rules for case statements.
Another case would be where you take some existing code that works
with Character, and change it to use Wide_Character.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Printing Enum Variable Re: Linux World

[Robert A Duff]

Samuel Mize <smize@imagin.net> writes:

> There's another point about C-style "enum"s not being a true type.
> IIRC, the compiler can't easily handle multiple "enum"s with the same
> identifier in them.  Is my recollection correct?

It seems unfair to blame that on enums specifically.  C doesn't have
overloading, so of course it doesn't have overloading of enums.

Interestingly, C++ has overloading, but not for enums.  C++ has a purely
bottom-up overloading resolution, whereas Ada has a two-pass,
bottom-up/top-down resolution, which allows information from above to
resolve enumeration type names (and parameterless functions, &c).
Similarly, Ada can use a single syntax for integer literals, because the
context can determine what type is desired.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Printing Enum Variable Re: Linux World

[David Botton]

The author, Hans Marqvardsen, you were responding to just happened to
mention my name, since he has an article on CONIO on my site. I wouldn't
get involved with a thread like this unless I was dragged in!

> (David, this was probably before your time,
> but Ada/Ed was an executable specification that ran perhaps
> 6-7 decimal orders of magnitude slower than a production
> compiler).

I am well aware of Ada/Ed :) I have been developing software
professionally for the last 14 years, although not always in Ada.

>   2) COM files must be buildable on NT :-)

Like I said, I got dragged in to this.

I only "feel" (I don't have proof, nor perspective on the market to
validate my "feelings") that this would be an important feature for
future customers of Ada compilers. It certainly has nothing to do with
compiler validation.

> The point is that NONE of the above issues are even vaguely
> validation issues.

Yup.

> Robert Dewar
Peace brother.

Re: Printing Enum Variable Re: Linux World

[Richard D Riehle]

In article <Pine.A41.3.96-heb-2.07.990304174949.28402A
100000@pluto.mscc.huji.ac.il>,
	Ehud Lamm <mslamm@mscc.huji.ac.il> wrote:

in reference to Ada enumeration types,

>Time and again I am amazed how this simple festure ofthe language stumps
>people. I see exercises which show understanding of important and
>difficult concepts like genericity - but fail to exploit enumeration type
>where appropriate. This should really end up on my idiom list. 

 Enumeration types also carry the potential for abuse.  I recall
 a programmer who had a package specification with an enumeration
 type where the set of values spanned three pages of source code.

 If enumeration types are to be on the idiom list, they should be 
 accompanied by a set of guidelines.  One of the problems we are 
 trying to solve with object-oriented programming and child library
 units is the extension of existing code without performing "open
 heart surgery" on it.  Heavy use of enumeration types can result in
 cracking open existing code to perform such extensions.

 Some of the guidelines I follow, and counsel my clients to follow,
 1) only use enumeration types when there is a well-known limit to the
 set of values.  2) Use them when there is a clear requirement for an
 ordered set, 3) Use them for identifying types that have a small
 set of values (e.g., Location is (Front, Back);).

 There is a point of view in the OOP community that says that enumeration
 types are an artifact of an obsolete style of programming.  That is,
 an enumeration type, because it is not extensible and cannot be
 further specialized, is antithetical to OOP.  Although I find this 
 viewpoint a little too narrow for my taste, one could make a very 
 good case to support it in many situations.

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com

Re: Printing Enum Variable Re: Linux World

[Ehud Lamm]

On Fri, 5 Mar 1999, Nick Roberts wrote:

> | There is a point of view in the OOP community that says that enumeration
> | types arean artifact of an obsolete style of programming.  That is,
> | an enumeration type, because it is not extensible and cannot be
> | further specialized, is antithetical to OOP.  Although I find this
> | viewpoint a little too narrow for my taste, one could make a very
> | good case to support it in many situations.

I am not sure I agree with this "OOP community" view. It may be useful to
note that in some sense all enumeration types are one type. The type of
data items can be seen as a generic parmater of this type (the type itself
supports things like succ and pred). Maybe this will help some one to see
that enumeration types should not be extened by adding values, but by
adding operations. This is possible with enumeration types in the smae way
in which it is possible for other types (like integer of tagged types). 

I am not sure this short explanation is enough to make my view clear...

> If you wanted to added a new state (blinking amber, say), you would have
> difficulty in two ways: firstly, you can't extend the enumerated type
> without performing 'open heart surgery' on the code; secondly, the question
> of whether traffic may pass may need to be qualified (by whether there is a
> pedestrian crossing the road), so that you can't just extend the array, you
> have to make some more extensive changes to the program's logic.  Now
> consider:
> 
>  type Traffic_Light_State isabstract tagged ...;
> 
>  function Traffic_May_Pass (State: in Traffic_Light_State) return Boolean
> is abstract;

This raises a different issue all together. When is it smart to model
using data structres, hiding the procedural nature of the problem, and
when should we model the procedural nature directly. Which abstraction
should we choose?

Let me make it concrete.

Consider generic menu procedure I posted. Now suppose we wanted to enhance
it so that the menu routine will call the appropriate handler according to
the user choice. We can do this in two ways:
1. Supply the menu routine with an array of pointers to procedures,
indexed by menu_choice. This allows us to simple call the apropriate
handler. We can make this array a generic parameter, or we can supply it
as a run time paramter. 

2. We can add a generic procedure paramter, which will accpet a
menu_chioce and decide what to do with it. This solution is usable in
Ada83 too. 

Which is better? It depends. The first choice has many advantages, but
lacks some flexibilty, which is quite eacy to achieve using the second
approach. I do not want to elaborate too much, since many might find the
obvious. Perhaps I'll summerize this example as a case-study some day.  
 (Other design choices exist, like making the menu a tagged type with
dispatching operations...)

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

> There is a point of view in the OOP community that says
> that enumeration types arean artifact of an obsolete
> style of programming.  That is, an enumeration type,
> because it is not extensible and cannot be further
> specialized, is antithetical to OOP.  Although I find
> this viewpoint a little too narrow for my taste, one
> could make a very good case to support it in many
> situations.

It is odd. Every few years, some new group of people
rediscover Church's thesis. They develop a new paradigm
and make the amazing discovery that they can manage to
program any computing problem using this paradigm. They
then conclude that one *ought* to use the paradigm 100%
of the time, some examples are:

  goto-free programming
  top down structured programming
  applicative/functional programming
  data flow programming
  integration of correctness proofs
  logic programming
  ...

and of course, most recently

  object oriented programming

It's really a very puzzling phenomenon. If you step back
and take a broader view, it is amazingly obvious that these
narrow viewpoints are just that, narrow, and that the far
more reasonable viewpoint is that we have a variety of
paradigms, and should use the one, or the mixture that is
appropriate to the problem at hand.

Yes, of course it is problematic to use an enumeration type
if one expects to make frequent changes to the set of
values in a manner that does not really correspond to the
abstraction in the first place. For example, it is a
definite mistake to try to model errno across targets as an
enumeration type, since the set of codes will change
frequently, and it is simply unhelpful to use an
enumeration type in this situation.

On the other hand, complaining about

  type day is (Sun, Mon, Tue, Wed, Thu, Fri, Sat);

on the grounds it does not allow for easy extension is
good only for inclusion in a set of bad jokes.

Extensible types and dynamic dispatching are certainly
useful techniques *some of the time*. If you get into a
way of thinking that ALL variant types and case statements
must be replaced with this approach, you will create a mess
for some problems where the case statements are more
appropriate.

This really is such obvious stuff that it should not need
saying, but I still find that we are beset by fanatics who
are singing the latest "do it my way, it is the only true
way" song!

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Ehud Lamm]

On Sat, 6 Mar 1999 robert_dewar@my-dejanews.com wrote:

> It is odd. Every few years, some new group of people
> rediscover Church's thesis. They develop a newparadigm
> and make the amazing discovery that they can manage to
> program any computing problem using this paradigm. They
> then conclude that one *ought* to use the paradigm 100%
> of the time, some examples are:
> 
> goto-free programming
> top down structured programming
> applicative/functional programming
> data flow programming
> integration of correctness proofs
> logic programming
> ...
> 
> and of course, most recently
> 
> object oriented programming
> 

one of the first things I tell my students is that Ada is a
multi-paradigm language. It supports most of the above (though logic
programming is not there, and it is not really a functional language). I
also add that know which paradigm to use, and when is it smart to combine
them - is one of the hard parts!

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

Re: Printing Enum Variable Re: Linux World

[Larry Kilgallen]

In article <7brec4$ti2$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com writes:

> It is odd. Every few years, some new group of people
> rediscover Church's thesis. They develop a new paradigm
> and make the amazing discovery that they can manage to
> program any computing problem using this paradigm. They
> then conclude that one *ought* to use the paradigm 100%
> of the time,

I have recently discovered that any program can be written
in machine language.  Please advise me what newsgroups I
should include along with comp.lang.ada when crossposting
my new advocacy thread :-).

Larry Kilgallen

Re: Printing Enum Variable Re: Linux World

[Dave Taylor]

Larry Kilgallen wrote:
> 
> In article <7brec4$ti2$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com writes:
> 
> > It is odd. Every few years, some new group of people
> > rediscover Church's thesis. They develop a new paradigm
> > and make the amazing discovery that they can manage to
> > program any computing problem using this paradigm. They
> > then conclude that one *ought* to use the paradigm 100%
> > of the time,
> 
> I have recently discovered that any program can be written
> in machine language.  Please advise me what newsgroups I
> should include along with comp.lang.ada when crossposting
> my new advocacy thread :-).
> 
> Larry Kilgallen
I've worked for some managers that believed that any problem 
could be solved using Powerpoint.

Dave

Re: Printing Enum Variable Re: Linux World

[Bruce or Tracy]

Hehehehe!!

Bruce

Dave Taylor wrote:
> 
> Larry Kilgallen wrote:
> >
> > In article <7brec4$ti2$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com writes:
> >
> > > It is odd. Every few years, some new group of people
> > > rediscover Church's thesis. They develop a new paradigm
> > > and make the amazing discovery that they can manage to
> > > program any computing problem using this paradigm. They
> > > then conclude that one *ought* to use the paradigm 100%
> > > of the time,
> >
> > I have recently discovered that any program can be written
> > in machine language.  Please advise me what newsgroups I
> > should include along with comp.lang.ada when crossposting
> > my new advocacy thread :-).
> >
> > Larry Kilgallen
> I've worked for some managers that believed that any problem
> could be solved using Powerpoint.
> 
> Dave

Re: Printing Enum Variable Re: Linux World

[Florian Weimer]

Samuel Mize <smize@imagin.net> writes:

>   /* one of these must be right, the other wrong */
>   SetWindow (W1, color, attribs);
>   SetWindow (W1, attribs, color);

This reminds me of another C problem which is related to some point.
For example, there once was a function called ReleaseDC(HWND hwnd,
HDC hdc) on Microsoft Windows (don't know if still exists), which had
to be called to release one of the five system-wide per-window drawing
contexts.  Of course, the `types' HWND and HDC were defined like this:

typedef unsigned int HWND;
typedef unsigned int HDC;

Nothing prevented you from calling ReleaseDC(hdc, hwnd), thus not
releasing the drawing context.  This was especially annoying during
software development---the machine froze if no more drawing contexts
where available.  But I've seen software which had this drawing context
leak and was delivered, too.

In the final days of Win16, Microsoft used the following trick to make
HWND and HDC (and the other handle types) distinct types:

struct tagHWND { int dummy; };
struct tagHDC { int dummy; };

typedef struct tagHWND *HWND;
typedef struct tagHDC *HDC;

Of course, this extremely ugly and platform dependent, but in fact,
it's quite helpful if you are programming with C (and not Ada ;).
AFAIK it is still used with Win32.

Re: Printing Enum Variable Re: Linux World

[Michael Young]

There are many good things to be said about strong typing. I fail to see
your point, however, in comparing type safety in C to that in Ada. A
more appropriate comparison would be Ada to C++. In your (narrow)
example, the differences in implementation would be next to
indistinguishable. It's also worth noting that C++ destructors formalize
resource deallocation, addressing the resource leak issue very
effectively. (I never did understand dewar's strong admonition to avoid
using finalize for performance reasons. I'd love to hear a capsule
summary if that's possible.)

While I'm not especially fond of the old SDK, its structure looks
surprisingly like object use in Ada today. Instead of the more succinct
C++/Java style aWindow.GetDC(), we see GetDC(aWindow).

Anyway, I'm not sure which you were bashing: C in its infancy, or the
old SDK. Both were laudable in their days. I expect I might say the same
of Ada95 in some not so distant future.

Michael.


Florian Weimer <fw@cygnus.stuttgart.netsurf.de> wrote in message
news:m3k8wufayz.fsf@deneb.cygnus.stuttgart.netsurf.de...
> Samuel Mize <smize@imagin.net> writes:
>
> >   /* one of these must be right, the other wrong */
> >   SetWindow (W1, color, attribs);
> >   SetWindow (W1, attribs, color);
>
> This reminds me of another C problem which is related to some point.
> For example, there once was a function called ReleaseDC(HWND hwnd,
> HDC hdc) on Microsoft Windows (don't know if still exists), which had
> to be called to release one of the five system-wide per-window drawing
> contexts.  Of course, the `types' HWND and HDC were defined like this:
>
> typedef unsigned int HWND;
> typedef unsigned int HDC;
>
> Nothing prevented you from calling ReleaseDC(hdc, hwnd), thus not
> releasing the drawing context.  This was especially annoying during
> software development---the machine froze if no more drawing contexts
> where available.  But I've seen software which had this drawing
context
> leak and was delivered, too.
>
> In the final days of Win16, Microsoft used the following trick to make
> HWND and HDC (and the other handle types) distinct types:
>
> struct tagHWND { int dummy; };
> struct tagHDC { int dummy; };
>
> typedef struct tagHWND *HWND;
> typedef struct tagHDC *HDC;
>
> Of course, this extremely ugly and platform dependent, but in fact,
> it's quite helpful if you are programming with C (and not Ada ;).
> AFAIK it is still used with Win32.

Re: Printing Enum Variable Re: Linux World

[Larry Kilgallen]

In article <7btj81$j0d$1@remarQ.com>, "Michael Young" <nobody@all.org> writes:
> There are many good things to be said about strong typing. I fail to see
> your point, however, in comparing type safety in C to that in Ada. A
> more appropriate comparison would be Ada to C++.

I believe Ada folk draw comparison to the languages in which people
end up programming, rather than what it says on the compiler box.
While those participating in this forum may be atypical, there is
a belief that most of those with a C++ compiler are programming in
C.  In that sense, this backward compatibility may be the greatest
technical weakness of C++, as well as its greatest marketing strength
(selling lots of licenses to people who don't really use the features).

> While I'm not especially fond of the old SDK, its structure looks
> surprisingly like object use in Ada today. Instead of the more succinct
> C++/Java style aWindow.GetDC(), we see GetDC(aWindow).

I am not sure how one views the first as more succinct, but my own
feelings are more swayed by type-safety than syntax.

> Anyway, I'm not sure which you were bashing: C in its infancy, or the
> old SDK. Both were laudable in their days. I expect I might say the same
> of Ada95 in some not so distant future.

If you think the days of that SDK are over, I think you are quite
mistaken.  The "latest released" is not at all equivalent to "what
people use".

Larry Kilgallen

Re: Printing Enum Variable Re: Linux World

[Matthew Heaney]

"Michael Young" <nobody@all.org> writes:

> It's also worth noting that C++ destructors formalize resource
> deallocation, addressing the resource leak issue very effectively.

It is the same for finalization of a Controlled type in Ada95.  

> While I'm not especially fond of the old SDK, its structure looks
> surprisingly like object use in Ada today. Instead of the more succinct
> C++/Java style aWindow.GetDC(), we see GetDC(aWindow).

This isn't a very convincing argument, since the C++/Java version
requires one more token than the Ada version.

The advantage of the Ada syntax is that binary operations are
symmetrical.  You don't want to have a distinguished receiver, because
there isn't one -- there are two.  Indeed, there may be more.

The other benefit of the Ada way is that the syntax for manipulation of
user-defined types is consistent.  You don't want to have Yet Another
Notation just because the type happens to be tagged.

  Push (Item, On => Stack);

Is stack a tagged type or not?  I don't know -- but that's the point.

Re: Printing Enum Variable Re: Linux World

[Michael Young]

Larry Kilgallen <kilgallen@eisner.decus.org> wrote in message
news:1999Mar7.074102.1@eisner...
> While those participating in this forum may be atypical, there is
> a belief that most of those with a C++ compiler are programming in
> C.  In that sense, this backward compatibility may be the greatest
> technical weakness of C++, as well as its greatest marketing strength
> (selling lots of licenses to people who don't really use the
features).

I agree wholeheartedly that C encourages certain poor programming
practices. However, Ada is not the only solution to these problem. I
hear in your postings: "Ada is better than C; C++ supports features and
practices we recognize as evil in C; therefore, C++ is bad. OTOH, Ada
rejects all of C; therefore Ada is good." That's pretty convoluted,
don't you think?

Ada can stand on its own merits, as any successful language must. To
hear your strong denials says otherwise, so I must be wasting my time
and effort here. After all, C++ already does everything I need and want
from a language (well, almost everything), in a way that I am more than
happy and comfortable with. What do I need with another "better C than
C"?

> > While I'm not especially fond of the old SDK, its structure looks
> > surprisingly like object use in Ada today. Instead of the more
succinct
> > C++/Java style aWindow.GetDC(), we see GetDC(aWindow).
>
> I am not sure how one views the first as more succinct, but my own
> feelings are more swayed by type-safety than syntax.

I was pointing out that the SDK exposed an object structured interface,
implemented in C, well before object oriented languages were seen
outside academia. I only meant to say that, because of the similarity in
syntax, this should have been more evident to Ada programmers than to
C++ or Java programmers. With that in mind, I found it especially odd to
see it bashed (along with everything not implemented in Ada).

> > Anyway, I'm not sure which you were bashing: C in its infancy, or
the
> > old SDK. Both were laudable in their days. I expect I might say the
same
> > of Ada95 in some not so distant future.
>
> If you think the days of that SDK are over, I think you are quite
> mistaken.  The "latest released" is not at all equivalent to "what
> people use".

There's a certain amount of baggage associated with backward
compatibility. Perhaps some day, Ada will reach a point of maturity
where this becomes a concern.

Also, I didn't mean to convey that the SDK has changed dramatically. It
hasn't. Most interaction in new code, though, is made through the MFC
(Microsoft's "thick binding" for the SDK).

In very large systems, interface stability is a primary requirement, not
merely an inconvenient liability. Many here are quick to point out that
"large systems" are the rightful domain of Ada. I therefore expected to
find in this crowd some understanding of the legacy issues involved. As
before with the SDK "object" syntax, I found the bashing unwarranted and
misguided.

Anyway, I came here to learn more about Ada, not to preach about large
system development. I'll refrain from further postings of this nature,
and hope you'll likewise use restraint in speculating about the
weaknesses of C++; I presume I already know more about those than you.

Michael.

Re: Printing Enum Variable Re: Linux World

[Hans Marqvardsen]

dewar@gnat.com wrote:
> Note that for most purposes, it does not matter at all
> what the external relationships are (you put characters
> into your program, and they come out "right").

However, the programmer (and the maintainer of his program) must
remember that they may get strange results,

if they ever compare strings except for equality 

or if they ever use the otherwise nice 
classification functions of Ada.Characters.Handling,  
Is_Control, Is_Graphic, Is_Letter, Is_Lower, Is_Upper,

or conversion functions:
To_Lower, To_Upper, To_Basic.

In conclusion: 
this is really a poor mans way of dealing with the full
character set.

> If the wrong
> characters are coming out, talk to your OS vendor, not
> your compiler vendor

There are in fact these two approaches:

a) Make the OS do the right thing
b) Give your program a suitable interface to the OS at hand

OF COURSE, in theory option a is preferable, but in practice
this approach can be difficult.

In Windows NT one can use the OS-supplied procedures
SetConsoleCP and SetConsoleOutputCP to use the proper codepage.
However one still has to select a non-default font, Lucida console,
manually at execution. 

Under Windows 95, it just cant be done, IMHO.

Option b may look more messy, but it works better IMHO.

The desired interface, such as Console_Io, can be constructed from the
OS-supplied procedures  CharToOemA and OemToCharA. 
No need to select any non-default font.
Works for W95 and NT alike.

Hence in practice option b is preferable, maybe the only possible.

Re: Printing Enum Variable Re: Linux World

[Michael Young]

Matthew Heaney <matthew_heaney@acm.org> wrote in message
news:m33e3gzw5n.fsf@mheaney.ni.net...
> > C++/Java style aWindow.GetDC(), we see GetDC(aWindow).
>
> This isn't a very convincing argument, since the C++/Java version
> requires one more token than the Ada version.
>
> The advantage of the Ada syntax is that binary operations are
> symmetrical.  You don't want to have a distinguished receiver, because
> there isn't one -- there are two.  Indeed, there may be more.

Please explain the part about symmetry and two or more receivers. Do you
mean something like:
"Joe, meet Jane. Jane, meet Joe."
  versus
"Meet(Joe, Jane)"

There are advantages and disadvantages to both, depending on the use and
situation. I can think of one language that supports both notations
equally, and it's not Ada.

I might be missing a whole bunch, but none of this seems really
earth-shattering in terms of expressing a design.

> The other benefit of the Ada way is that the syntax for manipulation
of
> user-defined types is consistent.  You don't want to have Yet Another
> Notation just because the type happens to be tagged.
>
>   Push (Item, On => Stack);
>
> Is stack a tagged type or not?  I don't know -- but that's the point.

Yes, I see your point regarding notations, but what exactly does that
mean? aStack.Push(aNumber) seems quite clear. In the other language, the
meaning is also the same, regardless if the type is tagged or not, or
whether the operation is dispatched or statically bound. These details
are necessarily private to the receiver's implementation (from a human
reader's point of view, that is). Ada is not the only, or even the
first, language to respect this privacy.

Could you be alluding to: aNumber.PushOnto(aStack)?

One has to ask why Number needs to be aware of Stack at all. In terms of
reader-friendliness, symmetry in notation seems more a liability than an
asset when symmetry does not truly exist. In fact, few useful examples
come to mind for symmetry in object designs. A uses B, but B is
oblivious to A.

Michael.

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

In article <7bva62$kgm$1@remarQ.com>,
  "Michael Young" <nobody@all.org> wrote:
> I agree wholeheartedly that C encourages certain poor
> programming practices. However, Ada is not the only
> solution to these problem. I hear in your postings: "Ada
> is better than C; C++ supports features and practices we
> recognize as evil in C; therefore, C++ is bad. OTOH, Ada
> rejects all of C; therefore Ada is good." That's pretty
> convoluted, don't you think?

Indeed that is a convoluted argument, and that is probably
why no one has made such a silly argument, or taken such
a silly position.

In fact Ada fully allows a low-level form of expression
corresponding to C. Indeed in some respects it goes much
further than C (bit packed arrays, full control over data
representation, full address arithmetic, ...) Sure Ada
tends to discourage casual use of such features by making
them explicit in the program, but it is hard to argue
against that choice if your aim is to make programs
readable and maintainable.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Larry Kilgallen]

In article <7bva62$kgm$1@remarQ.com>, "Michael Young" <nobody@all.org> writes:
> Larry Kilgallen <kilgallen@eisner.decus.org> wrote in message
> news:1999Mar7.074102.1@eisner...
>> While those participating in this forum may be atypical, there is
>> a belief that most of those with a C++ compiler are programming in
>> C.  In that sense, this backward compatibility may be the greatest
>> technical weakness of C++, as well as its greatest marketing strength
>> (selling lots of licenses to people who don't really use the
> features).
> 
> I agree wholeheartedly that C encourages certain poor programming
> practices. However, Ada is not the only solution to these problem. I
> hear in your postings: "Ada is better than C; C++ supports features and
> practices we recognize as evil in C; therefore, C++ is bad. OTOH, Ada
> rejects all of C; therefore Ada is good." That's pretty convoluted,
> don't you think?

I did not mean to say (and I don't believe I ever said) that Ada was
the only solution to anything.  I believe the fact that C++ supports
the operations of C is a weakness.  I view the fact that some Ada
compilers support the operations of assembly language is a weakness*.

>> > While I'm not especially fond of the old SDK, its structure looks
>> > surprisingly like object use in Ada today. Instead of the more
> succinct
>> > C++/Java style aWindow.GetDC(), we see GetDC(aWindow).
>>
>> I am not sure how one views the first as more succinct, but my own
>> feelings are more swayed by type-safety than syntax.
> 
> I was pointing out that the SDK exposed an object structured interface,
> implemented in C, well before object oriented languages were seen
> outside academia. I only meant to say that, because of the similarity in
> syntax, this should have been more evident to Ada programmers than to
> C++ or Java programmers. With that in mind, I found it especially odd to
> see it bashed (along with everything not implemented in Ada).

Certainly the Windows SDK presents an object-oriented model to the caller,
but I am much more interested in type safety than object orientation, so
I was not impressed when I first saw the Windows SDK.

> In very large systems, interface stability is a primary requirement, not
> merely an inconvenient liability. Many here are quick to point out that
> "large systems" are the rightful domain of Ada. I therefore expected to
> find in this crowd some understanding of the legacy issues involved. As
> before with the SDK "object" syntax, I found the bashing unwarranted and
> misguided.

The fact that the Windows SDK is a given cannot be contested.  That
does not make it pleasing, and the fact that it seemed just a "pretend"
effort at object orientation makes it less pleasing.  By comparison,
I think the X-Windows/Motif and the Macintosh GUI APIs are both more
regular than the one for Windows.

> Anyway, I came here to learn more about Ada, not to preach about large
> system development. I'll refrain from further postings of this nature,
> and hope you'll likewise use restraint in speculating about the
> weaknesses of C++; I presume I already know more about those than you.

We appreciate your participation, and for a C/Windows expert I think
an instructive place to look (if you have not already) would be the
Ada bindings to the Windows SDK.  The one that is used by the Aonix
GUI builder (I get the names confused), for instance, gives a good
look at what people had to go through in Ada to get a set of bindings
to the Windows API, and it seems to be hampered by an excessive number
of slightly different types due to irregularities in the basic Microsoft
definitions.  Certainly it is also hampered by being a machine-generated
set of bindings, but that is supposedly a self-defense mechanism to be able
to adapt to Microsoft changes.

But perhaps from your perspective something else is amiss in the way
those bindings were constructed.

Larry Kilgallen

* Ada compiler support for assembly language is somewhat ameliorated
  by the facts that:
      a) nobody would ever presume such usage was portable,
  and:
      b) recent posts have shown that real beginners have a
         tough time figuring out how to get it working.

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

In article <1999Mar8.075013.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:
> I view the fact that some Ada compilers support the
> operations of assembly language is a weakness*.

What a bizarre statement! The Ada 95 standard requires
such support, any compiler that does not provide this
support is not implementing the Systems Programming
Annex, and is lacking a feature that is often of
crucial importance.

Larry's analogy with C support in C++ is a false one.

The trouble in C++ is that some of the fundamental notions
are borrowed from C, and are at too low a level, and more
over, it is far too easy, ESPECIALLY for C programmers, to
slip into low level dictions in the middle of high level
C++ code.

In the case of machine insertions in Ada, a context clause
is required, and the syntax is very clear (almost
obtrusively so, quite deliberately). So it is not something
you "slip into" using at all.

On the other hand, it is quite a crucial feature in some
Ada 95 programs. I guess Larry works in an environment
(Ada 83 on Vaxes???) where this feature is not important,
but that seems odd justification for complaining about the
inclusion of this important feature.

Yes, it is tricky to use, but that's appropriate, it is
only intended to be used in very limited circumstances by
people who know exactly what they are doing!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Matthew Heaney]

"Michael Young" <nobody@all.org> writes:

> > The advantage of the Ada syntax is that binary operations are
> > symmetrical.  You don't want to have a distinguished receiver, because
> > there isn't one -- there are two.  Indeed, there may be more.
> 
> Please explain the part about symmetry and two or more receivers. Do you
> mean something like:
> "Joe, meet Jane. Jane, meet Joe."
>   versus
> "Meet(Joe, Jane)"

That more or less captures it. 

The most obvious example is a test for equality:

  procedure Op (O1, O2 : T'Class) is
  begin
     if O1 = O2 then ...;


Equality is a binary operation, and dispatches on the tag of O1 and O2.
This is a lot nicer on the eyes than

  if O1.Equal (O2) then ...;


> I might be missing a whole bunch, but none of this seems really
> earth-shattering in terms of expressing a design.

Ada95 is a revision of Ada83.  There was an existing syntax and mind-set
for Ada83 that the designers of Ada95 wanted to preserve.

The C++ approach of adding an object-oriented "corner" to the language,
with a different syntax from other parts of the language, is exactly the
way they _didn't_ want to go.

 
> > The other benefit of the Ada way is that the syntax for manipulation
> of
> > user-defined types is consistent.  You don't want to have Yet Another
> > Notation just because the type happens to be tagged.
> >
> >   Push (Item, On => Stack);
> >
> > Is stack a tagged type or not?  I don't know -- but that's the point.
> 
> Yes, I see your point regarding notations, but what exactly does that
> mean? 

It was intended as an example of what I alluded to above.  There was an
existing syntax for manipulation of user-defined types, and the
designers wanted to preserve this.

> Could you be alluding to: aNumber.PushOnto(aStack)?

No.  Push is a primitive operation of Stack_Type.  It is not a binary
operation.


> One has to ask why Number needs to be aware of Stack at all. 

No, it doesn't.  I think I have only confused you.  (Sorry.)


> In terms of reader-friendliness, symmetry in notation seems more a
> liability than an asset when symmetry does not truly exist. In fact,
> few useful examples come to mind for symmetry in object designs. A
> uses B, but B is oblivious to A.

Push is not a symmetrical operation, and wasn't intended as an example
of one.  "Symmetrical operations" just means that

  A op B 

and 

  B op A 

have the same meaning.  Just like

  Meet (Joe, Jane);

means the same as

  Meet (Jane, Joe);

or

  Marry (Joe, Jane);

means the same as

  Marry (Jane, Joe);

Meet and Marry are operations that apply to two objects, and both
objects have equal importance as far as the operation is concerned.

Saying

  Joe.Marry (Jane);

is misleading.

Re: Printing Enum Variable Re: Linux World

[Florian Weimer]

"Michael Young" <nobody@all.org> writes:

> In very large systems, interface stability is a primary requirement, not
> merely an inconvenient liability. Many here are quick to point out that
> "large systems" are the rightful domain of Ada. I therefore expected to
> find in this crowd some understanding of the legacy issues involved. As
> before with the SDK "object" syntax, I found the bashing unwarranted and
> misguided.

Sorry, I didn't intend to bash anything.  I only wanted to show that
C lacks distinct types for integers (with no default conversion among
them) and that ugly (but practical) hacks are used to imitate them.
The Windows SDK was just an example.  (If I wanted to bash it, I'd write
about things like CreateProcess(), which should be more convincing. <g>)

Re: Printing Enum Variable Re: Linux World

[Richard D Riehle]

In article <7c0knr$v5$1@nnrp1.dejanews.com>,
	robert_dewar@my-dejanews.com wrote:

>In fact Ada fully allows a low-level form of expression
>corresponding to C...

 As a follow-on to Robert's comment, and for the benefit of the
 Mr. Young, who indicated an interest in learning more about Ada, a
 key idea in Ada is to make all possible expressions possible, but
 to start with the default level of "safe."  That is, strong typing,
 separation of scope and visibility, and strict accessibility rules
 for access and tagged types, are the default in Ada.  

 It has often been noted that one principal upon which Ada is 
 founded is to  have a language design for which one can write 
 a compiler that catches the maximum number of errors before we 
 ever see an executable program.  

 One may start with a language in which the default is "safe" and relax
 the rules to make it less safe.  For example, use clauses, unchecked
 operations, and other built-in features of Ada relax the safety 
 default.  It is more difficult to start with a language where the
 default is "unsafe" and make it more safe.  This is a built-in
 problem for the C family of languages.  That is, every language
 built on top of C has the problem of starting with a model in which
 the default is "unsafe."  With C++ we can define class modules that
 improve the safety of a design, but the characteristics of the 
 foundation language are still there. The C foundation makes it 
 all too easy to revert back to unsafe practices.  If it were rare 
 among programmers to revert back to unsafe practices, many of the 
 complaints about C++ would be moot.  Sadly, the retro-C practices
 are not rare. It just too convenient to code the way we did in C.  

 Java, a member of the C family of languages, has taken the approach
 of deleting certain capabilities of C and C++.  For pointers, Java
 has adopted a model which closely resembles Ada access types.  Even
 so, Java syntax is still reminiscent of C.  A Java programmer can
 still make some of the same coding errors that occur in C programs.

 In the end, it is not a matter of whether we can code the same thing
 in one language that we can code in another.  It is a matter of how
 that same thing is expressed. It is not a matter of which syntax is
 more "natural"; not a matter of whether we do or do not have 
 "distinguished receivers"; not a matter of how easy it is to code
 a particular set of ideas.  Expressibility, in Ada, is a matter of 
 creating reliable, maintainable applications in which human life 
 and safety are at risk.  For large, safety-critical software,
 whether that expressibility consistently represents (even demands) 
 a model for reliability, dependability and safety.  This defines the 
 charter for Ada.  
 
 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com
 
             Of course, the notion of safety-critical becomes
             also becomes moot when developing for one of 
             the non-safe operating systems that are being 
             selected for so many of our military applications.

 

Re: Printing Enum Variable Re: Linux World

[Michael Young]

Richard D Riehle <laoXhai@ix.netcom.com> wrote in message
news:7c1833$2n@sjx-ixn6.ix.netcom.com...
>  In the end, it is not a matter of whether we can code the same thing
>  in one language that we can code in another.  It is a matter of how
>  that same thing is expressed. It is not a matter of which syntax is
>  more "natural"; not a matter of whether we do or do not have
>  "distinguished receivers"; not a matter of how easy it is to code
>  a particular set of ideas.  Expressibility, in Ada, is a matter of
>  creating reliable, maintainable applications in which human life
>  and safety are at risk.  For large, safety-critical software,
>  whether that expressibility consistently represents (even demands)
>  a model for reliability, dependability and safety.  This defines the
>  charter for Ada.

How does Ada accomplish this? What is the language's role in ensuring
correctness?

I know from personal experience that correct modules can be built regardless
of language. Is it simply that Ada (also) provides mechanisms to facilitate
safe usage? Or does it go farther, and provide *better* mechanisms to prevent
unsafe usage? What might those be? What level of safety or expression are we
discussing? Pointer arithmetic appears to not be on your mind when you wrote
this.

With C's evils aside, I would guess the single largest problem for
inexperienced C++ programmers is understanding the lifetime of objects,
particularly temporaries used in implicit type conversions. However, the rules
for instantiation and destruction are very simple, and are easily expressed in
short, understandable sentences. Further, there are simple mechanisms to
prevent implicit construction of types where this is not appropriate. The
reason they exist, in spite of the acknowledged problems, is they are useful
in expressing the design intent (bringing this discussion back on track). They
are problems for inexperienced programmers, but extremely powerful when used
appropriately.

I can see that requiring explicit conversion is useful and helpful (I
personally abhor the loss). Is this all that is meant, or is there more to
Ada's strengths?

Michael.

Re: Printing Enum Variable Re: Linux World

[Larry Kilgallen]

In article <7c3lft$t10$1@remarQ.com>, "Michael Young" <nobody@all.org> writes:
> Richard D Riehle <laoXhai@ix.netcom.com> wrote in message
> news:7c1833$2n@sjx-ixn6.ix.netcom.com...
>>  In the end, it is not a matter of whether we can code the same thing
>>  in one language that we can code in another.  It is a matter of how
>>  that same thing is expressed. It is not a matter of which syntax is
>>  more "natural"; not a matter of whether we do or do not have
>>  "distinguished receivers"; not a matter of how easy it is to code
>>  a particular set of ideas.  Expressibility, in Ada, is a matter of
>>  creating reliable, maintainable applications in which human life
>>  and safety are at risk.  For large, safety-critical software,
>>  whether that expressibility consistently represents (even demands)
>>  a model for reliability, dependability and safety.  This defines the
>>  charter for Ada.
> 
> How does Ada accomplish this? What is the language's role in ensuring
> correctness?

The role of the language is that those concerns permeate the design
of the language.  For instance, the enumerated types discussed earlier
allow me to create a variable of type Traffic_Light_Color, knowing that
the only values that can be assigned to it are Red, Yellow and Green.
Furthermore, I know it cannot mistakenly get intermixed with values
for a coworker's type Political_Orientation which has values Red
and Freedom_Loving_Capitalist.

That general idea is available in Pascal and other languages, but
Ada takes it a bit further and allows me to iterate from the start
(Traffic_Light_Color'first) to the end (Traffic_Light_Color'last)
without specifically naming the values and thus making me immune
to someone tacking on a new value at the end (or the beginning).
You can readily come up with an example where one would _not_
want to use those capabilities, but in my experience I want them
more often than not.  When the answer is "not", I don't use them.

And if it was not obvious, I have to really go out of my way to
assign the value "7" to one of those variables. If that really
is a valid traffic light color in Elbonia, then good programmers
will enhance the original declaration to make "Seven" the fourth
possiblity, thus letting the type system enforce the interface
to the outside world.

That is just a small part of the language which has safety
elements built in.  Ada is not unique in all its elements,
but it is rather thorough in safety features.

> With C's evils aside, I would guess the single largest problem for
> inexperienced C++ programmers is understanding the lifetime of objects,
> particularly temporaries used in implicit type conversions. However, the rules
> for instantiation and destruction are very simple, and are easily expressed in
> short, understandable sentences. Further, there are simple mechanisms to
> prevent implicit construction of types where this is not appropriate. The
> reason they exist, in spite of the acknowledged problems, is they are useful
> in expressing the design intent (bringing this discussion back on track). They
> are problems for inexperienced programmers, but extremely powerful when used
> appropriately.

In general, Ada tends toward compilation errors for those who have not
understood the rules.  That includes experts who have temporarily forgot
while working on something Important, as well as students whose first
reaction is to try it themselves rather than asking for their homework
answers on comp.lang.ada. :-)

Larry Kilgallen

Re: Printing Enum Variable Re: Linux World

[billy]

I think Ada is a wonderfull language also. However in the commerical world,
when I tell my boss that I'd like to write something in Ada, they refuse,
they want me to use C or Perl or Java or C++.

Even co-workers, who are all C-type programmers (sorry, no offense intended),
look funny at me when I suggest we try Ada. I tried one time to argue
technical detailes with a supervisor about the language and to compare
it to C, but he was not interested to even listen.

So, I am sitting here debugging C code where I would be much happier (and also
more productive) using Ada, but I need to pay the rent as they say.

Billy

Re: Printing Enum Variable Re: Linux World

[Michael Young]

Larry Kilgallen <kilgallen@eisner.decus.org> wrote in message
news:1999Mar9.131659.1@eisner...

> The role of the language is that those concerns permeate the design
> of the language.  For instance, the enumerated types discussed earlier
> allow me to create a variable of type Traffic_Light_Color, knowing that
> the only values that can be assigned to it are Red, Yellow and Green.
> Furthermore, I know it cannot mistakenly get intermixed with values
> for a coworker's type Political_Orientation which has values Red
> and Freedom_Loving_Capitalist.

I view these as design issues, not really coding problems. Who wants to know
what color the traffic light is, and why? My first guess is that a state
machine is a more appropriate abstraction. Likewise for your co-workers'
political views: these might be better captured as polymorphic behaviors. With
that said, there is no getting around the neutral nature of storage media.
From now until some enlightened future, these attributes will likely be stored
as coded numeric values in databases. This will always be a weak link, since
somebody outside the development staff can change the coding to your
detriment. I can do no more than check for a valid range -- isolated in the
factory implementation -- which need not be hard-coded as a distinct type. Ada
has the minor advantage of not having to manually check for the expected
range.

> That general idea is available in Pascal and other languages, but
> Ada takes it a bit further and allows me to iterate from the start
> (Traffic_Light_Color'first) to the end (Traffic_Light_Color'last)
> without specifically naming the values and thus making me immune

See above. Maybe for a lack of iteration, I don't find a need for iteration. I
find types with behaviors to be more appropriate than enumerations in more
cases than not.

> In general, Ada tends toward compilation errors for those who have not
> understood the rules.  That includes experts who have temporarily forgot
> while working on something Important, as well as students whose first
> reaction is to try it themselves rather than asking for their homework
> answers on comp.lang.ada. :-)

Aye. Compared to the untrained Java multitudes, C++ benefits from requiring
more upfront knowledge and experience. Ada tops even C++ in this regard. As an
pre-employment filter, this is not altogether a bad thing.

Michael.

Re: Printing Enum Variable Re: Linux World

[fraser]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

paene lacrimavi postquam "Pascal Obry" <p.obry@der.edf.fr> scribavit:

>billy@no_spam_please a �crit dans le message <7c4dr6$dmc@drn.newsguy.com>...

>>I think Ada is a wonderfull language also. However in the commerical world,
>>when I tell my boss that I'd like to write something in Ada, they refuse,
>>they want me to use C or Perl or Java or C++.

[ ... ]

>Just because I don't want you to feel alone.

>I had the very same problem during 6 years.

Same here.  What I do is use Ada on any stand-alone project that I can.
It's not much, and it's not using the language to its full potential,
but it's all I have at the moment.  Sigh.

On the bright side, an Ada program I wrote for my last company is still
chugging away (it was a database specification compiler, and I just
*happened* to have a bunch of compiler writing Ada components on hand).
At least, they haven't taken advantage of my "Free Support for One Year"
offer yet.

cheers,
Fraser.

Re: Printing Enum Variable Re: Linux World

[fraser]

paene lacrimavi postquam "Michael Young" <nobody@all.org> scribavit

>Aye. Compared to the untrained Java multitudes, C++ benefits from requiring
>more upfront knowledge and experience. Ada tops even C++ in this regard. As an
>pre-employment filter, this is not altogether a bad thing.

I don't understand this ... what metric are you using?  I would have
thought that Ada is a much easier language to dip into, because it
has better support for abstractions, the compiler is more likely
to tell you if you screw up, you don't need to use pointer arithmetic,
it's harder to trash your stack, and the reference manual is smaller.

Actually, I can understand it from the POV that the Great Unwashed (tm)
are more likely to have grabbed the most recent language du jour,
whereas if somebody knows Ada, they probably have some experience.
And if they like Ada, they've obviously got excellent taste :)

Real Life Story: I put a parenthesis in the wrong place, and ended
up trying to index a string with a character.  Using Ada saved me
(at least) a whole debug cycle.  This happens all the time.

Fraser.
(change 'i' to 'y' in sinopsis for my real email address)

Re: Printing Enum Variable Re: Linux World

[dennison]

In article <7c6hm5$eim$1@its.hooked.net>,
  "Mike Silva" <mjsilva@jps.net> wrote:
>
> bob wrote in message <7c6c6b$miv@drn.newsguy.com>...
> >In article <7c63lf$qg2$1@nnrp1.dejanews.com>, dennison@telepath.com says...
> >
> >This is a brilliant idea!
> >
> >"Ada, the family oriented language"
> >"Ada, loving families grow on it".
> >"Ada, the only language to give you enough time to spend with your spouse"
> >"Ada, keeps families togother."
> >"Ada, don't get married without it."
> >"Ada, at home and at work".
>
> And of course "Ada, for the children"

ROTFLOL!

I can just picture the ads now. How about a big picture of Charles Manson
with a catption reading:

   His dad didn't use Ada. Stop the madness.


T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Nick Roberts]

Then, of course, your wife asks "Who the hell is Ada?  Are you seeing a
woman behind my back?" :-)

Re: Printing Enum Variable Re: Linux World

[robert_dewar]

In article <7c4dr6$dmc@drn.newsguy.com>,
  billy@no_spam_please wrote:
> So, I am sitting here debugging C code where I would be m
> much happier (and also more productive) using Ada, but I
> need to pay the rent as they say.

The best advice is to continue to sharpen your Ada skills
in your spare time, and look for that job which will not
only let you use Ada, but encourage you to do so! And
meanwhile keep up your program of encouragement, you never
know. By the way, there are good advocacy materials
available to help you fight the good fight. Check the
adahome site for some useful pointers.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]


Dale Stanbrough a �crit dans le message ...

>
>Another thing you could do (it worked for the U.S. Navy!)
>is to realise it is easier to seek forgiveness than permission.
>Write your software in Ada anyway, and then give it to them
>as a completed work! (mind you if i was a manager and you did
>this to me i'ld be inclined to sack you :-).

That is indeed a solution. What amazed me is that you often don't have
to ask to write your software in C/C++ or Java, you just do it because
every body expect this. So just write your next software in Ada.

Pascal.

Re: Printing Enum Variable Re: Linux World

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]


billy@no_spam_please a �crit dans le message <7c4dr6$dmc@drn.newsguy.com>...
>
>I think Ada is a wonderfull language also. However in the commerical world,
>when I tell my boss that I'd like to write something in Ada, they refuse,
>they want me to use C or Perl or Java or C++.
>
>Even co-workers, who are all C-type programmers (sorry, no offense
intended),
>look funny at me when I suggest we try Ada. I tried one time to argue
>technical detailes with a supervisor about the language and to compare
>it to C, but he was not interested to even listen.
>
>So, I am sitting here debugging C code where I would be much happier (and
also
>more productive) using Ada, but I need to pay the rent as they say.


Just because I don't want you to feel alone.

I had the very same problem during 6 years.

Pascal.

Re: Printing Enum Variable Re: Linux World

[Larry Kilgallen]

Reply-To: Kilgallen@eisner.decus.org.nospam
Organization: LJK Software
Lines: 25

In article <dale-1003991644340001@r1021c-07.ppp.cs.rmit.edu.au>, dale@cs.rmit.edu.au (Dale Stanbrough) writes:

> I would think the best form of advocacy is to go back through
> your development and field error logs and determine how many
> of them could have been prevented at compile time by using Ada,
> and present this to your manager.

Even if Ada did not exist, or even if you were in an all-Ada shop,
your shop should be keeping a log of "why did this problem occur".
With that as a neutral base, if your answers turn out to be all
"this language does not support compiler checks for X", you may
at least be leading toward a discussion of language policy.

> Another thing you could do (it worked for the U.S. Navy!)
> is to realise it is easier to seek forgiveness than permission.
> Write your software in Ada anyway, and then give it to them
> as a completed work! (mind you if i was a manager and you did
> this to me i'ld be inclined to sack you :-).

A different approach would be to do prototypes in Ada.  That will
introduce the language, and sometimes organizations end up running
on the prototype for a while.  Of course running on the prototype
for a while is not in anyone's _plan_, but the best laid plans...

Larry Kilgallen

Re: Printing Enum Variable Re: Linux World

[dennison]

In article <dale-1003991644340001@r1021c-07.ppp.cs.rmit.edu.au>,
  dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

> Another thing you could do (it worked for the U.S. Navy!)
> is to realise it is easier to seek forgiveness than permission.
> Write your software in Ada anyway, and then give it to them
> as a completed work! (mind you if i was a manager and you did
> this to me i'ld be inclined to sack you :-).

Several years ago I actually did that on a one man job. But there wasn't much
they could say to me, since the user was a DoD entity. They didn't really care
anyway, as this was one of those "just get it done" jobs. Plus, I turned it in
more than a week early and significantly under budget (they planned on several
"at site" weeks for debugging, that I didn't need at all). There really wasn't
anything for management to complain about.

The "educational use only" public version of gnat is particularly handy for
such situations. :-)

On a more serious note, I should mention here that not only are those "at
site" debugging weeks expensive to a company's immediate bottom line, they
can have a insidious impact as well.  I had one friend whose marrige broke up
as a result of a several month "at site" stint trying to debug networked C
and Fortran code, and another (with young 5 kids) whose almost broke up.
Needless to say, the company didn't get much productive work out of either
for several months while they tried to straighten out their personal lives.

So I add "family friendly" to my personal list of Ada adjectives.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Printing Enum Variable Re: Linux World

[Mike Silva]

Michael Young wrote in message <7c4ru6$e45$1@remarQ.com>...
<...>
>I view these as design issues, not really coding problems. Who wants to
know
>what color the traffic light is, and why? My first guess is that a state
>machine is a more appropriate abstraction.

But enumerations (in whatever language) are ideal for representing these
states.

>Likewise for your co-workers'
>political views: these might be better captured as polymorphic behaviors.

Possibly, but at some point somebody is going to want to identify those
views (e.g. to get each person on the right mailing list), and again
enumerations are ideal.  In addition, you can do things like defining an
array of Political_Slate records over the enumeration, which is a very clean
and close match to the actual situation.

> With
>that said, there is no getting around the neutral nature of storage media.
>From now until some enlightened future, these attributes will likely be
stored
>as coded numeric values in databases. This will always be a weak link,
since
>somebody outside the development staff can change the coding to your
>detriment.

I don't understand this.  If somebody can break your data encoding spec
after the fact then there's no end to your troubles.

I like enumerations, but I don't see the appropriateness of enumerations as
an Ada vs. C++ issue.  I use them whereever I can in both languages.  I *do*
enjoy the extra Ada attribute support (constructs such as
  for index in Political_Spectrum'Range loop
are pleasingly elegant, IMHO).  In fact I find Ada attributes in general
quite nice.

Mike

Re: Printing Enum Variable Re: Linux World

[bob]

In article <7c63lf$qg2$1@nnrp1.dejanews.com>, dennison@telepath.com says...
>
 
>
>So I add "family friendly" to my personal list of Ada adjectives.
> 

This is a brilliant idea!

"Ada, the family oriented language"
"Ada, loving families grow on it".
"Ada, the only language to give you enough time to spend with your spouse"
"Ada, keeps families togother."
"Ada, don't get married without it."
"Ada, at home and at work".

(I'll come up with more if people want).
 
I think it will fly. eveyone nowadays is into the family thing, so I think
we should adopt this theme.

thanks to TED.

bob

Re: Printing Enum Variable Re: Linux World

[Mike Silva]

bob wrote in message <7c6c6b$miv@drn.newsguy.com>...
>In article <7c63lf$qg2$1@nnrp1.dejanews.com>, dennison@telepath.com says...
>
>This is a brilliant idea!
>
>"Ada, the family oriented language"
>"Ada, loving families grow on it".
>"Ada, the only language to give you enough time to spend with your spouse"
>"Ada, keeps families togother."
>"Ada, don't get married without it."
>"Ada, at home and at work".


And of course "Ada, for the children"

Mike

Re: Printing Enum Variable Re: Linux World

[Dale Stanbrough]

robert dewar wrote:

"By the way, there are good advocacy materials
 available to help you fight the good fight. Check the
 adahome site for some useful pointers."


I would think the best form of advocacy is to go back through
your development and field error logs and determine how many
of them could have been prevented at compile time by using Ada,
and present this to your manager. This of course will be an
underestimate of the errors that occur (many errors that a C
programmer would "discover" after a few minutes that wouldn't
have occurred at all in Ada will still not be reported).

Another thing you could do (it worked for the U.S. Navy!)
is to realise it is easier to seek forgiveness than permission.
Write your software in Ada anyway, and then give it to them
as a completed work! (mind you if i was a manager and you did
this to me i'ld be inclined to sack you :-).

Dale

Re: Printing Enum Variable Re: Linux World

[Richard D Riehle]

In article <dale-1003991644340001@r1021c-07.ppp.cs.rmit.edu.au>,
	dale@cs.rmit.edu.au (Dale Stanbrough) wrote:

>Another thing you could do (it worked for the U.S. Navy!)
>is to realise it is easier to seek forgiveness than permission.
>Write your software in Ada anyway, and then give it to them
>as a completed work! 

 I know a university student who did this in a data structures
 class.  Instead of writing the assignments in C or C++, he 
 did them in Ada.  Turned them in to a surprised professor.

(mind you if i was a manager and you did
>this to me i'ld be inclined to sack you :-).

 He did get a good grade in the class.  The professor was not so
 narrow-minded as to require him to re-do it in C++.  He persuaded
 the professor that the objective of the class was to learn the
 data structures and algorithms, not to use some particular language.

 I suspect most professors would be too myopic to appreciate this. But
 there are a few enlightened souls on some faculties.

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com