sommar@enea.se (Erland Sommarskog) (03/07/90)
Henry Spencer (henry@utzoo.uucp) writes: >Modern >C is a strongly-typed language by any reasonable definition, although >there are still a lot of antique compilers around that don't fully >enforce its rules. C strongly typed? If I write something like: (I don't speak C so the syntax is probably bogus.) typedef apple int; typedef orange int; apple a; orange b; ... a = b; Will a "modern" compiler object? -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
ark@alice.UUCP (Andrew Koenig) (03/07/90)
In article <849@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > C strongly typed? If I write something like: (I don't speak C > so the syntax is probably bogus.) > typedef apple int; > typedef orange int; > apple a; > orange b; > ... > a = b; > Will a "modern" compiler object? I don't understand why this is relevant. If in Standard ML I write type apple = int; type orange = int; val a: apple = 1; val b: orange = a; the compiler won't object either. Does this mean Standard ML is not strongly typed? -- --Andrew Koenig ark@europa.att.com
henry@utzoo.uucp (Henry Spencer) (03/08/90)
In article <849@enea.se> sommar@enea.se (Erland Sommarskog) writes: >>Modern >>C is a strongly-typed language by any reasonable definition... > >C strongly typed? If I write something like... > typedef apple int; > typedef orange int; > apple a; > orange b; > ... > a = b; > >Will a "modern" compiler object? No, because the somewhat-misnamed "typedef" explicitly declares a synonym, not a new type. However, if you write something like: char *p; int a; ... a = p; any modern compiler will object. C's type system is not extensible unless you count "struct", but the language is strongly typed -- mixing random types is not allowed. -- MSDOS, abbrev: Maybe SomeDay | Henry Spencer at U of Toronto Zoology an Operating System. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
jlg@lambda.UUCP (Jim Giles) (03/08/90)
From article <849@enea.se>, by sommar@enea.se (Erland Sommarskog): > [...] > C strongly typed? If I write something like: (I don't speak C > so the syntax is probably bogus.) > typedef apple int; > typedef orange int; > apple a; > orange b; > ... > a = b; Yes C is strongly typed - by the definition of 'strong typing'. The phrase 'strong typing' means that the type of any object in an scope can be determined at compile time. So, in the example you gave, it is quite trivial to determine the data types of all the objects given just by examining the text. C is not only strongly typed, but it requires explicit declarations of everything. You are confusing 'strong typing' with 'strict type checking'. The later term refers to languages which discourage (or even disallow) any mixed-mode operations without _explicit_ type coersions. To be sure, strict typing is easier to do if the language is also strongly typed - this is probably how this confusion of terms (which is common) originally arose. But a strict language isn't necessarily strongly typed. Any language which allows late binding is (again by definition) _not_ stongly typed - but such a language may still restrict mixed-mode operations; it would just have to do all the checking at run-time. J. Giles
ok@goanna.oz.au (Richard O'keefe) (03/08/90)
In article <849@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > C strongly typed? If I write something like: (I don't speak C > so the syntax is probably bogus.) > typedef apple int; > typedef orange int; > apple a; > orange b; > ... > a = b; > Will a "modern" compiler object? No, of course not. Try it in Pascal: program main; type apple = integer; orange = integer; var a: apple; o: orange; begin a := o; end. A Pascal compiler may complain that "o" is uninitialised, but it *must* accept the assignment as well-typed. (I tried it.) Try it in Ada (not checked, as I haven't access to an Ada compiler): declare subtype apple is integer; subtype orange is integer; a: apple; o: orange := 1; begin a := o; end Again, the assignment is well-typed. Why should C be different?
bvickers@ics.uci.edu (Brett J. Vickers) (03/08/90)
In article <1990Mar7.182230.5517@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > C's type system is not extensible unless >you count "struct", but the language is strongly typed -- mixing random >types is not allowed. This is simply not true. foo() { int a; char c; a = 48; c = a; } As far as I know, this will compile. C is extremely flexibly typed. If you want a strongly typed language, use Ada. -- bvickers@bonnie.ics.uci.edu
machaffi@fred.cs.washington.edu (Scott MacHaffie) (03/08/90)
In article <14262@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
%Yes C is strongly typed - by the definition of 'strong typing'. The
%phrase 'strong typing' means that the type of any object in an scope
%can be determined at compile time. So, in the example you gave, it is
You just described "static typing".
Scott MacHaffienmm@cl.cam.ac.uk (Nick Maclaren) (03/08/90)
Henry Spencer writes: > .... C's type system is not extensible unless > you count "struct", but the language is strongly typed -- mixing random > types is not allowed. I am afraid that I must disagree with this. While mixing RANDOM types is not allowed, even ANSI C permits a bewildering variety of type punning. For example: double x, y; memcpy(&x,&y,sizeof(double)); The ANSI standard (and K&R) explicitly require that any data type may be treated as an array of characters (under certain circumstances, such as the above). A huge proportion of the library relies upon this to work at all (e.g. much of string.h, some of stdlib.h, some of stdio.h). union {void *a; char *b;} fred; fred.a = ...; ... = fred.b; This example is a curiosity in ANSI C: while it is illegal, and the compiler is entitled to throw it out, it is also required to work! The reason is that 'char *' and 'void *' are different types but are required to have the same representation and alignment. There are a large number of more obscure cases, many of which are relied upon by traditional C programs. Good, portable ones avoid such constructions if at all possible, but sometimes their use is essential. Nick Maclaren University of Cambridge Computer Laboratory nmm@cl.cam.ac.uk
jwb@cepmax.ncsu.EDU (John W. Baugh Jr.) (03/08/90)
In article <2963@goanna.oz.au>, ok@goanna.oz.au (Richard O'keefe) writes: > In article <849@enea.se>, sommar@enea.se (Erland Sommarskog) writes: > > C strongly typed? If I write something like: (I don't speak C > > so the syntax is probably bogus.) > > [some C code] > > Will a "modern" compiler object? > > No, of course not. Try it in Pascal: > [some Pascal code] > A Pascal compiler may complain that "o" is uninitialised, but it > *must* accept the assignment as well-typed. (I tried it.) I think the issue here is "type equivalence," i.e., the relation that determines whether or not two types are compatible, assignable, etc. Equivalence mechanisms range from structural equivalence (fairly loose) to name equivalence (tight). Although the original Pascal definition was silent on the issue of type equivalence, I was under the impression that the recent ISO/ANSI Pascal standard defined equivalence based on name. For example, giving the definitions: type t1 = array[1..3] of boolean; t2 = array[1..3] of boolean; var v1 : t1; v2 : t2; the types of v1 and v2 are distinct under name equivalence, but equal under structural equivalence. John Baugh
ftw@quasar..westford.ccur.com (Farrell Woods) (03/09/90)
In article <25F5AA40.27091@paris.ics.uci.edu> bvickers@ics.uci.edu (Brett J. Vickers) writes: >In article <1990Mar7.182230.5517@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >> C's type system is not extensible unless >>you count "struct", but the language is strongly typed -- mixing random >>types is not allowed. >This is simply not true. [Example deleted] Henry's right! The point is that `char' and `int' (and, `short' and `long') all describe *integer* quantities. It's just that the range os values which each of these "types" can hold differs due to the amount of storage allocated to a variable of a given type. -- Farrell Woods -- Farrell T. Woods Voice: (508) 392-2471 Concurrent Computer Corporation Domain: ftw@westford.ccur.com 1 Technology Way uucp: {backbones}!masscomp!ftw Westford, MA 01886 "I can't drive...fifty-five!"
rimvallm@jupiter.crd.ge.com (Magnus Rimvall) (03/09/90)
In article <2963@goanna.oz.au> you write: > > declare > subtype apple is integer; > subtype orange is integer; > a: apple; > o: orange := 1; > begin > a := o; > end >Again, the assignment is well-typed. Why should C be different? and thereby attempt to imply that Ada, C and Pascal have an equal (lack of) strong typing and type checking. Obviously, you either know very little about Ada or you deliberately try to misinform the reader. If your Ada example had read as follows: declare type apple is NEW integer; type orange is NEW integer; a: apple; o: orange := 1; begin a := o; end the a:=o assignment would have been illegal, and would have been caught AT COMPILE TIME by any Ada compiler. Magnus Rimvall
merriman@ccavax.camb.com (03/09/90)
In article <1990Mar7.182230.5517@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > However, if you write something like: > > char *p; > int a; > ... > a = p; > > any modern compiler will object. C's type system is not extensible unless > you count "struct", but the language is strongly typed -- mixing random > types is not allowed. I guess that lets VAX C out as a modern compiler. the following compiles without complaint: #include stdio int i; char c; int *ip; char *cp; main() { i = 700; c = i; printf("%d %d\n", i, c); ip = &i; cp = ip; printf("%d %d\n", *cp, *ip); i = cp; ip = i; printf("%d %d\n", *cp, *ip); } and produces the following output: 700 -68 -68 700 32 544 Anyone care to explain the last line of output? BTW, I included the int to char assignment to demonstrate what I consider to be a really obnoxious and dangerous shortcoming (at least in VAX C). Do real C compilers allow the same thing, without comment?
bvickers@ics.uci.edu (Brett J. Vickers) (03/09/90)
ftw@quasar.westford.ccur.com (Farrell Woods) writes: >>In article <1990Mar7.182230.5517@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>> C's type system is not extensible unless >>>you count "struct", but the language is strongly typed -- mixing random >>>types is not allowed. > >Henry's right! The point is that `char' and `int' (and, `short' and `long') >all describe *integer* quantities. It's just that the range os values which >each of these "types" can hold differs due to the amount of storage allocated >to a variable of a given type. If C were as strongly typed a language as Ada is, it would require that a cast (or conversion) be used before setting two different "types" of integers equal. If C were as strongly typed a language as Ada (or Pascal) is, it would not allow integers to be accessed and stored as char types. I'm not knocking this flexible typing; I find it extremely useful. -- bvickers@bonnie.ics.uci.edu
ok@goanna.oz.au (Richard O'keefe) (03/09/90)
Concerning whether C is strongly typed; I gave Pascal and Ada equivalents of the fragment which was alleged to show C not to be strongly typed. In article <1990Mar8.142433.13559@ncsuvx.ncsu.edu>, jwb@cepmax.ncsu.EDU (John W. Baugh Jr.) writes: > I think the issue here is "type equivalence," ... > ... ISO/ANSI Pascal standard defines equivalence based on name. > > type > t1 = array[1..3] of boolean; > t2 = array[1..3] of boolean; > var > v1 : t1; > v2 : t2; > > the types of v1 and v2 are distinct under name equivalence, but equal > under structural equivalence. Quite right. But it isn't relevant to the example under discussion. Remember, the C fragment was typedef int apple, orange; apple a; orange b; a = b; The Pascal equivalent of such a typedef is type <id> = <type id>; and that does NOT introduce a new name. For example, type t1 = array[1..3] of boolean; t2 = t1; (* NO NEW TYPE IS INTRODUCED HERE *) var v1: t1; v2: t2; begin v2 := v1; is perfectly legal Pascal. Someone else claimed that the fact that char c; int i; i = c; or something like that is legal C also shows that C is not strongly typed. Again, Pascal and Ada are exactly the same. The Pascal equivalent of C's "char" is const minChar = {-128, or 0, or what have you}; maxChar = {127, or 255, or what have you}; type cChar = minChar..maxChar; The fact that var c: cChar; i: integer; begin i := c; is legal is not normally held to show that Pascal is not strongly typed; why should the same fact be held against C? True, C has no equivalent of Pascal's character type, but the absence of an equivalent for some other language's data type is not fatal to being strongly typed.
ok@goanna.oz.au (Richard O'keefe) (03/09/90)
In article <5880@crdgw1.crd.ge.com>, rimvallm@jupiter.crd.ge.com (Magnus Rimvall) writes: > In article <2963@goanna.oz.au> you write: > > declare > > subtype apple is integer; > > subtype orange is integer; > Obviously, you either know very little about Ada or you deliberately > try to misinform the reader. Those are fighting words. I shall reply in kind: surely you either know very little about C or you are being deliberately insulting. The point is that I *do* understand Ada well enough to show CORRECTLY what the Ada equivalent of the C fragment in question is. Rimvall's suggested version using NEW is *not* expressible in C *nor* in Pascal. What I was saying is that the C typedef typedef int apple; is the equivalent of subtype apple is integer; How does this count as ignorance or misinformation?
grano@cs.Helsinki.FI (Kari Gran|) (03/09/90)
In article <2963@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes:
!Try it in Ada (not checked, as I haven't access to an Ada compiler):
! declare
! subtype apple is integer;
! subtype orange is integer;
! a: apple;
! o: orange := 1;
! begin
! a := o;
! end
!Again, the assignment is well-typed. Why should C be different?
But you're using Ada's _subtypes_, which hide the fact that Ada is
a strictly (strongly? - not well defined terms anyway) typed language. If
you try
declare
type apple is integer;
type orange is integer;
a : apple;
o : orange;
begin a:= o; end;
then the types aren't any longer compatible and the assignment is thus
illegal.
Kari.
--
Kari Grano grano@cs.helsinki.fi Hey, my opinions are just mine..
"I've got a thousand telephones that don't ring" - R.Z.mph@lion.inmos.co.uk (Mike Harrison) (03/09/90)
In article <2963@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes: >Try it in Ada (not checked, as I haven't access to an Ada compiler): > declare > subtype apple is integer; > subtype orange is integer; > a: apple; > o: orange := 1; > begin > a := o; > end >Again, the assignment is well-typed. Why should C be different? Yes, but instead try: declare type APPLE is new INTEGER; type ORANGE is new INTEGER; A: APPLE; O: ORANGE := 1; begin A := O; end This assignment IS illegal, though you could write: A := APPLE(O); which performs an explicit type conversion. Mike, Michael P. Harrison - Software Group - Inmos Ltd. UK. ----------------------------------------------------------- UK : mph@inmos.co.uk with STANDARD_DISCLAIMERS; US : mph@inmos.com use STANDARD_DISCLAIMERS;
jejones@mcrware.UUCP (James Jones) (03/09/90)
In article <1990Mar7.182230.5517@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >any modern compiler will object. C's type system is not extensible unless >you count "struct", but the language is strongly typed -- mixing random >types is not allowed. Eh? C will let you coerce essentially anything. If all else fails, coerce the address of the object about whose type you wish to lie, and then dereference. James Jones
flc@n.sp.cs.cmu.edu (Fred Christianson) (03/09/90)
In article <4401@hydra.Helsinki.FI> grano@cs.Helsinki.FI (Kari Gran|) writes: >a strictly (strongly? - not well defined terms anyway) typed language. Here's ONE POSSIBLE definition. I'm not arguing that "strongly typed" is well defined. I'm just giving one definition. From Aho, Sethi and Ullman's _Compilers,_Principles,_Techniques,_and_Tools_: A language is strongly typed if its compiler can guarantee that the programs it accepts will execute without type errors ... For example if we first declare table: array[0..255] of char; i: integer and then compute table[i], a compiler cannot in general guarantee that during execution, the value of i will lie in the range 0 to 255. The C equivalent example char table[256]; int i; shows that C is not "strongly typed" according to Aho, Sethi, and Ullman. My other compiler/language books don't even use strong in their discussion of type checking. MY OPINION: For any reasonable definition of "strongly typed" C is not "strongly typed". ---- Fred p.s. Let's not argue about a reasonable definition for "reasonable".
aitken@shamesh.cs.cornell.edu (William E. Aitken) (03/10/90)
In article <8356@pt.cs.cmu.edu> flc@n.sp.cs.cmu.edu (Fred Christianson) writes: >In article <4401@hydra.Helsinki.FI> grano@cs.Helsinki.FI (Kari Gran|) writes: >>a strictly (strongly? - not well defined terms anyway) typed language. > >Here's ONE POSSIBLE definition. I'm not arguing that "strongly typed" is >well defined. I'm just giving one definition. > >From Aho, Sethi and Ullman's _Compilers,_Principles,_Techniques,_and_Tools_: > > A language is strongly typed if its compiler can guarantee that > the programs it accepts will execute without type errors ... > > For example if we first declare > > table: array[0..255] of char; > i: integer > > and then compute table[i], a compiler cannot in general guarantee > that during execution, the value of i will lie in the range 0 to 255. > >The C equivalent example > > char table[256]; > int i; > >shows that C is not "strongly typed" according to Aho, Sethi, and Ullman. I don't see how, evaluation of table[i] is not a type error but a subscript out of range error (incidentally, the same thing happens in Pascal which is (I believe) generally considered strongly typed). If you think that I am splitting hairs here, consider the case of zero division. I submit the thesis that there is no good definition of strongly typed. Some authors have used it to mean statically typed. I.e. all expressions and sub expressions have types determinable at compile time. This admits languages with a single type to which all objects belong. This is hardly satisfying. We have already seen that the definition given above is easily defeated by declaring, by fiat, that all run time errors are not type errors. Another possibility is to say that no run time errors will occur. This is easily confounded by the language that is defined to enter a tight infinite loop whenever it detects a run time error. (another possibility is to raise an exception, and provide a default handler) Outlawing these devices compromises either compilability or expressiveness: either the acceptability of a given program is no longer decidable, or the language is no longer Turing-complete, or both. When evaluating type systems, several issues must be addressed. (1) Is well-typing decidable? (2) Is well-typing compile-time decidable? (3) What run-time guarantees are there for well-type programs? (4) Are run-time checks required? how expensive are they? (5) How expressive is the type system? That is what properties of data can one express with types. (6) How restrictive is the type system? What programs can I write? The relevence of many points raised in this debate hinges on whether the expressive of a type system has anything to do with its ``strength''. I have rambled on for too long --- Bill. William E. Aitken <aitken@cs.cornell.edu> | On Earth it is considered {uw-beaver,rochester,decvax}!cornell!aitken | ill mannered to kill your Home: (607) 273-7810 Away : (607) 255-9206 | friends while commiting suicide ============================================*============= Avon ==============
jlg@lambda.UUCP (Jim Giles) (03/10/90)
In article <11007@june.cs.washington.edu>, machaffi@fred.cs.washington.edu (Scott MacHaffie) writes: - In article <14262@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes: - %Yes C is strongly typed - by the definition of 'strong typing'. The - %phrase 'strong typing' means that the type of any object in an scope - %can be determined at compile time. So, in the example you gave, it is - - You just described "static typing". Yes, I did. The two term are synonymous. English _does_ have this annoying habbit of providing more than one word for a given meaning. This is even true in technical jargon. The fact is that strong/weak typing is defined (at least in the language design field) as the distinction between compile-time and run-time type specification. If you prefer 'static' to 'strong' that is your choice. J. Giles
sommar@enea.se (Erland Sommarskog) (03/10/90)
Henry Spencer (henry@utzoo.uucp) writes:
)No, because the somewhat-misnamed "typedef" explicitly declares a synonym,
)not a new type. However, if you write something like:
)
) char *p;
) int a;
) ...
) a = p;
)
)any modern compiler will object. C's type system is not extensible unless
)you count "struct", but the language is strongly typed -- mixing random
)types is not allowed.
Well, apparently I am allowed to mix apples and oranges. If I have
two types of data that both happens to be represented by integers,
but have no logical connection what so ever I cannot apparently
express that in C. And consequently I cannot take help from the
compiler to catch inadvertent mixups in for instance procedure calls.
--
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.sesommar@enea.se (Erland Sommarskog) (03/10/90)
Richard O'keefe (ok@goanna.oz.au) writes:
)A Pascal compiler may complain that "o" is uninitialised, but it
)*must* accept the assignment as well-typed. (I tried it.)
True, Pascal is as weakly typed as C.
)Try it in Ada (not checked, as I haven't access to an Ada compiler):
) declare
) subtype apple is integer;
) subtype orange is integer;
) a: apple;
) o: orange := 1;
) begin
) a := o;
) end
)Again, the assignment is well-typed. Why should C be different?
That compiles, I would guess, but not if you declare:
TYPE apple IS NEW integer;
TYPE orange IS NEW integer;
which of course the way to do it.
--
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.seftw@quasar..westford.ccur.com (Farrell Woods) (03/10/90)
In article <25F6E8B7.16437@paris.ics.uci.edu> bvickers@ics.uci.edu (Brett J. Vickers) writes: >ftw@quasar.westford.ccur.com, I write: >>...The point is that `char' and `int' (and, `short' and `long') >>all describe *integer* quantities.... >If C were as strongly typed a language as Ada (or Pascal) is, it >would not allow integers to be accessed and stored as char types. You're missing the point: C doesn't have a `char' type in the same sense as Pascal, et. al. It has integers that can hold greater or lesser ranges of values, depending on your needs (you describe your need by declaring an appropriately sized variable). For instance: 'c' has type `int'. Really. Try this: main() { printf("%d\n", sizeof ('c')); } and tell us what your compiler says. It *should* give an answer that is the same as sizeof (int). -- Farrell Woods -- Farrell T. Woods Voice: (508) 392-2471 Concurrent Computer Corporation Domain: ftw@westford.ccur.com 1 Technology Way uucp: {backbones}!masscomp!ftw Westford, MA 01886 "I can't drive...fifty-five!"
bvickers@ics.uci.edu (Brett J. Vickers) (03/10/90)
ftw@quasar.westford.ccur.com (Farrell Woods) writes: >bvickers@ics.uci.edu (Brett J. Vickers) writes: >>ftw@quasar.westford.ccur.com, I write: >>>...The point is that `char' and `int' (and, `short' and `long') >>>all describe *integer* quantities.... > >>If C were as strongly typed a language as Ada (or Pascal) is, it >>would not allow integers to be accessed and stored as char types. > >You're missing the point: C doesn't have a `char' type in the same sense >as Pascal, et. al. In other words, C is NOT strongly typed. The very fact that C treats characters as 8-bit integers suggests this. It is fundamentally flexible where type is concerned. -- bvickers@bonnie.ics.uci.edu
mike@cs.umn.edu (Mike Haertel) (03/10/90)
In article <862@enea.se> sommar@enea.se (Erland Sommarskog) writes: >Well, apparently I am allowed to mix apples and oranges. If I have >two types of data that both happens to be represented by integers, >but have no logical connection what so ever I cannot apparently >express that in C. And consequently I cannot take help from the >compiler to catch inadvertent mixups in for instance procedure calls. So declare struct apple { int v; }; struct orange { int v; }; C uses name equivalence for structure types. -- Mike Haertel <mike@ai.mit.edu> "We are trying to support small memory machines." -- Larry McVoy
chris@mimsy.umd.edu (Chris Torek) (03/10/90)
In some article somewhere someone claims that because
f() {
typedef int apple, orange;
apple a;
orange o = 1;
a = o;
}
compiles without complaint, C must therefore not be strongly typed.
>In article <2963@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) points out
that by this logic, neither is (part of) Ada:
>> subtype apple is integer;
>> subtype orange is integer;
In article <4440@ganymede.inmos.co.uk> mph@lion.inmos.co.uk (Mike Harrison)
says to use instead
> type APPLE is new INTEGER;
> type ORANGE is new INTEGER;
Well, if we are allowed to rewrite the code arbitrarily, I suggest
typedef struct { int value; } apple;
typedef struct { int value; } orange;
f(void) {
apple a;
orange o = { 1 }; /* NB: requires ANSI C */
a = o;
}
which is (surprise surprise) illegal.
Those who will argue with Henry Spencer should read his original article
(and perhaps his followup; I cannot recall whether there was one) closely:
it says (paraphrased)
a) typedef does not define a new type.
b) `struct' defines a new type.
c) If you want the compiler to complain, you must
therefore not rely on `typedef' alone.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@cs.umd.edu Path: uunet!mimsy!chrisCMH117@psuvm.psu.edu (Charles Hannum) (03/10/90)
In article <862@enea.se>, sommar@enea.se (Erland Sommarskog) says: > >Well, apparently I am allowed to mix apples and oranges. If I have >two types of data that both happens to be represented by integers, >but have no logical connection what so ever I cannot apparently >express that in C. And consequently I cannot take help from the >compiler to catch inadvertent mixups in for instance procedure calls. Well, yes, the following does compile with no problems: typedef enum { SKIN, CORE } apple; typedef enum { PEEL, SEED } orange; apple grannysmith; orange tangerine; int main(void) { grannysmith = tangerine; } But if I may ask, what's your point? Anyone programmer with half a brain would know that a Granny Smith isn't equivalent to a tangerine. I like C precisely because it DOESN'T hold my hand. Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
chris@mimsy.umd.edu (Chris Torek) (03/10/90)
>>... C doesn't have a `char' type in the same sense as Pascal, et. al. In article <25F85CF6.7304@paris.ics.uci.edu> bvickers@ics.uci.edu (Brett J. Vickers) writes: >In other words, C is NOT strongly typed. No. In other words, C does not have a character type. Or, put another way, C has several integer types, but no character type. You cannot make from this the conclusion `C is not strongly typed.' >The very fact that C treats characters as 8-bit integers suggests this. >It is fundamentally flexible where type is concerned. C's type compatibility scheme opts for flexibility, yes. But this does not warrant your conclusion (`C not strongly typed') without a very strange definition of `strongly typed'. C has these types: { made integer: char, short, int, long arithmetic { up { from floating: float, double (plus unsigned variants and extensions such as `long long') pointer (points to some other type) { made array (of some other type) aggregate { up struct (containing one or more elements) { from union (an undiscriminated union) function (returns some other type) void (has no value) enumerated (rather peculiar; see comp.std.c for discussion of ANSI C enumerated types and constants.) None of these basic types are assignment compatible. Some of them cannot even be named outside a cast or declaration (namely array types and function types; no expression values have such a type). In addition, each distinct pointer, structure, array, union, or function type is not assignment compatible with any other type unless it is in some fundamental way `the same'. (Enumerated types may be assignment compatible, depending on your compiler.) For instance, given char **cpp; int *ip; char **z; short *(*fp)(char *); short *(*fp2)(int); `z' and `cpp' are assignment compatible, because they are both pointers that point to identical types. Neither is assignment compatible with ip or fp, even though both ip and fp are also pointers. A compiler that does not produce a diagnostic for z = fp; does not conform to the ANSI standard. Furthermore, fp and fp2 are not type compatible, and again a compiler that does not produce a diagnostic does not conform to the standard, even though they differ only in argument types. What does confuse many people is that the arithmetic types are all assignment-compatible. This leads them to conclude that C is not strongly typed. Were that the case, I, for one, would not expect int i = 1; float f; f = i; to put `1.0' into f, but rather to act as if I had written *(int *)&f = i; or f = *(float *)&i; so that `f' would become, e.g., 1.4013e-45 (using IEEE float, little-endian int, on a DECstation). But f becomes 1.0. The type system has intervened, changing the bit pattern in passing. The same *does* happen for char c; int i; c = i; but the conversion is less well defined. If the value in `i' is out of range for a `char' variable---that range being CHAR_MIN..CHAR_MAX---the result is undefined, much as the result of var r: real; i: integer; ... i := trunc(r); ... is (probably; I do not have any Pascal standard around to check) undefined when `r' is not in the range of `i'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris
throopw@sheol.UUCP (Wayne Throop) (03/11/90)
> From: flc@n.sp.cs.cmu.edu (Fred Christianson) > From Aho, Sethi and Ullman's _Compilers,_Principles,_Techniques,_and_Tools_: > A language is strongly typed if its compiler can guarantee that > the programs it accepts will execute without type errors ... > For example if we first declare > table: array[0..255] of char; > i: integer > and then compute table[i], a compiler cannot in general guarantee > that during execution, the value of i will lie in the range 0 to 255. By this definition, are there ANY stronly typed languages in the algol family? I can't think of any strongly typed languages by this definition that are in what I'd call practial use. Can anybody else? Certainly Ada, ModulaII, and Pascal all fail this test, do they not? And a general objection to this definition is that it doesn't define a gradiation; it defines "strongly typed" as a binary property, so that one language is not "more strongly typed" than another... it either Is or it Isn't. This doesn't follow the usual thoughts about strong typeing. -- Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org
grano@cs.Helsinki.FI (Kari Gran|) (03/11/90)
A related question is whether 'strong typing' refers to static or dynamic type checking - some type errors just can't be detected at compile time (subranges and indexes, for example). Also, one could argue whether a language that has implicit type conversions is strongly typed. In Pascal, you may write i : integer; r : real; ... r:= i + r; and the compiler won't object (I hope :-). Ada disallows this, but moves the whole stuff into _sub_types, thus allowing somewhat more flexible programming practices. But what comes to C.. IMO, it is typed all right, but very weakly. That results in great flexibility and efficiency, but with the expense of a certain unsafety. Which counts more depends on your mileage... :-). Kari. P.S. Oh, and I think I forgot 'new's from my previous posting. In fact I'm not so sure about that.. maybe someone could correct this? -- Kari Grano grano@cs.helsinki.fi Hey, my opinions are just mine.. "I've got a thousand telephones that don't ring" - R.Z.
CMH117@psuvm.psu.edu (Charles Hannum) (03/11/90)
In article <1798@gannet.cl.cam.ac.uk>, nmm@cl.cam.ac.uk (Nick Maclaren) says: > >The ANSI standard (and K&R) explicitly require that any data type may be >treated as an array of characters ... >the above). This is simply not true! See below ... > A huge proportion of the library relies upon this to work at >all (e.g. much of string.h, some of stdlib.h, some of stdio.h). Well, everything in string.h works with arrays of characters; what's your point? As for stdlib.h and stdio.h, see comments on the void type below ... > union {void *a; char *b;} fred; > fred.a = ...; > ... = fred.b; What is wrong with this? First, this would only work if "..." was another void pointer or a char pointer. You seem to be bashing C for the inclusion of a void type ... "void" in C is similar to "nil" in LISP. It's just a generic type, which can hold the place of any other type, WHEN USED IN A POINTER!! I couldn't assign a character to a void type, for example. But I *can* assign a void pointer to a character pointer, and vice versa. This is part of the power of the C language. It simplifies things like malloc(), for example. And void has *nothing* to do with char! Try this: #include <stdio.h> int main(void) { printf("%d %d\n",sizeof(void),sizeof(char)); } (Actually, my code sample above *does* show a deficiency in the C language; let's see if anyone can figure out what it is.) >[rest of gibberish deleted] Personally, I'm more concerned about the fact that this stupid terminal's "0" key on the keypad isn't working. It causes a lot more problems than a void type. Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
sommar@enea.se (Erland Sommarskog) (03/11/90)
Mike Haertel (mike@cs.umn.edu) writes:
)So declare
)
)struct apple { int v; };
)struct orange { int v; };
)
)C uses name equivalence for structure types.
Did I hear "kludge"? (But it should be acknowledged that not all
Pascal compilers would keep such apples and oranges above apart.).
--
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.sesommar@enea.se (Erland Sommarskog) (03/11/90)
Charles Hannum (CMH117@psuvm.psu.edu) writes: >But if I may ask, what's your point? Anyone programmer with half a brain >would know that a Granny Smith isn't equivalent to a tangerine. Stupidity. Ever heard of the work "mistake"? Say that I have the routine Macedonia declared as (in Ada syntax): FUNCTION Macedonia(Granny_smith : IN Apple; Tangerine : IN Orange) RETURN Some_type; Now, I'm calling this from another module. In which order comes the parameters now? Ah, it was probably the orange first, wasn't it? A strongly typed language like Ada will catch this error. With C or Pascal I have to spend half a day to find out why the damned fruit salad doesn't taste as intended. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
CMH117@psuvm.psu.edu (Charles Hannum) (03/11/90)
In article <873@enea.se>, sommar@enea.se (Erland Sommarskog) says: > >Stupidity. Ever heard of the work "mistake"? Say that I have the >routine Macedonia declared as (in Ada syntax): > > FUNCTION Macedonia(Granny_smith : IN Apple; > Tangerine : IN Orange) RETURN Some_type; > >Now, I'm calling this from another module. In which order comes >the parameters now? Ah, it was probably the orange first, wasn't >it? A strongly typed language like Ada will catch this error. >With C or Pascal I have to spend half a day to find out why the >damned fruit salad doesn't taste as intended. Your point is well taken. While I do often find C's liberal number conversion useful, it is also annoying that I can't defined a new type, without defining it as a structure (or union). Oh well. Fortunately, I haven't ever run into an application where I really desparately needed name equivalence in anything but structured. Perhaps some day I will. Then I'll switch to Eiffel. Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/12/90)
From grano@cs.Helsinki.FI (Kari Gran|): > P.S. Oh, and I think I forgot 'new's from my previous posting. In fact > I'm not so sure about that.. maybe someone could correct this? > >> declare >> type apple is integer; -- could read: type Apple is new Integer; >> type orange is integer; -- could read: type Orange is new Integer; >> a : apple; >> o : orange; >> begin a:= o; end; Actually, it would not matter. By LRM 3.3.1(8), "Two type definitions always define two distinct types, even if they are textually identical." The "new" mechanism will generally be used when we want to put more constraints on the new type than we had specified for the base type: type Weekday is new Day range Monday..Friday; This creates the type Weekday, which is distinct from (and incompatible with) the type Day. If we wanted to make them distinct but compatible: subtype Weekday is Day range Monday..Friday; Bill Wolfe, wtwolfe@hubcap.clemson.edu
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (03/12/90)
In article <90070.034113CMH117@psuvm.psu.edu> CMH117@psuvm.psu.edu (Charles Hannum) writes: >"void" in C is similar to "nil" in LISP. It's just a generic type, which can >hold the place of any other type, WHEN USED IN A POINTER!! I couldn't assign Some clarification is called for here. In C, 'void' (*not* 'void *') is used in function declarations and definitions to signify the absence of arguments and/or a return value. In this role, Common Lisp's closest analog is the expression (VALUES) which returns zero values. (The VALUES form is more often used to return multiple values.) NIL is quite different. In Common Lisp, NIL is a specific object: the only object of type NULL, which is in turn a subtype of both SYMBOL and LIST. NIL's existence is just as tangible as that of the number 0. NIL does, of course, fulfil some special roles (e.g., as the default initializer for a name binding). C's 'void *', on the other hand, plays the role of a generic pointer type, as you say. Its closest Common Lisp analog is the type T, which is a supertype of every type. If I were forced at gunpoint to write type declarations for a Lisp function's arguments, I would declare each of them to be of type T, which essentially asserts existence but nothing more. Despite the syntax, 'void *' has no semantic connection to 'void' at all as far as I can see. Indeed, they are almost opposites: "anything" vs. "nothing." Apparently, C compiler writers simply decided to apply some new semantics to whatever unused syntax was lying around. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/12/90)
From article <0500@sheol.UUCP>, by throopw@sheol.UUCP (Wayne Throop): %> From: flc@n.sp.cs.cmu.edu (Fred Christianson) %> From Aho, Sethi and Ullman's _Compilers,_Principles,_Techniques,_and_Tools_: %> A language is strongly typed if its compiler can guarantee that %> the programs it accepts will execute without type errors ... %> For example if we first declare %> table: array[0..255] of char; %> i: integer %> and then compute table[i], a compiler cannot in general guarantee %> that during execution, the value of i will lie in the range 0 to 255. > > By this definition, are there ANY stronly typed languages in the > algol family? I can't think of any strongly typed languages by this > definition that are in what I'd call practial use. Can anybody else? > Certainly Ada, ModulaII, and Pascal all fail this test, do they not? No compiler could make such a guarantee. However, two points: 1) i should have been declared "integer range table'range;", which would have enabled the compiler to enforce the constraint... 2) even without the constraint, Ada's exception handling facility will handle the error by raising the predefined exception Numeric_Error. Bill Wolfe, wtwolfe@hubcap.clemson.edu
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (03/12/90)
From article <8321@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ): > 2) even without the constraint, Ada's exception handling facility will > handle the error by raising the predefined exception Numeric_Error. That should read, "by raising the predefined exception Constraint_Error." Bill Wolfe, wtwolfe@hubcap.clemson.edu
CMH117@psuvm.psu.edu (Charles Hannum) (03/12/90)
In article <14318@cbnewsc.ATT.COM>, lgm@cbnewsc.ATT.COM (lawrence.g.mayka) says: > >Despite the syntax, 'void *' has no semantic connection to 'void' >at all as far as I can see. Indeed, they are almost opposites: >"anything" vs. "nothing." Apparently, C compiler writers simply >decided to apply some new semantics to whatever unused syntax was >lying around. As they did, but less effectively, with the keyword "static". Virtually, - Charles Martin Hannum II "Klein bottle for sale ... inquire within." (That's Charles to you!) "To life immortal!" cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..." c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."
jnixon@andrew.ATL.GE.COM (John F Nixon) (03/12/90)
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes: > The "new" mechanism will generally be used when we want to put more > constraints on the new type than we had specified for the base type: > type Weekday is new Day range Monday..Friday; What about this? type Weekday is Day range Monday..Friday > This creates the type Weekday, which is distinct from (and incompatible > with) the type Day. If we wanted to make them distinct but compatible: > subtype Weekday is Day range Monday..Friday; Would this break (ahhhh, I mean cause problems, errrr, well...)? subtype Weekday is new Day range Monday..Friday Wouldn't the programmer tend to get confused (I *think* both are illegal)? Would it not be better to say new type X is Y -- incompatible type declaration type X is Y -- compatible type declaration Gee, this Ada stuff looks mighty confusing; maybe someone should write adadecl ;-) -- ---- jnixon@atl.ge.com ...steinmetz!atl.decnet!jnxion
news@ism780c.isc.com (News system) (03/13/90)
In article <862@enea.se> sommar@enea.se (Erland Sommarskog) writes: > >Well, apparently I am allowed to mix apples and oranges. If I have >two types of data that both happens to be represented by integers, >but have no logical connection what so ever I cannot apparently >express that in C. And consequently I cannot take help from the >compiler to catch inadvertent mixups in for instance procedure calls. > I am unaware of any commonly available language that prevents this form of mistake. Look at the following: double distance; double time; double velocity; velocity = distance/time; /* this makes sense */ velocity = distance+time; /* I mixed 'apples' and 'oranges' and produced a lemon :-) */ I did read a paper (sorry, I don't have the reference) describing a language that allowed one to augment the the type declaration with a units declaration so as to be able to catch errors of this form. Marv Rubinstein
rimvallm@jupiter.crd.ge.com (Magnus Rimvall) (03/14/90)
In article <39941@ism780c.isc.com> marv@ism780.UUCP (Marvin Rubenstein) writes: >I am unaware of any commonly available language that prevents this form of >mistake. Look at the following: > > double distance; > double time; > double velocity; > > velocity = distance/time; /* this makes sense */ > velocity = distance+time; /* I mixed 'apples' and 'oranges' and produced > a lemon :-) */ > >I did read a paper (sorry, I don't have the reference) describing a language >that allowed one to augment the the type declaration with a units declaration >so as to be able to catch errors of this form. > > Marv Rubinstein The problem with mismatching units is particularly bothersome in the area of continuous system simulation, where the whole program/model consists of equations taking units. Some simulation programs do indeed support unit checking (a new version of the simulation language CSSL-IV which supported unit declarations/checks was announced some time ago - this might have been the paper Marv read). The task of unit tests is, at least in the USA, only half the battle. Until the metric system is adopted, we would also need automatic scaling of units (even the *dumbest* unit test unit could learn that a KW is equal to 1000 W, without knowing what a W itself is. Not even intelligent human beings can know for sure how much a "ton" or a "gallon" really is ... but this does not really belong in comp.*, so flame me in sci.misc). Magnus Rimvall Disclaimer: This letter does not necessarily reflect the opinions of anybody else (though they should)
fischer@iesd.auc.dk (Lars P. Fischer) (03/14/90)
In article <862@enea.se> sommar@enea.se (Erland Sommarskog) writes: >Well, apparently I am allowed to mix apples and oranges. If I have >two types of data that both happens to be represented by integers, >but have no logical connection what so ever I cannot apparently >express that in C. True. C has type synonyms, but you cannot introduce new types. It a pain at times, but you learn to live with it. Note that this does *not* mean that C is not strongly typed (it is). It means that there are some type constructions mechanisms that are not available in C. >And consequently I cannot take help from the >compiler to catch inadvertent mixups in for instance procedure calls. However: banach> cat te.c typedef enum { o1, o2 } orange ; typedef enum { a1, a2 } apple ; orange o; apple a; void main () { o = o1; a = o; } banach> lint te.c te.c(10): warning: enumeration type clash, operator = banach> Use lint, not Ada. /Lars -- Lars Fischer, fischer@iesd.auc.dk | Q: How does a project get to be one CS Dept., Univ. of Aalborg, DENMARK. | year late? A: One day at a time.
sakkinen@tukki.jyu.fi (Markku Sakkinen) (03/14/90)
In article <39941@ism780c.isc.com> marv@ism780.UUCP (Marvin Rubenstein) writes: > ... > velocity = distance/time; /* this makes sense */ > velocity = distance+time; /* I mixed 'apples' and 'oranges' and produced > a lemon :-) */ > >I did read a paper (sorry, I don't have the reference) describing a language >that allowed one to augment the the type declaration with a units declaration >so as to be able to catch errors of this form. I think there has been more than one article in ACM SIGPLAN Notices during the last two or three years that has suggested such a language extension (to Pascal at least) in considerable detail. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
al@nmtsun.nmt.edu (Al Stavely) (03/15/90)
In article <3744@tukki.jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: >In article <39941@ism780c.isc.com> marv@ism780.UUCP (Marvin Rubenstein) writes: >>I did read a paper (sorry, I don't have the reference) describing a language >>that allowed one to augment the the type declaration with a units declaration >>so as to be able to catch errors of this form. > >I think there has been more than one article in ACM SIGPLAN Notices >during the last two or three years that has suggested such a language >extension (to Pascal at least) in considerable detail. This is a moderately good but totally obvious idea, and language constructs for doing this have been re-invented over and over again. It's just that no one has thought it significant enough to incorporate into a major language. It might be amusing to count how many times this idea has been presented in SIGPLAN Notices over the last *twenty* years. - Allan Stavely, New Mexico Tech, USA al@nmt.edu
firth@sei.cmu.edu (Robert Firth) (03/15/90)
In article <3965@nmtsun.nmt.edu> al@nmtsun.nmt.edu (Al Stavely) writes: >In article <3744@tukki.jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: >>In article <39941@ism780c.isc.com> marv@ism780.UUCP (Marvin Rubenstein) writes: >>>I did read a paper (sorry, I don't have the reference) describing a language >>>that allowed one to augment the the type declaration with a units declaration >>>so as to be able to catch errors of this form. >> >>I think there has been more than one article in ACM SIGPLAN Notices >>during the last two or three years that has suggested such a language >>extension (to Pascal at least) in considerable detail. > > >This is a moderately good but totally obvious idea, and language constructs >for doing this have been re-invented over and over again. It's just that >no one has thought it significant enough to incorporate into a major language. Well, I know of a minor programming language that allows one to achieve most of what is required at a fairly low cost in language feature overhead. The concepts and their rationale are explained in the "Rationale for the Design of the Ada programming language", sections 7.2 and 7.3. Examples there of types with implied units are FRANC and MARK, DOLLAR and CENT, LENGTH and AREA. You might want to look it up. hit n now, rest is junk to massage some bloody fool's ego sorry i have to include more new text than quoted text so wasting your time and money
utoddl@uncecs.edu (Todd M. Lewis) (03/15/90)
In article <6475@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: >Well, I know of a minor programming language that allows one to >achieve most of what is required at a fairly low cost in language >feature overhead. The concepts and their rationale are explained >in the "Rationale for the Design of the Ada programming language", >sections 7.2 and 7.3. Examples there of types with implied units >are FRANC and MARK, DOLLAR and CENT, LENGTH and AREA. You might >want to look it up. Hey, this sounds really neat. Tell me, how does the rationale deal with keeping the conversions from FRANCs to MARKs to DOLLARs and CENTs? I've been using a file with the conversion factors in it for my own stuff, but that's always seemed just a little too cavalier for my tastes, what with these values changing by the second in the real world. I'm glad to see the solution so well worked out that it becomes part of the rationale for designing a language! Wow!