Re: Ada Operators in 9x

Re: Ada Operators in 9x

[Mike Berman]

firth@sei.cmu.edu (Robert Firth) writes:

| In article <C8yCIC.4C0@dale.cts.com> helkenn@dale.cts.com (David Helken)
| writes:

>>Can anyone from the 9x team (or anyone else for that matter) explain the
>>exclusion of user defined operator names in Adaxx?

| Sign.  A sad story.  Algol-68, you may recall, had this feature.  The

| But Algol-68 had the necessary "enabling technology": a way to distinguish
| lexically between user-defined operators and user-defined identifiers.  In
| other words, distinct upper and lower case letters.  Ada has only one 
| letter case, which is why we have those silly reserved words, and why
| it would make the compiler's life very complicated to allow arbitrary
| user-defined operators.
| 
| And the reason Ada has only one letter case?  Upward compatibility with
| junk hardware already obsolete when the requirement was written.  Yuk.

Whoa. Back up. Are you saying that case sensitivity is a good thing?
Am I missing liberally-placed smileys somewhere?

If I am interpreting this post correctly, the point is that Ada is
designed to be case-insensitive so as to support machines, such as
110-baud teletypes with oval keys, that have no mixed-case capability.
Since it's possible, however unlikely, that one may only be able to type
FRED, then Fred, fred, and frEd should all denote the same identifier.

If so, then fine, but the maintainability aspects "accidentally" derived
from this upwards compatibility decision can't be denied. While machines
excel at tracking minute details, I prefer not having to keep track of
both identifier spelling and permutations of case when reading someone
else's code.

Capabilities like the use of arbitrary identifiers as operators are
nice, but I, for one, would not revert to case sensitivity to get them.

Also, the potential for "obfuscated Ada" contests would be rather
scary...

-- 
Mike Berman
University of Maryland, Baltimore County     Fastrak Training, Inc.
berman@umbc.edu                              (301)924-0050
       The views represented in the above post are my own.

Re: Ada Operators in 9x

[cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!cs.ucf.edu!longwoo]

Mike Berman responded to Robert Firth's response to David Helken:

: Whoa. Back up. Are you saying that case sensitivity is a good thing?
: Am I missing liberally-placed smileys somewhere?

