Destroy All Ifs – A Perspective from Functional Programming

Post by buffyoda » Sun, Jul 17, 2016, 2:52 AM UTC

greggman wrote: post #84

buffyoda wrote: post #44

Earlier quoted context omitted.

A church encoded boolean is precisely isomorphic to every language's standard booleans (modulo strictness, perhaps) and doesn't offer any benefits; you're still forking the program based on the information content of a single bit. Let's take the following function invocation, which can be expressed with Boolean literals or Church encoded booleans, I don't care: match true false If you want to determine the significan…

since I'm not a fp expert what about a function like ctx.arc(10, 20, 30, 0, 6.28, false); There's nothing special about boolean. How do you encode all of those above into types in fp so that it's impossible to get them wrong and so they're self documenting? I hope you're not suggesting there be a horizontalFloat type and a verticalFloat type or are you?

Post by buffyoda » Sun, Jul 17, 2016, 2:54 AM UTC

GregBuchholz wrote: post #86

greggman wrote: post #84

Earlier quoted context omitted.

since I'm not a fp expert what about a function like ctx.arc(10, 20, 30, 0, 6.28, false); There's nothing special about boolean. How do you encode all of those above into types in fp so that it's impossible to get them wrong and so they're self documenting? I hope you're not suggesting there be a horizontalFloat type and a verticalFloat type or are you?

How about keyword parameters... ctx.arc(center=Point(10,20), radius=30, beginAngle=0, endAngle=6.28, Clockwise); ...and don't forget about units of measurement/dimensional analysis. https://stackoverflow.com/questions/107243/are-units-of-meas... ctx.arc(center=Point(10cm,20cm), radius=30mm, beginAngle=0rad, endAngle=6.28rad, Clockwise);

Post by buffyoda » Sun, Jul 17, 2016, 2:56 AM UTC

TwoBit wrote: post #88

buffyoda wrote: post #45

Earlier quoted context omitted.

Indeed, that's the whole point of inversion of control, is pulling the control out of the caller and into the callee. That's the primary reasoning benefit of functional programming.

I see no benefit to that. It makes more work for the caller. I want that function to do something for me and I want the leadt amount of unnecessary work on my side. Just like a good boss who delegates.

Post by timmytokyo » Sun, Jul 17, 2016, 3:04 AM UTC

twblalock wrote: post #67

true_religion wrote: post #20

This is the starter code: publish :: Bool -> IO () publish isDryRun = if isDryRun then do _ This would be nicer if you could do multiple functions with pattern matching. In Elixir this would be: @spec publish(boolean) :: any def publish(true = _isDryRun) do _ = unsafePreparePackage dryRunOptions IO.puts "Dry run completed, no errors." end def publish(false = _isDryRun) do pkg = unsafePreparePackage defaultPublishOpti…

Pattern matching is just as explicit as an if loop. In languages that implement it for null values, it is just as explicit as typing "if (foo == null)" in an imperative language. You have to think about it, and type just as much code to deal with it, as you would in a language without pattern matching. The only upside to pattern matching that I can see is that you are forced by the compiler to match all possible inpu…

Post by meshko » Sun, Jul 17, 2016, 3:14 AM UTC

barrkel wrote: post #5

Define true as a lambda taking two lazy values that returns the first, and false as one that returns the second, and you can turn all booleans into lambdas with no increase in code clarity. The straw man in the post - talking about a case-sensitive matcher that selectively called one of two different functions based on a boolean - is indeed trivially converted into calling a single function passed as an argument, but…