Three simple questions

Three simple questions

[Frank Christiny]

Friends,

Having arrived recently into the green Adian world, I am trying to
assimilate all there is to know about this powerful, unfairly
maligned computer language.  Most questions I have been able to
answer from the FAQs here and there but there are three (so far) that
have gone unanswered:

1.  What is the correct pronunciation of Dr. Ichbiah's name?
    Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
    final "h" is silent?

2.  What is the rationale for case-insensitivity in the language?
    I am beginning to think it is mostly for historical reasons
    (some machines didn't have two case letters way back then, etc.).
    Are there any real technical reasons for why this is so even
    after Ada95, besides preserving backwards compatibilty?

3.  How can one block-comment in Ada?
    It can become cumbersome sometimes, adding all those "--"s in
    front of a large block of code one wants to "test out" on the fly.
    Again, are there any good technical-engineering reasons why this
    feature was left out?

Regards,
-- 
Frank Christiny                       fchris@pdq.net
Sr. Software Engineer                 Lockheed Martin Space Operations
Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

Re: Three simple questions

[John McCabe]

Frank Christiny <fchris@pdq.net> wrote:


>1.  What is the correct pronunciation of Dr. Ichbiah's name?
>    Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
>    final "h" is silent?

Does it matter?

>2.  What is the rationale for case-insensitivity in the language?

At least one reason is for safety against misspelling. In
case-sensitive languages e.g. in C, if I had

   int an_Int;
   :
   <various other declarations
   
   for (An_Int = 1; An_Int < 10; An_Int++)
   :
   blah blah

and compile this I will get an error because of undefined An_Int. The
risk here is that I could just go to the declarations list and add:

   int An_Int;

rather than realising that I've just written an_Int incorrectly.

>    I am beginning to think it is mostly for historical reasons
>    (some machines didn't have two case letters way back then, etc.).
>    Are there any real technical reasons for why this is so even
>    after Ada95, besides preserving backwards compatibilty?

>3.  How can one block-comment in Ada?

You can't.

>    It can become cumbersome sometimes, adding all those "--"s in
>    front of a large block of code one wants to "test out" on the fly.
>    Again, are there any good technical-engineering reasons why this
>    feature was left out?

This is another safety issue. If you want to comment out regions of
code use something like ada-mode with Emacs.


Hope this helps.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Three simple questions

[Frank Christiny]

John McCabe wrote:
> 
> Frank Christiny <fchris@pdq.net> wrote:
> 
> >1.  What is the correct pronunciation of Dr. Ichbiah's name?
> >    Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
> >    final "h" is silent?
> 
> Does it matter?

      Yes, if you want to give accurate presentations on Ada and its
   rich history, or simply, just to know.

 
> >2.  What is the rationale for case-insensitivity in the language?
> 
> At least one reason is for safety against misspelling.
[snip]

      Whoa!  So you are saying the original designers of the language
   actually sat down and decided the majority of us programmers were
   dislexic or something?   I am sure there is more to it than that!

 
> >3.  How can one block-comment in Ada?
> 
> You can't.
[snip]
> This is another safety issue. If you want to comment out regions of
> code use something like ada-mode with Emacs.
> 
> Hope this helps.

      Sure Does.  Thanks!

-- 
Frank Christiny                       fchris@pdq.net
Sr. Software Engineer                 Lockheed Martin Space Operations
Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

Re: Three simple questions

[John English]

Frank Christiny wrote:
> John McCabe wrote:
> > Frank Christiny <fchris@pdq.net> wrote:
> > >2.  What is the rationale for case-insensitivity in the language?
> >
> > At least one reason is for safety against misspelling.
> [snip]
> 
>       Whoa!  So you are saying the original designers of the language
>    actually sat down and decided the majority of us programmers were
>    dislexic or something?   I am sure there is more to it than that!

(Dyslexic? Or was that a dilberate misspooling? Anyway...)

I'm dead against case sensitivity. For example, in Java you not only
have to remember a zillion API calls to do anything useful, you also
have to remember how they're capitalised. The Java rule is that class
names have EachWordCapitalised (or is that EachWordCapitalized? :-),
which is fine when you can remember whether "run time" is one word
or two (is it RuntimeException or RunTimeException?).

And of course, none of the compilers I've used will help tell you
what's wrong if you misspell something. You'd think they could add
error reporting for undeclared identifiers which would say "there's
no such thing as RunTimeException, but when I did a case-insensitive
check I found RuntimeException -- is that what you mean?". Of course,
the level of helpfulness that GNAT provides in error messages would
take all the fun out of programming in Java... ;-)

It gets even more fun with OOP; you think you've got a method called
DoThisNow and override it, but it's actually called doThisNow; the
result is two methods, one called doThisNow and the other called
DoThisNow, which are of course completely unrelated... and the
compiler will say nothing.

Since humans consider 'D' and 'd' to be variant representations of
the same letter, why shouldn't programming languages?

(This doesn't apply to language names like Ada/ADA, of course... but
I don't want to reopen that particular theological debate here... ;-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Three simple questions

[Dale Stanbrough]

John English wrote:

> It gets even more fun with OOP; you think you've got a method called
> DoThisNow and override it, but it's actually called doThisNow; the
> result is two methods, one called doThisNow and the other called
> DoThisNow, which are of course completely unrelated... and the
> compiler will say nothing.

Of course Ada has exactly the same problem, in that if you misspell
the name of a subprogram when trying to override, you are not 
informed by the compiler (e.g. consider Finalize and Finalise).

I think i like the Eiffel method better, where you explicity 
state that you are overriding an inherited method.

Dale

Re: Three simple questions

[Larry Kilgallen]

In article <dale-7FE0DC.22584210102000@news-server>, Dale Stanbrough <dale@cs.rmit.edu.au> writes:
> John English wrote:
> 
>> It gets even more fun with OOP; you think you've got a method called
>> DoThisNow and override it, but it's actually called doThisNow; the
>> result is two methods, one called doThisNow and the other called
>> DoThisNow, which are of course completely unrelated... and the
>> compiler will say nothing.
> 
> Of course Ada has exactly the same problem, in that if you misspell
> the name of a subprogram when trying to override, you are not 
> informed by the compiler (e.g. consider Finalize and Finalise).

I do not think that is "exactly" the same problem, as spelling is
less arbitrary than capitalization.

Re: Three simple questions

[John English]

Dale Stanbrough wrote:
> 
> John English wrote:
> 
> > It gets even more fun with OOP; you think you've got a method called
> > DoThisNow and override it, but it's actually called doThisNow; the
> > result is two methods, one called doThisNow and the other called
> > DoThisNow, which are of course completely unrelated... and the
> > compiler will say nothing.
> 
> Of course Ada has exactly the same problem, in that if you misspell
> the name of a subprogram when trying to override, you are not
> informed by the compiler (e.g. consider Finalize and Finalise).

This is in fact a particularly bad one, as there aren't even any
explicit calls you can search for, so debugging "by eye" is out.

Case differences just add another opportunity for foot-shootery,
though... as if there weren't already enough.

> I think i like the Eiffel method better, where you explicity
> state that you are overriding an inherited method.

I agree completely -- from a safety point of view, something like
this is surely essential for Ada 0X...

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Three simple questions

[Ted Dennison]

In article <39E30759.7A402CB6@bton.ac.uk>,
  John English <je@bton.ac.uk> wrote:
> Dale Stanbrough wrote:
> >
> > Of course Ada has exactly the same problem, in that if you misspell
> > the name of a subprogram when trying to override, you are not
> > informed by the compiler (e.g. consider Finalize and Finalise).
>
> This is in fact a particularly bad one, as there aren't even any
> explicit calls you can search for, so debugging "by eye" is out.
...

To bring this into the realm of actual experience, I got bit by this
exact problem last week.

I was debugging someone else's code, and couldn't figure out why one
dispatching routine wasn't working. Since there was an interface to
external C code involved, there were all sorts of other possible
problems to look for.

It turned out that the parameter profile (but not the name) of the
parent type's primitive method had changed over a year ago, but the
author of this package was too lazy to change his own code to match. He
was one of those "whatever works" folks, and the default "null;"
implementation matched his implementation. No one noticed any difference
until a year later. He is now off the project. So I went into his
package body to add the code to make his version of the dispatching
operation actually do something. Of course nothing happened because the
routine I changed was not being dispatched to. Testing in our system is
rather slow, as we have a limited number of test platforms (located in
another building). Also, as I mentioned above, the C interface left me
with lots of other good possible causes to look for. So it took me a
week to figure out what was really going on.

> I agree completely -- from a safety point of view, something like
> this is surely essential for Ada 0X...

I'm glad I'm not the only one who feels that way.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html
Day 5 of Free Europe


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[Tucker Taft]

Ted Dennison wrote:
> 
> In article <39E30759.7A402CB6@bton.ac.uk>,
>   John English <je@bton.ac.uk> wrote:
> > Dale Stanbrough wrote:
> > >
> > > Of course Ada has exactly the same problem, in that if you misspell
> > > the name of a subprogram when trying to override, you are not
> > > informed by the compiler (e.g. consider Finalize and Finalise).
> >
> > This is in fact a particularly bad one, as there aren't even any
> > explicit calls you can search for, so debugging "by eye" is out.
> ...
> 
> To bring this into the realm of actual experience, I got bit by this
> exact problem last week.
> ...
> > I agree completely -- from a safety point of view, something like
> > this is surely essential for Ada 0X...
> 
> I'm glad I'm not the only one who feels that way.

You'll be happy to know that pragmas have been proposed that
allow the programmer to prevent this kind of mistake.  See AI-218, at:

http://www.ada-auth.org/cgi-bin-acats/cvsweb.cgi/AIs/AI-00218.DOC?rev=1.4

> 
> --
> T.E.D.
> 
> http://www.telepath.com/~dennison/Ted/TED.html

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Three simple questions

[Ted Dennison]

Tucker Taft wrote:

> Ted Dennison wrote:
> >
> > In article <39E30759.7A402CB6@bton.ac.uk>,
> >   John English <je@bton.ac.uk> wrote:
> > > I agree completely -- from a safety point of view, something like
> > > this is surely essential for Ada 0X...
> >
> > I'm glad I'm not the only one who feels that way.
>
> You'll be happy to know that pragmas have been proposed that
> allow the programmer to prevent this kind of mistake.  See AI-218, at:
>
> http://www.ada-auth.org/cgi-bin-acats/cvsweb.cgi/AIs/AI-00218.DOC?rev=1.4

After looking over that AI, I think I'd rather see us wait for Ada0XX and fix
it "right". They are clearly a bit of a hack, but I'm worried that they will
become the permanent solution once they are officially blessed..

Since we already have a keyword to designate dispatching operations without
implementations (abstract), it wouldn't be a big conceptual leap to make
keywords to designate overriding dispatching operations ("overrides", or
perhaps "is new"). The big problem is that leaving the default behavior in a
backward-compatable state is undesirable. Perhaps the best solution would be
leave the default the way it is, and to also have an optional keyword
designating that the routine *cannot* be an override. Then it could probably
be left to coding standards to enforce usage of the appropriate keywords
(rather than taking the default). This would mesh with the situation we
currently have with the "in" parameter mode.

The text dismisses the keyword solution above as ugly (and new keywords as
"bad"). But the pragma solution is even uglier, as it comes on a completly
separate line. Worse yet, the pragma wouldn't appear in the body at all (which
is where I went looking for the source of my "bug").

In general I think the proposed pragmas are just a hack to cover what should
be a first-class part of the language. I do agree wholeheartedly with the part
of the AI that says "Syntax was determined to be too heavyweight a solution
for an amendment.". Of course that would make us wait until the next full
language revision, whereas pragmas can be applied now.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Three simple questions

[Tucker Taft]

Ted Dennison wrote:
> 
> Tucker Taft wrote:
> 
> > Ted Dennison wrote:
> > >
> > > In article <39E30759.7A402CB6@bton.ac.uk>,
> > >   John English <je@bton.ac.uk> wrote:
> > > > I agree completely -- from a safety point of view, something like
> > > > this is surely essential for Ada 0X...
> > >
> > > I'm glad I'm not the only one who feels that way.
> >
> > You'll be happy to know that pragmas have been proposed that
> > allow the programmer to prevent this kind of mistake.  See AI-218, at:
> >
> > http://www.ada-auth.org/cgi-bin-acats/cvsweb.cgi/AIs/AI-00218.DOC?rev=1.4
> 
> After looking over that AI, I think I'd rather see us wait for Ada0XX and fix
> it "right". They are clearly a bit of a hack, but I'm worried that they will
> become the permanent solution once they are officially blessed..

I would encourage you to give specific and detailed
comment on this proposal.  It is unlikely that
there will be any other solution considered unless
someone provides constructive feedback and a very
well thought out alternative proposal.

It is quite unlikely that there will be any massive ("full")
reengineering of Ada in the foreseeable future, 
but rather a series of small, "surgical" fixes (officially
known as "amendments").  New keywords are not out of the
question, but there has to be a *lot* of value provided,
and a lot of "taste" involved in the design.
Pragmas should also, of course, be designed with "taste,"
but admittedly it is hard to ever achieve a truly "tasty"
pragma ;-).

> ...
> --
> T.E.D.
> 
> Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
> WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

The AI process (was: Three simple questions)

[Ted Dennison]

In article <39E5E6AB.193CE326@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> I would encourage you to give specific and detailed
> comment on this proposal.  It is unlikely that
> there will be any other solution considered unless
> someone provides constructive feedback and a very
> well thought out alternative proposal.

For the enlightenment of myself and anyone else here who is equally
ignorant (yeah...I know. BOTH of us.), could someone familiar with the
process please go over this a bit? How does one go about officially
submitting AI's and/or commenting on them?

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html
Day 6 of Free Europe


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: The AI process (was: Three simple questions)

