That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often dependent on the order of the parameters) has always seemed extremely inelegant to me.

Addition and concatenation are not the same thing. Why they should share a symbol when they don't share some properties integral to their nature (it's non-commutative) is beyond me, and I think it's caused a lot of bugs that didn't need to happen.

Not allowing the addition of floats and ints together is less of a fundamental issue, but it also helps quite a few problems. Al alternative solution, if you didn't want to reply on implicit coercion would be to explicitly convert one operand to the appropriate type so they match.

Or you can go whole hog and provide an entirely separate set of operators for different types, like Perl did (string concatenation is '.', and equivalents comparitors are eq,ne,gt,lt,ge,le). That works well in Perl's case, but that's mostly because for Scalars Perl really just wants to know whether you are treating it as a number or a string, so there's only two types to account for.

'course it could, multiple languages already do that e.g. Rust (https://play.rust-lang.org/?gist=530fa94d3f451e896ac0d3ddeaf...), Haskell (https://repl.it/repls/FrozenBlondUmbrellabird), Swift (https://repl.it/repls/LuckyNaiveBream)

Needing to use +. to add two floats seems odd to me as well, and I believe this is what OP was pointing out. I would agree with you that adding and int to a float should require conversion of one of the arguments, but I see no need for a separate + operator for floats and ints.

Yes, what I was trying to express is that in a typed language with many types, choosing a few types and using operators to signify what you are doing is an odd choice, especially if you implement it for some types but not others. I understand the want of the language designers to protect people from these mistakes, I just think they chose an oddly inconsistent way of of doing so. The logical conclusion of different operators for different types is many more operators than shown here, so that leaves the language with these special cases. Special cases cause confusion.

Sadly, it is not associative (i.e. (a+b)+c != a+(b+c))

Imagine a being a large number, and b and c being so small that adding each single one to a will result in a, but adding their sum will result in just the smallest increment over a.

It's more like doing calculations on scientific notation, where there are special rules for how to keep the right number of significant figures/precision after operations. Like scientific notation, you would probably convert to one form or another (even if in your head) before doing the operation, and keep note of the possible loss of precision.

This is exactly the reason why adding floats to ints is something that people think should require an explicit conversion, so it's more obvious that's a point that may introduce loss of accuracy.

1: https://stackoverflow.com/questions/24442725/is-floating-poi...

2: https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BinMath/a...

Now that you mention, there was this fascinating denial-of-service vulnerability in PHP which is (kind of) related... https://news.ycombinator.com/item?id=2066352 http://www.exploringbinary.com/why-volatile-fixes-the-2-2250...

EDIT: To expand on this: The following code is valid, and may print "weird":

  double x = f();
  double y = x;
  if(x != 0 && y == 0) {
     printf("weird\n");
  }

F# has implicit `+` for basic types (though it’s not quite modular implicits). It also has a really nice syntax for async computations, similar to `async/await`. JS interop is much easier too. It can also run on the server with .NET core if you don’t want to use node.

The output JS is slighter heavier and less optimised than Reason/Bucklescript, and compile times slighter slower, but at the moment those are trade offs I’m happy to make

Having one code base like with ocsigen would be even better. Anything like that available?

This is a problem because when type inference kicks in for plain functions, usage of that "+" will make the compiler assume "int".

But worse, "+" in C# is not a method, but a static method and the compiler basically does magic, because you don't have this behavior for plain static methods and you don't have a generic interface in the language for "+", there's no Number, no Monoid and static methods themselves in C# can't be polymorphic.

The whole notion of "static methods" is broken btw and have nothing to do with OOP. The only purpose of static methods is to enforce visibility rules and this made some sense in C++, where you could have functions living outside of classes, but even there the real problem is the lack of useful namespacing.

And F# inherited this behavior, F# inherited static methods, along with math operators described as static methods.