Mike, I can't speak for the others, but if I had written it yea,
verily, case sensitivity would be not only a good thing, but a GOOD
THING:

   1.  It's available in (at least) C , Modula 2 (and its succesors?)
       and Smalltalk.

   2.  Every project I've ever been on has required adherance to some
       letter casing convention (whether LRM, `European', whatever).

   3.  No pretty printer I've ever seen can get comments right (in any
       reasonable style) in all situations.

   4.  It is a tremendous convenience (not to mention a relief to my
       grammar genes) to not have to create something related but
       non-homonymous like the_element.

Jim Crigler
-------------------------------------------------------------------------------
Disclaimers are for those who have opinions someone is afraid of.

Re: Ada Operators in 9x

[Joe Hildebrand]

> Whoa. Back up. Are you saying that case sensitivity is a good thing?
> Am I missing liberally-placed smileys somewhere?

It is nice to be able to sling your case around as you please, but if
you are trying for a consistent coding style across several (or hundreds)
of programmers, that style would be a lot easier to enforce if the 
compiler could catch the case deviations.

----------
Joe Hildebrand                  Fuentez Systems Concepts
hildjj@fuentez.com              11781 Lee-Jackson Hwy, Suite 700
Software Engineer               Fairfax, VA 22033
                                Phone: (703)273-1447   
                                Fax:   (703)273-2972

Standard disclaimers apply

Re: Ada Operators in 9x

[David Emery]

On the other hand, it's a source of great frustration to have to work
off syntax errors because you forgot the cApitalization conventioN.
				dave

Re: Ada Operators in 9x

[Rahul Dhesi]

In <205bsdINNbca@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:

>While machines
>excel at tracking minute details, I prefer not having to keep track of
>both identifier spelling and permutations of case when reading someone
>else's code.

If an identifier spelled FRED in one place is spelled Fred elsewhere,
it's either a problem of a symptom of problems.

- The programmer is typing carelessly;  did he make other errors
  that are not so benign?
- Different programmers are using different coding styles;  are they
  also using different conventions for a boolean flag?
- Did the programmer want two variables with related meanings,
  and forget to declare both, and got just one instead?

I don't know of any examples where inconsistent use of case improves
code.  I do know of many examples when multiple related identifiers can
be distinguished by case and it makes the code more readable.

Case-insensitivity of a language is nice when writing documentation for
it.  It helps differentiate between terminal and nonterminal symbols:

   If you want to select between two possibilities, use IF.

(However, oops!  There goes our convention of using keywords in
lowercase.)

The careful use of quote marks (and highlighting in rich text)
can achieve the same effect:

   If you want to select between two possibilities, use ``if''.
-- 
Rahul Dhesi <dhesi@rahul.net>
also:  dhesi@cirrus.com

Re: Ada Operators in 9x

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.]

emery@goldfinger.mitre.org (David Emery) writes:

>On the other hand, it's a source of great frustration to have to work
>off syntax errors because you forgot the cApitalization conventioN.

Exactly. I heard a good rule of thumb yesterday - code should be written
so that it can be read and understood over the phone. Not that one would
do this, but the idea is that our memory seems more closely tied to what
we hear and verbalize, not what we see (actually, the sense of smell is
most effectively tied into memory, but that doesn't help just yet).

In other words, identifiers should have a unique pronunciation.
The presence of unique identifiers which differ only by their case
results in code that is harder to understand (and therefore maintain).

On a related issues, I have also heard (and believe) that mixed case is
easier to read than all upper or all lower. We tend to recognize words
by their shape moreso than their spelling. SINCE ALL UPPER CASE IS MORE
OF A BLOCK-LIKE STRUCTURE, IT IS INCREMENTALLY HARDER FOR THE BRAIN TO
"SEE" WHAT IS WRITTEN. Mixed case has more of an inherent "shape". Plus,
it seems like I'm yelling when I write in all uppers.

This has strayed from a mainline Ada discussion, but it sure beats
griping about DoD policy for once.

-- 
Mike Berman
University of Maryland, Baltimore County     Fastrak Training, Inc.
berman@umbc.edu                              (301)924-0050
       The views represented in the above post are my own.

Re: Ada Operators in 9x

[Michael Feldman]

In article <9306241414.AA01973@fuentez.com> hildjj@JUPITER.FUENTEZ.COM (Joe Hil
debrand) writes:
>
>> Whoa. Back up. Are you saying that case sensitivity is a good thing?
>> Am I missing liberally-placed smileys somewhere?
>
>It is nice to be able to sling your case around as you please, but if
>you are trying for a consistent coding style across several (or hundreds)
>of programmers, that style would be a lot easier to enforce if the 
>compiler could catch the case deviations.
>
But how would that happen if the language were case-sensitive? My case
(no pun) in point is Modula-2, in which the reserved words MUST be in
upper-case, which is no problem really, but additionally you can declare
  q: Integer;
  Q: Integer;
in the same block. Suppose you _meant_ to write

  q := 35;

but instead hit the shift key accidentally and wrote

  Q := 35;

The same thing can happen in C, which is, I presume, why C programmers
use lower case almost exclusively.

My single-keystroke error above would NOT be caught if the language were
case-sensitive, but of course with Ada (like Pascal), the compiler
would nail you for a doubly declated variable. I like this. I HATE
single-keystroke errors that have big semantic effects, because I'm
as really liusy typist. :-)

Enforcing a lexical style is IMHO a good job for a nice style-checker tool,
or even a prettyprinter that can do it all for you. Some of these things
exist; if they are not powerful enough for your project, scream at your
vendor - that's what the market is (supposed to be) for!

The case-sensitivity issue is purely academic anyhow - Ada is what it is,
and Ada9X won't change this, because it would be REALLY damaging to
upward compatibility.

Cheers -

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-5296 (fax) - mfeldman@seas.gwu.edu (Internet)
"Pork is what those other guys get from the Government."
------------------------------------------------------------------------

Re: Ada Operators in 9x

[cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!agate!doc.i]

In article <1993Jun25.211211.231@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael F
eldman) writes:
   But how would that happen if the language were case-sensitive? My case
   (no pun) in point is Modula-2, in which the reserved words MUST be in
   upper-case, which is no problem really, but additionally you can declare
   "q: Integer;  Q: Integer;" in the same block.

You can also write the whole program in one block, but that doesn't
mean you do it.  Case sensitivity has other uses other than as a
plaything for programmers with a perverse style.

   Suppose you _meant_ to write "q := 35;" but instead hit the shift
   key accidentally and wrote "Q := 35;" 

Then you'd be doubly dumb.  Once for declaring "q" and "Q" in the same
block and twice for being sloppy about typing.

   The same thing can happen in C, which is, I presume, why C programmers
   use lower case almost exclusively.

Maybe, but I think not.  I've seen (and written) plenty of C that used
mixed case; a common convention being that types have initial capitals
and variables are lower case.

   My single-keystroke error above would NOT be caught if the language were
   case-sensitive, but of course with Ada (like Pascal), the compiler
   would nail you for a doubly declated variable. I like this. I HATE
   single-keystroke errors that have big semantic effects, because I'm
   as really liusy typist. :-)

I'm not keen on single keystroke errors either, but _all_ languages
suffer from them and there are much more insidious ones than the case
problem.  For example, ever typed "a + 1" when you meant "a - 1"?
This is easily done in the midst of a big formula I can assure you.

Re: Ada Operators in 9x

[cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!agate!doc.i]

In article <20fp75INNk3l@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes:
   I heard a good rule of thumb yesterday - code should be written
   so that it can be read and understood over the phone.
   Not that one would do this ...

Of course people do this, ask anyone whose suffered doing customer
support over the 'phone.  Wherever possible, using a fax is much
quicker and less error prone.

   ... but the idea is that our memory seems more closely tied to what
   we hear and verbalize, not what we see ...

Sounds rather contentious to me.

Re: Ada Operators in 9x

[Kenneth Anderson]

In comp.lang.ada you write:

>In article <1993Jun25.211211.231@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael 
Feldman) writes:

>   Suppose you _meant_ to write "q := 35;" but instead hit the shift
>   key accidentally and wrote "Q := 35;"

>Then you'd be doubly dumb.  Once for declaring "q" and "Q" in the same
>block and twice for being sloppy about typing.

You can't really mean the latter.  A person is "dumb" if they make
a typing mistake? I think you are arguing just for the sake of arguing...

Ken

Re: Ada Operators in 9x

[Stephen J Bevan]

In article <9306261803.aa04612@Paris.ics.uci.edu> kanderso@liege.ICS.UCI.EDU (K
enneth Anderson) writes:
   >   Suppose you _meant_ to write "q := 35;" but instead hit the shift
   >   key accidentally and wrote "Q := 35;"

   >Then you'd be doubly dumb.  Once for declaring "q" and "Q" in the same
   >block and twice for being sloppy about typing.

   You can't really mean the latter.  A person is "dumb" if they make
   a typing mistake?

That's your inference, not my implication.  Do you think it is a good
idea to define "Q" and "q" in the same block?  I think it is
questionable, but I'd allow it a) do deal with "G" and "g" in Physics
and b) for experienced programmers to make their own choice.  However,
once done, the onus is on the programmer to carefully make sure they
don't slip up, hence if they conciously decide to do something
dangerous and then don't take precautions, then yes, I think they are
dumb.

Re: Ada Operators in 9x

[ghost.dsi.unimi.it!univ-lyon1.fr!scsing.switch.ch!epflnews!disuns2.epfl.c]

In article <BEVAN.93Jun26164332@panda.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephe
n J Bevan) writes:
: In article <20fp75INNk3l@umbc4.umbc.edu> berman@umbc.edu (Mike Berman) writes
:
: 
:    ... but the idea is that our memory seems more closely tied to what
:    we hear and verbalize, not what we see ...
: 
: Sounds rather contentious to me.

Actually it would probably be better stated that if we can see an
identifier _and_ pronounce it then it will be easier to remember. This
is hardly contentious; it is a standard memory technic.

In languages with a hierarchical name space case sensitivity is much
less useful (IMHO) than in a language with a flat name space. If a
language also has a preprocessor on top of a flat name space then case
sensitivity becomes almost necessary.

In Ada (which has a hierarchical name space and no preprocessor) case
sensitivity really doesn't make a big difference one way or the other.
Any examples where it matters one way or the other are almost certain
to be contrived.

I feel that Ada made the right choice (for Ada) in making case
irrelevant since in my experience this tends to improve
maintainability.

Robb

Re: Ada Operators in 9x

[Mark A Biggar]

In article <1993Jun28.203652.5542@relay.nswc.navy.mil> bwallet@apssgi.nswc.navy
.mil (Brad Wallet) writes:
>an interesting little problem operators gave me lately:
>package MY_INTEGER is
>   subtype INTEGER_16 is private; --#  Defines a sixteen bit integer.
>   function "+"
>     (LEFT  : in INTEGER_16; --*     Left operand of the addition.
>      RIGHT : in INTEGER_16) --*     Right operand of the addition.
>     return INTEGER_16; --/  This function returns the sum of two sixteen bit 
integers.
>private
>   type INTEGER_16 is INTEGER range -32_767..32_767;
>   for INTEGER_16'size use 16;
>end MY_INTEGER;
>package body MY_INTEGER is
>   function "+"
>     (LEFT  : in INTEGER_16;
>      RIGHT : in INTEGER_16)
>     return INTEGER_16 is
>   begin
>      return (LEFT + RIGHT); -- (1)
>   end "+";
>end MY_INTEGER;

This recurses until you run out of stack memory.  By the overloading rules,
the only matching operation for "+" at (1) is the "+" you are currently
defining (which must be available because there is no other way to get 
recursion when you really DO want it.)   In order to get what you really
wanted you need to say:

	return (INTEGER_16(INTEGER(LEFT)+INTEGER(RIGHT));

or something similar.  Now the overloading rules make the "+" for
INTEGER the only usable version of "+".  Note the the conversion back
to INTEGER_16 will raise CONSTRAINT_ERROR on overflow, which is
probably what you want anyway.

--
Mark Biggar
mab@wdl.loral.com

Re: Ada Operators in 9x

[Charles H. Sampson]

In article <BEVAN.93Jun27092606@hippo.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen
 J Bevan) writes:
>In article <9306261803.aa04612@Paris.ics.uci.edu> kanderso@liege.ICS.UCI.EDU (
Kenneth Anderson) writes:
>   >Mike Feldman wrote:
>   >   Suppose you _meant_ to write "q := 35;" but instead hit the shift
>   >   key accidentally and wrote "Q := 35;"
>
>   >Then you'd be doubly dumb.  Once for declaring "q" and "Q" in the same
>   >block and twice for being sloppy about typing.
>
>   You can't really mean the latter.  A person is "dumb" if they make
>   a typing mistake?
>
>That's your inference, not my implication.  Do you think it is a good
>idea to define "Q" and "q" in the same block?  ...

     How about this scenario?  Q is declared in a package specification. 
The programmer declares q in a piece of code that uses that package.  (The
project is large enough that programmers are not expected to know all iden-
tifiers in all package specifications; only those that are of interest to
their area.  This is the strength of the hierarchical declaration struc-
ture.)

     If you dislike this example because it relies on the use clause, cast
it in one of the contexts where the use clause is necessary.  Another pos-
sibility is declaring Q as a package regional identifier and q in a sepa-
rately compiled subunit.

     If you dislike "Q" and "q", substitute any reasonable short project-
specific identifier.

                              Charlie

Re: Ada Operators in 9x

[cis.ohio-state.edu!math.ohio-state.edu!darwin.sura.net!source.asset.com!v]

In article <20fp75INNk3l@umbc4.umbc.edu> berman@umbc.edu (Mike Berman)
writes: 

> the sense of smell is most effectively tied into memory

Talk about multi-media,  "Introducing SmellAda, the first truly
memorable validated Ada compiler ... "

Re: Ada Operators in 9x

[agate!howland.reston.ans.net!darwin.sura.net!dtix.dt.navy.mil!relay-wo!re]

In article <1993Jun30.152449.7443@nosc.mil>, sampson@nosc.mil (Charles H. Samps
on) writes:
|> In article <BEVAN.93Jun27092606@hippo.cs.man.ac.uk> bevan@cs.man.ac.uk (Step
hen J Bevan) writes:
|> >In article <9306261803.aa04612@Paris.ics.uci.edu> kanderso@liege.ICS.UCI.ED
U (Kenneth Anderson) writes:
|> >   >Mike Feldman wrote:
|> >   >   Suppose you _meant_ to write "q := 35;" but instead hit the shift
|> >   >   key accidentally and wrote "Q := 35;"
|> >
|> >   >Then you'd be doubly dumb.  Once for declaring "q" and "Q" in the same
|> >   >block and twice for being sloppy about typing.
|> >
|> >   You can't really mean the latter.  A person is "dumb" if they make
|> >   a typing mistake?
|> >
|> >That's your inference, not my implication.  Do you think it is a good
|> >idea to define "Q" and "q" in the same block?  ...
|> 
|>      How about this scenario?  Q is declared in a package specification. 
|> The programmer declares q in a piece of code that uses that package.  (The
|> project is large enough that programmers are not expected to know all iden-
|> tifiers in all package specifications; only those that are of interest to
|> their area.  This is the strength of the hierarchical declaration struc-
|> ture.)
|> 
|>      If you dislike this example because it relies on the use clause, cast
|> it in one of the contexts where the use clause is necessary.  Another pos-
|> sibility is declaring Q as a package regional identifier and q in a sepa-
|> rately compiled subunit.
|> 
|>      If you dislike "Q" and "q", substitute any reasonable short project-
|> specific identifier.
|> 
|>                               Charlie
|> 

no, i think you all are missing point behind making Ada case sensitive.
since the original statement was that case sensitivity would allow for
more uniform coding standards enforcement by the language, i think the
implementation would be something like all reserved words must be
written in lower case and other stuff must be all caps.  that's part of
our coding standards.  this would make perfect sense.  u could go one
further and say that single, lower case letters could be used as programmer
defined operators.  remember, this thread began with a discussion of
overloaded operators.

adding case sensitivity just to added it would not make any sense, but
adding it force code uniformity would be withing the original purpose
of Ada.

brad

Re: Ada Operators in 9x

[Robert I. Eachus]

In article <1993Jun30.174116.24785@relay.nswc.navy.mil> bwallet@apssgi.nswc.nav
y.mil (Brad Wallet) writes:

  > no, i think you all are missing point behind making Ada case sensitive.
  > since the original statement was that case sensitivity would allow for
  > more uniform coding standards enforcement by the language, i think the
  > implementation would be something like all reserved words must be
  > written in lower case and other stuff must be all caps.  that's part of
  > our coding standards.  this would make perfect sense...

  Gee, since you are too lazy (apparently) to build a tool to enforce
your coding standards on everyone in the project, you want to require
all Ada compilers to enforce them on everyone!  That DOES NOT make
perfect sense to me.

     A long time ago a group I was in built a (very nice) pretty
printer for Ada for the project we were doing.  After lots of rounds
of discussions directed at which format was best, we compromised on
everybodies favorites.  Emacs ada-mode was modified to run files
through the pretty printer using the individual preferences when
loading, compiling, or saving, and a print alias used a separate set
of preferences for printing source files.  (For example, I prefer two
or three space indentation on screens, five spaces on wide printouts.)

     This worked just fine.  The only refinement added later was to
have a set of "project" preferences for delivered code.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada Operators in 9x

[agate!howland.reston.ans.net!darwin.sura.net!dtix.dt.navy.mil!relay-wo!re]

In article <EACHUS.93Jun30180618@spectre.mitre.org>, eachus@spectre.mitre.org (
Robert I. Eachus) writes:
|> In article <1993Jun30.174116.24785@relay.nswc.navy.mil> bwallet@apssgi.nswc.
navy.mil (Brad Wallet) writes:
|> 
|>   > no, i think you all are missing point behind making Ada case sensitive.
|>   > since the original statement was that case sensitivity would allow for
|>   > more uniform coding standards enforcement by the language, i think the
|>   > implementation would be something like all reserved words must be
|>   > written in lower case and other stuff must be all caps.  that's part of
|>   > our coding standards.  this would make perfect sense...
|> 
|>   Gee, since you are too lazy (apparently) to build a tool to enforce
|> your coding standards on everyone in the project, you want to require
|> all Ada compilers to enforce them on everyone!  That DOES NOT make
|> perfect sense to me.
|> 
|>      A long time ago a group I was in built a (very nice) pretty
|> printer for Ada for the project we were doing.  After lots of rounds
|> of discussions directed at which format was best, we compromised on
|> everybodies favorites.  Emacs ada-mode was modified to run files
|> through the pretty printer using the individual preferences when
|> loading, compiling, or saving, and a print alias used a separate set
|> of preferences for printing source files.  (For example, I prefer two
|> or three space indentation on screens, five spaces on wide printouts.)
|> 
|>      This worked just fine.  The only refinement added later was to
|> have a set of "project" preferences for delivered code.
|> --
|> 
|> 					Robert I. Eachus

no, no, no...u just don't get it...we enforce our standards...hey,
i even follow them (occasionally).  and your group follows its
standards.  and his group follows its standards.  and everyone's
code looks different.  Ada was designed to encourage / force good
coding practice...well, it dropped the ball on case sensitivity.

brad

Re: Ada Operators in 9x

[agate!howland.reston.ans.net!usenet.ins.cwru.edu!magnus.acs.ohio-state.ed]

I don't know Brad, but it seems like your are missing the point that Robert is
trying to make - I think :).  The idea is that no matter what the source code
style looks like - within a reason of course - the pretty printer will put it
in one's own preferred form...

pragma Satire (On);

-- say Bozo Clown likes it like this:

        package CIRCUS is
            
            type FUNNY_THING is limited private;

            ...
        private
            type FUNNY_THING is record
                ...
            end record;
        end CIRCUS; 

-- but Fred Dweeb likes it like this:

        package Circus is
            
                type Funny_Thing is limited private;

                ...
        private
                type Funny_Thing is
                record
                        ...
                end record;
        end Circus; 

-- Well a sufficiently empowered (buzzword alert) pretty printer should be able
-- to accomplish this despite the fact that the original source was authored by
-- Joe Noindent Veryloud and it looked like this:

        PACKAGE CIRCUS IS
        TYPE FUNNY_THING IS LIMITED PRIVATE;
        ...
        PRIVATE
        TYPE FUNNY_THING IS
        RECORD
        ...
        END RECORD;
        END CIRCUS; 

pragma Satire (Off);

Anyway... Is it July 4th yet?  Rats!!! I mean GNATS!!! Three more days...  ;)

Thomas Vachuska
------------------------------------------------------------------------------
tom@mothra.rose.hp.com                   (916)-785-4983  (Telnet & Voice Mail)
------------------------------------------------------------------------------

Re: Ada Operators in 9x

[Robert I. Eachus]

In article <1993Jul1.102841.1786@relay.nswc.navy.mil> bwallet@apssgi.nswc.navy.
mil (Brad Wallet) writes:

  > no, no, no...u just don't get it...we enforce our standards...hey,
  > i even follow them (occasionally).  and your group follows its
  > standards.  and his group follows its standards.  and everyone's
  > code looks different.  Ada was designed to encourage / force good
  > coding practice...well, it dropped the ball on case sensitivity.

     You totally missed my point.  The nit picking rules about
capitalization, indenting, and spacing are noise.  With the right
tools I don't have to look at ugly all lower case code, and you don't
have to look at ugly mixed case code.  I can look at code with the
"standard" block comments at the end of the file, you can see them at
the front.  We even considered adding support for four different
styles of use clause usage. (No use clauses, use clauses for
predefined and global packages, use clauses for use of operators with
all identifiers fully qualified, and type and operator renaming.)

     Useful coding standards have nothing to do with such fascist
minutia.  Good coding standards talk about proper decomposition into
modules, use of partcular language features, what types of concurrency
various parts of the code should cope with, etc.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada Operators in 9x

[Dave Bashford]

In article ... eachus@spectre.mitre.org (Robert I. Eachus) writes:
>In article ... bwallet@apssgi.nswc.navy.mil (Brad Wallet) writes:
>
>  > no, i think you all are missing point behind making Ada case sensitive.
>  > since the original statement was that case sensitivity would allow for
>  > more uniform coding standards enforcement by the language, i think the
>  > implementation would be something like all reserved words must be
>  > written in lower case and other stuff must be all caps.  that's part of
>  > our coding standards.  this would make perfect sense...
>
>  Gee, since you are too lazy (apparently) to build a tool to enforce
>your coding standards on everyone in the project, you want to require
>all Ada compilers to enforce them on everyone!  That DOES NOT make
>perfect sense to me.
>
>[some CRAZY IDEA about LETTING THE COMPUTER FORMAT CODE AUTOMATICALLY]
>
>     This worked just fine.  The only refinement added later was to
>have a set of "project" preferences for delivered code.

I JUST WANTED TO SAY that I LIKE THE IDEA OF ALL CAPS ON EVERYTHING BUT
keywords.  I AM CONSTANTLY being CONFUSED ABOUT WHETHER A CERTAIN word
IS A keyword OR NOT and IT MAKES SUCH A huge DIFFERENCE TO SOMEONE WHO
IS TRYING TO read Ada^H^H^HADA SOURCE code.  MY keyword QUICK REFERENCE
CARD FOR ADA LISTS ALL 10#63# of THE keywords, BUT IT'S BEGINNING TO
GET WORN OUT FROM USE.

BESIDES, I FEEL LIKE I'M GOING blind SINCE I LEFT VMS, FORTRAN, and BASIC.

(is a flame a flame in a religious discussion ?)
-- 

db
bashford@srs.loral.com (Dave Bashford, Sunnyvale, CA)

Re: Ada Operators in 9x

[munck]

In INFO-ADA Digest V93 #418, seas.gwu.edu!mfeldman@uunet.uu.net
(Michael Feldman) said:

> Suppose you _meant_ to write
>
>  q := 35;
>
>but instead hit the shift key accidentally and wrote
>
>  Q := 35;
>

Not terribly convincing.  Suppose you _meant_ to write

  q := 35;

but instead hit the z key accidentally and wrote

  zq := 35;

and happened to have a declaration for zq as well as q, just as
your example had Q and q.  Both are single-keystroke errors.


In fact, in my ideal, high-LOC-productivity environment, I would
rarely be typing names in any case.  Instead I would be mouse-clicking
on the name in earlier code or in a data-structure diagram in the next
window, while chording in reserved words, operators, and literals with
my left hand.  (Yes, I was tremendously influenced by one of the Great
Men of Computing as a youth.)

What I really want is a non-printing alphanumeric character --
something that looks like a space to the eye and an alphanumeric to
the parser.  After all, one rarely refer's to one's pet in writing as
the brown_and_white_cat or BrownAndWhiteCat.  It seems unlikely that
I'll get this in 9X.

Bob Munck

Re: Ada Operators in 9x

[Laurence VanDolsen]

In article <2849.741636874@blackbird> munck@STARS.Reston.Paramax.COM writes:
>
>What I really want is a non-printing alphanumeric character --
>something that looks like a space to the eye and an alphanumeric to
>the parser.  After all, one rarely refer's to one's pet in writing as
>the brown_and_white_cat or BrownAndWhiteCat.  It seems unlikely that
>I'll get this in 9X.
>
>Bob Munck

No, it won't be there.  All of us with two words in our last name would
like that character also.  I t would significantly reduce erroneous
sorts and redundant mailings of junk catalogs.

--
Laurence L. Van Dolsen - Der fliegender Hollander
My opinions are my own, but you are welcome to them.
Paramax - (805) 987-9302 - vand@cam.paramax.com

Re: Ada Operators in 9x

[Robert I. Eachus]

In article <1993Jul08.221838.35531@source.asset.com> vand@source.asset.com (Lau
rence VanDolsen) writes:

  > No, it won't be there.  All of us with two words in our last name would
  > like that character also.  I t would significantly reduce erroneous
  > sorts and redundant mailings of junk catalogs.

    Actually, the option to allow this is there, it is not required to
be supported...  This applies to Ada 83 and Ada 9X.  Personally I
would find code with NBSP and spaces having different effects
intolerable, but if you think you would like it go ahead.

    The current position is that compilers must have a mode in which
the input maps to the ACSII character set (which is now the same as
Latin-1) but compilers are free to support other modes.  For example
you would really want an IBM-PC compiler to have a moode which
supports the (psuedo)standard upper-page characters, or if you live in
Turkey, you would want a compiler that allowed dotless i's. Of course
such a source program will not be easily portable.  The GNAT compiler
will accept many mappings as command line options.




--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...