[Marc A. Criley]

Ted Dennison wrote:
> 
> In article <39E5E6AB.193CE326@averstar.com>,
>   Tucker Taft <stt@averstar.com> wrote:
> 
> > I would encourage you to give specific and detailed
> > comment on this proposal.  It is unlikely that
> > there will be any other solution considered unless
> > someone provides constructive feedback and a very
> > well thought out alternative proposal.
> 
> For the enlightenment of myself and anyone else here who is equally
> ignorant (yeah...I know. BOTH of us.), could someone familiar with the
> process please go over this a bit? How does one go about officially
> submitting AI's and/or commenting on them?

Merely peruse the Introduction chapter of the Ada Reference Manual: 
"Instructions for Comment Submission".

Marc A. Criley

Re: The AI process (was: Three simple questions)

[Tucker Taft]

"Marc A. Criley" wrote:
>... Merely peruse the Introduction chapter of the Ada Reference Manual:
> "Instructions for Comment Submission".

However, be sure to send your comments to
 
   mailto:ada-comment@ada-auth.org

rather than the address given in the Ada 95 manual.
Also, following the official format is not quite as 
important as it used to be, since the flow of comments 
is significantly slower.  The key thing is to be constructive
and thorough.  Don't just throw off random, unsubstantiated,
un-researched suggestions.  Put in the effort to really make
sure what you are proposing makes sense, and back it up
with appropriate rationale, examples, even wording suggestions.

> Marc A. Criley

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Three simple questions

[Robert A Duff]

Tucker Taft <stt@averstar.com> writes:

> I would encourage you to give specific and detailed
> comment on this proposal.

And I encourage you to do so well before November 17, which is the start
of the next ARG meeting.  This AI is on the agenda.

- Bob

Re: Three simple questions

[wv12]

In article <39E2D51E.D0122F20@bton.ac.uk>,

> I'm dead against case sensitivity. For example, in Java you not only
> have to remember a zillion API calls to do anything useful, you also
> have to remember how they're capitalised. The Java rule is that class
> names have EachWordCapitalised (or is that EachWordCapitalized? :-),
> which is fine when you can remember whether "run time" is one word
> or two (is it RuntimeException or RunTimeException?).

Case sensitivity enforces consistency among code produced by different
programmmers. Imagine programmer A insists on writing runTimeeXception
and programmer B insits writing runtimeexcception. Maybe you  yourself
on Monday decides to write runtimeException and on Tuesday,
RUNTIMEEXCEPTION. Now, that is sick. Well, if you can do anything
*useFUl* in Ada, you don't have to write it in Java.


>
> And of course, none of the compilers I've used will help tell you
> what's wrong if you misspell something. You'd think they could add
> error reporting for undeclared identifiers which would say "there's
> no such thing as RunTimeException, but when I did a case-insensitive
> check I found RuntimeException -- is that what you mean?". Of course,
> the level of helpfulness that GNAT provides in error messages would
> take all the fun out of programming in Java... ;-)
>
> It gets even more fun with OOP; you think you've got a method called
> DoThisNow and override it, but it's actually called doThisNow; the
> result is two methods, one called doThisNow and the other called
> DoThisNow, which are of course completely unrelated... and the
> compiler will say nothing.
>
> Since humans consider 'D' and 'd' to be variant representations of
> the same letter, why shouldn't programming languages?
>
Human only invents ASCII where 'd' and 'D' has different values.

> (This doesn't apply to language names like Ada/ADA, of course... but
> I don't want to reopen that particular theological debate here... ;-)
>
The way I see it, case insensitive languages just show they are aging.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[Larry Kilgallen]

In article <8s0b78$2no$1@nnrp1.deja.com>, wv12@my-deja.com writes:

> Case sensitivity enforces consistency among code produced by different
> programmmers. Imagine programmer A insists on writing runTimeeXception
> and programmer B insits writing runtimeexcception. Maybe you  yourself
> on Monday decides to write runtimeException and on Tuesday,
> RUNTIMEEXCEPTION. Now, that is sick. Well, if you can do anything
> *useFUl* in Ada, you don't have to write it in Java.

If you cannot get programmers to agree on style, you have a people
problem that cannot be solved with technology.  If somebody writes
Runtime_Exception and someone else writes runtime_exception it is
not the end of the world.

>> Since humans consider 'D' and 'd' to be variant representations of
>> the same letter, why shouldn't programming languages?
>>
> Human only invents ASCII where 'd' and 'D' has different values.

I gather you never heard of baudot or programmed using a KSR 35
terminal.  (two _different_ encoding schemes).

> The way I see it, case insensitive languages just show they are aging.

You seem to imply that "old is bad".  I think you will find that
in comp.lang.ada that is not a given and you have to prove it for
any particular example.

Re: Three simple questions

[Robert Dewar]

In article <LVzA9mCZWcOB@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:

> If you cannot get programmers to agree on style, you have a
> people problem that cannot be solved with technology.  If
> somebody writes Runtime_Exception and someone else writes
> runtime_exception it is not the end of the world.

No, but it is a bug in my view. And tools can help. In the
GNAT sources, we require all style checks to be turned on
(indeed you cannot check in a unit without doing a style
check). One of the style checks is that all references to
a given entity use the same casing as the declaration.

What to me is clear is that it is not a good idea to allow
two different identifiers that differ only in casing to
be simultaneously visible.

Incidentally, note that it is only computers that even for
a moment dally with case sensitivity. In ordinary language,
there are indeed style rules for capitalization, but the
case of characters is not in general semantically significant.

If I spell my name

robert dewar

That looks a little peculiar, but no one thinks this is a
different name from

Robert Dewar

:-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[The Ludwig Family]

Robert Dewar wrote:
 
> What to me is clear is that it is not a good idea to allow
> two different identifiers that differ only in casing to
> be simultaneously visible.
> 
> Incidentally, note that it is only computers that even for
> a moment dally with case sensitivity. In ordinary language,
> there are indeed style rules for capitalization, but the
> case of characters is not in general semantically significant.

That's not really true, as I'm sure you remember from your chemistry 
days.  Following rulings and recommendations from the CGPMs (French 
acronym for General Conferences on Weights and Measures, which are 
responsible by international treaty for defining the metric system) 
and ISO (particularly ISO 31 and ISO 1000), not only is case important, 
but also font (such as upright versus italics, serif versus sans serif, 
bold versus normal, ...) in the correct interpretation of symbols.

For example, take the letter s:
  as lower case, upright, not bolded, it means second (unit of time);
  as upper case, upright, not bolded, it means siemens (unit of 
     electrical conductance);
  as lower case, italics, not bolded, it typically means displacement;
  as upper case, italics, not bolded, it typically means surface or 
     surface area in mathematics, or entropy in thermodynamics;
  as upper case, italics, bolded, it typically means Poynting vector;
  and so on.
Upright and not bolded corresponds to units of measurement.
Italicized, not bolded corresponds to scalar variables.
Italicized, bolded corresponds to vectors.
Upright, bolded, sans serif corresponds to tensors.

Of course programming languages, indeed even Unicode, don't (and at 
least for the foreseeable future won't and even can't) make such 
distinctions, so we have to spell out our identifiers to make them 
more meaningful within the constraints of character sets for 
programming languages.

> If I spell my name
> 
> robert dewar
> 
> That looks a little peculiar, but no one thinks this is a
> different name from
> 
> Robert Dewar

Howard W. LUDWIG

Re: Three simple questions

[Florian Weimer]

The Ludwig Family <ludwigs@bellsouth.net> writes:

> For example, take the letter s:
>   as lower case, upright, not bolded, it means second (unit of time);
>   as upper case, upright, not bolded, it means siemens (unit of 
>      electrical conductance);

[...]

> Of course programming languages, indeed even Unicode, don't (and at 
> least for the foreseeable future won't and even can't) make such 
> distinctions, so we have to spell out our identifiers to make them 
> more meaningful within the constraints of character sets for 
> programming languages.

In fact, there's a proposal for an Unicode extension which will add
additional math alphabets (upright, italic, bold, script, Fraktur...).
Nevertheless, I think it's a good idea not to exploit these new
possibility when you're trying to write reliable software.  If $s$
becomes $S$ in a mathematical publication, most readers will hopefully
be able to interpret it correctly anyway, but machines can't do this
(unless there is some kind of type information which happens to be
contradicting).

Re: Three simple questions

[David Starner]

On 16 Oct 2000 22:12:35 +0200, Florian Weimer wrote:
>In fact, there's a proposal for an Unicode extension which will add
>additional math alphabets (upright, italic, bold, script, Fraktur...).
>Nevertheless, I think it's a good idea not to exploit these new
>possibility when you're trying to write reliable software.  

It should be compatibility composites to the letters, so if Ada0X 
forces identifier names to be normalized, it shouldn't be a problem.
As for now . . . how many people are actually using Unicode source
code for Ada?

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Three simple questions

[Florian Weimer]

dvdeug@x8b4e516e.dhcp.okstate.edu (David Starner) writes:

> On 16 Oct 2000 22:12:35 +0200, Florian Weimer wrote:
> >In fact, there's a proposal for an Unicode extension which will add
> >additional math alphabets (upright, italic, bold, script, Fraktur...).
> >Nevertheless, I think it's a good idea not to exploit these new
> >possibility when you're trying to write reliable software.  
> 
> It should be compatibility composites to the letters, so if Ada0X 
> forces identifier names to be normalized, it shouldn't be a problem.

Normalization is a noop on these characters. Otherwise they would be
quite pointless.

Re: Three simple questions

[David Starner]

On 18 Oct 2000 22:57:38 +0200, Florian Weimer wrote:
>dvdeug@x8b4e516e.dhcp.okstate.edu (David Starner) writes:
>
>> On 16 Oct 2000 22:12:35 +0200, Florian Weimer wrote:
>> >In fact, there's a proposal for an Unicode extension which will add
>> >additional math alphabets (upright, italic, bold, script, Fraktur...).
>> >Nevertheless, I think it's a good idea not to exploit these new
>> >possibility when you're trying to write reliable software.  
>> 
>> It should be compatibility composites to the letters, so if Ada0X 
>> forces identifier names to be normalized, it shouldn't be a problem.
>
>Normalization is a noop on these characters. Otherwise they would be
>quite pointless.

KC, not C normalization. KC will lose font/bold/etc information on a 
character. The current parts of the mathematical alphabet (in Letterlike
Symbols, U+2100) are already compatibility charactars, so I assume the
rest will be. 

Anyway, I can't see Ada not using KC normalization on the characters. NJ
(an encoding digraph) should not be different from the ASCII NJ, for example.

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Three simple questions

[Robert Dewar]

In article <8sn71i$8a21@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
>
> Anyway, I can't see Ada not using KC normalization on the
characters. NJ
> (an encoding digraph) should not be different from the ASCII
NJ, for example.


It may be helpful to remember that the Ada RM has NOTHING to
say about how programs are represented. There is no necessary
connection between the enumeration literal 'A' in the type
Standard.Character, and the way the letter A is represented
in source programs. In typical compilers there may be a strong
relationship in practice (quite useful for example if you
want to use type String to read in an Ada source program),
but this is an implementation choice, it is not something
that is required or even suggested by the RM.

I mention this, because I have found that there are wide
spread misconceptions in this area.

As an example, a compiler that required all keywords to be
input in bold would be a conforming compiler, that's true
even if the method of achieving bold was to have some strange
escape sequence in the sources. Similarly a compiler on IBM
main frames (contrary to widespread misinformed rumour, such
things still exist, and people buy new ones all the time) might
well represent sources in EBCDIC, and that would be just fine.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[David Starner]

On Sat, 21 Oct 2000 14:52:02 GMT, Robert Dewar wrote:
>In article <8sn71i$8a21@news.cis.okstate.edu>,
>  dstarner98@aasaa.ofe.org wrote:
>>
>> Anyway, I can't see Ada not using KC normalization on the
>characters. NJ
>> (an encoding digraph) should not be different from the ASCII
>NJ, for example.
>
>
>It may be helpful to remember that the Ada RM has NOTHING to
>say about how programs are represented. There is no necessary

Then what does section 2.1 of the RM mean?

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Three simple questions

[Robert A Duff]

dvdeug@x8b4e516e.dhcp.okstate.edu (David Starner) writes:

> Then what does section 2.1 of the RM mean?

Not a whole lot.  ;-)  See AARM-2.1(1.b), for example.

2.1 does mean *something*, though.  For example, I interpret it to mean
that you (the compiler vendor) have to provide *some* way of
representing each of the 2**16 characters ISO-10646.  But it doesn't
have to agree with anybody else's way of representing those same
characters.  You could use this to make an arbitrarily useless compiler,
I suppose, if you really wanted to.

- Bob

Re: Three simple questions

[Robert Dewar]

In article <wccem1739qn.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> dvdeug@x8b4e516e.dhcp.okstate.edu (David Starner) writes:
>
> > Then what does section 2.1 of the RM mean?
>
> Not a whole lot.  ;-)  See AARM-2.1(1.b), for example.
>
> 2.1 does mean *something*, though.

It means quite a bit, it requires not only that some method
be provided for representing all characters, but also that
the implementation define what this method is. This is from
Annex M:

    6  The coded representation for the text of an Ada program.
       See 2.1(4).

Note another example where there may be a difference between
source representation is in wide characters. It is quite
conceivable that the method, or set of methods, for representing
wide characters in source programs be different from the set
of methods usable in Text_IO. In the case of GNAT, there are
six different methods of representing wide characters, and all
are available for either source programs (by compiler option)
or for Text_IO (using a form parameter), but there is no
requirement that this be the case.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[Robert Dewar]

