5 ms·

I've seen this before and it's terrible. Haskell's type system is terrible for this, ie. instead of plain vanilla operator overloading they have (^+^)... I once

by Maro 9y ago

I've seen this before and it's terrible. Haskell's type system is terrible for this, ie. instead of plain vanilla operator overloading they have (^+^)... I once played around with a way to automatically track units when writing code like this, and I gave up on Haskell, doing it in C++ was much easier/sane. https://github.com/mtrencseni/physcode https://github.com/mtrencseni/physcode

thepratt 9y ago
There isn't operator overloading as other languages have it, but you can write instances for your types. It seems you're just complaining about using vector addition operator (^+^) instead of a different addition operator (+); if it bothered you that much an instance would create a link defining + as ^+^.
- marcosdumay 9y ago
  > but you can write instances for your types Yes, as long as they have the structure your classes demand. It's not exactly Haskell's type system that is bad, it's the numeric classes that are a bit of a mess. Math has a much cleaner structure that, for example, does not demand that you can convert any integral value into an instance of your numbers. Haskell tried to simplify it, but wasn't successful.
KirinDave 9y ago
You say it's terrible to use an alternative operator but then don't really say why Why is that bad? In Haskell, + is reserved for Num, which require some other properties that you can't guarantee for vectors. It'd be pretty bad to run afoul of that in a physics conversation. Haskell certainly can let the + operator mean multiple things in multiple contexts.
runeks 9y ago
> Haskell's type system is terrible for this, ie. instead of plain vanilla operator overloading they have (^+^)... Haskell’s type system does not prevent you from overloading the + operator. It’s the standard library (“Prelude”) that defines + to only work on numbers, and not on vectors, but with Haskell’s type system allows you to define + to do anything you want.
- tome 9y ago
  Yes indeed. Not only is it possible to overload + but Haskell's type system has absolutely nothing to say on the matter.
  - Maro 9y ago
    Yes but if you want to use libs, and they don't do it this way, you're f--ked. This is one of the things I ran into.
    - dllthomas 9y ago
      Well, no, you're not "f--ked", there's just a pile of boilerplate. Not fun - and likely not worth it for the marginal benefit of being able to reuse + that way - but plenty possible. And for what it's worth, I certainly agree that the way Num is structured is a wart in Haskell, and I think the previous two commenters agree. It's just that we should be clear about where the blame lies - and that's not the type system.
nickpeterson 9y ago
This might work well in F#. It has the ability to use most basic mathematical operators with different numerical types, so it cuts down on the multiple symbols Haskell and ocaml get forced into, and has native units of measure functionality baked into the language.
- professor_plum 9y ago
  F# also handles physical units in a really nice way.
  - sitkack 9y ago
    See, "F# For Scientists"
jason-johnson 9y ago
Actually the issue you're complaining about is not a Haskell problem, it's entirely a library problem. It so happens that the standard library has a really poorly defined numeric hierarchy at the moment. If you want to fix it right now, you can avoid importing the prelude and import a different numeric library which has more sensible definitions for everything. The issue is that for most things you'd want (+) to be defined like: (+) :: a -> a -> a But actually, to be more flexible it could be defined as: (+) :: a -> b -> a So then all the normal stuff would supported, as now, but you could also support things like: instance BetterNum DateTime where (+) :: DateTime -> Duration -> DateTime And so on.

by Maro 9y ago

thepratt 9y ago

There isn't operator overloading as other languages have it, but you can write instances for your types. It seems you're just complaining about using vector addition operator (^+^) instead of a different addition operator (+); if it bothered you that much an instance would create a link defining + as ^+^.

marcosdumay 9y ago
> but you can write instances for your types Yes, as long as they have the structure your classes demand. It's not exactly Haskell's type system that is bad, it's the numeric classes that are a bit of a mess. Math has a much cleaner structure that, for example, does not demand that you can convert any integral value into an instance of your numbers. Haskell tried to simplify it, but wasn't successful.

KirinDave 9y ago

You say it's terrible to use an alternative operator but then don't really say why Why is that bad? In Haskell, + is reserved for Num, which require some other properties that you can't guarantee for vectors. It'd be pretty bad to run afoul of that in a physics conversation. Haskell certainly can let the + operator mean multiple things in multiple contexts.

runeks 9y ago

> Haskell's type system is terrible for this, ie. instead of plain vanilla operator overloading they have (^+^)... Haskell’s type system does not prevent you from overloading the + operator. It’s the standard library (“Prelude”) that defines + to only work on numbers, and not on vectors, but with Haskell’s type system allows you to define + to do anything you want.

tome 9y ago
Yes indeed. Not only is it possible to overload + but Haskell's type system has absolutely nothing to say on the matter.
- Maro 9y ago
  Yes but if you want to use libs, and they don't do it this way, you're f--ked. This is one of the things I ran into.
  - dllthomas 9y ago
    Well, no, you're not "f--ked", there's just a pile of boilerplate. Not fun - and likely not worth it for the marginal benefit of being able to reuse + that way - but plenty possible. And for what it's worth, I certainly agree that the way Num is structured is a wart in Haskell, and I think the previous two commenters agree. It's just that we should be clear about where the blame lies - and that's not the type system.

nickpeterson 9y ago

This might work well in F#. It has the ability to use most basic mathematical operators with different numerical types, so it cuts down on the multiple symbols Haskell and ocaml get forced into, and has native units of measure functionality baked into the language.

professor_plum 9y ago
F# also handles physical units in a really nice way.
- sitkack 9y ago
  See, "F# For Scientists"

jason-johnson 9y ago

Actually the issue you're complaining about is not a Haskell problem, it's entirely a library problem. It so happens that the standard library has a really poorly defined numeric hierarchy at the moment. If you want to fix it right now, you can avoid importing the prelude and import a different numeric library which has more sensible definitions for everything. The issue is that for most things you'd want (+) to be defined like: (+) :: a -> a -> a But actually, to be more flexible it could be defined as: (+) :: a -> b -> a So then all the normal stuff would supported, as now, but you could also support things like: instance BetterNum DateTime where (+) :: DateTime -> Duration -> DateTime And so on.