So in order to abstract over things that have "+", which is really needed in F# otherwise you can't express really basic things for an FP language like "List.sum", you have to (1) use inline functions, which aren't translated directly to .NET functions and (2) use a really awkward signature that instructs the type system that the type has a "+" static method that it can use, e.g...

    > let sum x y = x + y;;
    val sum : x:int -> y:int -> int

    > let inline sum x y = x + y;;
    val inline sum :
      x: ^a -> y: ^b ->  ^c
        when ( ^a or  ^b) : (static member ( + ) :  ^a *  ^b ->  ^c)

This is close to how type classes work in other languages, however for the F# compiler this is magic that doesn't scale and making use of "static methods", a flawed concept, a signature that can't be encoded in .NET's type system and therefore the function is forced to be "inline".

Which is another problem, because in F# inline functions are more like macros, or in other words these "inline" functions are not values. As soon you try using one as a value, it gets materialized and you loose the type info. So it is very ephemeral.

Given this, frankly, I would rather have OCaml's operators. At least they are plain functions.

It is not much different from class messages in Smalltalk.

Static methods are just plain functions tied to classes from an era when people thought having classes everywhere is actually a good idea, in C# and F# also tied to weird, magical compiler rules around operators.

Speaking of Smalltalk and OOP, operators like "+" in languages like Smalltalk are object methods and can be used in generic functions doing polymorphic calls. In OCaml they are plain functions with no overloading. In Haskell they are functions requiring type classes to work, sort of like what F# is doing, but non-broken.

Btw, if you're wondering from where the convention of using static methods for operators comes from, that's another relic of C++, a language not known for elegance, finesse or for being a good OOP language.

Which also apply to Smalltalk.

> Static methods are just plain functions tied to classes from an era when people thought having classes everywhere is actually a good idea,

Using GNU Smalltalk serialization syntax,

    Object subclass: #MyClass.

    MyClass class extend [
        myClassMethod [
            ^ 'Hello from class method'
        ]
    ]

    Transcript show: MyClass myClassMethod.

    class MyClass {
        public static string myClassMethod () {
            return "Hello from class method";
        }
    }

    System.out.println(MyClass.myClassMethod());

Better know C++, before bashing it.

In C++ operators can be defined as member functions and participate in inheritance resolution except for operator=.

I guess you are mixing C++ with C#.

I tried it with React-Native but found it a bit cumbersome to get it to interact with existing components in Reasons JSX

    Prelude> (3::Int) + (4::Integer)

    <interactive>:2:13:
        Couldn't match expected type ‘Int’ with actual type ‘Integer’
        In the second argument of ‘(+)’, namely ‘(4 :: Integer)’
        In the expression: (3 :: Int) + (4 :: Integer)
        In an equation for ‘it’: it = (3 :: Int) + (4 :: Integer)

Essentially you want Haskell's numeric tower, and while it's pretty amazing it's worth noting that it requires a lot of machinery with big implications.

Go on...

Algebraic effects are also in the works which will help with stuff like async/await, but works over arbitrary effects (not just async). Like monads but nicely composable without the ickiness of MTL. Alas it's still unclear what the ETA is. :( Something I'm really looking forward to!

https://www.reddit.com/r/ocaml/comments/63hgid/tracking_mult...

That's also what makes scala so unapproachable, you get stuff like ++> or =*= that doesn't make any sense.

x + y makes sense to most people

x ^ y not so much

Scala is a super approachable language, without any (that I can think of) strange operators in the stdlib. You could make a case for Cats, I guess, but writing purely functional Scala isn't necessary at all, and is something you can approach when or if you feel comfortable to do so.

It is a mystery.

But pointing at Scalaz is a bit ridiculous. It's a known test library for trying things out and basically not allowed in any Scala codebase I've been working on.

I'm just saying; the impression exists for a reason and the reason is a popular and well-known library.

I never was a fan of the JVM stuff and Scala seemed like a reasonable alternative to Java, but I never got it.

I think the case is obvious for integer vs floats -- addition should be addition.

Many languages don't use "+" for string addition, because string addition is not commutative (a+b != b+a) SQL, for example, uses "||" for this, and Haskell uses "++"

That being said, argument type overloading is important for clarity. One of the famous failures in Haskell is "map" only works on lists, and "fmap" on other functors.