In article <8sseq9$a2g1@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
> >It may be helpful to remember that the Ada RM has NOTHING to
> >say about how programs are represented. There is no necessary
>
> Then what does section 2.1 of the RM mean?


It is a VERY common misconception that 2.1 dictates
representation and suggests that the representaiton has
something to do with Standard.Character, but this is
just a "common sense" guess. This section merely says
that the compiler must be able to represent a certain
set of characters in the source, it has nothing whatsoever
to say about what representations are used.

For example, it would be quite fine to require keywords to
be written in bold in an environment where this made some
kind of sense (e.g. old style paper tape codes where Algol
keywords were typically marked as bold to distinguish them
from identifiers :-)

Whether it is a good idea or not depends on the environment.
I can certainly see an EBCDIC compiler using EBCDIC for source
representation even if type Standard.Character has to be ASCII,
but for most compilers in a typical environment, it makes sense
to choose a representation identical to Standard.Character.

It may well be the case in fact that you can use Text_IO to
read a source file, and get what you expect, but section 2.1
of the RM definitely does NOT guarantee this. Indeed it is
very clearly spelled out:

4   The character repertoire for the text of an Ada program
consists of the collection of characters called the Basic
Multilingual Plane (BMP) of the ISO 10646 Universal
Multiple-Octet Coded Character Set, plus a set of format_
effectors and, in comments only, a set of
other_control_functions; the coded representation for these
characters is implementation defined (it need not be
a representation defined within ISO-10646-1).




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[Robert Dewar]

In article <8sseq9$a2g1@news.cis.okstate.edu>,
  dstarner98@aasaa.ofe.org wrote:
> >It may be helpful to remember that the Ada RM has NOTHING to
> >say about how programs are represented. There is no necessary
>
> Then what does section 2.1 of the RM mean?


It is a VERY common misconception that 2.1 dictates
representation and suggests that the representaiton has
something to do with Standard.Character, but this is
just a "common sense" guess. This section merely says
that the compiler must be able to represent a certain
set of characters in the source, it has nothing whatsoever
to say about what representations are used.

For example, it would be quite fine to require keywords to
be written in bold in an environment where this made some
kind of sense (e.g. old style paper tape codes where Algol
keywords were typically marked as bold to distinguish them
from identifiers :-)

Whether it is a good idea or not depends on the environment.
I can certainly see an EBCDIC compiler using EBCDIC for source
representation even if type Standard.Character has to be ASCII,
but for most compilers in a typical environment, it makes sense
to choose a representation identical to Standard.Character.

It may well be the case in fact that you can use Text_IO to
read a source file, and get what you expect, but section 2.1
of the RM definitely does NOT guarantee this. Indeed it is
very clearly spelled out:

4   The character repertoire for the text of an Ada program
consists of the collection of characters called the Basic
Multilingual Plane (BMP) of the ISO 10646 Universal
Multiple-Octet Coded Character Set, plus a set of format_
effectors and, in comments only, a set of
other_control_functions; the coded representation for these
characters is implementation defined (it need not be
a representation defined within ISO-10646-1).




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[Robert Dewar]

In article <87wvf5hnp9.fsf@deneb.enyo.de>,
  Florian Weimer <fw@deneb.enyo.de> wrote:
> dvdeug@x8b4e516e.dhcp.okstate.edu (David Starner) writes:
> > It should be compatibility composites to the letters, so if
Ada0X
> > forces identifier names to be normalized, it shouldn't be a
problem.


No one knows if and when there might be an Ada0X, perhaps never,
given the approach of issuing TC's. But for sure no one would
even countenance a major incompatible suggestion like this.

If you want normalized identifier names, ask your implementor
to provide a compiler option for this purpose (in GNAT it is
-gnatyk)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[David Starner]

On Sat, 21 Oct 2000 14:48:23 GMT, Robert Dewar wrote:
>In article <87wvf5hnp9.fsf@deneb.enyo.de>,
>  Florian Weimer <fw@deneb.enyo.de> wrote:
>> dvdeug@x8b4e516e.dhcp.okstate.edu (David Starner) writes:
>> > It should be compatibility composites to the letters, so if
>Ada0X
>> > forces identifier names to be normalized, it shouldn't be a
>problem.
>
>If you want normalized identifier names, ask your implementor
>to provide a compiler option for this purpose (in GNAT it is
>-gnatyk)

Normalized as in Unicode normalization, not case wise. I didn't mean
that Ada0X should force the names to be normalized - instead the compiler 
should do normalization just like it does case folding now.

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Three simple questions

[Robert Dewar]

In article <39EA448C.28DF1A2C@bellsouth.net>,
  The Ludwig Family <ludwigs@bellsouth.net> wrote:

> That's not really true

Well it is really true in practice, sure you can find some
examples where case sensitivity matters in English, but you
have to really reach. After all, we don't have a way of
pronouncing case, so you are looking for cases which can
be written and not spoken -- that's really rather rare :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[The Ludwig Family]

Robert Dewar wrote:

> In article <39EA448C.28DF1A2C@bellsouth.net>,
>   The Ludwig Family <ludwigs@bellsouth.net> wrote:
> 
> > That's not really true
> 
> Well it is really true in practice, sure you can find some
> examples where case sensitivity matters in English, but you
> have to really reach. After all, we don't have a way of
> pronouncing case, so you are looking for cases which can
> be written and not spoken -- that's really rather rare :-)

Actually, it's not at all rare in most of the applications domains 
I have worked in:  physics, radar engineering, and similar areas.  
We program formulas that are written mathematically, and when we 
discuss the mathematical expressions, we often talk refer to "big s" 
and "little s" for variables when both are used in the same context.  
For units of measurement, we normally say the unit name (as "seconds" 
for "s" and "siemens" for "S").  Of course, when we program the 
formulas, we use "more meaningful names" because it tends to make 
software more understandable and because the syntax of most languages 
do not support case and font sensitivity.

I do grant that most application domains for software development 
do not make use of such scientific/mathematical expressions, so 
perhaps a better phrase would be "it is really true in most practice".

Howard W. LUDWIG

Re: Three simple questions

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> In article <LVzA9mCZWcOB@eisner.decus.org>,
>   Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> 
> > If you cannot get programmers to agree on style, you have a
> > people problem that cannot be solved with technology.  If
> > somebody writes Runtime_Exception and someone else writes
> > runtime_exception it is not the end of the world.
> 
> No, but it is a bug in my view. And tools can help.

I agree.  If I define a language, it will be illegal.

Of the two, case INsensitivity is better than case sensitivity, because
the latter is more error prone.  However, a rule that is better than
both would be:  Overload resolution is case INsenstive.  There is a
post-name-resolution legality rule that says you have to spell each use
with the same casing as the declaration.  I believe that's essentially
what you get if you use GNAT in the mode where it complains about
casing.

> What to me is clear is that it is not a good idea to allow
> two different identifiers that differ only in casing to
> be simultaneously visible.

Well, I don't think that's *quite* right.  After all, Ada allows two
different identifiers to be simultaneously visible even when they are
identical -- they don't *even* have to differ in casing.  What I would
say is that it's a bad idea for the casing of a usage control name
resolution.

If "foo" were both an acronym and a word, it would be reasonable to have
a procedure Foo and a procedure FOO both visible.  But I wouldn't want
overload resolution to treat them differently.  (I can't think of any
such words in English right now, but there must be some.)

On the other hand, I wouldn't mind a language where I could say:

    function Capitalize(string: String) return String;

where it's clear from the context of use whether we're talking about the
parameter or the type.  It's not distinguished by case; case would be
merely an extra cue.  Of course, in Ada, neither parameter names nor
type names are overloadable.

One thing I find strange is that Ada zealots who very much agree that
case sensitivity is a bad idea in programming languages are willing to
hand out long tiresome lectures on the spelling of Ada (vs ADA).  ;-)
I worry that it turns off newcomers, especially in the rare cases where
the lecture is rude (eg, "How DARE you criticize Ada when you don't even
know how to spell it, you nitwit?!").

- Bob

Re: Three simple questions

[James Hassett]

Robert Dewar wrote:

> Incidentally, note that it is only computers that even for
> a moment dally with case sensitivity. In ordinary language,
> there are indeed style rules for capitalization, but the
> case of characters is not in general semantically significant.
>
> If I spell my name
>
> robert dewar
>
> That looks a little peculiar, but no one thinks this is a
> different name from
>
> Robert Dewar
>

I agree in general, but the Guardians of Corporate Identity often pay
close attention to case as well.

I have the impression that some people are much more sensitive to
case differences than other people--some people seem to notice more
readily than others the "preferred" use of case in names such as
AdaMULTI, AverStar, GNAT, SIGAda, TRI-Ada, Tcl/Tk, or VxWorks.
(I've tried to include examples that run counter to the notion that
an acronymic etymology matters.)  It seems that some people are
less likely than others to notice case differences, some people are
less inclined to bother with case differences in their writing, and
some people are quite compulsive about the use of case.

If this is true, it might account for the fact that the issue of
case sensitivity seems to ignite raging controversy--those who are
quite sensitive to case find it a useful distinction, while those
who are less sensitive find it leads to much trouble.

If I'm right about this diversity in the population of programmers,
then the best rule for language design is that case should not be
significant--unless the language will be used only by those who are
acutely sensitive to case. :-)

(It seems a bit ironic that while the Ada language itself is not
case sensitive, many of its advocates--myself included--are quite
sensitive to the distinction between "Ada" and "ADA"!)

- Jim Hassett

Re: Three simple questions

[Robert Dewar]

In article <39EB0761.4204C9ED@planet8.tds-eagan.lmco.com>,
  James Hassett <hassett@planet8.tds-eagan.lmco.com> wrote:
> (It seems a bit ironic that while the Ada language itself is
> not case sensitive, many of its advocates--myself
> included--are quite sensitive to the distinction between "Ada"
> and "ADA"!)
>
> - Jim Hassett

Actually this makes perfect sense. Typical Ada folks would
be very unhappy at having the two identifiers Ada and ADA
around in the same program, but if the indentifier were
declared as Ada, then all references should use the same
spelling.

SO in fact the position is actually quite consistent, even
though it appears not to be at first sight :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[Robert Dewar]

In article <39EB0761.4204C9ED@planet8.tds-eagan.lmco.com>,
  James Hassett <hassett@planet8.tds-eagan.lmco.com> wrote:

> I have the impression that some people are much more sensitive
> to case differences than other people

Actually my general experience is that

a) most people agree it is a bad thing to have two identifiers
differing only by case in the same place.

b) even when languages do allow case insensitivity it is a bad
idea to take advantage of this and spell the same identifier
in different ways in different places.

My preference therefore is a language environment where there
is case sensitivity, but you cannot have two identifiers
differing only in casing.

Note that GNAT gives you this if you specify -gnatynr (I
find this a very valuable style check)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[David Gillon]

wv12@my-deja.com wrote:

> Case sensitivity enforces consistency among code produced by different
> programmmers. Imagine programmer A insists on writing runTimeeXception
> and programmer B insits writing runtimeexcception. Maybe you  yourself
> on Monday decides to write runtimeException and on Tuesday,
> RUNTIMEEXCEPTION. Now, that is sick. 

Your naming scheme should be consistent, explicit and mandatory within
at least the current project, but the undeniable fact is that
programmers are human and error prone, and that a case insensitive
language is less susceptible to problems caused by finger-fumbles. With
Ada's pronounced slant towards safety critical applications any
opportunity to remove a potential error source has to be a point in its
favour.

>Well, if you can do anything *useFUl* in Ada, you don't have to write it in Java.

When (if?) Java grows up and starts dealing with safety critical
applications, case sensistivity may well be something it wants to adopt
from the more mature and widely used Ada ;)

> The way I see it, case insensitive languages just show they are aging.

YAATAICMFP...

-- 

David Gillon

Re: Three simple questions

[John English]

wv12@my-deja.com wrote:
> 
> In article <39E2D51E.D0122F20@bton.ac.uk>,
> 
> > I'm dead against case sensitivity. For example, in Java you not only
> > have to remember a zillion API calls to do anything useful, you also
> > have to remember how they're capitalised. The Java rule is that class
> > names have EachWordCapitalised (or is that EachWordCapitalized? :-),
> > which is fine when you can remember whether "run time" is one word
> > or two (is it RuntimeException or RunTimeException?).
> 
> Case sensitivity enforces consistency among code produced by different
> programmmers. Imagine programmer A insists on writing runTimeeXception
> and programmer B insits writing runtimeexcception. Maybe you  yourself
> on Monday decides to write runtimeException and on Tuesday,
> RUNTIMEEXCEPTION. Now, that is sick. Well, if you can do anything
> *useFUl* in Ada, you don't have to write it in Java.

So what's wrong with running a prettyprinter over the code? Any
sensible prettyprinter will not only enforce a layout standard,
it'll enforce a capitalisation standard (turn runtime_exception
into Runtime_Exception)? Software tools are supposed to make life
easier, not harder (although there are many counter-examples ;-)
-- why have a dog and bark yourself?

Whitespace sensitivity would be good too, by your argument; it
would enforce consistent layout standards.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Three simple questions

[Pascal Obry]

John English <je@bton.ac.uk> writes:

> wv12@my-deja.com wrote:
> > 
> > In article <39E2D51E.D0122F20@bton.ac.uk>,
> > 
> > > I'm dead against case sensitivity. For example, in Java you not only
> > > have to remember a zillion API calls to do anything useful, you also
> > > have to remember how they're capitalised. The Java rule is that class
> > > names have EachWordCapitalised (or is that EachWordCapitalized? :-),
> > > which is fine when you can remember whether "run time" is one word
> > > or two (is it RuntimeException or RunTimeException?).
> > 
> > Case sensitivity enforces consistency among code produced by different
> > programmmers. Imagine programmer A insists on writing runTimeeXception
> > and programmer B insits writing runtimeexcception. Maybe you  yourself
> > on Monday decides to write runtimeException and on Tuesday,
> > RUNTIMEEXCEPTION. Now, that is sick. Well, if you can do anything
> > *useFUl* in Ada, you don't have to write it in Java.
> 
> So what's wrong with running a prettyprinter over the code? Any
> sensible prettyprinter will not only enforce a layout standard,
> it'll enforce a capitalisation standard (turn runtime_exception
> into Runtime_Exception)? Software tools are supposed to make life
> easier, not harder (although there are many counter-examples ;-)

