comp.lang.ada
 help / color / mirror / Atom feed
From: Richard D Riehle <LaoXhai@ix.netcom.com>
Subject: Re: Types (was Ada 95 LRM Error?)
Date: 1999/02/01
Date: 1999-02-01T14:19:17-06:00	[thread overview]
Message-ID: <795285$duu@dfw-ixnews8.ix.netcom.com> (raw)
In-Reply-To: yecu2x715hb.fsf@king.cts.com

In article <yecu2x715hb.fsf@king.cts.com>,
	Keith Thompson <kst@cts.com> wrote:

>The general point is correct, but the specific point is not; int and
>char are definitely distinct types in C.

 Semantics, again.  Yes, they seem to be "distinct types" (i.e.,
 have distinct names) but the next paragraph makes one wonder.

>Note that there are several possible sources of confusion here.  The
>types char and int are assignment compatible, character literals are
>of type int, char objects are usually promoted to int in arithmetic
>expressions, and char function arguments are promoted to int in the
>absence of a prototype.

 This reminds me of a card trick expert at some obligatory social
function.
 No matter what card I select, the card trickster will be able to find
 it through some illusory sleight of hand.  

 My understanding of type, in part, is that a type has,

    1) a name, in scope within some declarative region
    2) a defined set of operations for objects of the name
    3) a defined set of values for objects of the name
    4) a "wall" between objects of the named type and 
              objects with some other type name.

The last characteristic, a wall, is important for type to have any
real meaning.  Ada allows us to get beyond the "wall" through type
conversion, view conversion, and even unchecked conversion, but the 
wall is always there.  In C, there is no wall.  When considered this
way, int and char are not really distinct. C allows the dangerous 
illusion of distinct types, a source of many interesting defects 
in C and C++ software.  

The example of Integer, Natural, and Positive does not meet this test
because subtypes, in the reserved word sense, have no wall between them.
Perhaps int and char are more analogous to Ada entities we define using
the subtype reserved word. 
 
This thread began with a consideration of the type definitions in the
Interfaces.COBOL examples in the Annex B.  Robert Dewar has pointed
out that COBOL does, in fact, have types, abeit somewhat more flexible
types than we find in Ada.  Any attempt to interface between a strongly
typed language and one that is weakly-type, requires some concession
to the characteristics of the weakly-typed language. 

The ability to implicitly promote one type to another does not seem to
me to meet the standards I would expect for "distinct types."  

It is interesting that one can start with a strongly-type language, one
where the default is strong typing, and selectively relax the type model
for some targeted environment. It is harder to start with a weakly-typed
language and  make it strongly-typed.  This is one of the key problems
with C++.  The language starts with the weak typing of C and tries to
overlay a model for strong typing.  The result is a language that, like
the card trickster at the party, seduces the naive programmer into
believing in magic.  

Richard Riehle
http://www.adaworks.com





  reply	other threads:[~1999-02-01  0:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-27  0:00 Ada 95 LRM Error? Al Christians
1999-01-27  0:00 ` Martin C. Carlisle
1999-01-28  0:00   ` J. David Bryan
1999-01-28  0:00 ` Richard D Riehle
1999-01-27  0:00   ` Al Christians
1999-01-28  0:00     ` robert_dewar
1999-01-28  0:00       ` Al Christians
1999-01-28  0:00     ` Richard D Riehle
1999-01-28  0:00       ` Interfaces.Cobol (Was LRM Error?) Al Christians
1999-01-29  0:00       ` Ada 95 LRM Error? robert_dewar
1999-01-31  0:00         ` Keith Thompson
1999-02-01  0:00           ` Richard D Riehle [this message]
1999-02-02  0:00           ` robert_dewar
1999-01-28  0:00 ` robert_dewar
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox