3 ms·
> Most operations would include a type in their name. Interestingly, this is the case in OCaml (albeit with a shorter syntax), and it is very handy. OCaml has
by vog 12y ago
> Most operations would include a type in their name.
Interestingly, this is the case in OCaml (albeit with a shorter syntax), and it is very handy.
OCaml has two separate operators for integer addition (+) and float addition (+.), and it is illegal to write something like "1.5 + 1.5", as you either have to write "1.5 +. 1.5" or convert them to integers. This is used for the strong type checking of OCaml.
While this seems annoying at first, I found this to be very practical, especially in numerical algorithms. In other languages like C/C++/Java you always struggle with implicit conversions between int and double. When do these really happen, given all those implicit rules? If you care about correctness, you'll find yourself casting stuff to double or int/long, like this:
(double)(SOME_EXPRESSION) / (double)(ANOTHER_EXPRESSION)
just to be sure this is really a floating division happening there, rather than an integer division that throws away accuracy. In OCaml, you just write:
(SOME_EXPRESSION) /. (ANOTHER_EXPRESSION)
and have a guaranteed floating point division, as well as a typecheck telling you when you e.g. forgot to convert SOME_EXPRESSION from integer to floating point.
You'll then have to add explicit conversions wherever needed, but this is really the lesser evil – especially since it gives you full control over when this actually happens.
- JadeNB 12y ago> This is needed for stronger type checking. Is 'needed' (as opposed to 'used') really correct here? Haskell's type classes manage to handle the type checking for different kinds of addition perfectly well without an explicitly different operator: > :t 1 + 1 1 + 1 :: Num a => a > :t 1.5 + 1.5 1.5 + 1.5 :: Fractional a => a In other words, since 1 makes sense as an element of any 'Num'mable type, so does 1 + 1; but, since 1.5 only makes sense as an element of a 'Fractional'able type, we can only regard 1.5 + 1.5 as an element of those more restrictive types.
- vog 12y agoIndeed, I meant "used". Fixed this in my comment above. Thanks!
- username223 12y ago> In other languages like C/C++/Java you always struggle with implicit conversions between int and double. Not that I've noticed. Uni-typed operators are essential in something like Perl, which has lots of implicit conversions (think of the horrible "+" operator in PHP, or "|" in Perl). They're also helpful in something with type inference like Ocaml, though Haskell does okay without them. But with the plentiful explicit type declarations in C-style languages, polymorphic operators are rarely confusing.
- TazeTSchnitzel 12y agoI wouldn't say + in PHP is horrible. If anything, it's more sensible than other languages in that it does only addition, rather than trying to combine addition and concatenation (which is silly, because in a weakly-typed language having 5 + 5 and "5" + "5" work differently makes no sense).
- TazeTSchnitzel 12y agoPascal and Visual Basic do something similar for division.
- vog 12y agoAlso, Python3 has a separate operator, "1 / 2" versus "1 // 2", where "/" is always floating point and "//" is always integer. Python2 also has "1 // 2", but the "/" operator can be floating point as well as integer, depending on the inputs.