Definitly such tool exist. I always use the GNAT -gnaty switch now. It is
very good to have the compiler checking for source consistency. Also GLIDE
do capitalize things automatically. You can like the way the capitalization is
done (mostly using the RM convention) or not, at least it is done
consistently !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Three simple questions

[mjsilva]

In article <8s0b78$2no$1@nnrp1.deja.com>,
  wv12@my-deja.com wrote:
> In article <39E2D51E.D0122F20@bton.ac.uk>,
>
> > I'm dead against case sensitivity. For example, in Java you not only
> > have to remember a zillion API calls to do anything useful, you also
> > have to remember how they're capitalised. The Java rule is that
class
> > names have EachWordCapitalised (or is that EachWordCapitalized? :-),
> > which is fine when you can remember whether "run time" is one word
> > or two (is it RuntimeException or RunTimeException?).
>
> Case sensitivity enforces consistency among code produced by different
> programmmers. Imagine programmer A insists on writing runTimeeXception
> and programmer B insits writing runtimeexcception. Maybe you  yourself
> on Monday decides to write runtimeException and on Tuesday,
> RUNTIMEEXCEPTION. Now, that is sick.

No doubt such perverse programmers would similarly amuse themselves
with the following:

char runTimeeXception;
int runtimeexcception;
short runtimeException;
long RUNTIMEEXCEPTION;

int this_exception = runTimeeXception;  /* correct or not? */

Perhaps the solution is to train or fire perverse programmers.


> Well, if you can do anything
> *useFUl* in Ada, you don't have to write it in Java.

I'll drink to that!
>
> > Since humans consider 'D' and 'd' to be variant representations of
> > the same letter, why shouldn't programming languages?
> >
> Human only invents ASCII where 'd' and 'D' has different values.

And then they write extra searching and sorting code to treat them as
equivalent...
>
>
> The way I see it, case insensitive languages just show they are aging.

The way I see it case insensitivity allows me to avoid dealing with
unimportant but irritating baggage.

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[DuckE]

> Case sensitivity enforces consistency among code produced by different
> programmmers. Imagine programmer A insists on writing runTimeeXception
> and programmer B insits writing runtimeexcception. Maybe you  yourself
> on Monday decides to write runtimeException and on Tuesday,
> RUNTIMEEXCEPTION. Now, that is sick. Well, if you can do anything
> *useFUl* in Ada, you don't have to write it in Java.
>

I disagree.  Case sensitivity would enforce consistency among code produced
by different programmers if and only if the occurrance of two variables with
the same spelling and different case produced a compilation time error.

Otherwise:

  Programmer #1 uses "runtimeException"
  Programmer #2 uses "runTimeException"
  Programmer #3 uses "RunTimeException"

Refer to different values, which might or might not be correct.

BTW: I have seen 'C' code with little traces of the difficulty with case
sensitivity that were compensated for by adding:

#define runTimeError runtimeError

FWIW

SteveD

Re: Three simple questions

[Larry Kilgallen]

In article <BF259CEB83D72A27.E3DDC61E336AB14F.68F3B83D3BAA6ABF@lp.airnews.net>, Frank Christiny <fchris@pdq.net> writes:

>> >2.  What is the rationale for case-insensitivity in the language?
>> 
>> At least one reason is for safety against misspelling.
> [snip]
> 
>       Whoa!  So you are saying the original designers of the language
>    actually sat down and decided the majority of us programmers were
>    dislexic or something?   I am sure there is more to it than that!

There is almost nothing in the Ada design related to "the majority" of
programmers.  The goal is more oriented toward "worst case" or "serving
all".  If _some_ programmer would have trouble maintaining the safety
aspects of code you have written, that would be bad for people riding
the particular airplane or railroad train you have programmed.

As it happens I have maintained code I wrote ten years earlier.
All the checking built into the language has been quite helpful
in reducing the number of new defects I added due to having been
away from the design for some time.

=======

By the way, your original question at the top of this page struck me
as quite odd.  While C/C++ uses case sensitivity, I always understood
that to be part of the Topsy-like development history of the Unix
operating system.  To me, it is case-sensitivity that should be
(but cannot be) rationalized, as there is never a good reason for
allowing TheItem and theItem to be separate variables.

Case for case-sensitivity (Was: Three simple questions)

[Frank Christiny]

Larry Kilgallen wrote:
> By the way, your original question at the top of this page struck me
> as quite odd.  While C/C++ uses case sensitivity, I always understood
> that to be part of the Topsy-like development history of the Unix
> operating system.  To me, it is case-sensitivity that should be
> (but cannot be) rationalized, as there is never a good reason for
> allowing TheItem and theItem to be separate variables.

      Unix topsy-turvy?  Man, now you got me going   ;-)
      As opposed to the Microsoft world, Unix is the doldrums!

      You ask me for the case for case-sensitivity and John English
   says that:

>Since humans consider 'D' and 'd' to be variant representations of the
>same letter, why shouldn't programming languages?

      I can address both those questions in this post.

      Not being a partisan of case-sensitivity I can nevertheless
   assert that, first of all, Humans DO care for case sensitivity,
   otherwise why have case-sensitivity in the grammar to begin with?
   Consider the following "overloaded" sentences:

   In the Company of my friend.       In the company of my friend.
   Ada presentation today.            ADA presentation today.
   Standing by the Bank.              Standing by the bank.

      As for the computer languages, consider this:

1. Case sensitivity allows for a greater array of variable naming
   and semantics.  In case-insensitive languages you cannot reuse a
   chunk of the english vocabulary because it has already been
   "privatized".  Not only can you not use "while", but "While", or
   "WHILE", etc.  Once you define "My_List", the type, you cannot
   declare "my_List", the object.

   (Weak point.  Of course it's weak.  I told you, I am not out
   to convince anyone about case-sensitivity).

2. Case sensitivity standardizes the coding practice of the
   internals.  Some Ada samples of the different practices I have
   been able to observe just two months into my introduction to the
   language:

   WITH Ada.Text_IO               with Ada.Text_IO
   PROCEDURE Some_Procedure       procedure Some_Procedure
   my_int : INTEGER;              My_Int : integer;
   BEGIN                          begin
      NULL:                          null;
   END Some_Procedure;            end Some_Procedure;

   With Ada.Text_IO
   procedure Some_Procedure
   my_int : INTEGER;
   begin
      NULL;
   end Some_Procedure;

      The first two versions are at least self-consistent.  The
   galling part is that the code I have to actually maintain at work
   is the of the latter flavor!  Maybe because it was the result of
   many tinkerers prior to me.  So, what do I do in this case?
   Follow the manglers or establish my own personal touch, just to
   be contrary, ah?  The language manual and rationale do not have
   any suggestions on this regard, as far as I know.

      Dis I convince you?  Of course not.  You are OK though.

-- 
Frank Christiny                       fchris@pdq.net
Sr. Software Engineer                 Lockheed Martin Space Operations
Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

Re: Case for case-sensitivity (Was: Three simple questions)

[tmoran]

>   The language manual and rationale do not have any suggestions on
>this regard, as far as I know.
  But "Ada 95 Quality and Style" does.

Re: Case for case-sensitivity (Was: Three simple questions)

[mjsilva]

In article
<FF7E28B976F0121D.F97167433B3E2BF3.4FD17582438B6D33@lp.airnews.net>,
  Frank Christiny <fchris@pdq.net> wrote:

>       As for the computer languages, consider this:
>
> 1. Case sensitivity allows for a greater array of variable naming
>    and semantics.  In case-insensitive languages you cannot reuse a
>    chunk of the english vocabulary because it has already been
>    "privatized".  Not only can you not use "while", but "While", or
>    "WHILE", etc.

Surely this is not a serious burden!  When I use C I would never think
to use different-case reserved words for variables.

>  Once you define "My_List", the type, you cannot
>    declare "my_List", the object.

I developed this habit in C, but now I realize I mostly did it from
laziness.  In your example My_List is a type while my_List is an
instance of that type being used for a specific purpose.  With a little
thought "my_List" can no doubt be given a more helpful name such
as "Input_list" or Student_list"; something that better indicates the
function of this particular My_List.

Mike


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Case for case-sensitivity (Was: Three simple questions)

[John Magness]

mjsilva@my-deja.com wrote:

> In article
> <FF7E28B976F0121D.F97167433B3E2BF3.4FD17582438B6D33@lp.airnews.net>,
>   Frank Christiny <fchris@pdq.net> wrote:
>
> >       As for the computer languages, consider this:
> >
> > 1. Case sensitivity allows for a greater array of variable naming
> >    and semantics.  In case-insensitive languages you cannot reuse a
> >    chunk of the english vocabulary because it has already been
> >    "privatized".  Not only can you not use "while", but "While", or
> >    "WHILE", etc.
>
> Surely this is not a serious burden!  When I use C I would never think
> to use different-case reserved words for variables.
>
> >  Once you define "My_List", the type, you cannot
> >    declare "my_List", the object.
>
> I developed this habit in C, but now I realize I mostly did it from
> laziness.  In your example My_List is a type while my_List is an
> instance of that type being used for a specific purpose.  With a little
> thought "my_List" can no doubt be given a more helpful name such
> as "Input_list" or Student_list"; something that better indicates the
> function of this particular My_List.
>
> Mike
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

type my_list_type is ......   or type my_list_t is ...

    my_list : my_list_type;

I know many Ada programmers who suffix type names like this.  Including
myself on occasion. No big deal.
John

Re: Case for case-sensitivity (Was: Three simple questions)

[David C. Hoos, Sr.]

There _are_ some recommendations for Ada code formatting
and style (including capitalization) in
http://www.adaic.org/docs/style-guide/95style/html/cover.html

"Frank Christiny" <fchris@pdq.net> wrote in message
news:FF7E28B976F0121D.F97167433B3E2BF3.4FD17582438B6D33@lp.airnews.net...
> Larry Kilgallen wrote:
> > By the way, your original question at the top of this page struck me
> > as quite odd.  While C/C++ uses case sensitivity, I always understood
> > that to be part of the Topsy-like development history of the Unix
> > operating system.  To me, it is case-sensitivity that should be
> > (but cannot be) rationalized, as there is never a good reason for
> > allowing TheItem and theItem to be separate variables.
>
>       Unix topsy-turvy?  Man, now you got me going   ;-)
>       As opposed to the Microsoft world, Unix is the doldrums!
>
>       You ask me for the case for case-sensitivity and John English
>    says that:
>
> >Since humans consider 'D' and 'd' to be variant representations of the
> >same letter, why shouldn't programming languages?
>
>       I can address both those questions in this post.
>
>       Not being a partisan of case-sensitivity I can nevertheless
>    assert that, first of all, Humans DO care for case sensitivity,
>    otherwise why have case-sensitivity in the grammar to begin with?
>    Consider the following "overloaded" sentences:
>
>    In the Company of my friend.       In the company of my friend.
>    Ada presentation today.            ADA presentation today.
>    Standing by the Bank.              Standing by the bank.
>
>       As for the computer languages, consider this:
>
> 1. Case sensitivity allows for a greater array of variable naming
>    and semantics.  In case-insensitive languages you cannot reuse a
>    chunk of the english vocabulary because it has already been
>    "privatized".  Not only can you not use "while", but "While", or
>    "WHILE", etc.  Once you define "My_List", the type, you cannot
>    declare "my_List", the object.
>
>    (Weak point.  Of course it's weak.  I told you, I am not out
>    to convince anyone about case-sensitivity).
>
> 2. Case sensitivity standardizes the coding practice of the
>    internals.  Some Ada samples of the different practices I have
>    been able to observe just two months into my introduction to the
>    language:
>
>    WITH Ada.Text_IO               with Ada.Text_IO
>    PROCEDURE Some_Procedure       procedure Some_Procedure
>    my_int : INTEGER;              My_Int : integer;
>    BEGIN                          begin
>       NULL:                          null;
>    END Some_Procedure;            end Some_Procedure;
>
>    With Ada.Text_IO
>    procedure Some_Procedure
>    my_int : INTEGER;
>    begin
>       NULL;
>    end Some_Procedure;
>
>       The first two versions are at least self-consistent.  The
>    galling part is that the code I have to actually maintain at work
>    is the of the latter flavor!  Maybe because it was the result of
>    many tinkerers prior to me.  So, what do I do in this case?
>    Follow the manglers or establish my own personal touch, just to
>    be contrary, ah?  The language manual and rationale do not have
>    any suggestions on this regard, as far as I know.
>
>       Dis I convince you?  Of course not.  You are OK though.
>
> --
> Frank Christiny                       fchris@pdq.net
> Sr. Software Engineer                 Lockheed Martin Space Operations
> Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

Re: Case for case-sensitivity (Was: Three simple questions)

[Ted Dennison]

In article
<FF7E28B976F0121D.F97167433B3E2BF3.4FD17582438B6D33@lp.airnews.net>,
  Frank Christiny <fchris@pdq.net> wrote:
> 1. Case sensitivity allows for a greater array of variable naming
>    and semantics.  In case-insensitive languages you cannot reuse a

{As if in a dream, you see the master before you. He smiles and
answers.}

Ahhh, Grasshopper. Code may be run and debugged many times, but is
written just once. Adado is to sacriface the one for the many.
{You hear a gong, and your vision clears once again.}


