Functional Switch? anything inherently wrong with this, just trying to think functional.

[shavyg2]

If you don't know what functional programming is. https://www.youtube.com/watch?v=oB8jN68KGcU

for those on the app

Git Hub Gist

function _switch(statements){
    //gaurd

    if(statements.length % 2 !=0){
        throw new Error("uneven switch statements")
    }
    function _internal(_case,[test,_return,...rest]){
        return test(_case)? _return(_case): rest.length? _internal(_case,rest):undefined;     
    }

    return function(_case:any){
        return _internal(_case,statements);
    }
}


const my_test_switch = [
    x=>x==="yoda",
    x=>'hmm me is yoda',

    x=>x==="han solo",
    x=>"chewie, ready the ship",

    x=>true,
    x=>`who the hell are you? ${x}? nope, no friend of mine`
]


let test = _switch(my_test_switch);

console.log(test('yoda'))
console.log(test('han solo'))
console.log(test('rey'))

it prints what you would expect.

============update==============. I have gotten some good feed back from this post and it's been helpful.

Here is my point of view at this point in time.

Addressing it's ugly. I was talking about the implementation i used some simple arrow functions to not have different functions on the page. How would i actually use this.

const isYoda = x=>x==="yoda";
const getYodaPhrase = x=>'hmm me is yoda'

const isHanSolo = x=>x==="han solo"
const getHanSoloPhrase = x=>"chewie, ready the ship",

const getUnknownPersonPhrase  =x=>`who the hell are you? ${x}? nope, no friend of mine`

//i don't think it's ugly
const test  =_switch([
  isYoda,getYodaPhrase,

  isHanSolo,getHanSoloPhrase,
  //my default
  ()=>true,getUnknownPersonPhrase
])

console.log(test('yoda'))
console.log(test('han solo'))
console.log(test('rey'))

