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

"Joachim Durchholz" <joachim_d@gmx.de>
1 Dec 2002 22:36:55 -0500

          From comp.compilers

Related articles
[48 earlier articles]
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-26)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-11-26)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-11-26)
Re: Pointers to "why C behaves like that ?" vugluskr@unicorn.math.spbu.ru (Roman Shaposhnick) (2002-11-26)
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-12-01)
Re: Pointers to "why C behaves like that ?" nmm1@cus.cam.ac.uk (Nick Maclaren) (2002-12-01)
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-12-01)
Re: Pointers to "why C behaves like that ?" peter_flass@yahoo.com (Peter Flass) (2002-12-01)
Re: Pointers to "why C behaves like that ?" fjh@students.cs.mu.OZ.AU (Fergus Henderson) (2002-12-01)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-12-01)
Re: Pointers to "why C behaves like that ?" dot@dotat.at (Tony Finch) (2002-12-01)
Re: Pointers to "why C behaves like that ?" dot@dotat.at (Tony Finch) (2002-12-01)
Re: Pointers to "why C behaves like that ?" sander@haldjas.folklore.ee (Sander Vesik) (2002-12-01)
[13 later articles]
| List of all articles for this month |

From: "Joachim Durchholz" <joachim_d@gmx.de>
Newsgroups: comp.compilers
Date: 1 Dec 2002 22:36:55 -0500
Organization: Compilers Central
References: 02-11-095 02-11-103 02-11-128 02-11-150 02-11-177
Keywords: types, design
Posted-Date: 01 Dec 2002 22:36:55 EST

Roman Shaposhnick wrote:
> On 24 Nov 2002 18:38:19 -0500, Joachim Durchholz wrote:
>> Hindley-Milner typing is simple and efficient.
>
> But I suppose they require all pieces of code that has anything
> to do with "a" to be available at once.


This is correct insofar as type information can flow across subroutine
call boundaries.
However, it's useful even if it works just within a module - you can
omit almost all type annotations for local variables, for example. If
you have
      f (x: Real)
          local y
          y := x * x
you don't have to revisit the "local" declaration if you later discover
that the parameter of f should have been Numeric.
Or you can change the result type of a function.


Type inference will also help when importing modules.


When exporting from a module, type inference will give the most general
type that's consistent with the internal implementation. This type may
be more general than intended; for this reason, functions exported from
a module tend to have a type annotation.


> So, what I'm really saying is, that while dynamic typing is great
> in theory, I have yet to see a nice practical implementation,
> suitable for big software projects.


Take a look at Haskell. It's nice and practical, and IIRC it's already
being used for big projects.


Regards,
Joachim


Post a followup to this message

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