One thing you have to understand about Ada philosopy ("Adado") is that
convienience of the writer is not considered a primary goal. The
convienence of the maintainer is paramount. This can be a major
stumbling block for those schooled in language like C, that favor the
writer.

Look at things from that perscpective, and the choice may start to make
more sense. it is certianly *not* in the best intrests of maintainers to
allow keywords as variable names.

>
> 2. Case sensitivity standardizes the coding practice of the
>    internals.  Some Ada samples of the different practices I have

Not true. Its quite common to see C programs where there are several
different naming and casing conventions being used. The only thing that
has to be consistent is the uses of the *same* variable.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html
Day 5 of Free Europe


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Case for case-sensitivity (Was: Three simple questions)

[David Starner]

On Tue, 10 Oct 2000 11:10:57 -0700, Frank Christiny wrote:
>      Unix topsy-turvy?  Man, now you got me going   ;-)
>      As opposed to the Microsoft world, Unix is the doldrums!

Please don't go there. 

>      Not being a partisan of case-sensitivity I can nevertheless
>   assert that, first of all, Humans DO care for case sensitivity,
>   otherwise why have case-sensitivity in the grammar to begin with?

DO? What does that mean? ;-) Case sensitivity carries grammar and,
less formally, intonation. Its use in English is governed by a set
of (complex) rules, that have no direct analog in progamming.

>2. Case sensitivity standardizes the coding practice of the
>   internals.  Some Ada samples of the different practices I have
>   been able to observe just two months into my introduction to the
>   language:
>
>   WITH Ada.Text_IO               with Ada.Text_IO
>   PROCEDURE Some_Procedure       procedure Some_Procedure
>   my_int : INTEGER;              My_Int : integer;
>   BEGIN                          begin
>      NULL:                          null;
>   END Some_Procedure;            end Some_Procedure;
>
>   With Ada.Text_IO
>   procedure Some_Procedure
>   my_int : INTEGER;
>   begin
>      NULL;
>   end Some_Procedure;

In a way, this is an argument for case-insensitivity. In a case sensitive
language, you would still have the ambigious casing on stuff like my_int,
but now it would matter. A lot of C code that used varying cases has coding
standards to keep the casing consistent - that wouldn't hurt for your Ada
code.

Anyway, the code in the upper right hand corner seems to correspond with
what I've been told is good. If you're using GNAT, -gnaty will enforce roughly
that casing, as well as tons of other style rules (which you can turn off and
on one by one, so, for example, you only get the casing rules.)

-- 
David Starner - dstarner98@aasaa.ofe.org
http/ftp: dvdeug.dhis.org
And crawling, on the planet's face, some insects called the human race.
Lost in space, lost in time, and meaning.
	-- RHPS

Re: Case for case-sensitivity (Was: Three simple questions)

[John English]

What a lot of bandwidth for three "simple" questions...

As my final contribution to this debate, here is a counterexample
of a sort from Mark Twain's essay, "The Awful German Language":

  "In German, all Nouns begin with a capital letter. Now that is
   a good idea; and a good idea, in this language, is necessarily
   conspicuous from its lonesomeness. I consider this capitalizing
   of nouns a good idea, because by reason of it you are almost
   always able to tell a noun the minute you see it. You fall into
   error occasionally, because you mistake the name of a person for
   the name of a thing, and waste a good deal of time trying to dig
   a meaning out of it. German names almost always do mean something,
   and this helps to deceive the student. I translated a passage one
   day, which said that "the infuriated tigress broke loose and utterly
   ate up the unfortunate fir-forest," (Tannenwald.) When I was girding
   up my loins to doubt this, I found out that Tannenwald, in this
   instance, was a man's name."

:-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Case for case-sensitivity (Was: Three simple questions)

[dmitry6243]

In article
<FF7E28B976F0121D.F97167433B3E2BF3.4FD17582438B6D33@lp.airnews.net>,
  Frank Christiny <fchris@pdq.net> wrote:

> 1. Case sensitivity allows for a greater array of variable naming
>    and semantics.  In case-insensitive languages you cannot reuse a
>    chunk of the english vocabulary because it has already been
>    "privatized".  Not only can you not use "while", but "While", or
>    "WHILE", etc.  Once you define "My_List", the type, you cannot
>    declare "my_List", the object.
>
>    (Weak point.  Of course it's weak.  I told you, I am not out
>    to convince anyone about case-sensitivity).
>
> 2. Case sensitivity standardizes the coding practice of the
>    internals.

Yes! But to make it a real nightmare we must go further. For instance,
to develop a language, say, SUmAtrA. The source code will be given in
HTML format and all identifiers will be font-color-size-style-sensitive
(the first release). In the second release (Service Pack 666a),
identifiers will be specified as GIF images.

--
Regards,
Dmitry Kazakov


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Case for case-sensitivity (Was: Three simple questions)

[John English]

Frank Christiny wrote:
>       Not being a partisan of case-sensitivity I can nevertheless
>    assert that, first of all, Humans DO care for case sensitivity,
>    otherwise why have case-sensitivity in the grammar to begin with?
>    Consider the following "overloaded" sentences:
> 
>    In the Company of my friend.       In the company of my friend.
>    Ada presentation today.            ADA presentation today.
>    Standing by the Bank.              Standing by the bank.

I fail to see your point -- these would all be resolved by context,
surely?

> [...snip...]
> 
> 2. Case sensitivity standardizes the coding practice of the
>    internals.  Some Ada samples of the different practices I have
>    been able to observe just two months into my introduction to the
>    language:
> 
>    WITH Ada.Text_IO               with Ada.Text_IO
>    PROCEDURE Some_Procedure       procedure Some_Procedure
>    my_int : INTEGER;              My_Int : integer;
>    BEGIN                          begin
>       NULL:                          null;
>    END Some_Procedure;            end Some_Procedure;
> 
>    With Ada.Text_IO
>    procedure Some_Procedure
>    my_int : INTEGER;
>    begin
>       NULL;
>    end Some_Procedure;
> 
>       The first two versions are at least self-consistent.  The
>    galling part is that the code I have to actually maintain at work
>    is the of the latter flavor!  Maybe because it was the result of
>    many tinkerers prior to me.  So, what do I do in this case?

Run a prettyprinter over the code. That's what tools are for.

>    Follow the manglers or establish my own personal touch, just to
>    be contrary, ah?  The language manual and rationale do not have
>    any suggestions on this regard, as far as I know.

The LRM uses lowercase for reserved words and Capitalised_Names for
identifiers throughout, and the style guide makes this an explicit
recommendation.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Case for case-sensitivity (Was: Three simple questions)

[Frank Christiny]

John English wrote:
> >
> >    In the Company of my friend.       In the company of my friend.
> >    Ada presentation today.            ADA presentation today.
> >    Standing by the Bank.              Standing by the bank.
> 
> I fail to see your point -- these would all be resolved by context,
> surely?

      The point was to emphasize that for a human parser, the
   sentences are different.  Even without the context they are very
   different.  (The river could hardly be expected to have a Bank,
   unless it's the "Left Bank" of course).  The same is true in a
   case-sensitive language.  You can do "lazy" stuff like that there,
   such as I mentioned earlier; and, without regard for the context.

> > 2. Case sensitivity standardizes the coding practice of the
> >    internals.  Some Ada samples of the different practices I have
> >    been able to observe just two months into my introduction to the
> >    language:
> >
> >    WITH Ada.Text_IO               with Ada.Text_IO
> >    PROCEDURE Some_Procedure       procedure Some_Procedure
> >    my_int : INTEGER;              My_Int : integer;
> >    BEGIN                          begin
> >       NULL:                          null;
> >    END Some_Procedure;            end Some_Procedure;
> >
> >    With Ada.Text_IO
> >    procedure Some_Procedure
> >    my_int : INTEGER;
> >    begin
> >       NULL;
> >    end Some_Procedure;
> >
> >       The first two versions are at least self-consistent.  The
> >    galling part is that the code I have to actually maintain at work
> >    is the of the latter flavor!  Maybe because it was the result of
> >    many tinkerers prior to me.  So, what do I do in this case?
> 
> Run a prettyprinter over the code. That's what tools are for.

      Sure, but you missed the point again.  The language does look
   confusing to a case-sensitive newcomer.  I guess the same happens
   going the other way around.  In any case, thanks to all of you
   guys' input I've begun to see the rationale behind
   case-insensitivity and, most of all, I recognize it seems to work.
   It shows to what extent Adaites would go to avert preventable
   errors.  Now, all I need to do is get used to it...

-- 
Frank Christiny                       fchris@pdq.net
Sr. Software Engineer                 Lockheed Martin Space Operations
Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

Re: Case for case-sensitivity (Was: Three simple questions)

[Larry Kilgallen]

In article <D4BEB678D89A64A9.0BF2E74EC8861347.89ADE1DE3BC27E76@lp.airnews.net>, Frank Christiny <fchris@pdq.net> writes:
> John English wrote:
>> >
>> >    In the Company of my friend.       In the company of my friend.
>> >    Ada presentation today.            ADA presentation today.
>> >    Standing by the Bank.              Standing by the bank.
>> 
>> I fail to see your point -- these would all be resolved by context,
>> surely?
> 
>       The point was to emphasize that for a human parser, the
>    sentences are different.  Even without the context they are very
>    different.  (The river could hardly be expected to have a Bank,
>    unless it's the "Left Bank" of course).  The same is true in a
>    case-sensitive language.  You can do "lazy" stuff like that there,
>    such as I mentioned earlier; and, without regard for the context.
> 
>> > 2. Case sensitivity standardizes the coding practice of the
>> >    internals.  Some Ada samples of the different practices I have
>> >    been able to observe just two months into my introduction to the
>> >    language:
>> >
>> >    WITH Ada.Text_IO               with Ada.Text_IO
>> >    PROCEDURE Some_Procedure       procedure Some_Procedure
>> >    my_int : INTEGER;              My_Int : integer;
>> >    BEGIN                          begin
>> >       NULL:                          null;
>> >    END Some_Procedure;            end Some_Procedure;
>> >
>> >    With Ada.Text_IO
>> >    procedure Some_Procedure
>> >    my_int : INTEGER;
>> >    begin
>> >       NULL;
>> >    end Some_Procedure;
>> >
>> >       The first two versions are at least self-consistent.  The
>> >    galling part is that the code I have to actually maintain at work
>> >    is the of the latter flavor!  Maybe because it was the result of
>> >    many tinkerers prior to me.  So, what do I do in this case?
>> 
>> Run a prettyprinter over the code. That's what tools are for.
> 
>       Sure, but you missed the point again.  The language does look
>    confusing to a case-sensitive newcomer.  I guess the same happens
>    going the other way around.  In any case, thanks to all of you
>    guys' input I've begun to see the rationale behind
>    case-insensitivity and, most of all, I recognize it seems to work.
>    It shows to what extent Adaites would go to avert preventable
>    errors.  Now, all I need to do is get used to it...
> 
> -- 
> Frank Christiny                       fchris@pdq.net
> Sr. Software Engineer                 Lockheed Martin Space Operations
> Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

Re: Case for case-sensitivity (Was: Three simple questions)

[nickerson]

In article <D4BEB678D89A64A9.0BF2E74EC8861347.89ADE1DE3BC27E76@lp.airnews.net>, 
Frank Christiny <fchris@pdq.net> writes:

|>> >
|>> >    In the Company of my friend.       In the company of my friend.
|>> >    Ada presentation today.            ADA presentation today.
|>> >    Standing by the Bank.              Standing by the bank.
..
|>      The point was to emphasize that for a human parser, the
|>   sentences are different.  Even without the context they are very
|>   different.  (The river could hardly be expected to have a Bank,
|>   unless it's the "Left Bank" of course).  The same is true in a
|>   case-sensitive language.  You can do "lazy" stuff like that there,
|>   such as I mentioned earlier; and, without regard for the context.

yes, we have human parsers and computer parsers; that is the real 
point I believe; humans do better with this kind of context than 
computers do; consider complexity however; the fact is that humans 
also do a poor job at times, get confused, and get overwhelmed 
by complexity that would never faze a computer; confusion while 
programming is a very bad thing; so we simplify and wipe out an 
annoying set of errors by going with a case-insensitve language;

meaningful names aside, how clever would it be to use as my variables 
the 5 character, all {a,A}; that gives me 2**5=32 choices which is
plenty for local variables {aaaaa,aaaaA,aaaAa,aaaAA, ..., AAAAA};
horrid cleverness perhaps for a person and trivial for the machine; 

previous points on valuing the reader over the writer are also well 
taken; (aside: if we're so good parsing then why are there so many 
Usenet misunderstandings and why did emoticons get invented;)

|>      Sure, but you missed the point again.  The language does look
|>   confusing to a case-sensitive newcomer.  I guess the same happens
|>   going the other way around.  In any case, thanks to all of you
|>   guys' input I've begun to see the rationale behind
|>   case-insensitivity and, most of all, I recognize it seems to work.
|>   It shows to what extent Adaites would go to avert preventable
|>   errors.  Now, all I need to do is get used to it...
|>-- 
|>Frank Christiny                       fchris@pdq.net
|>Sr. Software Engineer                 Lockheed Martin Space Operations
|>Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

each language does take some getting used to; I used FORTRAN and
PL/I and had never considered case sensitivity before being exposed
to C on the VAX; the first time I got bitten with i /= I amazed 
naive me; but then it takes a while to believe that it's ok to program 
in lower case RATHER THAN EVERYTHING BUT PRINTED "Error Messages" IN 
UPPER CASE; (which humorously brings me back to emoticons - nowdays 
this is always derided as shouting rather than being a STYLE);

--bn (Bart Nickerson)
nickerson@pundit.ds.boeing.com
(206) 662-0183

Re: Case for case-sensitivity (Was: Three simple questions)

[Robert Dewar]

In article <G2FuBE.J9K@news.boeing.com>,
  nickerson@pundit.ds.boeing.com () wrote:
> meaningful names aside, how clever would it be to use as my
variables
> the 5 character, all {a,A}; that gives me 2**5=32 choices
which is
> plenty for local variables {aaaaa,aaaaA,aaaAa,aaaAA, ...,
AAAAA};
> horrid cleverness perhaps for a person and trivial for the
machine;


Reminds me of a code obfuscator I once saw for COBOL that
replaced all variable names with 30 character strings consisting
entirely of O's and 0's (letter oh and digit zero).

Of course you can still do *that* in Ada which is a reminder
that if you are determined to obfuscate, then the language
cannot stop you, so the argument with a's and A's above is
a little bit bogus :-)



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Case for case-sensitivity (Was: Three simple questions)

[Jean-Pierre Rosen]

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


"Robert Dewar" <robert_dewar@my-deja.com> a �crit dans le message news: 8sb2d2$hnb$1@nnrp1.deja.com...
> Reminds me of a code obfuscator I once saw for COBOL that
> replaced all variable names with 30 character strings consisting
> entirely of O's and 0's (letter oh and digit zero).
>
> Of course you can still do *that* in Ada which is a reminder
> that if you are determined to obfuscate, then the language
> cannot stop you, so the argument with a's and A's above is
> a little bit bogus :-)
>
Of course, a code obfuscator for Ada could go far beyond what can be done in other languages, with clever use of overloading (all
subprograms called A unless they share a profile), redefining operators, etc.... Another proof that Ada is *far* above other
languages ;-)

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: Case for case-sensitivity (Was: Three simple questions)

