On: A deep dive into Multicore OCaml garbage collector

[ice109]

I don't know if you've worked with a production Haskell code base but it cannot be over stated what a poor decision operator overloading is. if they got rid of that it would immediately make Haskell an order of magnitude more practical

[the_why_of_y → ice109]

Haskell doesn't really have the problems that are commonly associated with operator overloading.

Haskell does have type classes, which do allow overloading, even of operators, but the type class uniquely determines the type of the operator - and there can be only one definition of any operator in scope.

Also, you can just define as many new operators as you like.

For these reasons, you can't have the madness of operator<< in C++, or whatever it is that Perl does with the same operator doing 5 completely different things depending on context.

[tom_mellior → the_why_of_y]

> Haskell doesn't really have the problems that are commonly associated with operator overloading.

Nobody said it did. People said that it has its own brand of problems with operators looking something like >>+@*<>> peppering your code.

[ice109 → tom_mellior]

lol i wonder if you work on my team

[ice109 → the_why_of_y]

>Also, you can just define as many new operators as you like.

this is exactly the problem

[mercurial → ice109]

Haskell for hobby programming coupled with professional Perl experience gave me enough idea of what creative programmers could come up with in terms of ASCII art.

[tome → ice109]

Haskell doesn't have overloading at all, either of operators nor of non-operator identifiers, so I guess you mean something else.

Do you mean user-defined operators, or do you mean operators whose type has a typeclass context?