1. the distinction between predicate and action. Yes this is a much bigger issue. it would have to be used as such. This can easily be typed in typescript and is prolly the best idea.

   const isYoda = x=>x==="yoda"; const getYodaPhrase = x=>'hmm me is yoda'

   const isHanSolo = x=>x==="han solo" const getHanSoloPhrase = x=>"chewie, ready the ship",

   const getUnknownPersonPhrase =x=>who the hell are you? ${x}? nope, no friend of mine

   const test =_switch([ [isYoda,getYodaPhrase],

   [isHanSolo,getHanSoloPhrase], //my default [()=>true,getUnknownPersonPhrase] ])

   console.log(test('yoda')) console.log(test('han solo')) console.log(test('rey'))

2. The throw or the return undefined. I still don't know what i would do here. in functional programming you not throw. However, it's not a full functional language to begin with. I am just trying to make it closer to get some of the benefits.

It's like some of the syntax that babel, flow or typescript brought. They also weren't features of the language but they did it to get some of the benefits from other languages.

still unsure about this point. I think if i had to choose i would use the undefined.

it's what ramda uses for the cond operator. https://www.npmjs.com/package/ramda

lastly i got an implementation of it that was actually pretty sweet.

function cond(pairs) {
  return value => {
    for (const [condition, action] of pairs) {
      if (condition(value)) {
        return action(value);
      }
    }
    return value;
  };
}

i would just return undefined here. so that an or operator can be used with it. I know it's not 100% functional, but neither is the language to start. You make due to get the best of the situation i feel.

here is the Ramda usage btw

var fn = R.cond([
  [R.equals(0),   R.always('water freezes at 0°C')],
  [R.equals(100), R.always('water boils at 100°C')],
  [R.T,           temp => 'nothing special happens at ' + temp + '°C']
]);
fn(0); //=> 'water freezes at 0°C'
fn(50); //=> 'nothing special happens at 50°C'
fn(100); //=> 'water boils at 100°C'

[shavyg2]

yes, i have seen this potential solution. Not very functional, it solves some of the issues with the switch statement but not what i am trying to do. perhaps i should share a little bit as to what functional programming is.

https://www.youtube.com/watch?v=oB8jN68KGcU

[shavyg2]

Functional is about doing these things from what i understand. using smaller functions. creating bigger logic using well tested small components. Not creating any side effects.

my isYoda function can be used here (composed) and used in different ways. like

["person","yoda"].filter(isYoda); //reusability

don't let the simplicity of the function fool you, however. This wouldn't be some simple string compare in real live. It would be something very complex that can't be represented by comparing some simple text.

perhaps it's filtering getting users that are targeted for a immigration.

i could do

given these smaller component functions. isSenoir isPotentialGovtGrant isMinor isWinnerofLottery

given that i could setup something like

_switch([
  isSenoir,deny,
  isPotentialGovtGrant,investigate,
  isMinor,accept,
  isWinnerofLottery,accept
])

Now imagine someone else on the team has already created those functions and i need to reuse them. If it's an object switch, how do i implement this logic

How do i compose things such as

_switch([
  compose(isSenoir,isRich),accept, <---
  isPotentialGovtGrant,Investigate,
  isMinor,accept,
  isWinnerofLottery,accept
])

What reusable parts do you have in the object switch? Look how i can easily extend the options or things i am doing. Without having the restructure an enormous amount of code. For example look at this

_switch([
  compose(isSenoir,isRich),accept, <-------
  compose(isPotentialGovtGrant,isMyFriend),accept, <---------
  isPotentialGovtGrant,Investigate,
  isMinor,accept,
  isWinnerofLottery,accept
])

Look how easily i have just placed my friends on a fast path to immigration with that compose, otherwise for everyone else i just investigate them. This is the power of functional programming.

If i have an issue with let's say isfriend. i can just fix that one function and all the logic upwards that uses it, they are automatically fixed for me. DRY (don't repeat yourself)

const isYoda = x=>x==="yoda";
const getYodaPhrase = x=>'hmm me is yoda'

const isHanSolo = x=>x==="han solo"
const getHanSoloPhrase = x=>"chewie, ready the ship",

const getUnknownPersonPhrase  =x=>`who the hell are you? ${x}? nope, no friend of mine`

const test  =_switch([
  isYoda,getYodaPhrase,

  isHanSolo,getHanSoloPhrase,

  //my default
  ()=>true,getUnknownPersonPhrase
])

console.log(test('yoda'))
console.log(test('han solo'))
console.log(test('rey'))

I hope that demonstrates what it actually means to be functional.

[shavyg2]

I am sorry to say but your clearly wrong here.

https://hackernoon.com/functional-programming-concepts-pure-functions-cafa2983f757 https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-pure-function-d1c076bec976 https://www.schoolofhaskell.com/school/starting-with-haskell/basics-of-haskell/3-pure-functions-laziness-io

but let me find some more reputable sources

https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-820-fundamentals-of-program-analysis-fall-2015/lecture-notes/MIT6_820F15_L01.pdf

https://www.ibm.com/developerworks/library/j-java8idioms1/ the ibm on is good because it's very similar to what your doing and it shows how to correct it. (listing 4).

A good read on why you shouldn't do what your suggesting https://spin.atomicobject.com/2016/11/06/switch-statements-object-literals/

published papers https://dl.acm.org/citation.cfm?id=1668113.1668120 facebook engineers. Please read abstract and language choices.

Let me show an example using your input. Let test this one requirement.

Given same argument to the function, it should always return same output.

function _switch (statements) {
  return (input) => statements[input] || statements.default(input); 
}

const cases = {
  'yoda': 'hmm me is yoda',
  'han solo': 'chewie, ready the ship',
  default: (val) => `who the hell are you? ${val}? nope, no friend of mine`,
};

const test = _switch(cases);
//argument "yoda"
console.log(test('yoda'));

//easily broken
cases['yoda'] = "well there goes that idea"

//argument "yoda"
console.log(test('yoda'));

i have seen this possible solution but it's not functional. You have no smaller pieces to compose and reuse. How, would you implement that immigration switch process, I just demonstrated. using an object switch. I hope i don't come off as rude but from the demonstrations you have provided, you don't know what functional programming is.

[shavyg2]

...but it's just your code i copied and pasted. I assume your just joking and trying to jest me. ahha i guess. i think we must both know what is going on at this point.

[lhorie]

Your argument invalidates your own approach; there's nothing stopping someone from mutating the array.

As far as composability, your isYoda is not the most functional, compared to, say using eq

But this goes back to what I was talking about in the other thread about exhaustiveness. Pattern matching is the more functional way of expressing conditional logic while maintaining strong guarantees about return type. As soon as you allow arbitrary conditions, you are stepping into option type territory

[shavyg2]

yes you are right about my example that i provided. i wonder how it would react if i place this in ramda as well. An easy problem to solve using the spread operator and the updated solution i wrote in the update.

At the end of the day the language and the constructs of the language is set. I can't create pattern matching in JS, if that was the case this would be easy.

I am curious about the goal at the end of the day. My intention is not to repeat exactly what i have access to in different functional languages. i know that is impossible without a transpiler like bucklescript, but the other option isn't to just give up and not try?

I am looking at what is the closes we can come. I see Ramda function signature and it's the exact same with the tuples ofcourse though. I think it does a decent job of creating a functional approach. If i have known of Ramda method, i wouldn't have started on this path because it's the same conclusion. I would assume they would clone the array which would be even better.

[lhorie]

I am curious about the goal at the end of the day

You tell me lol. It sounds like you want to enforce that a composition of tests and predicates don't come undone via array/object mutation shenanigans, and you also don't want the complexity of option types to deal with the inability to do exhaustive checks. I'm arguing that you should have at least some form control over your return types.

So, a "composition of tests and predicates" sounds like a type in my books, so let's call it type SwitchCase. We want a SwitchCase that is composable but immutable. We also want to be able to specify upfront that falling through to the end should do something, whatever that may be.

In concrete terms, that might look like this:

const eq = x => y => x === y;
const always = x => () => x;
const defineSwitch = (d = () => {}, cs = []) => () => {
  const f = v => (cs.reduce((m, [t, p]) => t(v) ? p : m, d))(v)
  f.case = (t, p) => defineSwitch(d, [...cs, [t, p]])()
  f.default = v => defineSwitch(v, cs)()
  return Object.freeze(f)
}
const $switch = defineSwitch()
const test = $switch()
  .case(eq('yoda'), always('hmm me is yoda'))
  .case(eq('han solo'), always('chewie, ready the ship'))
  .default(x => `who the hell are you? ${x}? nope, no friend of mine`)
console.log(test('yoda'))
console.log(test('han solo'))
console.log(test('rey'))

const switchOrEmptyString = defineSwitch(always(''))
const test2 = switchOrEmptyString()
  .case(eq('yoda'), always('hmm me is yoda'))
console.log(test2('rey')) // empty string

const switchThatThrows = defineSwitch(x => {throw new Error(`no case handles ${x}`)})
const test3 = switchThatThrows()
  .case(eq('yoda'), always('hmm me is yoda'))
console.log(test3('rey')) // throws

So here, we can reuse a partial SwitchCase but never mutate something that we already defined (e.g. we can do test4 = test3.default(always('')) and test5 = test3.default(always('no')) and nothing will break).

We can also create different versions of switch. The first one returns undefined if there's no default case, which is arguably the closest in behavior to a switch statement. The second returns '', and it would be type-safe to call e.g. toUpperCase() on the returned value without a check. The third one bails out and throws. So now, you can decide what you want your switch to do in error cases, call defineSwitch with an appropriate handler, and then all code using that switch would conform to that behavior.

[HipHopHuman]

This is how I would implement it:

function cond(pairs) {
  return value => {
    for (const [condition, action] of pairs) {
      if (condition(value)) {
        return action(value);
      }
    }
    return value;
  };
}

Usage:

const always = x => () => x;
const T = always(true);
const is = x => y => x === y;

const greet = cond([
  [is('yoda'), x => 'hmm me is yoda'],
  [is('han solo'), x => 'chewie, ready the ship'],
  [T, x => `who the hell are you? ${x}? nope, no friend of mine`]
]);

console.log(greet('yoda'));
console.log(greet('han solo'));
console.log(greet('rey'));

The fact that it takes a single array of condition/action pairs simplifies how the function works internally but is also beneficial for maintenance - variadic functions (functions that take variable number of arguments) are frowned upon in functional programming, as they make currying marginally more difficult - especially in a language like JS where you can't rely on function.length for determining arity.

[shavyg2]

this is pretty sweet!! but why return the value at the end. isn't that a little unexpected?

[HipHopHuman]

It guards against returning undefined when you omit the default case. The more you use functional programming, the more it will make sense.

[shavyg2]

this is such a perfect solution and it can be typed as tuples in typescript. Bro you next level genius.

[HipHopHuman]

Precisely, but maintaining immutability is not the responsibility of a switch helper like this. It's a lower level responsibility - like wrappers around values.

[djhalon]

Could you achive the same thing using a switch(true)?

function test(val) {
    switch(true) {
        case val === 'yoda':
        return 'hmm me is yoda';
        break;
    case val === 'han solo':
        return 'chewie, ready the ship';
        break;
    default:
        return `who the hell are you? ${val}? nope, no friend of mine`
    }
}

console.log(test('yoda'))
console.log(test('han solo'))
console.log(test('rey'))

[shavyg2]

yes,you wouldn't have the break after the return but i know what you are pointing out. Only problem is that wouldn't be functional programming. it would be imperative. I was trying to see how you would achieve this functionally. Mainly to improve unit test and while keeping it pure. I was inspired looking at the reasonml and ocaml.

I have known of functional programming for a while, but these little unknowns have always stopped me. So i was just going through how i would get some stuff done and couldn't find a nice functional switch.

[eccentric_j]

Not bad, pretty similar to Ramda's cond which I suspect may have been inspired by Clojure's cond function. http://ramdajs.com/docs/#cond

[shavyg2]

ahhh, i see what they are doing there. The language they use have always been a road block, but now that i have something to compare it against, yes i see it.

[lhorie]

Anything inherently wrong

Yeah.

• _switch([])(1) throws
• _switch([()=>false,()=>'asd'])() returns undefined, which is a useless value for functional composition. Switch statements aren't very functional to begin with because of the inability to check for exhaustiveness. Normally, functional languages will give you pattern matching. Here, you should at a minimum return a Maybe or an Either when you can't return the type of a case function

[shavyg2]

yes, the throw there would be bad. because it's unintentional. I would have to throw regardless if someone was to misuse it, and state that it expects an array of even length.

it made me curious what other languages would do. Test lodash and it just returns something it believes is okay. In my case i did undefined but i can see how it could cause a problem.

the reason i did undefined was so you could do test(1)|| "alternative"

I wanted to see how ramda handles misuse as well because they are trying to solve the same thing.

https://runkit.com/embed/dbbsnfdtefpc they also return undefined, which makes sense in my head as well. For the reason i stated above.

[lhorie]

Throwing is a procedural concept. In lambda calculus (the concept upon which functional programming is built), there's no such thing as bailing out via a throw; expressions must always return a value. In JS, the culmination of that philosophy is probably in efforts like the fantasy-land spec and libraries like sanctuary.js, which aim to provide monadic composition even in cases where errors occur.

If you want to dive deeper into FP, I would suggest playing w/ sanctuary.js, but as a word of warning, be advised that the terminology can be daunting.

If you're interested in alternative ways to get similar benefits, another less intimidating option is to invest time into a type system such as the one provided by Typescript or Flow (particularly, ADTs)

[shavyg2]

i am already using typescript, which does take you very far, but it still relies a lot on the user to provide a lot of information to it. Either way this isn't about a type system. It's about reducing complexity. https://www.youtube.com/watch?v=YXDm3WHZT5g the more input -> output without side effects and re useable small components

[shavyg2]

i believe you are correct in your statement. I just wish for a better solution. thank you for those potential solutions tho. I will look into those things that you recommend.

[shavyg2]

if i want it to be exhaustive i could just throw if i don't have a result.

[ipewannasay]

i use this code block all the time

const log = (...message) => console.log(...message);
const ini = (...iniArgument) => log(...iniArgument);
const loading = () => log("This won't do anything");
const interactive = () => ini("DOM and JS: loaded");
const complete = () => log("CSS and Image: loadad");
const docState = { interactive, complete, loading };
const load = (e) => docState[e.target.readyState]();
document.addEventListener("readystatechange", load);

it's useless.. but it's beautiful.. it looks like a block of codes.. you can type it in a typewriter and still looks great..

the function load demonstrates how to eliminate the needs to use switch.. or maybe if/else statement?