[Ken Garlington]

"Frank Christiny" <fchris@pdq.net> wrote in message
news:FF7E28B976F0121D.F97167433B3E2BF3.4FD17582438B6D33@lp.airnews.net...

>       Not being a partisan of case-sensitivity I can nevertheless
>    assert that, first of all, Humans DO care for case sensitivity,
>    otherwise why have case-sensitivity in the grammar to begin with?

as a counter-example, the human e e cummings didn't care for case
sensitivity, yet seemed to communicate reasonably well.

as a second counter-example, unix is case-sensitive... yet only lower-case
seems to be used for most commands, file names, etc...

(still contemplating Bank and bank...)

Re: Three simple questions

[Larry Elmore]

John McCabe <john@assen.demon.co.uk.nospam> wrote in message
news:39e2588f.21565740@news.demon.co.uk...
> Frank Christiny <fchris@pdq.net> wrote:
>
> >1.  What is the correct pronunciation of Dr. Ichbiah's name?
> >    Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
> >    final "h" is silent?
>
> Does it matter?

It can -- if for some odd reason one wants to mention his name (or more
liekly some other word with non-obvious pronunciation in English) in a
conversation, one would like to be able to pronounce it correctly and not
look unnecessarily ignorant to those who do know how to correctly pronounce
that word (and who might not even understand what you mean without further
explanation because your pronunciation is so far from the norm).

Larry

Re: Three simple questions

[Ed Falis]

Ish'-bee-uh

- Ed

Larry Elmore wrote:
> John McCabe <john@assen.demon.co.uk.nospam> wrote in message
> news:39e2588f.21565740@news.demon.co.uk...
>> Frank Christiny <fchris@pdq.net> wrote:
>>
>> >1.  What is the correct pronunciation of Dr. Ichbiah's name?
>> >    Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
>> >    final "h" is silent?
>>
>> Does it matter?
>
> It can -- if for some odd reason one wants to mention his name (or
> more
> liekly some other word with non-obvious pronunciation in English) in a
> conversation, one would like to be able to pronounce it correctly and
> not
> look unnecessarily ignorant to those who do know how to correctly
> pronounce
> that word (and who might not even understand what you mean without
> further
> explanation because your pronunciation is so far from the norm).
>
> Larry
>
>

Re: Three simple questions

[Jeff Carter]

Ed Falis wrote:
> 
> Ish'-bee-uh

Being French, 3 rules apply: CH is pronounced like SH in English fish; I
is pronounced sort of like English EE in bee; and the accent is always
on the last syllable. This is why it is pronounced eesh-bee-UH when he
is at home.

> 
> - Ed
> 
> Larry Elmore wrote:
> > John McCabe <john@assen.demon.co.uk.nospam> wrote in message
> > news:39e2588f.21565740@news.demon.co.uk...
> >> Frank Christiny <fchris@pdq.net> wrote:
> >>
> >> >1.  What is the correct pronunciation of Dr. Ichbiah's name?
> >> >    Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
> >> >    final "h" is silent?

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail

Re: Three simple questions

[Philippe Torres]

Jeff Carter wrote:
> 
> Ed Falis wrote:
> >
> > Ish'-bee-uh
> 
> Being French, 3 rules apply: CH is pronounced like SH in English fish; I
> is pronounced sort of like English EE in bee; and the accent is always
> on the last syllable. This is why it is pronounced eesh-bee-UH when he
> is at home.

More like eesh-bee-AR (like in grammar).

Philippe

Re: Three simple questions

[Stefan Skoglund]

John McCabe wrote:
> At least one reason is for safety against misspelling. In
> case-sensitive languages e.g. in C, if I had
> 
>    int an_Int;
>    :
>    <various other declarations
> 
>    for (An_Int = 1; An_Int < 10; An_Int++)
>    :
>    blah blah
> 
> and compile this I will get an error because of undefined An_Int. The
> risk here is that I could just go to the declarations list and add:
> 
>    int An_Int;
> 
> rather than realising that I've just written an_Int incorrectly.

The problem in this case is implicit creation of new variables
and whats more those variables is always a int ie
the compiler wont bitch about the assignment.

Re: Three simple questions

[Pascal Obry]

Frank Christiny <fchris@pdq.net> writes:

> Friends,
> 
> Having arrived recently into the green Adian world, I am trying to
> assimilate all there is to know about this powerful, unfairly
> maligned computer language.  Most questions I have been able to
> answer from the FAQs here and there but there are three (so far) that
> have gone unanswered:
> 
> 1.  What is the correct pronunciation of Dr. Ichbiah's name?
>     Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
>     final "h" is silent?

It is like in "each" and yes the "h" is silent.

> 
> 2.  What is the rationale for case-insensitivity in the language?
>     I am beginning to think it is mostly for historical reasons
>     (some machines didn't have two case letters way back then, etc.).
>     Are there any real technical reasons for why this is so even
>     after Ada95, besides preserving backwards compatibilty?

Safety and readability. Why should this_is_a_long_var be differente to
THIS_IS_A_Long_Var ? Human should not care about case-sensitive name in
a program but about the meaning of it... just my 2cents :)


> 3.  How can one block-comment in Ada?
>     It can become cumbersome sometimes, adding all those "--"s in
>     front of a large block of code one wants to "test out" on the fly.
>     Again, are there any good technical-engineering reasons why this
>     feature was left out?

Any good IDE will do that. AdaGIDE, ada-mode, Glide...

Pascal.

-- 

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: p.obry@der.edf.fr         |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|         http://perso.wanadoo.fr/pascal.obry
--|
--|   "The best way to travel is by means of imagination"

Re: Three simple questions

[Jeff Carter]

Pascal Obry wrote:
> 
> Frank Christiny <fchris@pdq.net> writes:
> 
> > Friends,
> >
> > Having arrived recently into the green Adian world, I am trying to
> > assimilate all there is to know about this powerful, unfairly
> > maligned computer language.  Most questions I have been able to
> > answer from the FAQs here and there but there are three (so far) that
> > have gone unanswered:
> >
> > 1.  What is the correct pronunciation of Dr. Ichbiah's name?
> >     Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
> >     final "h" is silent?
> 
> It is like in "each" and yes the "h" is silent.

I find this reply puzzling, since I think Pascal Obry is French. The CH
in French is pronounced like the SH in English fish (there may be
exceptions to this, but I've never encountered them).

-- 
Jeff Carter
"Perfidious English mouse-dropping hoarders."
Monty Python & the Holy Grail

Re: Three simple questions

[Keith Thompson]

Pascal Obry <p.obry@der.edf.fr> writes:
[...]
> > 3.  How can one block-comment in Ada?
> >     It can become cumbersome sometimes, adding all those "--"s in
> >     front of a large block of code one wants to "test out" on the fly.
> >     Again, are there any good technical-engineering reasons why this
> >     feature was left out?
> 
> Any good IDE will do that. AdaGIDE, ada-mode, Glide...

Actually, any decent text editor should allow you to do this fairly
easily.  Certainly both vi and emacs do.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Three simple questions

[Ken Garlington]

"Frank Christiny" <fchris@pdq.net> wrote in message
news:2BED68CA963D6D55.A78776F656DA0452.75A61ED22116F1B6@lp.airnews.net...
> Friends,
>
> Having arrived recently into the green Adian world, I am trying to
> assimilate all there is to know about this powerful, unfairly
> maligned computer language.  Most questions I have been able to
> answer from the FAQs here and there but there are three (so far) that
> have gone unanswered:
>
> 1.  What is the correct pronunciation of Dr. Ichbiah's name?
>     Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
>     final "h" is silent?

I believe it is something like "itch-bee-ahhhh," but I don't know for sure.

> 2.  What is the rationale for case-insensitivity in the language?
>     I am beginning to think it is mostly for historical reasons
>     (some machines didn't have two case letters way back then, etc.).
>     Are there any real technical reasons for why this is so even
>     after Ada95, besides preserving backwards compatibilty?

A hint as to the answer to this question may lie in Section 2 of the Ada83
Rationale:

"The allowed characters belong to the ISO (ASCII) character set, and the
text of a program may contain both upper case and lower case letters. For
portability reasons, it is possible to write any program in a 56 character
subset of the ISO character set.... Reserved words other than operators
cannot be redeclared, and operators can only be redeclared as operators and
with the same precedence. Hence programmers cannot write obscure programs by
redefining the meaning of words that play an important syntactic role in the
definition of the structure of Ada texts.... an underline character may
appear between two other characters of an identifier. This underline is
significant and plays the role of the space in ordinary prose (but without
breaking the integrity of the identifier). The need for such an underline is
seen from good choices of names such as BYTES_PER_WORD
rather than BYTESPERWORD. Furthermore the significance of the underline
makes SPACE_PER_SON a different identifier from SPACEPERSON or SPACE_PERSON
and A_NYLON_GRIP different from ANY_LONG_RIP."

-- http://www.adahome.com/LRM/83/Rationale/Text/ratl-c2.hlp

So, at least part of the argument for case-insensitivity could be backwards
compatibility (as also described in section 2.1 of the Ada83 standard).
However, it could also be argued that allowing the following might be
considered "obscure" programming:

procedure Launch (Person : String);
procedure Launch (Space : Positive);

SpacePerson: String;
SpacePerSon: Positive;

...

Launch (SpacePerson);
-- compiles (and maybe executes) without an explicit error message.
-- Is it what was meant? Will anyone notice?

> 3.  How can one block-comment in Ada?
>     It can become cumbersome sometimes, adding all those "--"s in
>     front of a large block of code one wants to "test out" on the fly.
>     Again, are there any good technical-engineering reasons why this
>     feature was left out?

This one is a little easier to answer. Again, from section 2 of the
Rationale:

"Comments may appear alone on a line or at the end of a line. As an end of
line remark, the comment should appear as an explanation of the preceding
text -- hence the use of a double hyphen (doing duty for a dash) is natural
and appropriate, as illustrated by this sentence. For simplicity, a space is
not allowed between the two hyphens. No form of embedded comments (within a
line of text) is provided, as their utility is insufficient to justify the
extra complexity. Single comments that are larger than one line are not
provided. Such comments would require a closing comment delimiter and this
would again raise the dangers associated with the (unintentional) omission
of the closing delimiter: entire sections of a program could be ignored by
the compiler without the programmer realizing it, so that the program would
not mean what he thinks. Long comments can be written as a succession of
single line comments, thus combining elegance with safety."

>
> Regards,
> --
> Frank Christiny                       fchris@pdq.net
> Sr. Software Engineer                 Lockheed Martin Space Operations
> Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

Re: Three simple questions

[Pat Rogers]

You should have a look at the Rationale document for Ada83.  It
answers these questions and many like them, apart from the first
("ish' bee ah").



"Frank Christiny" <fchris@pdq.net> wrote in message
news:2BED68CA963D6D55.A78776F656DA0452.75A61ED22116F1B6@lp.airnews.net
...
> Friends,
>
> Having arrived recently into the green Adian world, I am trying to
> assimilate all there is to know about this powerful, unfairly
> maligned computer language.  Most questions I have been able to
> answer from the FAQs here and there but there are three (so far)
that
> have gone unanswered:
>
> 1.  What is the correct pronunciation of Dr. Ichbiah's name?
>     Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
>     final "h" is silent?
>
> 2.  What is the rationale for case-insensitivity in the language?
>     I am beginning to think it is mostly for historical reasons
>     (some machines didn't have two case letters way back then,
etc.).
>     Are there any real technical reasons for why this is so even
>     after Ada95, besides preserving backwards compatibilty?
>
> 3.  How can one block-comment in Ada?
>     It can become cumbersome sometimes, adding all those "--"s in
>     front of a large block of code one wants to "test out" on the
fly.
>     Again, are there any good technical-engineering reasons why this
>     feature was left out?
>
> Regards,
> --
> Frank Christiny                       fchris@pdq.net
> Sr. Software Engineer                 Lockheed Martin Space
Operations
> Houston, Texas, USA                   http://freeweb.pdq.net/fchris/
>

Re: Three simple questions

[Marin David Condic]

Frank Christiny wrote:

> 2.  What is the rationale for case-insensitivity in the language?
>     I am beginning to think it is mostly for historical reasons
>     (some machines didn't have two case letters way back then, etc.).
>     Are there any real technical reasons for why this is so even
>     after Ada95, besides preserving backwards compatibilty?

Ada is not case-sensitive because case-sensitivity is a bad idea. In
normal English usage, there is no significant difference between "Marin"
or "MARIN" or mArIn". Readers would interpret that to mean a reference to
me. Identifiers in a program are likely to be similarly interpreted on
cursory inspection, so it would be a bad idea to have "x" mean an entirely
different variable than "X". Too much opportunity for subtle bugs.

Case sensitivity in a language or OS is an abomination and those
responsible should be kept from getting into the gene pool through some
sort of sterilization program. But that's just my guarded, reserved,
polite opinion. Sometime ask me how I *really* feel. :-)

>
> 3.  How can one block-comment in Ada?
>     It can become cumbersome sometimes, adding all those "--"s in
>     front of a large block of code one wants to "test out" on the fly.
>     Again, are there any good technical-engineering reasons why this
>     feature was left out?

There are no "Open/Close" comment delimiters. Some of the Ada sensitive
editors will let you highlight a block of text and comment/uncomment it in
one swell foop. Weakness or Strength? You be the judge.

MDC
--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Three simple questions

[Keith Thompson]

Marin David Condic <mcondic.nospam@acm.org> writes:
[...]
> Ada is not case-sensitive because case-sensitivity is a bad idea. In
> normal English usage, there is no significant difference between "Marin"
> or "MARIN" or mArIn".

The first is your name, the second is your name shouted, and the third
is your name in a ransom note.

And then of course there's "polish" vs. "Polish".

8-)}

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Three simple questions

