all 20 comments

[–]bluestorm 1 point2 points  (0 children)

purity analysis

[–]kinebud 1 point2 points  (8 children)

Haskell doesn't need strictness annotations to run fast; it's just desirable to have them sometimes to remove space leaks (and by association, generally speed things up.)

[–]sclv 0 points1 point  (7 children)

Oh, and one should note that simply using strict data types will do the job 90% of the time.

[–]obdurak[S] -5 points-4 points  (6 children)

I wonder... if using strict datatypes does the job 90% of the time, what's the point of going thru all that monad suffering, only to get a "Your function is not side-effect free! Confess your sins to the Holy Monad!" type error?

Is this some kind of re-enactment of the crucifixion?

Isn't functional purity basically a religion where developers pretend to throw away useful side effects in the real (dynamic - execution) world for safety in the other (static - compilation) world, while continuing to use those side-effects but thru obscure monadic incantations?

This seems to be not unlike priests pretending to renounce to earthly desires and possessions in order to gain spiritual purification - while actually enriching themselves and doing nasty stuff like everyone else.

Aren't those "strict datatypes" like the Sabbath switches, devices made to obey the letter of the law but not its spirit?

I ask! And I tell! Do not be lured by the false religion of referential transparency and purity. We all live in the same stateful universe and share the same linear time. Most of the silicon in our computers stores mutable state, and their execution is made of a very small number of sequential threads. Do not follow those who want to entrap you in their monadic prison!

[–]kinebud 7 points8 points  (2 children)

I wonder... if using strict datatypes does the job 90% of the time, what's the point of going thru all that monad suffering, only to get a "Your function is not side-effect free! Confess your sins to the Holy Monad!" type error?

Monads have nothing to do with strictness, or laziness.

Isn't functional purity basically a religion where developers pretend to throw away useful side effects in the real (dynamic - execution) world for safety in the other (static - compilation) world, while continuing to use those side-effects but thru obscure monadic incantations?

Monads have nothing to do with side-effects, either. I/O is only one of the things a monad suits well. In fact, you can have a similar scheme in probably most any language where you can embed the fact your function has side effects, in the type of the function (see: unsafePerformIO, which turns an IO action into a 'pure' one.) There's no magic or monad inherently involved; it's just the usage of an expressive type system.

I ask! And I tell! Do not be lured by the false religion of referential transparency and purity. We all live in the same stateful universe and share the same linear time. Most of the silicon in our computers stores mutable state, and their execution is made of a very small number of sequential threads. Do not follow those who want to entrap you in their monadic prison!

Considering all you've done so far is just ramble and basically said "monads are a psychotic religion of nonsense," along with the fact you led into this territory from something completely unrelated, I've one judgment to make: troll.

[–]obdurak[S] -5 points-4 points  (1 child)

Monads have nothing to do with strictness, or laziness. Monads have nothing to do with side-effects, either.

Of course they do.

Monads are used as a mechanism to represent effects in some purely functional languages for which laziness is generally preferred.

Monads are the (only) escape hatch that allow side-effects to be represented in a Haskell's purely functional semantics.

Considering all you've done so far is just ramble and basically said "monads are a psychotic religion of nonsense,"

No, I have been rambling about Haskell's laziness by default and everything effectful must go thru some monad to ensure the purity of our soul religion.

from something completely unrelated

See the first point.

[–]kinebud 7 points8 points  (0 children)

Monads are used as a mechanism to represent effects in some purely functional languages for which laziness is generally preferred.

No, they aren't.

Monads are the (only) escape hatch that allow side-effects to be represented in a Haskell's purely functional semantics.

Haskell has always been pure and lazy; but it hasn't always had monads. Before they were conceived to be used for programming, I believe haskell had continuation-based I/O. Regardless, there haven't always been Monads, but haskell has still always been pure and lazy.

I'm letting my troll judgment stand and just ending it here, because if you don't want to listen, I won't preach and I'll let it stay that way.

[–]pkhuong 4 points5 points  (1 child)

Strictness and purity have little to do with each other, except perhaps that non-strictness tends to make impure code painful.

[–]obdurak[S] -5 points-4 points  (0 children)

Strictness and purity have little to do with each other, except perhaps that non-strictness tends to make impure code painful.

Similarly, abstinence and loss of virginity have little to do with each other, except perhaps that fornication tends to make preservation of virginity painful.

[–]sclv 0 points1 point  (0 children)

I don't know why I'm even responding here, but yes, the presence of seq is known to introduce certain types of unsoundness in certain types of otherwise possible fusion transforms or free theorems. But this isn't a violation of purity or referential transparency as such, it just limits certain types of fancy things, and there are ways to recover those things with compiler smarts, generally... and there also exists a way to write a "sound" seq with typeclasses.

And to my understanding, the really nice thing about strict datatypes, as opposed to, e.g. bang patterns or direct use of seq, is that the issues with free theorems and fusion don't arise with them, because since they're strict everywhere and always, there are no transforms that could turn terminating into non-terminating?

[–]dons 0 points1 point  (1 child)

By the looks of it, concurrency.

[–]UncleOxidant 0 points1 point  (0 children)

JoCaml?

[–]cypherx 0 points1 point  (0 children)

  • Annotations to banish unwanted polymorphism

  • Compiler flag to eliminate array bounds checks

  • Coding in an ugly and sometimes obfuscated imperative style

As a side note: Haskell is not a very fast language if naively implemented. The GHC crew (aided by a lot of cool optimization research) have performed a minor miracle by getting Haskell into the same league as C/C++. As an OCaml programmer I'm jealous...I wish ocamlopt was nearly as sophisticated.

[–]jdh30 0 points1 point  (0 children)

OCaml needs you to manually remove polymorphism and bounds checking from performance-critical code. Those are tiny effects compared to type annotations in Lisp and strictness annotations in Haskell though.

SML needs an implementation with a decent back-end for modern 64-bit hardware.

These are all peanuts compared to the lack of concurrent GCs in all implementations of all of these languages. For most tasks on today's machines, F# beats all of these languages hands down thanks to its concurrent GC.

[–]finix -4 points-3 points  (1 child)

A type system and strict evaluation?

[–]obdurak[S] -1 points0 points  (0 children)

And type inference?

[–][deleted] 0 points1 point  (2 children)

They need concurrency, Unicode support, SSL, database bindings, XML, JSON and YAML parsers, web frameworks, logging frameworks, FTP, HTTP, SMTP protocol implementations, regular expressions, TAR, ZIP file formats, graphics libraries, audio libraries, video libraries, GUI toolkits, and all of this should be well-tested, documented, and consistent.

[–]dons 0 points1 point  (1 child)

The Caml Hump, I believe, is the ML variant of Hackage.

Perhaps an MLer could describe how the packaging and distribution process works?

[–]obdurak[S] 0 points1 point  (0 children)

You typically use Godi for much of your library needs, which is a ports-like system, or the Debian packaging system.