On 13 Nov, 09:14, torb...@[EMAIL PROTECTED]
(Torben =C6gidius Mogensen)
wrote:
..=2E.
> > 1. a human /reader/ would not know what data types were meant without
> > examining a lot of context.
>
> That is true also with explicit types. If you, say, write
>
> mytype f(oldtype x)
>
> you need to find the declarations of mytype and oldtype to know what
> the types look like. Just knowing the name gives you no information.
My intention is that declarations can appear at the top of any block
so to find a type or any other identifier one would need to look at
the top of the current block, then of any enclosing blocks. Not too
onerous. Almost infinitely easier than working the compiler's type
inference by hand.
> You can argue that in an IDE, you can just hover over the type to see
> its declaration, but, equally, you can hover over a name in a language
> with inferred types and see its (inferred) type.
OK
> > 2. the code could easily apply more widely than the /writer/ intended
> > (or wanted).
>
> And why is this a problem? More often, the problem is that you can't
> reuse a function because its declared type is too limited, i.e., that
> you could haev reused it if it was declared as a template, but since
> it is not, you can't.
It's not a problem in many cases. However, to try to illustrate, take
a simple example where you want to define multiplication for two
integers. If the machine's word size is 32-bit I may want to define
function (<integer bits (2 * X)>) (<integer bits X> a, b) mult
for X in (8, 16, 32) to use a simple intrinsic function,
for X in (64, 128) to use long multiplication,
for X in (256, ...) to use a fast long multiply such as <http://
en.wikipedia.org/wiki/Sch%C3%B6nhage-Strassen_algorithm>
..=2E.
> > I see your point. Lets say that if I read someone else's code I want
> > to be able to see how polymorphic his functions are!
>
> If you work in an IDE, this is no problem. If you don't, you can run
> the code through the compiler and see what type is re****ted (most
> compilers for languages with type inference can be made to re****t the
> types during compilation).
True.
> You can say that infreered types get you the best of both static and
> dynamic typing: You get the type safety of static typing and the
> uncluttered, reusable code of dynamically types languages like Python
> or Ruby, but you don't get the late checking of dynamic languages or
> the verbose, unflexible code of explicitly typed languages.
When you use type inference do you partially specify types such as
saying a certain identifier is a floating point variable but leave the
precision to the compiler, or do you leave it as just an identifier
and let the compiler infer everything about its type?
|