[Marin David Condic]

Ahhhhh.... So you admit that in all three cases, it remains *my*name*! :-) The
identifier here references the same object (actually, "subject", but thats
philosophy) I didn't say character case was irrelevent to understanding.
Obviously, we invented upper and lower case to be able to change some
characteristics of the words we were representing. But seldom does character
case imply a complete change of meaning.

I'll admit you've got me there with Polish and polish. :-)

MDC

Keith Thompson wrote:

> Marin David Condic <mcondic.nospam@acm.org> writes:
> [...]
> > Ada is not case-sensitive because case-sensitivity is a bad idea. In
> > normal English usage, there is no significant difference between "Marin"
> > or "MARIN" or mArIn".
>
> The first is your name, the second is your name shouted, and the third
> is your name in a ransom note.
>
> And then of course there's "polish" vs. "Polish".
>
> 8-)}

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Three simple questions

[Wes Groleau]

> > And then of course there's "polish" vs. "Polish".

And in order to avoid confusion, capitalization rules are
suspended when the word starts a sentence.

"polish the silver."  NEVER   "Polish the silver."

Ada should work the same as English, nye?

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: Three simple questions

[David Starner]

On Mon, 16 Oct 2000 14:04:58 +0200, Alejandro Villanueva wrote:
>Wes Groleau wrote:
>
>> > > And then of course there's "polish" vs. "Polish".
>>
>> And in order to avoid confusion, capitalization rules are
>> suspended when the word starts a sentence.
>>
>> "polish the silver."  NEVER   "Polish the silver."
>>
>
>Wops! Are you saying that "polish the silver." is a correct sentence in
>English??? I've always thought that you MUST write the very first letter
>in a sentence in caps!!!

Or so I've always heard. I think he was being sarcastic, because if he wasn't,
he's just wrong. Standard English always requires a capital letter to start
the sentence. (Hacker English, on the other hand, demands that words with 
intrinsic casing (gcc and GCC, for example) keep that casing even at the start
of a sentence.)

-- 
David Starner - dstarner98@aasaa.ofe.org
http://dvdeug.dhis.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: Three simple questions

[Robert A Duff]

dvdeug@x8b4e516e.dhcp.okstate.edu (David Starner) writes:

> (Hacker English, on the other hand, demands that words with 
> intrinsic casing (gcc and GCC, for example) keep that casing even at the start
> of a sentence.)

... which I find rather ugly, I must say.  Another reason not to use the
all-lower-case convention for identifiers.

I find myself going to some trouble to avoid starting a sentence with a
case-senstive name -- "The 'gcc' command compiles Ada programs.", rather
than "'gcc' compiles Ada programs.", which is ugly, or "'Gcc' compiles
Ada programs.", which is wrong.

- Bob

Re: Three simple questions

[Larry Kilgallen]

In article <wcc8zro93vg.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes:

> I find myself going to some trouble to avoid starting a sentence with a
> case-senstive name -- "The 'gcc' command compiles Ada programs.", rather
> than "'gcc' compiles Ada programs.", which is ugly, or "'Gcc' compiles
> Ada programs.", which is wrong.

Isn't it only wrong on case-sensitive operating systems ?

Re: Three simple questions

[Florian Weimer]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> In article <wcc8zro93vg.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes:
> 
> > I find myself going to some trouble to avoid starting a sentence with a
> > case-senstive name -- "The 'gcc' command compiles Ada programs.", rather
> > than "'gcc' compiles Ada programs.", which is ugly, or "'Gcc' compiles
> > Ada programs.", which is wrong.
> 
> Isn't it only wrong on case-sensitive operating systems ?

Yes.  For example, the Revised Report on the Algorithmic Language
Scheme capitalizes identifiers at the beginning of a sentence.
Usually, they are written entirely in lowercase letters, but it
doesn't matter because Scheme is not case-sensitive. ;-)

Re: Three simple questions

[Robert Dewar]

In article <E$AxXKqRbPwQ@eisner.decus.org>,
  Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
> In article <wcc8zro93vg.fsf@world.std.com>, Robert A Duff
<bobduff@world.std.com> writes:
>
> > I find myself going to some trouble to avoid starting a
sentence with a
> > case-senstive name -- "The 'gcc' command compiles Ada
programs.", rather
> > than "'gcc' compiles Ada programs.", which is ugly, or
"'Gcc' compiles
> > Ada programs.", which is wrong.
>
> Isn't it only wrong on case-sensitive operating systems ?

Assuming there was no missing smiley here and that Larry
was serious (which may be a silly assumption), I will say
that I know exactly what Bob means, and I do the same
myself. It is analogous to knowing that the following
sentence is malformed.

E.e. cummings was one of the last centuries most brilliant
poets.

Please no followups on whether you agree with the sentiment :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[Larry Kilgallen]

In article <8sg7bj$fon$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <E$AxXKqRbPwQ@eisner.decus.org>,
>   Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote:
>> In article <wcc8zro93vg.fsf@world.std.com>, Robert A Duff
> <bobduff@world.std.com> writes:
>>
>> > I find myself going to some trouble to avoid starting a
> sentence with a
>> > case-senstive name -- "The 'gcc' command compiles Ada
> programs.", rather
>> > than "'gcc' compiles Ada programs.", which is ugly, or
> "'Gcc' compiles
>> > Ada programs.", which is wrong.
>>
>> Isn't it only wrong on case-sensitive operating systems ?
> 
> Assuming there was no missing smiley here and that Larry
> was serious (which may be a silly assumption), I will say
> that I know exactly what Bob means, and I do the same
> myself. It is analogous to knowing that the following
> sentence is malformed.
> 
> E.e. cummings was one of the last centuries most brilliant
> poets.

Since the three characters were quoted, I would expect that on
a case blind command language the statements:

	'gcc' compiles...
	'Gcc' compiles...
	'gCC' compiles...

would all be equally true, especially since the substitute
"The 'gcc' command compiles" indicates that the three letters
represent the command rather than the official product name of
the compiler.

If I were king, I would have named the compiler with a capitalized
acronym even if the command to invoke it had to be lower case on
my favorite operating system.  But I rarely agree with Mr. Stallman.

Re: Three simple questions

[Florian Weimer]

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

> If I were king, I would have named the compiler with a capitalized
> acronym even if the command to invoke it had to be lower case on
> my favorite operating system.  But I rarely agree with Mr. Stallman.

"gcc" ("GNU C Compiler") has already been renamed to "GCC" ("GNU
Compiler Collection"). ;-)

-- 
Florian Weimer 	                  Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

E. E. Cummings (was Re: Three simple questions)

[Robert I. Eachus]

Robert Dewar wrote:

> Assuming there was no missing smiley here and that Larry
> was serious (which may be a silly assumption), I will say
> that I know exactly what Bob means, and I do the same
> myself. It is analogous to knowing that the following
> sentence is malformed.
> 
> E.e. cummings was one of the last centuries most brilliant
> poets.

I think it should be:

 "E. E. Cummings was one of this century's most brilliant poets."

Normally I don't pick on errors in grammar or punctuation, but there are
some errors that need a lot of stamping out:
 
"The poet replied on 1 March 1951: "E.E.Cummings, unless your printer
prefers E. E. Cummings/ titlepage up to you;but may it not be tricksy
svp[.]" 

(from http://www.gvsu.edu/english/cummings/caps2.html, which has a neat
Fifth Wave cartoon to tempt you.)

As to the rest of the sentence, I am fairly sure that Robert meant to
use the possessive not the plural of century, but in this case both are
potentially right!  If I change the phrase to "of the last few
centuries," now the possessive seems wrong, but if I extend the phrase
to "the last few century's brilliant poets," we are back to the
possessive.  I could assume that it has to be the plural, since we are
still in the twentieth century, but E. E. Cummings was born in 1894. My
version doesn't raise quite as many questions.

Back to the topic at hand, I try very hard not to start a sentence with
a word which should not be capitalized, and go out of my way to avoid
starting a sentence with a number:  "The book, _1984_ by George
Orwell..." rather than "_1984_ by George Orwell.."

What do I do when I can't avoid the problem?  I avoid it anyway. ;-)

Re: Three simple questions

[Keith Thompson]

Robert A Duff <bobduff@world.std.com> writes:
[...]
> I find myself going to some trouble to avoid starting a sentence with a
> case-senstive name -- "The 'gcc' command compiles Ada programs.", rather
> than "'gcc' compiles Ada programs.", which is ugly, or "'Gcc' compiles
> Ada programs.", which is wrong.

Or "Adainit should contain the elaboration code for library units."
(RM95-B.1(39))

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

Re: Three simple questions

[Wes Groleau]

> >> "polish the silver."  NEVER   "Polish the silver."
> >
> >Wops! Are you saying that "polish the silver." is a correct sentence in
> >English??? I've always thought that you MUST write the very first letter
> >in a sentence in caps!!!
> 
> Or so I've always heard. I think he was being sarcastic, ...

Yes.  I was responding to an earlier post which cited "polish" vs.
"Polish"
as evidence that programming languages ought to be case-sensitive.

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: Three simple questions

[Ken Garlington]

"Marin David Condic" <mcondic.nospam@acm.org> wrote in message
news:39E71FF3.E4408743@acm.org...

> I'll admit you've got me there with Polish and polish. :-)

"Hand me the polish!"
"Which polish?"
"The KIWI Paste Polish!" (as spelled on the label...)

Re: Three simple questions

[Richard Kenner]

In article <39E47BAC.8DB1AD0B@acm.org> Marin David Condic <mcondic.nospam@acm.org> writes:
>Ada is not case-sensitive because case-sensitivity is a bad idea. In
>normal English usage, there is no significant difference between "Marin"
>or "MARIN" or mArIn". Readers would interpret that to mean a reference to
>me. Identifiers in a program are likely to be similarly interpreted on
>cursory inspection, so it would be a bad idea to have "x" mean an entirely
>different variable than "X". Too much opportunity for subtle bugs.

In addition, as somebody pointed out in a subtle way, it makes it much
harder to have a verbal conversation about a program.  If you have
RollControl, rollControl, Rollcontrol, and rollcontrol variables, all
meaning different things, when you try to discuss code that uses them
verbally, it becomes a very confusing conversation really quickly
because we don't have normal English mechanisms to distinguish case.

Some would say this argues in favor of underscores not being
significant either, so you couldn't have a disinct Roll_Control
variable either, but "roll underscore control" sounds a lot smoother
than saying "each cycle we set the capital r roll capital c control
variable from the average of the lower-case r roll lower-case c
control, lower-case r roll capital c control, and capital r roll
lower-case c control variables"!

Re: Three simple questions

[Laurent Guerby]

kenner@lab.ultra.nyu.edu (Richard Kenner) writes:
> [...] Some would say this argues in favor of underscores not being
> significant either, so you couldn't have a disinct Roll_Control
> variable either, but "roll underscore control" sounds a lot smoother
> than saying "each cycle we set the capital r roll capital c control
> variable from the average of the lower-case r roll lower-case c
> control, lower-case r roll capital c control, and capital r roll
> lower-case c control variables"!

Nice example ;-).

As for underscores, if you put them consistently between words, you
don't even need to mention them while discussing your program. And
since Ada identifiers cannot begin with, have two consecutive or end
with an underscore, there's no problem at all.

Note that this issue transcend programming languages and goes up to
the more general human-computer interface field. Having case
sensitivity there is even worse and sometimes can be dangerous (source
of big mistakes once someone introduce XYZ and XYz in the system...).

The software I work on for my company (in Ada) has an API based on
names (object/attibute), and we follow and document the Ada rules for
the allowed set of names. Other software is written on top of usually
using another language (C, C++, Java, VB, you name it) by other
developpers. This layer often adds case sensitivity (ignoring our
documention rationale) and I remember a meeting with a manager who
asked the guyes who did the software in C++ using our API "are you
sure case sensitivity is a good idea". Needless to say, after a
meaningful silence the consensus was "no", but the software wasn't
changed because it would be too costly...

-- 
Laurent Guerby <guerby@acm.org>

Re: Three simple questions

[Robert A Duff]

