Re: More static type fun.

From: Dirk Thierbach (dthierbach_at_gmx.de)
Date: 11/16/03 

Date: Sun, 16 Nov 2003 19:28:07 +0100

Raffael Cavallaro <raffael@mediaone.net> wrote:
> Dirk Thierbach <dthierbach@gmx.de> wrote:

> No question that this is a matter of programmer preference. I do
> think, however, that what one prefers is greatly influenced by one's
> perception of how common runtime type errors are.

I don't think so.

> In other words, what is the tradeoff between time spent making sure
> that one's code is acceptable to the type checker,

I think it really would help if you could accept that with static
types, you don't have to necessarily invest "useless" time to
"make the code acceptable". Yes, I know with C and Java, you often do.

Try to think of type checks in a polymorphic typed language as a
test-suite that is automatically executed at compile-time, because
passing those tests constitutes the minimum requirement that allows
your program to actually run.

Would you say that you have to "waste" time to make sure that your
code is "acceptable" do your unit tests? The time you spend during
this process is exactly the time that you need to develop your ideas
and shape the final program.

> Clearly, you think that the number of otherwise undetected runtime
> type errors would be large,

No, I don't think they would. I think the amount of time I would have
to invest in unit tests to catch bugs and gotchas in my program would
be large. That's why you hear from static typers "as soon as my
program typechecks, it is usually correct". (Usually, not
always). That's not because in some magical way, the type checker has
proved them to be bug free, that's because at that stage, the program
has already passed a lot of tests, without the need to write down a
single one of them.

> The perception of lisp and smalltalk programmers is that this number
> of otherwise undetected runtime type errors is small, and not worth
> the extra effort of placating the compiler,

Still the same problem: You think this is about undetected runtime
type errors, and about placating the compiler. It is not.

> To a lisper, Haskell really does require one to do more in the way
> of explicitly informing the compiler than lisp - for example, having
> to explicitly tell the compiler that you want to use lists with more
> than one type of element.

But the point is that you think differently. You think "will I use
these things uniformly in my program? If yes, it's a list with
a common type. Will I have to make decisions based on what type
there is in the list? If yes, make those decisions explicit (you
can defer this until you reach the part of the program where you
actually have to make the decisions; type inference will figure
it out). Is it not really a list with things I want to operate
uniformly on, but does it contain different things, and I never
intend to use them uniformly? If yes, use tuples."

Lispers do all three things with one datatype, namely a list. So
they have to get used to a new language feature. Once you have
absorbed the difference, it will never slow you down.

> This interruption to one's work flow and thought process

There is no interruption in work flow and thought process. It's an
integral part of the thought process.

> Unfortunately, we sometimes can't know in advance which is the program
> that will need that extra dynamism - the ability to reshape the
> program without having to largely rewrite it.

Yes. And that's what polymorphic types are good for. The type checker
will figure out what degree of generality my functions have. (I have
run into examples where I figured out by looking at the type after I
wrote my function, that I could use the very same function in very
different situations as well).

Here's a simple example: The well-known map function has type

map :: (a -> b) -> [a] -> [b].

That means I can use map with a function that converts from type a to
type b on any list with elements of type a, and I will get a list of
type b. And I don't have to rewrite it, no matter what a and b will
be. It might even turn out that a is a datatype that mixes, say,
integers and floats, or functions themselves, or trees, any other
thing one can imagine.

> he, and other lispers/smalltalkers feel safer knowing they have this
> ability should they need it.

And I also feel very safe knowing I have the ability to change my
program in unexpected ways should I need it. I feel even safer,
because the automatic test-suite the type checker creates for me is
a big help in refactoring. So when it turns out that I have to change
a small part of my program, the type checker will flag all the places
where this affects the rest of my program, so I can adapt them one
after the other without any fear of forgetting any of them. (After
all, my hand-written unit tests might not have 100% code coverage,
because I was too lazy writing them).

Raffael, I know your arguments, and I have heard them often enough.
They are certainly true for characterizing the difference between Lisp
at statically typed languages like C and Java. But they just don't
apply to polymorphic HM-style types systems; these are very different
beasts.

- Dirk

Relevant Pages

  • Re: Just a bit of silliness
    ... But format strings could be eliminated completely: ... This would require a great deal of compiler support, ... parameter lists are declared explicitly, ... Since C doesn't have runtime type information, ...
    (comp.lang.c)
  • Aurora Beta 1
    ... The Aurora compiler has just been updated to Beta 1. ... non-indexed triangle lists. ... The ClassView pane in the IDE now does something. ...
    (comp.lang.misc)
  • Re: Symbols, metacircular evaluation, external representation.
    ... You could only use strings, and you would have to use parsers all the time. ... same kind of symbolic expressions, it's very easy to write functions ... writting a metacircular interpreter (or a lisp compiler), ... lists. ...
    (comp.lang.scheme)
  • Re: PLOT: A non-parenthesized, infix Lisp!
    ... Dmitry, I don't think anyone objects to detecting type errors, or even ... type warnings, before runtime. ... People who use dynamically typed languages ... manages lists of things, have it in a program, and then, while ...
    (comp.lang.misc)
  • Re: foreach enhancement
    ... > strong typing is not an option, and that optimization will not be able to ... > concerned with optimization of for loops and typing - since lists will be ... *very* different and the compiler itself will certainly be able to know the ...
    (microsoft.public.dotnet.languages.csharp)