Re: Pointers to "why C behaves like that ?"

"Fergus Henderson" <fjh@cs.mu.OZ.AU>
24 Nov 2002 01:22:30 -0500

          From comp.compilers

Related articles
[18 earlier articles]
Re: Pointers to "why C behaves like that ?" torbenm@diku.dk (Torben Ęgidius Mogensen) (2002-11-24)
Re: Pointers to "why C behaves like that ?" torbenm@diku.dk (Torben Ęgidius Mogensen) (2002-11-24)
Re: Pointers to "why C behaves like that ?" nmm1@cus.cam.ac.uk (Nick Maclaren) (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 ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-24)
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)
[42 later articles]
| List of all articles for this month |

From: "Fergus Henderson" <fjh@cs.mu.OZ.AU>
Newsgroups: comp.compilers
Date: 24 Nov 2002 01:22:30 -0500
Organization: Computer Science, University of Melbourne
References: 02-11-059 02-11-071 02-11-083 02-11-097 02-11-119
Keywords: design, types
Posted-Date: 24 Nov 2002 01:22:30 EST

"Manos Renieris" <er+cc@cs.brown.edu> writes:


>Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
>> Somebody mentioned type inference in ML. My opinion is: it's nice
>> *within* a single function, but the *interfaces* to pieces of software
>> ought to have *explicit* declarations of types, so I can understand
>> them without reading all the code.


I completely agree. That's why we designed Mercury the way we did:


- Local variables do not need to be explicitly declared;
the compiler will automatically infer their types.
Spelling errors are caught by singleton variable analysis
and/or data-flow analysis.


- By default, the types of all procedures must be declared.


However, sometimes (especially during the early stages of code
development) it is nice to apply this only to module interfaces,
rather than procedure interfaces. So Mercury also supports another
mode of operation in which type declarations are optional for
procedures which are local to a module (private); in that case, the
compiler performs ML-style type inference.


>There is a common misconception that because types are inferred, they
>are hidden. In fact, the result of the type inference can be
>presented to the the user.


Certainly they can be presented to the user, but either


(1) they will not be as easily visible as the source code,
because the user will have to invoke a separate tool
to view them


or


(2) you must restrict users to using a specific editor (or set
of editors) that has been customized to interface with
your type inference engine.


Furthermore, whichever choice you make, it is difficult for the system
to presenting accurate results of type inference for the kinds of
incomplete, not yet syntactically correct program fragments that
result when the user is in the middle of making a modification to
their source -- which is usually the point at which such information
is most useful.


So the point is not that inferred types are completely hidden, just
that in practice they are much less visible than explicit type
declarations in the source code.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.