A good type system does not prevent you from making logic errors. It's just another level of protection, like managed memory. In the same way that reference counting prevents you from leaking memory, a type system prevents certain kinds of mistakes that are generally solved with discipline in other programming languages - for example, in Python, I can construct the following program:

    def greater_than(a, b):
        return a > b

    if __name__ == '__main__':
        print(greater_than(5, 4))
        print(greater_than([], 4))

Which is a perfectly valid program, but throws a runtime error. However, in Haskell:

    module Main where

    greater_than :: (Ord a) => a -> a -> Bool
    greater_than a b = a > b

    main = do
        print $ greater_than 5 4
        print $ greater_than [] 4

I have added a constraint that forces the caller to pass a value that can be compared - and the compiler will throw an error if I don't do that.

Of course this won't get rid of every problem programmers face, but it helps.

    greater_than = (>)

...sorry. The way you wrote it is better for illustrating your point to non-Haskellers, it just felt dirty!

>the type system only provides a syntax which catches certain classes of errors

Yes, type errors. The problem is you have a drastically limited idea of what a type error is.

>The type system, for example, does not help you when you have five Ints and you use the wrong one for an index and the output of the procedure is thereby completely messed up at runtime.

Yes it does, you are choosing not to use the type system. If they are not five Ints but five specific things, then you should have five types, not one.

I'm not sure what you mean by a "specific thing." Take the absolute simplest case, Fibonaccis. You accidentally write somewhere:

    fibs n
      | n <= 1 = n
      | otherwise = fibs n + fibs (n - 1)

Whoops, that's an error because you had three Ints you needed to keep track of and you chose the wrong two to go into the recursive call. Are you really claiming that types make this sort of semantic error better?

You get similar problems if you were looking for the max of two mins of two lists of Ints and you accidentally wrote the min of the two mins, or if you have two functions

    findMinBefore :: (Ord x) => Array Int x -> Int -> x 
    findMinAfter :: (Ord x) => Array Int x -> Int -> x

and you accidentally use the wrong one.

Ultimately you're responding to a claim which says that there exist semantic errors, by saying that no, that's "a drastically limited idea" of what syntax can do, and results from people "choosing not to use the type system". That's a bit baffling to me. Could you clarify, so that I could see how I can eliminate these sorts of semantic errors entirely?

>Ultimately you're responding to a claim which says that there exist semantic errors, by saying that no, that's "a drastically limited idea" of what syntax can do

No I am not. I am responding to what you said, not what you want to invent after the fact. It is very simple, and is the difference between these two functions:

    f :: Int -> Int -> Int -> Int -> Int -> Int
    f :: Type1 -> Type2 -> Type3 -> Type4 -> Type5 -> Type6

Well, let me encourage you to actually respond to what I said, then:

> you have five Ints and you use the wrong one for an index

In other words:

    f :: Int -> Foo
    doStuff :: Int -> Int -> Int -> Int -> Int -> Foo 

Of course that's abstract: I meant "you" as a programmer dealing with these functions and the ints might well be a low index, a high index, and the neighborhood of a pivot index, so it's called as:

   doStuff lo hi (p - 1) p (p + 1)

and of course you probably wouldn't pass all three p's in -- but those are definitely three different Ints which you may have to keep track of.

It sounds like your panacea here is to instead have the programmer write:

    doStuff' :: Lo -> Hi -> Pminus -> Pivot -> Pplus -> Foo

The problem is, that `f` still has type `Int -> Foo` and there is still this huge semantic error of providing the wrong argument to f. So no, if you actually explicate what I said you indeed find problems much like what I "invent after the fact".

Are you saying that `f` should not have input type `Int`? That input type is isomorphically non-negotiable: you're either going to write five `f` functions or you're going to have type coercions, and both ways have the problem. I really don't see anything you've said which alleviates it.

If none of what I was saying was what you thought I was saying, that's OK, mistakes happen all the time. Then, I'd just ask: in your own words, what did you think I was saying when I said, "you have five Ints and you use the wrong one for an index"?

If you didn't want to learn and were just posting FUD, then save everyone the time and say that after the first post. No need to act ignorant and try to drag things out in to some endless charade of pretending you don't understand so you can salvage your FUD.

I would like to learn if there is something here to teach but after giving you several opportunities to explain yourself and only getting vague short comments, I'm not sure that I believe you have anything to teach.

I don't have any desire to post FUD about Haskell. I like Haskell and it's probably my favorite language at the moment. What I posted was not FUD and these replies are not "salvaging" FUD.

So, again: in your own words, what did you think I was saying?

> The type system, for example, does not help you when you have five Ints and you use the wrong one for an index and the output of the procedure is thereby completely messed up at runtime.

You could use newtype.