Laurent Guerby <guerby@acm.org> writes:

> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:
> > [...] Some would say this argues in favor of underscores not being
> > significant either, so you couldn't have a disinct Roll_Control
> > variable either, but "roll underscore control" sounds a lot smoother
> > than saying "each cycle we set the capital r roll capital c control
> > variable from the average of the lower-case r roll lower-case c
> > control, lower-case r roll capital c control, and capital r roll
> > lower-case c control variables"!
> 
> Nice example ;-).

I don't buy it.  I find it impossible to chat about programs of any
substantial size without writing them down -- that's what whiteboards
are for.

> As for underscores, if you put them consistently between words, you
> don't even need to mention them while discussing your program. And
> since Ada identifiers cannot begin with, have two consecutive or end
> with an underscore, there's no problem at all.

The same is true of casing -- if you use sensible conventions, case
sensitivity doesn't damage talking.  Eg, you might have "the type FOO",
and "the variable foo".

I still think case sensitivity is error prone.

> Note that this issue transcend programming languages and goes up to
> the more general human-computer interface field. ...

Reminds of a user-interface I heard of that used the C convention, where
an integer literal starting with "0" is octal.  It's bad enough in a
programming language, but to foist that on unsuspecting (non-programmer)
users is pretty horrible.

- Bob

Re: Three simple questions

[Laurent Guerby]

Robert A Duff <bobduff@world.std.com> writes:
> I don't buy it.  I find it impossible to chat about programs of any
> substantial size without writing them down -- that's what whiteboards
> are for. [...]

May be we aren't talking about the same thing. 

I have no problem telling someone (over the phone, so no whiteboards),
that the gizmo they're looking after in our code (> 100K, not that big
by Ada standard, but definitely not toy size ;-) is in package gizmo
factory, function make it with the argument item color being red which
translates directly to Gizmo_Factory.Make_It (Item_Color => Red); no
need to look up the spec or to try 50 casings.  When I run after
inconsitent names, I change them and try to educate the author (non
software engineer) about the merits of consistency in big programs (>
100 lines ;-).

As for talking about complex algorithms, or for how to insert your new
feature which will need changing over 20 packages, yes the whiteboard
or your favourite editor buffer is needed, I unfortunately agree 100%.

-- 
Laurent Guerby <guerby@acm.org>

Re: Three simple questions

[Ronald Cole]

Laurent Guerby <guerby@acm.org> writes:
> When I run after
> inconsitent names, I change them and try to educate the author (non
> software engineer) about the merits of consistency in big programs (>
> 100 lines ;-).

No kidding.  At the database company I worked for >10 years ago, they
had peppered the code with "r"this and "t"that, where "r" and "t"
meant either "relation" and "tuple" or "row" and "table".  Sometimes
you had to read a lot of context to figure out which one was meant.

-- 
Forte International, P.O. Box 1412, Ridgecrest, CA  93556-1412
Ronald Cole <ronald@forte-intl.com>      Phone: (760) 499-9142
President, CEO                             Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084  4A88 8851 E6C8 69E3 B00B

Re: Three simple questions

[Wes Groleau]

> I don't buy it.  I find it impossible to chat about programs of any
> substantial size without writing them down -- that's what whiteboards
> are for.

Nevertheless, Ada easier to discuss than C--because with C, you have
to write EVERYTHING down.

:-)

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: Three simple questions

[Marin David Condic]

Point taken, but I think this may be a bit contrived. Even C programmers (unless they're
trying to be "clever") are not likely to create a RollControl and a rollcontrol in the same
context. What is far more likely to be the case is when you've got one of those "quickie"
variables for a loop index or some logical test, etc, where you've got an "X" and an "x" that
exist in the same context. It would still be hard to verbally discuss them, but it is more
likely to be an accident than an intention.

Now I could imagine this possibly being a problem *across* contexts - say if a member variable
is defined in a C++ class one way and a local version is used in some function where the name
is different by case. That may happen a bit more regularly and it certainly would be confusing
to discuss "member variable RollControl" and "local variable rollcontrol".

Another good reason to use Ada - packages, dotted notation, case-insensitivity,... It all adds
up to more reliability.

MDC


Richard Kenner wrote:

> In addition, as somebody pointed out in a subtle way, it makes it much
> harder to have a verbal conversation about a program.  If you have
> RollControl, rollControl, Rollcontrol, and rollcontrol variables, all
> meaning different things, when you try to discuss code that uses them
> verbally, it becomes a very confusing conversation really quickly
> because we don't have normal English mechanisms to distinguish case.
>
> Some would say this argues in favor of underscores not being
> significant either, so you couldn't have a disinct Roll_Control
> variable either, but "roll underscore control" sounds a lot smoother
> than saying "each cycle we set the capital r roll capital c control
> variable from the average of the lower-case r roll lower-case c
> control, lower-case r roll capital c control, and capital r roll
> lower-case c control variables"!

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "Giving money and power to Government is like giving whiskey
    and car keys to teenage boys."

        --   P. J. O'Rourke
======================================================================

Re: Three simple questions

[Larry Hazel]

Frank Christiny wrote:
> 
> 2.  What is the rationale for case-insensitivity in the language?
>     I am beginning to think it is mostly for historical reasons
>     (some machines didn't have two case letters way back then, etc.).
>     Are there any real technical reasons for why this is so even
>     after Ada95, besides preserving backwards compatibilty?

Hello,

My name is Larry.  I want you to meet my brother larry and my other brother
LARRY.  Are we confused yet?

Larry Hazel

Re: Three simple questions

[Tucker Taft]

[NOTE: as you can see from the number of responses,
there is no such thing as a "simple" question about
a programming language...]

Frank Christiny wrote:
> 
> Friends,
> 
> Having arrived recently into the green Adian world, I am trying to
> assimilate all there is to know about this powerful, unfairly
> maligned computer language.  Most questions I have been able to
> answer from the FAQs here and there but there are three (so far) that
> have gone unanswered:
> 
> 1.  What is the correct pronunciation of Dr. Ichbiah's name?
>     Is the "ch" pronounced as in "Loch" or as in "each"?  Is the
>     final "h" is silent?

Eesh-bee-uh is how I pronounce it.  Jean will have to give his own
official version.  By the way, at one of the early Ada conferences,
someone claimed that "Ichbiah" was Swedish for "iceberg" and that
is why 90% of the complexity of Ada 83 was hidden below the surface.

Of course, with Ada 95 we tried to raise the iceberg a bit, and maybe
even smooth off a few of those dangerous irregularities.

> 
> 2.  What is the rationale for case-insensitivity in the language?
>     I am beginning to think it is mostly for historical reasons
>     (some machines didn't have two case letters way back then, etc.).
>     Are there any real technical reasons for why this is so even
>     after Ada95, besides preserving backwards compatibilty?

This is an explicit choice, and one that I think I would personally
make the same way again.  I have been teaching a "Programming Languages"
course recently, and it is surprising how frequently students, even those
conversant in C, are surprised that in some contexts, "Begin" and "BEGIN"
mean two different things.

One thing that some compilers do is warn the programmer if they
use different upper/lower casing in a reference than in the declaration.
E.g., if you declare something as "XYZ" but have a reference like "xyz"
then you would get a warning.  That seems like a friendly feature, and 
might even be worth enshrining in a language rule, or perhaps at least
a pragma.

> 
> 3.  How can one block-comment in Ada?
>     It can become cumbersome sometimes, adding all those "--"s in
>     front of a large block of code one wants to "test out" on the fly.
>     Again, are there any good technical-engineering reasons why this
>     feature was left out?

From my perspective, being a big fan of "grep" (the Unix version of
a file "search" command), I am always pleased that every line that
has been commented out starts with "--".  It can be quite distressing
to think that a line is executable, and then discover that it is
actually buried in a commented-out block.

Note that most programmer-friendly text editors have an ability to insert
something in front of every line of a block, or to remove same.

Finally, in languages that do provide block comments, I find they
rarely work right if the block being commented-out already contains
comments.  If you tend to comment at least once every 10 or so lines,
a block of code doesn't have to be very big to require significant
fiddling to allow block commenting to work.  By contrast, you can
always stick "-- " in front of every line, even if the line already
contains a comment.

Both of these latter two answers reflect in part Ada's philosophy of
favoring the "reader" over the "writer."  And since in most cases,
even for our own code, we end up being a more frequent reader than
a writer, this philosophy generally increases the overall productivity 
of the original programmer as well as some subsequent program 
reviewer/maintainer/enhancer.

> 
> Regards,
> --
> Frank Christiny                       fchris@pdq.net
> Sr. Software Engineer                 Lockheed Martin Space Operations
> Houston, Texas, USA                   http://freeweb.pdq.net/fchris/

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA

Re: Three simple questions

[Bjarne Bäckström]

Tucker Taft <stt@averstar.com> wrote:

[...]
> someone claimed that "Ichbiah" was Swedish for "iceberg" and that
> is why 90% of the complexity of Ada 83 was hidden below the surface.

   Sorry to disappoint you, but "iceberg" is "isberg" in Swedish ...
even less complex than the English version. :-)

Re: Three simple questions

[Anders Wirzenius]

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


"Bjarne B�ckstr�m" <bjarne.backstrom@telia.com> wrote in message
news:200010120307433041802@t4o921p87.telia.com...
> Tucker Taft <stt@averstar.com> wrote:
>
> [...]
> > someone claimed that "Ichbiah" was Swedish for "iceberg" and that
> > is why 90% of the complexity of Ada 83 was hidden below the surface.
>
>    Sorry to disappoint you, but "iceberg" is "isberg" in Swedish ...
> even less complex than the English version. :-)

... which leads me to annoy you with telling that the Finnish (finnish ;-)
word
for iceberg is j��vuori ( j auml auml v u o r i, maybe your screen does not
show the auml letter) which is pronounced EXACTLY
sorry, exactly, as it is written: short sound for one letter, long sound for
two letters. Just try.

Isn't the Finnish language easy ?

Anders

Re: Three simple questions

[Bjarne Bäckström]

Anders Wirzenius <anders.wirzenius@pp.qnet.fi> wrote:

[...]
> ... which leads me to annoy you with telling that the Finnish (finnish ;-)
> word
> for iceberg is j��vuori ( j auml auml v u o r i, maybe your screen does not
> show the auml letter) which is pronounced EXACTLY
> sorry, exactly, as it is written: short sound for one letter, long sound for
> two letters. Just try.

   Lessee, "j��vouri" contains eight letters; If I start, say on a
Monday, when do I stop? ;-)

P�iv�,
/Bjarne.

Re: Three simple questions

[Anders Wirzenius]

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


"Bjarne B�ckstr�m" <bjarne.backstrom@telia.com> wrote in message
news:20001013172528721245@t1o921p93.telia.com...
> Anders Wirzenius <anders.wirzenius@pp.qnet.fi> wrote:
>
> [...]
> > ... which leads me to annoy you with telling that the Finnish (finnish
;-)
> > word
> > for iceberg is j��vuori ( j auml auml v u o r i, maybe your screen does
not
> > show the auml letter) which is pronounced EXACTLY
> > sorry, exactly, as it is written: short sound for one letter, long sound
for
> > two letters. Just try.
>
>    Lessee, "j��vouri" contains eight letters; If I start, say on a
> Monday, when do I stop? ;-)

Sorry, of course I should have mentioned that the group of letters shall
consist of either vowels or consonants but not mixed. Thanks for the
indication of the incompleteness of the definition. The "lang" in
comp.lang.ada should have remained me of being exact.

>
> P�iv�,

This is a new shortening of the Finnish translation of "Have a good day" (my
assumption of your intention). The complete wish reads "Hyv�� p�iv�n
jatkoa". You might also have meant "Good day" which is translated "Hyv��
p�iv��", shortly: "P�iv��", not "P�iv�"
;-) ;-) (how do you write ";-)" in upper case?)

End of discussion from my side.

I am a former programmer (Fortran, Basic) that laborated a little with Ada
back in 1980's (1983?) using a parser on a Vax 11/780 machine. The parser
had a speed of 2..5 minutes per line of Ada code then. Which caused me to
drop the language.
Resently I discovered the free compilers in Intranet and that started a new
era in my life. Wov!

Does anybody of you know of any Ada usage or Ada programming in Finland?
There was at least a bank system which was programmed in Ada. I think the
hardware was a Nokia product named MP 10. The system was dropped when the
bank company was mergered with another bank company.

Anyone knowing somethong about Ada in Finland today?

Anders

Re: Three simple questions

[Wes Groleau]

> Isn't the Finnish language easy ?

I've never met a Finn who has any trouble with it.

-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: Three simple questions

[Robert Dewar]

In article <39E73EA6.8140805E@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
>
> > Isn't the Finnish language easy ?
>
> I've never met a Finn who has any trouble with it.


Well you know what Mark Twain said about France ....
France, a very sophisticated country, even the children
speak French :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Three simple questions

[Simon Wright]

Frank Christiny <fchris@pdq.net> writes:

> 3.  How can one block-comment in Ada?
>     It can become cumbersome sometimes, adding all those "--"s in
>     front of a large block of code one wants to "test out" on the fly.
>     Again, are there any good technical-engineering reasons why this
>     feature was left out?

If it's executable, you can say

  if False
    -- stuff
  end if

but really your IDE should do it (in Emacs ada-mode, 'C-c ;' to
comment and 'C-c :' to uncomment; Apex has this too)

Re: Three simple questions

[Robert Dewar]

In article <x7vhf6j9ab8.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:

>   if False
>     -- stuff
>   end if


And then add some comments to explain why you did this, there
is nothing worse than seeing commented out code with no
explanation whatsoever of WHY it is commented out. Yet that
is in my experience quite a common occurrence in some code!


Sent via Deja.com http://www.deja.com/
Before you buy.