Related articles |
---|
[24 earlier articles] |
Re: Pointers to "why C behaves like that ?" nicola.musatti@objectway.it (Nicola Musatti) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" fjh@cs.mu.OZ.AU (Fergus Henderson) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" anw@merlot.uucp (Dr A. N. Walker) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24) |
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24) |
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24) |
Re: Pointers to "why C behaves like that ?" stephen@dino.dnsalias.com (Stephen J. Bevan) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" cgweav@aol.com (Clayton Weaver) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-11-24) |
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-26) |
[37 later articles] |
From: | thp@cs.ucr.edu |
Newsgroups: | comp.compilers |
Date: | 24 Nov 2002 18:33:59 -0500 |
Organization: | University of California, Riverside |
References: | 02-11-095 02-11-103 02-11-128 |
Keywords: | types, design |
Posted-Date: | 24 Nov 2002 18:33:58 EST |
jacob navia <jacob@jacob.remcomp.fr> wrote:
+> Requiring programmers to provide compilers with information that can
+> be statically inferred is an unfortunate waste of human resources.
+> Where types can be inferred statically, they can be annotated into the
+> source code via static analysis tools. Where types cannot be
+> statically inferred, the programmer ought to get a warning but the
+> execution can proceed on the basis of dynamic typing. Let the
+> programmer decide how he/she wishes to proceed.
+
+ fn(a)
+ {
+ b = a;
+ }
+
+ How can you know what "a" is?
+
+ If you examine the whole program (this precludes a separate compilation
+ model like C) you can find two calls to "fn" one with:
+ fn(2)
+ fn(6)
+
+ Is the type of "b" an integer, a double, an unsigned char or a long long?
+
+ All those answers are correct.
That same question occurs in strongly typed languages:
template< class T >
void fn( T a ) {
T b = a;
// ...
}
The point to generic programming is that the same piece of code can be
used for arguments of different types.
+ Yes, that can be maybe in principle be done but with an associated enormous
+ cost in compiler complexity and problems.
+
+ When you support several types of integers and floating point data like in C
+ this kind of inference becomes extremely complex.
Type inference is well-known compiler technology and is relatively
easy compared to some of the rest of the things that compilers must
do.
+ What do you do with arrays?
+
+ Finding the expression
+ table[i] = b+8.9;
+
+ You can (maybe) deduce that table contains floating point data but how big
+ do you dimension it?
+
+ Yes, of course, you dimension it to have at least "i" elements. And each
+ time "i" becomes greater than the size of "table" you redimension it copying
+ the data in the new table.
+
+ This way you generate
+
+ for (i=0; i< b;i++) {
+ table[i] = i;
+ }
+
+ If "b" is 10 000 at run time you resize the table 10 000 times. NICE!
I'm not suggesting that explicit declarations be prohibited. In the
absence of explicit dimensioning, however, defaults and resizing may
be required (as is done in many popular languages).
Tom Payne
Return to the
comp.compilers page.
Search the
comp.compilers archives again.