This is a quoted thread content F# and trends in functional programming in a discussion thread model, please follow my thread (my id on Kaskus is “erilive”) on Kaskus! And it’s available in Bahasa Indonesia!
Hi guys,
If you want to know more about F# and trends in functional programming in a discussion thread model, please follow my thread (my id on Kaskus is “erilive”) on Kaskus! And it’s available in Bahasa Indonesia!
There’s a lot of discussion happens there! And I invite you to join, and I will invite you all of those are advanced or just beginner in functional programming and F#. Some topics are very interesting but quite advanced such as type classes, but there is an easy topic about why functional programming matters.
Here’s the address:
And paragraphs below are samples from the thread:
Monad sample
Quote:Original Posted By erilive on http://www.kaskus.co.id/show_post/000000000000000759711105/18/
Monad yang mana gan? Maybe monad, Identity monad, Reader monad, State monad?
Kalau Reader monad di F#, sudah ada yang bahas:
http://codebetter.com/matthewpodwysocki/2010/01/07/much-ado-about-monads-reader-edition/Dan sepertinya kalau diimplementasikan di bahasa selain F# (kecuali kalau di Haskell) sepertinya akan menjadi kurang elegan.
Monad disini bukan "Monad" di cabang matematika Category Theory.
Kalau memang banyak peminatnya, akan saya jelaskan Monad di thread ini, agan-agan :)
Notes in English: (as translated)
Which Monad? There are Maybe Monad, Identity Monad, state Monad.
Reader Monad sample in F# has been discussed in:
http://codebetter.com/matthewpodwysocki/2010/01/07/much-ado-about-monads-reader-edition/
And if it’s implemented in other language besides F# and Haskell, it’ll be less elegant.
Monad in this context is not direct equals to Monad in Category theory from Math discipline.
Quote:Original Posted By Syinn
silahkan aja kalo mau langsung bahas monad, saya nyimak dulu ...kalo ada yang kurang ngerti , akan saya tanyakan pada anda
ada baiknya bahas yang awal dulu, yakni monad state
Dan sepertinya kalau diimplementasikan di bahasa selain F# (kecuali kalau di Haskell) sepertinya akan menjadi kurang elegan.
btw, saya ingin tahu kenapa om bisa berkesimpulan yang saya bold di atas ? bisa anda jelaskan secara tehnik dan detail?
karena soal keeleganan code pemrograman kan tergantung kreatifitas programmer itu sendiri, apapun bahasa program yang dia gunakan (ini kalo menurut saya lho, om )
Note in English:
He (Syinn) wanted to know about why I told him it’s less elegant.
And here’s my answer:
This is state monad in F# and sample code to use:
module StateMonad
let (>>=) x f =
(fun s0 ->
let a,s = x s0
f a s)
let returnS a = (fun s -> a, s)
type StateBuilder() =
member m.Bind(x, f) = x >>= f
member m.Return a = returnS a
let state = new StateBuilder()
let getState = (fun s -> s, s)
let setState s = (fun _ -> (),s)
let Execute m s = m s |> fst
Now, in C#: (taken from http://taumuon-jabuka.blogspot.com/2012/06/state-monad-in-c-and-f.html)
The Bind operator is implemented below:
As you shall see, it’s less elegant!
Why IO Monad is “EVIL”?
Syinn asked again! But the topic is about why IO Monad is “EVIL”:
Here’s my answer: (and apologize if it’s quite long)
There is a blog post that describe IO Monad is evil: http://kawagner.blogspot.com/2007/02/why-monads-are-evil.html
And I assume he (Syinn) quoting that blog post although he didn’t mention it.
My definite answer is: IO Monad isn’t evil. According to that post, because value evaluation when designing IO Monad became imperative, and therefore it would break referential integrity. But it’s not! Because the nature of Haskell is non strict (lazy), the timing of the execution is not so important and the reference is not broken.
A simple sample of this is when dealing with iterator of yield in C# (since VS 2005) and in VB.NET (since VB 11 in Visual Studio 2012).
Due to the fact that I/O is side effect, then declaring I/O must be explicit and has to be marked as signature to a part of the “world” that includes garbage collection.
Functional programming, especially the "pure" ones, forces us to be aware and be careful in handling side effect such as I/O, pointer, exceptions.
You will have it on my part 4, 5 of functional programming series! Watch for my next blog post entry!
