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] |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.