Am 11.05.2013 23:21, schrieb Orchid Win7 v1:

>>> 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).

... which is exactly why namespaces were invented in the first place. 
Any contemporary programming language that bothers to use namespaces 
should avoid such nuisances once and for all.

Post a reply to this message

>>>> 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).
>
> ... which is exactly why namespaces were invented in the first place.
> Any contemporary programming language that bothers to use namespaces
> should avoid such nuisances once and for all.

Well, the other alternative is to define each record in a separate 
compilation unit. That'll do it. But that's also rather inconvenient.

In mitigation, Haskell programs tend not to have quite so many data type 
definitions as a typical C program, and they tend to have a lot fewer 
fields. That's not to say that name collisions don't happen though.

There have been a couple of solutions suggested. GHC has a mode in which 
names are allowed to overlap, and the compiler tries to "guess" what you 
meant at compile-time. This mostly works, but many people consider it to 
be a deeply evil hack. Then there's Frege, which is basically a very 
slightly modified Haskell which compiles to Java source code. In Frege, 
every type is its own namespace, and in case of ambiguity you must 
prefix the field name with the type name. (Note that C# does this with 
enum values.)

Ultimately the problem is type inference. Pascal lets you write 
"foo.bar" to access a field - but then, in Pascal the type of "foo" must 
be explicitly stated in a type signature. Haskell is trying to let you 
write the same expression but still let the compiler automatically 
detect the type of "foo" - a much harder problem...

Post a reply to this message

> It is NOT typically written as
>
>    exp(ix) = cos(x) + i sin(x)
>
> except when written in computer source code.

Isn't that just because in maths the brackets are usually left out with 
standard functions if it's obvious what the parameter is? For more 
complex parameters brackets are usually used to avoid any ambiguity.

When writing "user defined" functions like f(x) in maths you always use 
brackets.

Post a reply to this message

On 13/05/2013 08:20 AM, scott wrote:
>> It is NOT typically written as
>>
>> exp(ix) = cos(x) + i sin(x)
>>
>> except when written in computer source code.
>
> Isn't that just because in maths the brackets are usually left out with
> standard functions if it's obvious what the parameter is? For more
> complex parameters brackets are usually used to avoid any ambiguity.

You leave out the brackets unless there's grounds for confusion. Which 
is pretty much what Haskell does. (And what most other programming 
languages do for everything except subroutine arguments.)

> When writing "user defined" functions like f(x) in maths you always use
> brackets.

Pro tip: Don't use the word "always" around mathematicians. It tends to 
make them find obscure counter-examples. ;-)

(Why, I have a book somewhere which claims that a "function" is actually 
a set of 2-tuples...)

Post a reply to this message

> You leave out the brackets unless there's grounds for confusion. Which
> is pretty much what Haskell does.

A mathematician would not expect any confusion with an expression like 
sin 2x, so would leave out the brackets.

Post a reply to this message