4 ms·
> With all due respect, that's just bullshit. First of all because there is no such thing as "true referential transparency", second because most techniques tha
by mietek 14y ago
> With all due respect, that's just bullshit. First of all because there is no such thing as "true referential transparency", second because most techniques that are available in Haskell for dealing with side-effects are also available in Scala.
A referentially transparent expression is guaranteed not to have side effects. A Haskell function which doesn't advertise in its type that it may have side effects, by being in the IO monad, can be trusted to be referentially transparent. This cannot be said about OCaml or Scala functions.
- dxbydt 14y agoPardon me...are you saying you want something in the type signature of a scala function that guarantees said function will not do input output to files sockets etc...and does not make a call to random number generators and does not modify global vars...so basically all it does is operate solely on params passed to it...absolutely no side effects...is that what you are asking for? That would be awesome from a testability standpoint...
- mietek 14y agoYes! This is exactly what you get in Haskell, and it is awesome for a number of reasons. Check this out: http://learnyouahaskell.com/input-and-output#hello-world http://learnyouahaskell.com/input-and-output#hello-world
- dxbydt 14y agoYeah I know exactly what you mean in Haskell. Its just that in scala given the java inter-op there are a whole hunch of escape hatches that will always be there. I remember in the coursera exercises when you submitted code that used mutable vars...it would flag your code and deduct points. So essentially even if someone provided a purefn annotation...to actually enforce that, the compiler would have to scan each function and disbar i/o, calls to rng, calls to global vars... tall order.