>> Whitespace is used to delimit scope in Haskell. A space character is 1
>> space wide; a tab character is a different randomly-chosen size in every
>> program known to Man.
>
> ... which is why placing importance on indentation in a programming
> language constitutes a design flaw...

Well, you can say that if you wish. I'm not going to agree with you 
though. :-P

It's really quite irritating to have your program not compile just 
because you accidentally left out a semicolon with it's damned obvious 
what you actually meant. Haskell means I never have to worry about this.

>> * Calling functions with tuples.
>>
>> In anything derived from ALGOL, a function call looks like
>>
>> foo(1, 2, 3)
>>
>> But in Haskell, the correct syntax is
>>
>> foo 1 2 3
>
> I think this is actually a pretty stupid notation for a functional
> programming language; after all, the braced notation is /the/
> traditional notation for functions in mathematics.

No, no it is not.

Consider, for example, Euler's relation. It is customarily written as

   exp ix = cos x + i sin x

It is NOT typically written as

   exp(ix) = cos(x) + i sin(x)

except when written in computer source code.

> I'd go even further and question the whole concept of passing multiple
> arguments to a function. You can't output multiple values from a
> function (unless using a tuple), so why should you input multiple values
> (unless using a tuple)?

That is a whole other question, of course.

There are plenty of standard mathematical functions which take multiple 
arguments. (GCD, anyone?) When it comes to computers, there is a simple 
and easy way of implementing passing multiple bits of data to a 
subroutine at once; if anything, the strange thing is that nobody has 
come up with a programming language that lets you RETURN several items 
at once. At the machine level, this would be a very easy thing to 
implement. I can only imagine it's because nobody has come up with a 
nice notation for writing it...

>> Code: print -2
>> Means: print - 2 (I.e., subtract 2 from print.)
>> Intended: print (-2) (I.e., print out -2.)
>>
>> Notice how all three of these are the exact same bug; function
>> application has the highest precedence of any operator, which apparently
>> isn't what people are expecting. (The final example is arguably a bug in
>> the language specification, but there you have it.)
>
> I wouldn't call the latter case a bug in the language spec. It's the
> whole idea of making function application have highest precedence that
> I'd call a bug.

Consider, for example, the expression

   tan x = cos x / sin x

Here operator precedence does EXACTLY what we want it to do. Consider 
another example:

   string = printf "%x" value1 ++ show value2 ++ unlines list3

Here, again, we concatenate the output from several different functions 
into a single string, and operator precedence works exactly how we want 
it to, without needing any brackets.

I suspect that basically for any possible choice of precedences, you 
will nearly always be able to find an example where it doesn't work how 
you'd like it to. Never the less, I think the current operator 
precedences work pretty well.

> BTW this wouldn't be a problem if Haskell used the classic "fn(x,y,z)"
> notation for functions.

That's true. But then again, remember that Haskell allows you to call a 
function with a different number of arguments than the function expects. 
That's probably the main reason why it doesn't use that syntax.

>> Lots of people try to write Haskell like
>>
>> data Foobar = Foobar {foo :: Int, bar :: Int, baz :: Int}
>> data Fizz = Fizz {foo :: Bool, wok :: Int}
>>
>> This doesn't work at all, due to a namespace collision.
>
> A /severe/ design bug, if I'm asked. Nothing I'd expect from a
> contemporary programming language.

It's embarrassing, sure. But it's not really an especially severe bug; 
it's just a nuisance having to manually prefix all your field names with 
the name of the type that they belong to (or some abbreviation thereof).

Post a reply to this message